2.1 如何介入组织

对于公司内老的产品线，运维需求往往会因为某些运维工程师的深入跟进，使整个运维小组内始终有几个人是某个产品线的专家级维护者。这样的角色在日常运维中起着非常重要的纽带作用，他们在团队转变为 SRE 团队前，提前做了很多SRE团队应该做的事情，可以认为他们是团队转变为SRE团队的先驱者。

在现实中，大家都在说要做自动化运维，要开发大量的自动化工具，但实际情况是公司的业务线会不断地变化，对接的运维工程师也在不断变化，在很多时候我们都会遇到运维工程师和支持产品轮转的情况。线上业务每时每刻都在演化，每天都有大量新的特性发布，产品的需求也变得越来越复杂，在整个过程中，虽然可以通过工单平台自动化执行业务日常的运维需求，但总会有一些专业的业务相关知识需要运维工程师理解后再人工执行。因为通过工单平台自动化执行的运维需求，很多时候是不满足业务多样化需求的，所以和大多数的工单处理系统一样，运维的工单系统中总会有日常工单。

运维工程师在很多时候是缺少和内部用户互动的，运维平台需要人工介入日常工单，这往往是运维工程师了解业务需求的一个窗口，运维工程师可以通过分析这些日常工单的内容，对业务的发展情况和需求有一个大致的了解。传统的运维理念是只要处理好工单和需求就好了，转变成SRE后，只是做到处理好工单和需求的程度是不够的，需要运维工程师去深入了解业务，主动地和用户沟通，帮助业务稳定运行。

例如，之前遇到过一个团队，他们习惯称线上A集群为线上集群，称线上B集群为测试集群，而在运维团队内部只认可CMDB系统中A集群和B集群的名称，这导致运维团队每次提需求的时候都需要反复确认集群信息。实际上这些工单需求95%以上都是可以自动执行的，只是因为他们的集群名称和运维规范（和内部其他团队的规范）不一样，所以所有的任务都需要额外增加人工复核。这种简单的问题，偶尔还会因为沟通失误而发生线上故障。

在传统的运维逻辑中，系统运维团队、数据库运维团队、应用运维团队一般都直接执行业务团队提过来的运维需求，最多退回让他们重新填写工单数据。在成立运维小组后，整个小组的成员都会定期沟通这样的情况：如果发现需要退回重新写工单数据这样的操作，小组成员就会发起专项的改进，通过梳理问题，逐一改进相关问题，改进整体的运维流程。

运维小组从单一的运维任务承担角色，转变为对线上系统稳定性负责的角色需要经过长时间的磨合。在总结多个业务团队的运维小组执行情况后，我们初步总结了和业务对接的方法和策略，初步对SRE概念进行了实践。

首先在我们内部，对接一个业务，主要分为以下几个步骤。

（1）运维需求沟通。

无论是新业务还是传统业务，对运维需求都是从线上业务运维操作需求开始的。在传统的运维模式下，运维工程师直接像客服一样坐在工单系统的后面，等待业务用户提需求，这种模式其实很被动，经常会丢失很多业务用户真实的运维需求信息。例如，当运维工程师看到业务用户提了一个服务器权限的申请需求时，在传统的运维模式下，运维工程师一般会直接执行这个需求。但这种操作其实是有问题的，业务用户可能只是要查一个线上问题才申请服务器权限的，而查线上问题的初始需求很多时候并没有在工单里进行描述。

在新的业务模式下，运维团队是直接和业务团队一起办公的。开发工程师和运维工程师坐在一起，运维工程师能第一时间收到所有的运维需求或业务调整，并且能够进行问题提炼。这种运作方式让运维团队能第一时间感知业务发展进度和技术变化，更好地理解业务的运维需求。

从传统的运维团队和业务团队沟通来看，运维团队很少主动地和业务团队沟通，而且往往是很久才进行一次沟通，沟通的时效性和深入度都不足。在新的运维小组模式中，运维团队的工作进度和业务团队的工作进度往往是绑定的。从整个业务层看，运维团队和业务团队的沟通加强了很多，有时候业务团队会主动邀请运维团队参与项目设计，帮助运维团队落地实施细节。

以前我们对业务需求的理解往往停留在业务需要什么样的监控和需要什么样的工具上。很多的业务需求只是运维工程师自己依据经验设计的。随着运维工程师对业务的深入，他们会发现不同的业务对运维需求有不同的侧重点。例如，有些业务可能只是要求技能培训支持，有些业务只是要求协助架构整合，有些业务则只是希望能整合运维能力到他们的业务流程。

