4.2 变更控制

所有公司都在变更管理机制建设上有各自的实践和落地，那是不是完善变更管理机制后，变更就不会出现问题了呢？实际情况是所有公司的业务团队虽然拥有完善的变更管理机制，但只要变更还是由人触发或操作的，线上业务肯定还会因此而异常。只不过大一些的公司，控制体系会更好，更不容易将问题引入线上。

我们总是能看到很多公司，如Amazon、Microsoft、Google、GitHub等，每年总会出现一些变更引起的线上故障。结合网上其他公司的变更错误和网易内部的变更错误，可以发现所有运维团队犯的错误都惊人的相似，如证书过期、发布时提交错误参数等。这些错误说明国内外的运维团队虽然在技术水平上可能会有差别，但在犯错时，大家都是平等的（很多变更错误和技术无关，纯粹就是人的意识或经验问题）。

各大公司的运维团队都会犯错，事后复盘注重的点却是完全不一样的。有些公司会说要加强运维团队的变更控制，有些公司则会说要提升软件鲁棒性。这就引申出一个问题：别人家的公司是怎么通过变更控制做到更高的可用率呢？我们发现不同公司或不同业务在变更异常上的不一样表现，主要是变更控制的差异导致的。

当一个团队重视变更控制，即使是用最土的方式来控制时，也能做到更低的异常。但实际情况是落地很难，因为总会有一些东西比变更控制更加重要。在互联网公司有一种需求叫“老板需求”，当你的团队遇到“老板需求”时，如果项目进度紧张，那么很可能会在变更控制过程中有意识地放过一些事故征兆。

4.2.1 如何建设好的变更控制

变更控制的核心是为了降低故障发生的概率，在运维和开发都是独立部门时，运维就有意识地去进行变更控制。变更控制的方法主要是定制变更时间窗口，很多公司可能都会有规定，会智能地将网络变更设置在周三的0点到1点之间，日常发布只允许周二到周四执行。这种规定非常死板，对于外部其他人来说，甚至有点无法理解这样的规定。但是对于实施这些规定的公司来说，这样的变更控制机制是他们业务稳定运行的基石。

每家公司的变更控制机制并不是一成不变的，它是随着业务发展和团队技术发展演化的。如果硬套其他公司的变更控制机制到自己的业务上，那么很可能在实施时会遇到“水土不服”的情况。典型的变更和故障统计图如图4-3 所示，故障率有时会和变更频率成正相关，有时又会因为加强治理得到有效控制，这种故障率的变化主要取决于团队对变更的把控。

可能有人会了解一些金融系统的变更控制机制，如银行网络、系统和软件的变更控制机制，想将银行的变更控制机制引入互联网业务中。如果把银行的变更控制机制经过调整，直接落地到一家互联网公司的业务中，那么除了能拖累业务发展，根本无法获得更多的正面收益。

银行的变更控制机制是建立在业务要求高安全性和硬件底层不惜堆积成本上的。互联网业务的要求迭代速度很快，更能容忍故障，大部分运行在普通的 PC 服务器上，软硬件的可靠性会弱一些，所以一般情况下业务连续性能做到99.99%就已经非常高了。

互联网公司和银行对可靠性要求和硬件基础是完全不同的。将银行的变更控制机制完全地套在互联网公司的业务上，很可能连互联网公司底层的基础设施都不支持。只有适合自己公司业务需求的变更控制机制才是好的变更控制机制。

4.2.2 制定符合业务需求的变更控制机制

在制定变更控制机制时，我们往往会考虑以下几种因素。

1.团队成员的能力和经验

在制定一个变更控制机制时，第一个要考虑的要素是人。团队成员不同的技术水平和经验能力会是整个变更控制机制的核心。所以在制定变更控制机制时就有了很重要的一条：“因人而异”，对不同的人执行不同的变更控制机制。例如，当团队新来的实习生执行变更时，肯定要层层把关；但当团队的核心成员执行变更时，可能团队领导稍微关注一下变更的类型就可以直接放权让他执行了。

这样做最直接的逻辑就是：“老司机开车时，不需要陪驾和叮嘱；新司机开车时就得反复叮嘱，还要老司机坐在他边上开几趟。”

