4.4 变更风险控制

对变更决策有了初步的判断逻辑后，再回归变更的本元——变更风险控制。无论是早期UNIX系统管理员，还是SRE工程师、DevOps工程师，只要和业务稳定性风险打交道，那么与变更相关的任务会一直是运维的核心工作。

讲了那么多变更，说到底是为了让情况更加可控。一个可控的变更，即使变更失败，团队成员往往也可以接受变更结果。一个高不可控的变更，如果真的出现问题，往往是灾难性的结果，所以很少有团队成员会支持高不可控的变更。

在传统运维团队还分系统管理员、数据库管理员等角色时，传统运维团队对线上业务的风险评估很多都是基于团队成员历史经验和个人技术素养的。这导致同样一个变更需求，资深人员的评估和新手的评估会有完全不一样的结论，原因是团队成员认知水平的差异。传统运维团队为了解决这样的评估差异，变更风险控制会依赖团队成员的交叉Review评估。

交叉 Review 评估能在很大程度上起到变更风险控制的作用，但是实际落地时往往会有较大的成本和执行偏差。假如规定让老员工对新员工执行的变更进行评估，实际执行时，这种评估会消耗较多老员工的时间，变更风险的控制程度会更依赖人工执行的细致程度。

以最常见的Nginx配置变更为例，很多时候配置文件不能真正地反映业务团队原始的需求，这导致在配置Review时，很难真正地控制风险。因为这个操作相当于让审计人看到配置 Patch 时，重新按照业务逻辑执行一次写配置Patch的操作。

可以说传统运维团队在类似Nginx配置变更方面显得很无力，因为运维团队和开发团队是独立的，很少能推动业务在设计上压制这样的变更风险。

SRE团队在这方面会具有更好的控制优势，一方面是SRE团队做事流程和方式的统一，使业务团队只能以统一的工具和方式做配置。再次以Nginx变更为例，业务团队可能会要求运维团队将业务非常特殊的逻辑写到Nginx配置中。传统运维团队可能会被压着做掉这样的需求变更，但如果是SRE团队，因为SRE团队会使用工具对配置进行调整，所以会让工具填写变更需求。如果有人开发过配置生成工具，就会清楚人工配置往往是更灵活的，工具在生成配置方面，肯定会有一定的局限性。当业务真有奇怪的需求提出时，很大的概率会被工具提示无法执行。可能偶尔会有团队要求人工挑战，突破工具的限制，但最终所有不合理的需求还是会被工具和流程所压制。

另一方面SRE团队因为和开发团队有类似的背景能力，所以有时候完全可以从技术实现上对业务需求进行挑战。因为开发团队有时候并不是希望可以突破规则，而是对线上执行的配置变更缺少风险了解。当SRE团队可以用开发团队了解的方式，讲述线上配置对应的代码逻辑时，很多情况下是可以说服业务团队的。最坏的情况也是SRE团队能和开发团队一起想出折中的办法，而不是被动地执行业务团队的变更。

在变更控制中，变更不可能是100%无风险的，我们来讲一下变更风险因素的评估和控制。

1.不要评估“不可能”的风险

“不可能”的风险指的是没有条件满足的风险。例如，类似物理学中损坏杯子概率性地恢复完整和服务器 CPU 执行 XOR 逻辑时获得 OR 执行结果等。很低概率会发生的风险，正常不应该在变更评估中考虑，而应该尽量在系统设计时考虑。例如，执行变更时不去考虑机房被雷电击中的概率，但是在机房和系统设计时要考虑机房失效的概率。这样做的一个好处就是能控制评估时间，让成员能聚焦在和业务变更相关的风险上，而不是“脑暴”地罗列所有的风险。

2.控制变更因素

线上业务如果要执行变更，一个很重要的逻辑是一次只变更一个因素。可能有人在执行变更时，很喜欢“夹带私货”，如趁线上维护时，同时升级一次系统。其实这种行为的风险是非常高的，因为变更本身已经有非常高的概率会遇到其他不可控因素，再往里面加复杂度，往往会有惨痛教训。

例如，与金融相关的变更，业务中断超过30分钟就得上报央行。可能你申请的是一个数据库切换操作，结果因为额外执行了业务升级，维护复杂度上升超过了30分钟的中断时间，然后公司可能会面临被监管部门警告的风险。

如果要变更多个不同因素，最好分多次执行，多次变更之间最好独立，防止相互干扰。这种情况也是有惨痛教训的，在早期制度规范没有完善时，经常会有全站更新的发布操作。例如，半夜时A服务和B服务同时执行，线上突然出现了问题，整个过程你会没有办法看出是回滚A服务还是回滚B服务。