先给结论：我倾向「能回滚就无条件先回滚，回滚耗时 ≤ 5 分钟是红线」，但这个"无条件"在三种场景下会翻车——schema 变更、数据已写、下游已消费。想听听大家在这三种场景下的真实选择。
【背景】 我负责 3 个核心服务的 oncall（K8s + MySQL 8.0 + Redis，单机房 12 节点）。过去一年我们复盘过 6 次 P0，其中 4 次的决策点都卡在同一个问题上：
是回滚还是热修？
我们的现状是：回滚（git revert + 镜像重打 + 滚动发布）平均耗时 7 分钟（含健康检查），热修（单副本 patch + 灰度 1 个 pod）平均 11 分钟。看起来差不多，但实际差异在「回滚失败的回滚」——回滚本身如果因为 schema 不兼容再失败一次，就是 14 分钟 + 数据不一致。
【常见分歧，我见过三种做法】
-
回滚党（我们团队之前的默认策略）：P0 第一动作永远是 revert，理由简单——「让系统回到 10 分钟前已知的稳定状态，比在故障现场猜根因快 10 倍」。这个策略在纯代码 bug 上完美，但去年 11 月一次 DB 连接池参数变更引发的雪崩，回滚后旧参数把连接池打满的问题又复现了一次（因为 DB 端有 2 分钟缓存），实际耗时 19 分钟。
-
热修党（另一个团队的策略）：只要 10 分钟内能定位到具体配置项或代码行，直接改，不走完整发布流程。优点是精准、不碰其他服务；缺点是 oncall 工程师需要在故障压力下写代码——我们统计过，故障状态下写的 patch，事后 review 发现 40% 有逻辑偏差（不是错，是"改对了一处但漏了另一处"）。
-
分场景党（我个人现在倾向的）：按故障类型走决策树：
- 代码/配置变更引入 → 无条件回滚（目标 ≤ 5 分钟）
- 资源/容量类（连接池打满、内存泄漏）→ 先扩资源止血，再回滚或热修
- 数据类（脏数据写入、schema 变更）→ 不能回滚，走数据修复 + 热修
【我的倾向与理由】
我倾向第三种，核心依据是两个数字：
- 我们 6 次 P0 里，有 2 次是「回滚了但根因没解决」（因为根因在 DB 端/下游），回滚后 30 分钟内二次故障；
- 有 1 次是「热修了但 patch 本身有 bug」，二次故障比第一次更严重（因为 patch 改了一条路径，但另一条路径还开着）。
所以我的判断标准是：回滚/热修的选择，取决于「回滚后系统能否回到一个可验证的稳定状态」，而不是「哪个动作更快」。如果回滚后系统状态不可预期（schema 已变、数据已消费），热修反而更安全。
【想听大家在什么场景下怎么选】
- 你们团队的 P0 第一动作是什么？有没有量化过回滚耗时（从决策到全量恢复）？
- 「回滚后二次故障」你们遇到过吗？根因是什么？
- 数据类故障（不能回滚的场景）你们的止血 SOP 是什么？有没有「先停写、再修复」的标准流程？
- 有没有团队把「回滚耗时 > 5 分钟」当红线，倒逼发布流程改造的？具体改了什么？
我抛砖引玉，想把这个决策树聊透——它比「SLO 怎么定」更贴近一线 oncall 的真实压力。