4.3 稳定性和迭代速度的权衡

变更控制的松和严在实际工作中都有对应的应用场景，变更管理、变更控制都是为了控制风险。可能会有人想到既然都有变更控制机制和变更管理机制，那为什么在实际工作时还会有不一样的感受呢？

其实线上没有100%没风险的事情，大家都开过变更风险评估会议。会议中团队讨论最多的是风险及风险对应的解决方案，但是没有人能说清楚所有的风险。我们对风险的评估，更多的是一种问题判断的取舍关系。

风险从数学上讲更多的是和概率相关。一旦讲到概率，所有的风险都是可能发生的，宇宙射线可能会导致位反转，然后导致服务器内存的数据异常。但实事求是地讲，在互联网公司没有谁会担心这样的风险概率。如果考虑这样的风险概率，那么线上服务器都不是现在这样的规格和价格了。如果你同意忽略某些低概率的风险，那么就让我们来谈一下变更管理机制和业务稳定性、业务迭代速度的关系。

变更管理机制只是定义一种变更管理的方法，变更控制机制也只是定义一种变更控制的方法，它们更像是一种处理逻辑，而不是精确计算的数学函数。在实际落地时，变更更多地表现为和业务需求相关的一种控制考量，变更和团队管理的概念类似，讲究的是要根据实际情况，因地制宜的执行。

当一个业务运行和做业务的变更管理时，需要考量很多的因素。当做业务的变更决策时，有人会用心中有“一杆秤”做比喻，“秤”的一头放着业务稳定性，另一头放着业务迭代速度，决策严厉与否决定了“秤”的支点位置。我们常说一个好的决策，通常能让业务稳定性和业务迭代速度在“秤”上是平衡的。

对于业务来说，稳定性和迭代速度是整个变更管理的核心，所有的变更管理本质上都是在寻找这两者的完美平衡点。为了找到这个完美平衡点，可以从以下几个方面考虑。

1.业务发展阶段

如果是业务发展初期，大部分情况下都是迭代速度优先的，这个时候业务团队往往会全力以赴地开发，以满足市场对业务的需求。如果这个时候没有特殊的因素，那么变更控制往往是弱化的，更多的是为了方便追踪变化。但这并不能说明业务发展可以没有变更管理机制，可能是变更管理机制没有那么严，只是变更审批下放到业务小组。没有变更管理机制的业务发展其实是在“埋地雷”，迟早有一天会“炸”。毕竟我们看到太多的业务在发展初期，为了求快，因为没有变更记录，当线上出现问题时，却发现无从查起的实例。

如果是业务发展中期，可能业务已经有一定的稳定性要求。业务会追求商誉、客户口碑等各种潜在的商业价值，但是这往往也是业务高速发展的时期，可能市场上会有多个类似的产品与之竞争。团队往往会面临很困难的抉择，一方面是稳定性，另一方面是竞争压力。通常看到的业务处理方式是注重稳定、兼顾迭代速度，也就是说业务团队如果没有办法时，为了速度就会选择牺牲稳定性。当然业务团队一般会选择损失相对较小的时间和方案。这个时期往往是最难处理两者关系的时期，如果SRE团队和业务团队对线上情况掌握不明，只是为了迭代速度做的变更决策，往往会变成“莽”一次的行为。若运气不好，很容易酿成线上重大事故。

如果是业务成熟稳定期，一般情况下业务团队和业务架构都比较成熟，线上一般会相对稳定。即使有大的变动需求，也会因为业务团队处于成熟稳定期，有稳定的收入，而选择稳定性优先的策略。

2.业务体量

业务体量很多时候是我们做变更决策时要重点考虑的一个点。当一个业务被1000万人访问或被100万人访问时，通常会导致业务负责人对同一个问题做出截然相反的决策。举例来说，当一个业务每天被100万人访问时，如果业务变更时想突破一下稳定性流程，可能的机会成本是损失“1万元”，而收益是减少1天的团队开发和评估时间。当业务每天被1亿人访问时，这个机会成本可能会膨胀到“100万元”或更多，而收益是减少3天的团队开发和评估时间。被100万人访问的业务团队规模可能是5人，被1亿人访问的业务团队规模可能是几百人甚至几千人，我相信业务团队会仔细地思考是否需要冒着不可控的因素来执行变更。

3.业务影响力

业务影响力也是一个非常重要的因素，这个因素和业务体量相关，但更多地和业务在公司乃至全社会的重要性相关。以电商业务的页面服务器为例，A 业务对应页面上的商品信息，B 业务对应页面上的打点JavaScript 异步调用。如果只基于业务体量考虑，两者的变更决策结果就没办法体现两者的区别。

线上这样的业务很多，电商业务所有的子系统不能执行一样的变更逻辑，所以很多时候线上更需要基于业务影响力的考量。通过业务影响力的考量，B 业务变更审批的要求往往会低很多，这个反映到实际情况中就是：B业务执行迭代速度优先的变更策略，A业务执行稳定性优先的变更策略。

在保证业务稳定性的前提下，SRE团队很重要的工作是让业务能更快速的发展。因此在保证业务的SLO达标且错误配额没有耗尽的情况下，在做变更决策时，可以适度地偏向迭代速度优先的变更策略。毕竟我们所处的行业竞争激烈，更快的业务迭代速度能为公司赢得市场优势。