线上炸了：先回滚还是先查根因？这个值班里的老吵架，咱们摊开吵一次

【背景】 我做了 10 年运维，值班群里吵得最多、每次吵架最凶的，不是工具选型，而是出故障那一刻的决策：先回滚止血，还是先抓现场查根因？上周我们组又为这事差点吵翻——发版后 P99 抖了 8 分钟，有人喊「马上回滚」，有人说「等我把日志和 profile 抓全，就 2 分钟」。最后抓现场抓了 11 分钟，抖了 19 分钟才回滚完。复盘时两边都觉得自己对。

【常见分歧 / 几种做法】

1. 「回滚优先派」：用户感知 > 一切，先恢复再复盘，现场可以靠日志、监控、链路追踪事后还原，但用户流失补不回来。
2. 「现场优先派」：不抓现场等于把根因丢了，很多抖动（GC、连接池、锁竞争）事后再复现不出来，回滚了也就白炸一次，下次还炸。
3. 「看影响面派」：核心链路 / 资金链路先回滚，边缘服务可以留现场；按爆炸半径分级处理。
4. 「看变更类型派」：代码变更敢回滚，配置 / 数据变更（DDL、缓存结构、消息格式）回滚反而更危险，只能向前修。

【我的倾向与理由】 我偏向「分级 + 时间盒」：

• 默认规则：用户可感知的故障，回滚决策时间盒 ≤ 3 分钟，3 分钟内没确认能止血就回滚，不犹豫；
• 现场不是「抓全才回滚」，而是「最小现场快照」：一条命令级别的东西（JFR / heap dump / 当前慢 SQL / 错误日志最近 100 条）在回滚前 30 秒内并发抓走，抓不完就放弃，不阻塞回滚；
• 数据 / 配置类变更不满足「可回滚」前提时，预案必须写「向前修」路径，别指望一键回退——这是我踩过最疼的坑：一次把字段长度改大后回滚，旧代码写新表直接报错，故障时间翻倍。

一句话：回滚是默认动作，抓现场是 30 秒的并发动作，不是前置条件。

【想听大家怎么选】

• 你的团队有没有成文的「回滚 vs 查因」SOP？触发条件是什么（错误率、P99、资金损失）？
• 数据类变更炸了，你们「向前修」的预案长什么样？举一个真实案例。
• 有没有「为了抓现场多扛了 5 分钟」最后发现根因本来要靠回滚才能验证的教训？
• 值班新人第一反应抓现场不喊回滚，你会怎么带？

欢迎拍砖，最好带真实故障数据（脱敏后），空谈「应该快」的请绕道。