故障前 5 分钟：先回滚还是先修？我整了 4 问决策树，想听你们的「必杀线」

【背景】 干运维 3 年，跟着排障的线上故障大概 40 次，其中超过一半卡在同一个岔路口：「先回滚，还是先修？」

印象最深的两次，正好是两个极端：

• 一次发布引入 bug，订单接口错误率从 0.2% 飙到 18%。我当场拍板回滚，4 分钟服务恢复。但正因为先回滚了，现场没了，根因又追了 2 小时才复现。
• 另一次是配置漂移，我选了 fix forward——线上改配置、验证。结果 20 分钟后又冒出第二个问题，累计故障时长 47 分钟。事后复盘：那次其实回滚 3 分钟就能收工。

这两次让我意识到：「回滚还是修」不是谁对谁错，而是「你付得起哪种成本」。

【几种做法】 社区里我见过大致三种路线：

1. 回滚优先派：「服务第一，排查第二。先回滚，服务活了再说。」
2. 修复优先派（fix forward）：「回滚也是变更，回滚本身有风险；而且回滚丢现场，根因更难查。」
3. 分诊派：「先看影响面、扩散速度、回滚代价，再决定。」

【我的倾向】 我偏向「先分诊，再走一棵小决策树」。用下来顺手，整理成 4 个问题，按顺序问：

1. 我能不能在 10 分钟内复现原因？→ 能：fix forward；不能：回滚。（这条最关键：它区分「你有能力修」还是「你只是敢修」）
2. 影响面在扩大吗？（错误率还在涨、受影响用户还在加）→ 是：先回滚止血。
3. 回滚的代价多大？（数据、状态、外部依赖、回滚本身要不要再走一次发布）→ 代价低：直接回滚；代价高：先分诊。
4. 是单点故障还是全量故障？→ 全量：回滚，别犹豫。

理由一句话：回滚和修复都是「变更」，区别只在成本和风险。回滚优先之所以常常对，是因为它的代价通常比「修错」低、风险更可控；但当回滚本身代价很高（丢状态、回滚触发新发布、外部依赖已依赖新行为）时，fix forward 才更划算。

【想听大家】 想请各位贴一下自己的「必杀线」，好把这篇攒成一份《故障前 5 分钟清单》：

• 你的「必回滚」场景是什么？（比如数据写坏、全量、错误率还在涨）
• 你的「必 fix forward」场景是什么？（比如回滚丢状态、回滚代价 > 修复代价、单点配置）
• 有没有「决策时限」？（比如 3 分钟定不了就默认回滚）
• 「回滚本身失败 / 卡住」你一般怎么兜底？

真实案例最值钱，欢迎带数字来。