P0 事故中，on-call 是否有权不请示直接回滚？聊聊值班同学的"决策权"边界

背景

先讲一个我亲历、且至今还会被翻出来的场景。

凌晨 2:47，一条 P0 告警把 on-call 的值班同学（一位入职 9 个月的后端）从床上叫醒：支付接口 5xx 率从 0.3% 飙到 12%，持续了 4 分钟。按团队 SOP，回滚需要走发布平台的审批流——审批人是当天上线版本的 owner，他人在海外，电话打不通。值班同学心里非常清楚：这版代码就是 owner 上午 11:30 推的，回滚窗口只有 20 分钟（再过 15 分钟就要进对账批处理）。

他最后的选择是：等。等了 23 分钟，直到 owner 回电、确认「可以回滚」，才在发布平台点下按钮。从告警到恢复，47 分钟。事后复盘，owner 说「你做得对，我没说你不能滚」；但值班同学自己也承认，那 23 分钟里他一直在心里给自己打气「别背锅」。

这个场景不新鲜，但它逼出一个我们很少认真讨论的问题——P0 事故中，on-call 到底有没有"直接回滚权"？

常见的几种做法

我观察了身边 5、6 个团队，大致分四派：

• A 派「on-call 即 owner」：值班期间，on-call 就是 owner。任何 P0/P1，on-call 有权直接回滚、降级、切流，事后补审批即可。理由：事故每多 1 分钟，损失都是指数级的；让值班同学等审批，本质上是把"事故恢复时间"外包给了"审批人的响应时间"。
• B 派「分级授权」：按事故等级分。P2 以下 on-call 自己处理；P1 要通知 owner 并电话确认；P0 直接给 owner 打电话，owner 10 分钟没响应，on-call 自动升级为"有权直接操作"。这一派的关键是"超时自动升级"——它把"等不等"从一个道德判断题，变成了一个可执行的规则。
• C 派「双人在场」：任何回滚都要两个人，一个操作一个 review。这一派通常出现在金融、支付类团队。它最稳，但代价是：凌晨 3 点，谁能保证第二个人 5 分钟能上？我见过一个团队因为"找不到第二个人"，P0 拖了 40 分钟。
• D 派「SOP 说了算」：所有操作都要走变更平台，权限由平台控制，不区分等级。这一派的问题我亲历过——审批流在凌晨 3 点，就是事故恢复时间的天花板。

我的倾向

我自己是 A 派的"变体"，更接近 B 派。我的判断是：

1. P0 事故中，on-call 必须有权直接回滚，且这个权力要事前写进 SOP，而不是"出了事大家商量着来"。理由：事故的恢复时间是 SLO 的一部分，把恢复时间外包给"审批人的响应时间"，等于把 SLO 的可达性交给了一个不可控变量。
2. 但"有权"不等于"无脑"。我见过一个团队把 A 派执行到极致，结果 on-call 在 P1 事故里也直接回滚，回滚后发现其实不是版本问题，而是上游依赖挂了，反而把本来 10 分钟能恢复的 P1 拖成了 40 分钟。所以权限必须配触发条件——不是"on-call 觉得是版本问题就回滚"，而是"满足 X 指标条件（比如核心接口 5xx 率 > 5% 且持续 > 3 分钟，或 P99 劣化 > 3 倍基线）时，on-call 有权直接回滚，无需审批"。
3. 事后不能追责"操作正确但结果不好"的回滚。这是 A/B 派能真正落地的心智前提。如果 on-call 知道"我按 SOP 操作了，结果不好我还是要被复盘追问"，那他在凌晨 3 点的理性选择一定是"等"——而"等"才是 P0 事故最贵的动作。

想听大家聊什么

我特别想听三种场景下的真实做法：

1. 你的团队 P0 事故中，on-call 回滚需要走什么流程？是"直接点"、"电话确认"、"双人在场"，还是"等平台审批"？
2. 你或者你的同事，有没有因为"等审批"导致恢复时间被拉长的真实案例？（不用脱敏到公司，讲个大概时间线就行）
3. 你怎么定义"on-call 有权直接回滚"的触发条件？ 是只看告警等级？看核心业务指标？还是"on-call 自己判断"？
4. 一个不太方便但很真实的问题：你的团队里，如果 on-call 按 SOP 回滚了、但事后证明回滚是错的（其实不是版本问题），他会被追责吗？ 这决定了你的团队里，on-call 在凌晨 3 点到底是"敢点"还是"会等"。

我自己不觉得这个问题有标准答案——A/B/C/D 四派在各自团队里都可能是对的，取决于业务形态、团队规模、事故后果的可逆性。但我觉得**"on-call 在 P0 中有没有决策权"这件事，应该被每个团队明确写下来、并且被反复演练**，而不是每次事故后临时讨论。

期待你们的真实案例。