距离2016年过去两年，本文谈谈自己从加入A厂，经历了应用运维的统一，并目睹应用运维变革至今的一些总结。关于技术上的一些总结可以参考 --- 我们离Google SRE还有多远？
在A厂应用运维的简称是PE，每年离双十一系统最近的一批人。从2010年原本分散的BU运维组织聚合到一起组成一个统一的应用运维部门。到了2016年，这一年是应用运维变革的元年，一是外部，Google SRE一书中文版的发行，引起了一股潮流，业内的运维团队纷纷脱掉了运维的外衣，穿上SRE的马甲。二是内部，按照当时组织架构的调整，PE大部从原本组织架构剥离，人员拆分到各个业务研发线。至少从2016年开始，应用运维无论从名称上或是组织上都像走到了生命的终结点。
作为曾经大PE团队的一员，也经历过组织架构变动的不适应。但相比其他团队，幸运的是我所在的团队 --- 大数据PE团队至今在A厂仍独立存在。2016年调整之后仍然保持不变，和研发团队不同属一个事业部，一年后，2017年归属到大数据事业部，事业部内部我们和研发团队仍然保持独立。
我们有作为一个独立团队存在的归属感，这种归属感带来很强烈的凝聚力。在大数据业务爆发，集团、公有云、专有云三块数据战场同时开战，EB级的数据、千万个计算任务，公有云服务几万用户，在专有云快速搭建百套数据服务，并输出团队自主研发的运维管控平台。连我们的竞争对手都感叹我们用一个几十人的团队完成了他们上百人团队还未完成的事。
我们有组建一个数据时代的幸运感，和其他PE团队不同，大数据PE团队成立较晚，如果不是整个数据之初所有数据团队布局就是一个分布式的微服务架构，可能就不会提前感知到传统思维的局限性，如果不是强烈的自我变革的驱动力，就很可能被时代趋势被迫变革，那样的话错过的是本该属于我们的机会。
我们更有一种职业的使命感，虽然因为组织架构变化遭遇过“信仰危机”，一度不知道自己依然是PE还是SRE，但其实内心很清楚我们并不是纯粹的研发团队。我们想让更多人理解我们的价值，我们希望更多人能加入我们，一起抓住属于我们自己的机会。因此，是时候对过去变革中的喜怒哀乐做一个总结，并感谢公司给予的机会和团队给予我的帮助。
一、融入
2010年初，A厂实施数据战略，与之相应成立了业务产品研发、基础系统研发等相应的研发团队，大家朝着各自模块“服务化”的目标和组织方式开展起来，为什么要把服务化加上引号，因为服务化这三个字是一个具体的过程，并不是突然间就达到的终态。首先，各个模块服务之间相互隔离，互相不影响。初期非常典型的问题，就是一个作业把集群大部分机器内存撑爆，而导致集群所有服务都无法正常，虽然当下这类的问题已经比较罕见，但是随着服务模块的增加，隔离和互不影响是一直是整个系统演进优化的命题之一。其次，服务要可以单独发布，互不影响。一直以来都是有限定、有约束的单独发布，这个限定和约束的边界虽随着系统优化不断的被打破，可盲目乐观的理解单独发布，一定会陷入各种依赖问题和故障中。最后，模块服务的研发负责该模块所有事情。是的，在微服务还未兴起的时候，数据业务的组织架构就是研发负责所有工作，而那时作为运维团队，是如何随着系统演进融入到这个组织架里的呢？
① 技术架构能力上互补。在初期，和专注于业务产品和代码的研发相比，我们对硬件、系统、网络的技术能力是能够形成互补的。曾经不知道哪位研发Leader头脑一热，觉得自己的服务是分布式且冗余（或者说应该是冗余的），决定所有服务器统一硬件配置，结果导致存放集群元数据的Master单点运行在一台没有任何保护，普普通通SATA硬盘的服务器上，这对系统的稳定性的风险可想而知。而如果我们仅仅提醒研发团队应将单点改为多点冗余，然后就等着版本上线？这也不切实际，因为这可能需要很长的改造时间，而且可能在初期这都不是优先级最高的事情（往往业务功能初期优先级更高）。随着我们拿出一个短期可行的改造方案和研发团队讨论，通过HeartBeat+DRBD的方案，用成熟的主备方案缓解单点的问题，再采购硬件可冗余的服务器，减少服务器硬件带来的风险。虽然这不是根本的解决方案，比如会存在脑裂。但相别之前风险已经降低很多，短期内的警报可以解除。研发可以将有限的资源去满足业务初期其他更高优先级的需求以换的生存时间。半年后，上线三节点设计的Master彻底解决元数据冗余的风险问题。这样的Case在初期特别多，早期由于系统设计缺陷、业务的压力、人员紧缺的问题往往都是运维团队融入组织，赢得认可的绝佳机会。让研发做所有事情的初衷是好的，使研发人员为自己写的代码买单，这样就能考虑到软件长期可维护性。可这在实际情况中可能只是一厢情愿，或者需要付出惨痛的代价。在我看来，要做任何事就必须先具备与之匹配的能力和责任，否则拔苗助长反而会危害到所有人的长期利益。
② TroubleShooting的能力，所有问题的Owner。在初期，我们往往特别关注排障问题，因为一个很小问题都很容易引起多个研发团队相互扯皮。大家一会就没有了头绪。为什么会出现这样的情况呢？A厂在最初的一两年内发布了多款重量级的产品，如此快的节奏背后的就是多个服务的不同叠加组合。将分布式存储P+分布式调度F+协同服务N+通信服务K组成基础服务，再与计算服务D结合为集团、公有云客户提供数据存储、计算、算法等等服务。好处是，多个团队高效协同发布，抢占市场先机。可作为硬币的另外一面，灾难性的排障过程，每当类似作业运行变慢或者性能间歇性的问题时，过程尤为痛苦。通常需要从F团队叫人查到P团队，再查到N团队，一直查下去，一个电话会议里通常5-6个团队大家要么证明自己没问题，要么说明自己负责的领域不属于该问题，需要团队其他人来响应，大家你一言我一语，往往几个小时过去，却一点进展都没有。久而久之，我们在大小各种问题的处理中就变成了主导，我想这是因为作为一个全程参与所有问题的处理过程本身是学习任何系统的最快捷径，所以从全局的角度来看，我们可能变成最了解系统全貌的团队。其次，我们不负责任何模块，往往站在如何快速解决当下的问题，和之前大家忙于证明自己的模块是没有问题是有本质立场差别。最后，在解决问题的电话会议里思路清晰不犹豫，做决策和Call正确的人，这些能力都渐渐让其他团队都愿意配合，最终提高了大家的效率，否则一出问题大家都要上来Standby，自证清白也不能离开干自己的事情是效率非常低下的，在A厂数据业务产品演进过程中，一个核心模块往往被组合成好几个服务产品，要是每个产品出问题，该核心模块的人都要起来Standby，那么这个团队根本没有时间去做任何改进，可能查问题的人都不够。
③ 利用好全局观，上帝视角。我们常说自己拥有一个系统的上帝视角，由于在初期缺乏有效的管理，和标准化的执行力，加上业务的一路飞奔，出现过很多不识庐山真面目，只缘身在此山中的问题。曾经一个管理部署服务Y，服务D通过给集群的服务器打上相应角色的标签来判断需要启动那些服务，比如服务F、服务P等等，之前提到，一个计算服务D由服务F+P+N+K组成。不幸的是服务F实现过程中，又依赖部署服务Y的标签服务，这样导致了一个高可用性要求服务（D依赖的F）依赖一个低可用性要求的服务（Y仅在部署时需要）。这些看起来很简单的问题其实也是分布式系统架构的下的“副产品”，而我们正好通过上帝视角发现并解决很多这类问题。
回顾我们融入的过程，无论是我们还是研发其实就像渡过一个蜜月时期，大家为了产品业务交付给客户的最终价值而一起努力奋斗，并且结下了彼此间信任的果实。相反，如果一谈起运维，还停留在IT时代那种刻板印象，就未免就以偏概全，鸡同鸭讲了。包括我们在融入之初，自己就决定与IT运维的方式说再见，这是什么原因呢？首先，在IT时代，系统面临的吞吐量和延迟要求远不如今，系统环境相对简单且封闭。其次，软件的开发迭代周期可以很长，常年很少做新功能类的升级。而且也不必考虑软件扩展性，通常就是将业务按照地域、部门做切分，在地域、部门内部独立部署支持，业务流和数据流很少互通。那么应用的部署、扩容等场景相对要简单很多。还有，研发语言要求统一，并且各个模块耦合度高，运行稳定之后，就不太需要发生变化。为了保证这个稳定态不受变化，往往需要可靠的服务器（昂贵的小型机），冗余（小型机一台不够，双机热备，存储RAID做数据冗余），数据备份（磁带备份）。此外，IT时代运维团队将减少任何导致系统不可服务时间的工作（无论是人为疏忽还是发布）成为其最核心的KPI，为此如何建立的各种流程，让公司各个研发、测试和运维部门各司其职，高效协作是核心命题。而现如今互联网时代，特别是移动互联时代，如上所述的背景均已不复存在，例如，新的系统需要快速上线，上线后再根据用户需求不断发布更新迭代，升级非常频繁。在譬如，由于系统的耦合度降低，走向分布式，研发团队小规模化，“服务化”。一个业务产品由不同的子服务 — 服务A，需要服务B，服务C，服务D组合而成，这些服务可以由不同的语言，不同的架构独立研发并发布，但这样给服务A的部署和稳定性变的更加的复杂，和IT时代相比，在互联网时代下分布式，服务化架构的影响下，我们面临的问题更复杂，也更富有挑战。
二、变革
变革是渡过融入期之后，我们讨论思考最多的命题，这本身就是一个变革、日新月异的时代。任何团队或者组织的价值是都是交付客户价值的链，在这个竞争市场中，大家Share的是相同的价值目标，而不是Share相互之间的默契程度和对团队边界的墨守成规。所以再强调技术能力互补，TroubleShooting能力并不是我们的护城河，因为这些能力任何团队作为价值链的一员都会具备，而如果我们还再单纯谈成本优化、效率提升、配置管理而不关心团队能力是否处于价值链中就可能很快消亡。我们处于这个时代的趋势中既幸运又焦虑，幸运的是我们也可以做任何事，焦虑的是时不待我。那几年，我们常说如其让别人来变革我们，不如我们自己变革自己，从2013年起，我们内部达成变革共识，那么我们是如何行动的呢？
① 具备研发能力，首先改变招聘策略。因为我们不能要求当时团队的每个同学人人都具备代码能力，所以我们改变了招聘的方式，在面试中增加代码面试，以及邀请研发人员来交叉面试的环节。这是第一个阵痛期，并且很长时间招不到合适的人选，业务的压力还在蹭蹭的涨。其次，缺乏经验导致的“惯性恐惧”心里。这是第二个阵痛期，外部对我们有认知的惯性，即使看到我们的改变，也常常带有偏见，说我们就是野路子，不愿加入。内部同学对自身也没有信心，也是人对一个未知领域的本能反应。有些人跟我说，“我们是运维，不是研发，不专业啊！”现在回过头来看，经验的缺失并不是技术问题，而是心里问题，就像有个小人在你脑海里复现，告诫你不要离开舒适区，并且列举很多原因让你接受那是一个限制。而你要做的就是忽视和一笑而过。在A厂打响冲集群规模的技术攻坚战时，其中负责部署的模块已经无法承担更大集群规模的要求，在这种背景下我们接手并改造了此模块。从人员上，原本属于该模块的研发人员并未加入我们，我们短期内也未招到一个合适的人。靠原本团队内部的研发能力（一边白天处理线上问题，一边晚上码代码），最后不仅完成了既定目标，而且还将所有服务模块的部署时间减半。最后，渡过技术偏好的阶段，这是第三个阵痛期，当人员招聘的情况得到改善，内外部的环境逐渐打消了质疑，原本一个很小的服务模块也随着业务发展承载了越来越多的场景，我们也开始对服务做内部分层、子服务化的拆分，也开始建立CI/CD的流程，也开始治理发布之后一段时间没有使用的模块，慢慢大家对技术偏好的执着造成的摩擦越来越多，内耗不可避免的严重起来。
② 培养产品思维。具备产品思维的人是几乎不能招到，只能培养。因为A厂的产品技术环境太特殊，大部分产品都是自研为主。同时，我们在变革过程中也并非要求所有人必须向研发方向转型，对于那些常年在一线处理大小问题的关键同学来说，一个问题他就是比别人要早定位、早解决，那么强迫他去写代码，太浪费他的时间，更浪费团队的时间。相比研发能力，我们更希望培养他的产品思维。若没有产品思维的思考，这样的同学将永远陷入无尽的答疑和问题支持中，成长空间有限。其次，作为解决问题思考延续，产品思维可以很好锻炼从点到面的思考能力。有一款产品A，问题非常多，不稳定，人员换了一批又一批，反馈都是太乱，问题多等等，直到有一个人干的不亦乐乎，我曾问他，“是因为产品问题收敛了吗？”他说，“没有，但我认为虽然问题很多，但总逃不出那几类。”大道至简，殊途同归，让事半功倍。在很长一段时间，特别是与高可用、可运维相关时，我们就会被邀请参加研发团队的新功能设计评审会参与讨论。如果要在讨论中让他们快速理解痛点和初衷，那么平时就要反复思考，能从解决单个问题的思路转为产品设计的思维阐述。 最后，产品思维的另一个好处是培养个人主动性，Owner和服务意识，曾经一位同学加入团队之后有些不适应，他跟我说，“原来都是别人找我求助，为什么现在总要求我配合别人？”原本习惯了被动解决问题，现在需要了解更多的信息帮助主动思考，这种状态本身也契合团队变革的要求。
③ TPMs/技术运营。一开始，我们培养技术运营能力，认为技术运营目的就是让更多人认识并认同我们。但在实际过程中，具备这些运营沟通能力的人往往很适合在重大紧急项目中发挥粘合的作用，特别是当组织到了一定规模，需要协调考虑的团队太多的时候。一方面，他/她们参与项目的始终，对其他团队有非常好的沟通，他们的存在往往就是一个高效的流程机制。其次，他们往往对落地执行的进度毫不退让，有必要的诀窍解开团队之间的“死结”。最后，他们作为技术团队的意愿，有一定技术背景知识，在参与关键决策的过程中，建议不会被大家忽视。这样的角色和Facebook的Technical Program Managers不谋而合，所以我们一度将技术运营改称为TPMs。这一角色在A厂专有云输出，双十一业务，混部项目中发挥了不可替代的作用，是团队综合影响力的体现。
④ 新的团队管理能力。事实上，除了以上三点能力的转型，我们也鼓励人员向技术专精领域深入，特别是“老本行” — 系统、网络、硬件等方向。面对团队多样化的综合能力要求，必须要有与之匹配的管理模式，过去师傅带徒弟的方式已经不能满足团队转型过程中人员的培养。作为技术Leader，不仅有能力招到合适的人才，也要以身作则思考自己转型的方向，同时，对下属人员有清晰的定位，在经验上有能力提供指引，在不同能力定位上，需要具备开阔的眼界，能创造条件，让人员有空间的发展。
由价值链轮来决定一个团队的能力打破了各个团队墨守成规的边界，运维不在是过去的运维，研发也不在是研发。这种发展的趋势改变了架构组织形式，诞生的新的团队方式。2016年当集团发生组织架构调整，而我们继续保持独立那时起，我们明白，对我们来说，没有不变的职责，只有不变的团队，而不变的团队总将消亡，职责依然有人会继续承担，保持独立我们也并不代表传统，因为我们早已变革自己。
三、新的变革
终于整理到了尾声，但转型轨迹其实还未讲完。从2017年开始，渡过了一个短暂的调整期之后，变革的脚步并没有停下来。现在不管是AIOps还是ChatOps的称谓，我们都会有一种似是而非的感觉，但这也并不重要，永远不变的就是变化本身、接受变化的态度和付诸行动的决断力，期待新的挑战。
