上线后的三十秒：先想清楚怎么退

周一早上 9 点，你改了一行支付网关的超时配置，回车，部署完成，日志一扫，清爽。你松了口气，继续去开别的会。

30 分钟后，支付回调开始排队，超时错误一片。你才想起来回答那个问题：**怎么退？** 如果答案是"回头再重新部署一次"，那你其实没有回滚方案，你只是在假设回滚会自动发生。

这条技能不讨论架构，只给一个 2 分钟的预检清单。

什么时候用

- 部署代码、改配置、开 feature flag、跑数据库迁移

- 在共享环境（staging、生产、"大家共用的那台服务器"）动手

- 会向外发消息、写外部系统、改数据的情况

什么时候不用

- 本地小实验，崩了重跑零成本

- 一次性文案，错了重写就行

- 纯读操作（查日志、看数据）

三种都不占，就别上流程——**别把流程本身当成工作量**。

检查清单（2 分钟）

1. **写出回滚命令。** 真的写下来——commit message、工单、Slack 都算。说不清具体命令，就没有回滚方案，只有一句愿望。

2. **估计回滚耗时。** 30 秒一个 revert 和 40 分钟数据重建是两个风险量级。超过 10 分钟的"回滚"不是回滚，是二次事故预案——这种情况应该改用灰度或开关，而不是赌一把。

3. **留现场。** git tag、配置 diff、表备份。"前面那个版本我记得"= 没有备份。

4. **副作用能不能撤销？** 消息发了、缓存落了、下游表写了——这些退不掉。副作用不可逆时，问题不在回滚方案不够好，而在操作本身该改成可逆（先干跑、先灰度）。

5. **记下旧值。** 超时从 5s 改成 30s？在工单里写"旧值：5s"。人类记忆在 3:17 的凌晨不可靠。

常见坑

**坑一：把备份当回滚。** 备份存在不等于恢复快。恢复脚本半年没跑过、备份在异地、要审批才能拉回来——这些都很常见。回滚的验收标准是"现在能不能 10 分钟内复原"，不是"有没有备份"。

**坑二：flag 没验证就上岗。** feature flag 本身也是个变更。关掉 flag 后服务能不能正常起、会不会报空指针，没人测过。flag 当保命符之前，先让它单独测一次。

**坑三：回滚代码，数据没回滚。** 新代码写新列，revert 之后旧代码去读旧表，字段对不上。数据库变更要么向后兼容，要么标"不可回滚"，两种都行，混着来最危险。

**坑四：打算了但没落字。** 开会时说"先灰度再回滚"，开动到上线忘回滚这一半。回滚方案必须和应用方案的完整度一样：同样的工时、同样的文档位置、同样的验收细节。事故时你有时间看的往往只有落字的。

一个 10 秒自检

**"炸了之后 10 分钟能退吗？"** 能 → 有一条命令、一个备份引用、一段耗时估计。不能 → 先去把它变能，再上线。

发布前工单模板

## 回滚
命令:  / 改回 X=5s / 关 flag: pay-timeout>
预估耗时: 
现场: <备份/快照位置>
不可逆副作用: <有：xxx / 无>

五条都填不出，就红灯。

举例：一条超时的回滚长什么样

工单：把支付回调超时从 5 秒改成 30 秒。回滚区块应该长这样：

- 命令：配置面板把 `pay.cb.timeout` 从 30 改回 5，或跑 `config rollback --key pay.cb.timeout`

- 预估耗时：2 分钟

- 现场：改动前截图存工单附件

- 不可逆副作用：无——因为这是一条配置，不是数据迁移

对比一个危险的版本："回滚：重新部署前一份镜像"。问题在于这个动作要多长没人测过、前一份镜像是多少天前的人不清楚、期间新数据写状态怎么办没人想过。看起来有方案，三个问号都悬着。第二种写法才是把坑填了。

尾声

回滚方案的价值不在出事那天，而在动手之前：它就是那一小段写出来的话，逼着你在 14:00 把"退路"想清楚。写不出来的那一刻，是上线前信息量最大的一刻。