上线前先写好回滚方案（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 分钟内能退回来"。回滚单不是官僚流程，是给自己买的最低成本的保险。