P1 前 15 分钟，先回滚止血还是先定位根因？聊聊你们的默认动作

背景

做了 5 年运维，值班这几年我反复遇到同一个分歧，而且几乎每次 P1 群里都会吵起来：故障刚发现的前 15 分钟，oncall 的默认动作到底是「先回滚/切流止血」还是「先花几分钟把根因定位清楚再动手」？

我手上有两组真实数据可以给大家参考：

• 我们一条核心支付链路上，最近 12 个月里 7 起 P1，其中 5 起是「发版后 10 分钟内 P99 从 80ms 抖到 1.2s」。这 5 起里，2 起 oncall 选择先回滚，从发现到恢复平均 9 分钟；3 起选择先 git diff 看改动点再决策，平均花了 22 分钟才恢复，其中 1 起因为根因其实是上游依赖抖动、回滚了个寂寞，白白多花了 40 分钟。
• 反过来，也有 1 起不是发版引起的慢查询故障，oncall 习惯性回滚后，因为版本本身没问题，反而把故障现场冲掉了，最后靠抓包 + binlog 才定位到，恢复时间 47 分钟。

常见的几种做法

1. 无脑回滚派：P1 一律先回滚到上一个稳定版本，理由是最坏情况也就是「多回滚了一次」，但拖着的每一分钟都在烧客户。
2. 先判再动派：先看最近 30 分钟有没有变更、看监控曲线形态，2–3 分钟内给出「是不是发版引起」的判断，是就回滚，不是就直奔 DB / 依赖。
3. 分级处理派：把故障按「影响面 × 恢复手段成本」分档，只有「快速回滚且回滚成本低」的才走回滚，否则直接拉根因小组。
4. 流程化派：写进 runbook，规定「发现后 5 分钟内必须给出动作」，避免 oncall 一个人扛。

我的倾向

我偏向第 2 种 + 第 4 种的组合：默认动作是「先花 3 分钟确认是不是变更引起」，同时把 runbook 写死——如果 3 分钟还没结论，就强制进入回滚/降级流程，不允许继续「再看看」。理由是：

• 回滚不是零成本：它会冲掉现场、可能引入版本不一致、还可能像上面那起一样白干；
• 但「先定位」也不能变成「慢慢看」：P1 的 MTTR 里，「决策时间」往往比「执行时间」更贵，所以必须给「先判再动」设一个硬上限。

想听听大家

1. 你们团队的 P1 默认动作是什么？有没有写进 runbook？
2. 你们是怎么界定「回滚成本低 / 高」的？比如双机房、灰度、蓝绿，是不是决定了默认动作？
3. 有没有过「回滚了个寂寞」或者「该回滚没回滚」的真实案例？当时是怎么决策的？
4. 你们怎么量化「决策时间」和「执行时间」的占比？有没有具体的指标口径？

期待各位用具体数字和场景来聊，别只说「看情况」哈。