用 AI 做上线检查清单：回滚预案

上线检查清单最容易失效的地方，是它太容易通过。三十个勾打满，纪要写着「已确认」，第二天早上七点告警响起来，值班的人翻遍文档，找不到一句「现在该退到哪个版本、谁来按这个按钮」。用 AI 拉一份清单，这个毛病不会自动消失。清单记录的是「检查过」，回滚预案要回答的是「现在怎么办」，这两件事之间隔着一整个夜里。

清单和预案，差在动词

清单是静态的：改了哪些文件、跑过哪些测试、谁确认过。预案是动态的：什么条件下退、按什么顺序退、退的过程中看什么、谁有权决定。前者可以照着抄，后者必须按你自己的系统结构写。

很多团队把两件事混在一起，结果清单很长、预案只有一句「必要时回滚到上一版本」。这句话在真出事时没有用，因为它没有回答任何一个具体问题。判断一份预案能不能用，有个很土的办法：交给当晚不在项目里的值班同事，问他能不能照着做完。他卡住的地方，就是预案缺的地方。

能执行的预案有五个部件

决定成败的其实是联系人表那一行，它最容易被写成形式。联系人表不是名单，是权限：谁能在没有上级确认的情况下按下回滚，谁能在观察十分钟和立刻回滚之间做选择。这一条写不清，前面几行都白做。

触发条件要写成数字

「错误率上升就回滚」不是条件，是愿望。条件要能被执行的人一眼判断：看哪个指标、在哪个看板上、连续几个采样点超过多少、观察窗口多长。常见的一组是核心接口错误率、下单或提交成功率、P99 延迟、以及业务侧的转化漏斗。阈值别拍脑袋，拿上周同期的基线往上浮一档。

还有一个容易漏的维度：并非所有异常都指向这次变更。把「变更前就存在的波动」和「变更后新出现的错误码」分开看，能避免一次没必要的回滚。指标体系的搭法可以参考模型评估指标里分层看数的思路——总体指标不动、分层指标已经崩了，这种情况很常见。

回滚顺序按依赖倒着走

顺序错了，回滚会变成第二次故障。基本原则是按依赖倒序：先切断入口流量或关掉开关，让新请求不再进来；再退应用版本；再退配置；最后处理数据。每一步都要有验证点——退完这一步，看哪个指标恢复了，才走下一步。

验证点不过就停在那一步，不要继续往下退。继续退会把现场搞乱，后面排查时连「退到哪了」都说不清。整条路径的预计耗时也要写，超过预期就升级，别一个人硬扛。

数据能不能退，是最容易漏的一条

代码可以退回旧版本，写进去的数据未必能退。按可逆性分三类看：只新增字段、旧代码忽略它，这类基本安全；改了字段含义或取值范围，旧代码读新数据会出错，属于危险区；删除或覆盖了原值，不可逆，只能靠备份或补偿脚本。

结构变更通常要设计成两步走：上线版本同时能读新旧两种结构，先让新旧共存；稳定几天、确认没有回退需求之后，再清理旧字段和旧数据。代价是代码要多写一段兼容逻辑，换来的是「随时能退」。如果这次变更涉及历史数据重算，还要额外准备一份回滚前的快照，以及一个能重放的计算脚本。

谁拍板，几分钟内拍

回滚是个决策，不是个操作。决策需要有人承担「白退一次」的代价，也需要有人承担「该退没退」的代价。这两个人合在一处更稳，分开就没人敢下这个决定。

给决策设一个时间盒：发现异常后五分钟内定「退」还是「再观察一个窗口」，超过就默认退。这条规则听起来粗暴，实际能救很多次发布——犹豫的成本通常高于白退的成本。对外沟通的人也要提前定，客户侧、客服侧、内部群，谁说话、说什么口径，出事时再想就来不及了。

没演练过的回滚等于没有

工具在这一环能做的有限，得说清楚。它能帮你把变更差异列出来、把检查项排成表、把回滚步骤写成草稿、把当天的操作时间线整理成复盘材料。它做不到的是：知道你的系统里哪一步会卡住，知道数据库主从切换要几分钟，知道哪个下游团队周末没人。

更要紧的是它会编。回滚命令、配置项名称、参数默认值，它写出来格式正确、语气笃定，实际执行可能直接报错，或者造成更大范围的影响。这类内容只能对着自己的部署文档逐条核，成因在AI 幻觉里有说明。让它出清单时，把「只使用我提供的服务名和配置项，不确定就标注待确认」写成硬约束，写法参考提示词的结构。

演练是唯一能验证预案的动作。挑一个低峰时段，真实走一遍：切流量、退版本、验指标、处理数据，全程计时。走完你会发现预案里至少有两三处是错的，早发现比晚发现便宜得多。上线后头几个小时还要盯指标漂移，数据漂移那篇讲的观察方法在这里同样适用。

速查：回滚预案的四道硬关

• 触发条件写成指标加阈值加观察窗口，不写「感觉不对」
• 顺序按依赖倒序，每步带验证点，不过就停
• 数据分三类看：新增可留、改语义危险、删改不可逆
• 拍板人和替补写进表，决策时间盒五分钟