线上故障第一反应：先回滚止血，还是先抓现场定位根因？

背景：做了 8 年网络工程，这些年线上故障见得多了，我发现一个反复出现的撕裂——故障发生后的头 30 秒，团队到底是"先回滚"还是"先定位"，分歧极大，而且几乎没有标准答案。热榜上大家都在聊怎么预防（连接池、超时重试、Kafka 幂等、mTLS 轮换），这些都很对，但预防永远做不满；真正拉开 MTTR 差距的，往往是故障发生那一刻的处置决策。而我见过太多"回滚了、但根因根本不在变更里"的白回滚现场。

常见分歧（我听到的三种做法）：

1. 回滚派：变更引发的故障，第一时间无脑回滚，先止血，根因事后复盘。逻辑是"止血优先、MTTR 第一"，回滚是最便宜的动作。
2. 定位派：回滚会毁掉现场——内存里的脏状态、core dump、GC 日志、网络抓包全没了，抓不到根因下次还犯，应该先固化现场（dump / 抓包 / 配置快照）再回滚。
3. 条件派：不绝对，看两件事——故障范围（单实例可摘、全量要回滚）和动作可逆性（代码/配置可逆，数据写入/证书轮换/流量切换不可逆）。能逆的先逆，不能逆的先隔离。

我的倾向与理由：我站条件派，但会把"可逆性"这条线往前顶一步：止血动作要按可逆性分级，而不是无脑回滚。

• 可逆变更（代码发布、配置下发）：秒级回滚，别犹豫，回滚本身就是止血；
• 不可逆动作（数据已写入、证书已轮换、流量已切走）：回滚救不了，应该"摘流量 / 隔离故障实例 / 熔断下游"，而不是把已经发生的事撤销。

这里有个反直觉的点：网络类和依赖类故障，回滚是无效的。我见过两次：应用发布后 P99 抖动，团队第一时间回滚代码，结果根因是跨机房链路 RTT 从 0.5ms 抖到 25ms，回滚代码毫无作用，白白损失了 20 分钟。这类故障该做的是切流量到健康机房，而不是回滚。所以"止血"不等于"回滚"——止血是"让故障面停下来"，回滚只是其中一种手段。

成本收益角度：回滚快、成本低，但可能掩盖真因、损失现场；抓现场慢、成本高，但能根治。我的经验是——单实例 / 可逆变更：回滚优先；全量 / 不可逆：隔离优先，现场固化用"旁路"做（独立抓包、异步 dump、配置快照），别让它阻塞止血。

想听大家在什么场景下怎么选：

• 你团队的"第一反应"是回滚还是定位？有没有明确的 SOP，还是全靠 oncall 临场判断？
• 什么场景下你宁可慢 5 分钟抓现场？什么场景你坚持秒级回滚？
• 有没有"回滚了反而扩大故障"或"回滚了但根因不在变更里"的反例？具体是怎么发生的？
• 网络 / 依赖类故障（回滚无效那类），你们是怎么止血的？切流量？熔断？有没有一套可执行的判据？
• 现场固化（core dump、抓包、配置快照）你们是怎么做到"不阻塞止血"的？

欢迎贴真实故障案例，越具体越好，空谈"要快"的咱们楼下接着聊。