线上事故第一决策：先回滚还是先热修？我们踩过的坑是「回滚要 40 分钟、热修只花了 20 分钟，但最后用了 2 小时」——你们团队的 SOP 到底定在哪？

【背景】 做了 8 年运维，复盘事故时发现一个规律：事故损失的大小，往往不取决于 bug 本身，而取决于「回滚 vs 热修」这个第一决策花了多久。

去年一次真实经历：一个发版把订单服务的金额字段从分改成元，上线 10 分钟线上出现对账不平。值班同学第一反应是「定位到具体代码行再热修」，因为回滚要走发布平台的审批流 + DB 里已经落了 3 千多条新格式的数据，他判断「回滚更麻烦」。结果排查 + 热修 + 二次验证，从报警到恢复用了 2 小时 10 分，对账差异补了 4 万条。

上个月同样的服务又出事故，值班直接 kubectl rollout undo deployment/order-svc，3 分钟回到上一版本，脏数据本来就有对账任务兜底补偿。全程 18 分钟。

同一个团队，两次事故，差距全在「第一决策」上。

【常见分歧，我见过三种流派】

1. 无条件回滚派：「回滚最快、风险最低，先回滚再说，定位可以事后慢慢做。」逻辑是回滚是确定性动作，热修是概率性动作。
2. 先修后滚派：「回滚会丢用户正在处理的状态（比如半路提交的表单、进行中的支付），热修影响面更小。」
3. 看情况派：无状态服务先回滚，有数据迁移 / 有状态服务的先评估——但「评估」这一步往往就是事故延长的元凶，因为没人说得清评估要多久。

我自己的倾向：默认回滚优先，但只给「评估」留 5 分钟窗口。具体做法：

• 发布平台必须支持一键回滚（kubectl rollout undo 或 CI 里保留上一版镜像 tag），审批流在回滚场景默认豁免；
• DB migration 必须写 down 脚本，回滚前先跑一遍 dry-run；
• 事故 SOP 里写死：报警 → 先问「能不能回滚」→ 能，5 分钟内没找到反对理由就回滚；不能（有不可逆数据迁移 / 多服务联动发版 / 状态卡在中间态），才进入热修流程，并且热修本身也要有 15 分钟止损线，超时就强制回滚。

理由很简单：回滚是「退回已知正确状态」，热修是「赌一个新的正确状态」，事故时我们的信息是不完整的，赌的胜率远低于直觉。

【想听大家在什么场景下怎么选】

1. 无状态 Web 服务 + 纯代码 bug：这个应该没争议，先回滚？
2. 带不可逆数据迁移的发版（比如大表拆列、分库分表切流后）：回滚不了，你们的热修止损线定多久？
3. 多服务联动发版：A 服务改了接口契约，B 服务跟着改了，回滚 A 会不会把 B 打挂？这种情况你们怎么设计「可独立回滚」的发版？
4. 热修本身又引入了新 bug（二次事故）：你们有没有真实案例？第二针怎么打的？
5. 你们团队的「回滚审批流」在事故时是豁免的还是要走的？走一次要几分钟？

欢迎把你们的 SOP 原文（脱敏后）贴出来，我想对比一下不同团队的「5 分钟窗口」到底怎么落地的。