对这些不同业务需求的深入分析，会让运维团队更好地安排人力和投入力度，更好地提炼需求，交付新的运维工具和平台。有效而又深入地和业务团队沟通，会让运维团队更好地了解业务团队的真实运维诉求，迅速定制运维策略，有针对性地跟进业务。当运维团队和业务团队能够进行有效的沟通后，业务的稳定性就有了一个良好的开端。很多时候业务团队对运维团队的第一印象也是来自于此。

（2）梳理业务的稳定性需求。

运维需求沟通完成后，运维团队会迎来真正的问题。运维团队会看到很多稳定性风险。过去运维工程师对业务稳定性风险的评估是基于运维团队的历史经验和运维团队成员的能力制定的。因为要依赖运维团队的经验和能力，所以整个团队里面不可避免地会有几个“明星”运维工程师。这些“明星”运维工程师是运维团队宝贵的财富，但“明星”运维工程师是有限的，业务却是无限的。如果业务的稳定性只依赖运维团队的经验和能力，部分业务的稳定性就会因为运维团队的能力和经验而发生变化。

转变为 SRE 后，SRE 团队将梳理业务稳定性的需求列为工作的第二个重点。SRE团队的SLI/SLO/SLA理念顺理成章地开始了落地。

通常在对业务运维需求和业务架构有了初步的认识后，SRE 团队就开始着手定制针对业务的稳定性保障策略。从架构和设计层出发推动团队成员落地各个组件的SLI，进而让开发团队制定SLO，这个步骤其实很关键，因为线上稳定性依赖开发团队的代码质量、架构和运维操作。过去线上出现问题时，很多情况是因为运维团队扣KPI，开发团队不承担任何责任（所以网上常调侃运维团队是“背锅”的）。SRE团队对SLI、SLO等指标的落地，在某种程度上对开发团队进行了约束，毕竟如果某个组件的SLO不达标，开发团队内部就会有绩效压力。

对不同组件的SLO梳理，可以让SRE团队有针对性地制定策略，合理地安排投入人员等。并不是每个组件都要求可用率达到99.99%，虽然可以做到每个组件的可用率达到99.99%，但是这种情况实现的边际成本是超乎想象的。所以在梳理业务稳定性需求的时候，我们通常聚焦于业务团队的SLI和SLO的制定，同时完成依赖关系梳理，然后就可以很容易地描绘出一个业务在稳定性方面的需求列表和规划。有时候只是单纯地评估稳定性需求，也可以看出一个业务的发展需求。例如，如果是业务新特性优先级高于业务错误率，则业务就是处于发展初期，运维工作的核心就是提升发布等环境的效率。如果是综合考虑业务稳定性和业务错误率，则业务就是处于稳定维护期，运维工作的核心要注意平衡迭代和稳定性。如果是重点考虑业务的稳定性，则业务就是处于高度成熟期，而且往往和资金等因素关联，这个时候运维工作就要侧重整体的风险控制，用有限的成本，尽量压制不稳定的因素。

（3）运维计划安排。

在完成运维需求沟通和梳理业务的稳定性需求后，传统运维团队就可以开始日常工作。传统运维团队的日常工作就是接需求和处理需求。在传统运维团队转变为SRE团队后，日常的工作其实还是有稍微不一样的地方。SRE团队会深入理解业务的运作，主动根据业务情况和运行情况制定维护窗口、运维流程等机制。SRE 团队的日常工作不再只是被动地接受业务的运维需求，而是有计划、有条理地主动推进线上运维。

与业务活动相关的运维需求，SRE团队通常会制定详细的项目计划表来推进相关工作的节点和落地方式。相比之前被动地接受业务需求，SRE团队的跟进模式很接近软件开发迭代模式，很多时候甚至和业务一致，直接执行敏捷开发的方式。

除了日常工作和与业务活动相关的运维需求，SRE团队还会结合业务特性进行一些运维流程改进培训、运维操作培训、运维赋能培训等培训和技术宣讲。培训和技术宣讲一方面是提升业务团队对线上稳定性的重视程度，另一方面是希望通过培训和技术宣讲让业务团队接受 SRE 团队统一推广的流程和工具。

总的来说，一个良好的运维计划安排不仅包括日常工作计划、业务活动计划，还包括运维培训和技术宣讲。