上线前先写好回滚方案（Rollback First）

上周我盯的一次发版，新代码上线 20 分钟后报了一个边界数据异常。排查、定位、准备热修，前后烧掉两小时。事后复盘发现一个更扎心的事实：如果上线前花 10 分钟写一张"回滚单"，那两小时里至少有一小时半可以直接跳过——因为窗口的第一步本来就是"先回滚再查"，而当时没人提前确认过回滚到底怎么回、回不到哪里。

"Rollback First"这个习惯很简单：**在做任何不可逆或半不可逆的操作之前，先把"怎么退回去"写下来，而不是出事后现想。**

什么时候用

- **部署上线**：任何进生产环境的代码、配置、数据迁移，发布前必答三个问题：回滚触发条件是什么？回滚要几步、几分钟？回滚后数据怎么收尾？

- **数据库变更**：加列、改类型、跑迁移脚本之前，先确认旧版本服务能不能直接跑在新结构上。不能，就先加后改，分两次发布。

- **删东西**：删文件、删分支、删配置项、清缓存。`rm` 之前先想 `trash` 或者备份放哪。

- **对外承诺**：给客户、老板发出的坏消息或变更通知，发之前想好对方追问第二句时你怎么接，以及说错了能不能收回。

- **Agent 干活**：让自动化脚本批处理之前，先保证每批操作可撤销，或至少输入有快照。

什么时候别用

- **一次性试错**：本地实验环境、草稿、可随意重来的场景，写回滚单是形式主义，浪费时间。

- **纯加法变更**：加一个没人引用的配置项、加一张新表，旧逻辑完全不碰——这种"天然可回滚"的操作，写一句话确认即可，不用展开成仪式。

- **回滚成本高于业务成本的场景**：极少数情况（比如停了一个已经泄露的接口），直接上、快上，回滚反而是错误决策。判断"能不能回"比"要不要回"更前置。

回滚单最小清单

一张合格的回滚方案，写在发布记录里就够了：

1. **触发条件**：什么信号出现就必须回，而不是"看看再说"。（例：错误率 >1%、核心接口 P95 翻倍、客服报障 >3 起）

2. **回滚动作**：具体到命令或按钮。"回滚到上一版本"不算答案，"`git revert` 这个 commit 后重新部署 CI 流水线 #x"才算。

3. **耗时预估**：从决定回滚到服务恢复，预计几分钟。超过 30 分钟的回滚方案，上线前就应该先把回滚演练一遍。

4. **数据收尾**：回滚后脏数据怎么办？新写入的记录是留着、屏蔽还是删除？

5. **谁来执行**：写名字。半夜出事时"找值班的人回滚"等于没人回滚。

常见坑

- **回滚方案只存在于脑子里。** 复盘时人人都觉得自己"知道怎么回"，出事时才知道 DB 结构已经兼容不了旧代码。写下来才是存在。

- **把"回滚"和"修复"搞反。** 默认动作是先回滚止损、再从容排查。很多团队出了事直接在生产环境热修，把一个故障变成两个。

- **演练缺失。** 回滚方案没跑过，就只是猜测。重大变更上线前，在 staging 把回滚完整跑一遍，通常 10 分钟，能删掉方案里一半的幻觉。

- **只回滚代码不回滚配置。** 代码退回旧版本，新配置还在，服务照样起不来。回滚单里代码、配置、数据三样要一起列。

一句话总结

上线的勇气不来自"我觉得没问题"，而来自"就算有问题，我 15 分钟内能退回来"。回滚单不是官僚流程，是给自己买的最低成本的保险。