2.业务的技术架构

另一个重要的变更因素就是业务架构，不同层级的业务架构设计会有完全不同的变更控制机制。当只有同机房跨服务器容错时，对比跨机房容错或跨地区容错，业务团队对变更的控制会完全不一样。另外在业务架构中不同的组件也会有不同的变更控制机制。例如，无状态应用服务器的维护和数据库节点的维护，变更控制机制会完全不一样。前者可能只要在内部沟通群中知会一下，但后者就需要层层上报，获得审批后，还得找维护窗口维护。技术架构中的容错机制和模块的重要程度会决定变更控制机制趋严还是趋松。

3.业务活动周期

变更控制机制是为了业务的发展，可以说业务活动周期是变更控制机制中重要的因素。每年到“双十一”等电商活动时，所有做电商的同学都知道，线上服务器是不能做任何大的变动的，一般会提前1～2周封版（封版就是线上禁止任何版本的变更操作）。到了电商活动当天，即使在线上发现了一些很小的问题，若想执行变更进行修复，也得层层汇报审批。如果问题影响程度不大，那么对应的变更申请大概率是会被决策团队驳回的。

同样的问题，如果发生在评审阶段，只要团队内部报备一下就可以直接执行变更。在业界，电商开发团队的技术和经验都是较强的，业务团队也做好了跨机房容错等设计，但就是因为“双十一”等电商活动的重要性，有时候就连简单的文件清理都可能不被允许。当然在做重要业务活动时，难免会有人在服务器上偷偷调整一些东西去试图修复一些小问题，这种情况就得依赖工具和制度去约束。

4.业务资源

除了人和技术，变更很多时候也会和业务资源紧密相关。例如，当一个团队虽然有高可用设计和人员齐备，但手头服务器资源都很紧张时，可能原来不是需要严格审批的一个变更，反而会需要反复权衡。除了服务器资源，在SRE层面还有一种资源会严重影响变更控制机制，那就是错误配额。当然传统运维也有类似的机制，如某个业务的可用率（类比SLO）快消耗殆尽时，线上变更一般会要求强审批流程。SRE除了基于业务的SLO，更是会基于业务错误率等因素，对变更进行控制。

一般来说变更控制在SRE团队是通过工具平台来实现的。例如，针对以上4个因素，工具平台在建设时会有以下几种设计原则。

（1）基于变更人的背景、历史变更记录、变更类型，决定变更审批流程。

（2）基于业务模块的冗余程度和可靠性要求，决定变更审批流程。

（3）基于是否是业务活动期，决定变更审批流程。

（4）基于业务资源水位和变更错误率等数据，决定变更审批流程。

需要注意的是，在实际生产中，很多因素都是动态变化的。当太多的异常因素没有经过演练测试时，即使业务架构设计的可靠性很高，变更审批也不会因此变得松懈。虽然通常负责开发的工程师可能对他负责的业务架构设计有信心，但是业务领导会看到更多、更全面的信息。所以常常会出现开发工程师认为不用审批的变更，但在业务领导看来是一定需要审批的情况。

这种情况有时候会让团队成员在思想上显得不那么统一。当然解决这种问题的办法也有，如加强团队内部信息的透明度，将对业务担心的点传递给所有成员。这样开发工程师自然而然就会明白变更控制的意图。

SRE团队会经常接到各个业务团队提过来的变更需求。传统运维团队在变更控制方面，更多的是执行变更的角色。一般情况是业务团队符合流程地提出变更，传统运维团队就需要执行变更，而SRE团队在变更控制中往往会有更多的话语权。

SRE 团队不只是简单地执行变更，还包括变更环节的工具建立和变更控制机制的最终把关。因为对线上业务SLO等情况要有清楚的认知，所以SRE团队在设计变更相关平台时，通常会结合自己的运维经验，使用工具自动评估变更控制的严格程度（如在变更平台上基于历史业务错误率判断是否需要审批的逻辑）。有时候因为SRE理念在公司层面的推广，大家对业务错误率的控制会达成共识，这个时候SRE团队在变更控制方面会有很高的话语权。