先写下何时停手 — 变更类型、影响范围、回退标准

一句话总结

好的变更申请单，先写的不是“做什么”，而是“什么时候停、怎么回滚”。从作业窗口中倒扣回滚所需的时间，就得到中止决策时间，而这个时间就是触发回滚的扳机。演练是在作业之前得知这份计划是否过于乐观的唯一办法。

为什么需要它

Google SRE 书写道，生产系统中发生的故障约有 70% 是由变更引起的。变更不可能消除，所以只能收窄变更演变成事故的路径。该书列举的方法有三个——渐进式发布、快速而准确地发现问题、出问题时安全回滚。

变更申请单（change request）和作业计划书，是在作业之前就在纸面上确认这三件事的工具。如果让凌晨三点比计划晚了 20 分钟的作业人员去判断“再做一会儿好像就能完成”，通常会继续做下去。事先把停止的标准写成数字，就不必把这个判断交给疲惫的人。

工作原理

变更类型。 ITIL 4 的变更赋能（change enablement）实践把变更分为三种。

类型	含义	示例
标准（standard）	风险低、流程已预先批准的重复性变更	按已批准的操作规程调整配置值
正常（normal）	经过评估和批准后安排日程的变更	按新的操作规程扩容 DB 卷
紧急（emergency）	不马上做就很快会变成故障、需要尽快处理的变更	更换几个小时后到期的证书

划分类型的原因是让审批成本与风险相匹配。如果把所有变更都提交给委员会，人们就会绕过流程；如果所有变更都直接做，就会出事故。紧急变更也不是没有审批，而是通过较短的路径获得批准，事后再补全记录。

影响范围。 “重启一台 DB”的影响不只是那台 DB。使用该 DB 的服务、使用那个服务的服务……必须把依赖追踪到底，才能得出通知对象和确认对象。如果只看直接依赖就发通知，隔了两层的结算报表团队早上就会看到空白画面。

作业窗口与中止决策时间。 如果作业窗口是 02:00–04:00，回滚最坏需要 50 分钟，再留 5 分钟余量，那么 03:05 就是中止决策时间。到这个时间点作业仍没有完成到确认为止，就必须开始回滚，才能在窗口内恢复原状。按计划作业是 60 分钟的话，03:00 结束，所以在窗口内“刚好够”。但如果 60 分钟这个数字是乐观的呢？

回滚标准必须可以衡量。 “出问题就回滚”不是标准。要写成“到 03:05 S5 的确认还没结束的话”、“错误率超过 1% 且持续 5 分钟以上”这样的时间、比率、条数。还要为每个作业步骤写明判断已完成的确认方法（verify）。没有确认方法的步骤，就是不知道有没有完成的步骤。

预检与通知。 开始作业之前，确认回滚的依据是否还有效（昨晚的备份成功了吗、有没有空间创建快照），以及作业对象与计划书的前提是否一致（版本、容量、路径）的清单就是预检。只要有一项不符，就不开始作业，这是规则。向受影响服务的负责人，还要在申请单中写明由谁通过什么渠道通知开始、结束和回滚决定。

演练。 在开发环境或复制环境中真正运行同一套流程，并为每个步骤记录开始和结束时间。把计划与实际比较，就能看出哪个步骤过于乐观。如果演练中越过了中止决策时间，正式作业中越过的可能性也很高——要先想办法延长窗口、拆分作业，或缩短慢的步骤。

在现场相遇的样子

在韩国的 SI 和运维现场，这些文档以“作业计划书”“作业结果书”“变更申请（CR）”的名字流转。格式因公司而异，但审阅者驳回的理由几乎一样——回滚步骤只有“恢复原状”一个词，受影响服务列表只有直接依赖，作业时间之和把窗口塞得满满的，预检里没有备份确认。

作业结束后会留下结果书。写下计划中每个步骤的实际开始、结束时间，确认结果，以及与计划不同的地方，如果回滚了，还要写下那个决策时间和依据。下一次同类作业的计划书，就从这份结果书的实测时间出发。没有结果书，每次重新估算，同一个步骤每次都会晚同样的时间。

最昂贵的失误是没有计算回滚时间。作业 60 分钟、窗口 120 分钟看起来很宽裕，但回滚要花 50 分钟的话，余量只有 5 分钟。如果有演练记录，作业之前就会知道这个余量实际上是负数。

下一项实验要做什么

区分三个变更申请的类型，从服务依赖列表中把重启 DB 的影响范围追踪到底。在作业计划表和窗口中计算作业和回滚的时间以及中止决策时间，并据此编写 JSON 变更申请单——头部（类型、窗口、影响、预检）和主体（每步的确认方法、可衡量的回滚标准）。最后在演练记录中找出最慢的步骤，判定是否越过了中止时间。