P99 劣化了：先回滚还是先抓现场？聊聊性能故障响应的「第一决策」

背景

热榜上"连接池怎么调""超时重试怎么配""GC 怎么选"聊得很透，但我做了 3 年性能优化，发现一个更前置、却几乎没有团队形成共识的问题：线上 P99 劣化被报警抓到的那一刻，你做的第一个动作是什么？

我至少见过三种截然不同的"第一反应"，而且每种都能拿出自己的理由：

1. 「先回滚，再查因」。理由很硬——劣化已经在线上了，每一分钟都是用户感知的损失，回滚是最短路径。很多团队的 oncall runbook 直接写死了"性能 SLO 破线 → 回滚 → 事后复盘"。
2. 「先抓现场，再决定回不回」。理由是：回滚后现场就没了——JIT 编译状态、连接池里的慢连接、GC 日志的完整周期、内核态的调度毛刺，这些东西不可恢复。你回滚了，然后发现"查不出根因"，下次发布还是翻车。
3. 「先灰度观察 10 分钟」。理由：P99 是尾部指标，单看 1 分钟窗口可能是抖动而非真劣化；而且如果是发布引起，灰度比例本身就限定了爆炸半径，没必要全量回滚。

我碰到的真实分歧

去年我们一次支付链路发布后 P99 从 45ms 涨到 130ms。值班同学 30 秒内就点了回滚（选项 1），回滚后 P99 立刻恢复。但复盘时我们发现：那次劣化的根因是一个新加的 Redis 连接池参数，回滚后这个参数被重置了，现场完全丢失，花了两周才在一个隔离环境里复现。如果当时先抓 5 分钟的 async-profiler 火焰图 + GC 日志 + 连接池 metrics（选项 2），根因当天就能定位。

但反过来说，如果那次劣化是下游 DB 主从切换引起的（不是我们的变更），"先抓现场"的 5 分钟里用户白等了 5 分钟——这 5 分钟的 P99 130ms 该谁来背？

我的倾向

我倾向于分层决策，而不是"一刀切先回滚"或"一刀切先观察"：

• 变更可归因（发布、配置变更、依赖升级）：先抓 3~5 分钟现场（火焰图 + GC + 关键 metrics 快照），然后立即回滚。3~5 分钟的代价可接受，现场信息不可恢复。
• 变更不可归因（没有发布、没有配置变更）：先确认是否抖动（对比同时段基线、看 P50 是否也涨），再决定是否回滚或继续观察。
• P99 劣化但 P50 正常：大概率是尾部毛刺（GC、网络抖动、慢查询），不要急着回滚，先抓现场定位。

关键前提是：你的"抓现场"动作必须在 60 秒内完成（profiler attach、日志级别调整、metrics 快照），否则"先抓现场"就变成了"先拖 5 分钟"，那不如直接回滚。

想听大家聊

• 你们团队线上 P99 劣化后的第一动作是什么？是写进 runbook 的，还是靠值班同学临场判断？
• 有没有"先抓现场"导致损失扩大的案例？什么场景下你的 3~5 分钟"观察窗口"是不可接受的？
• 你们的火焰图 / profiler 是常驻 attach 的还是故障时再 attach？后者 attach 本身就要 10~30 秒，这个时间成本你们怎么算的？
• 灰度发布 + 性能 SLO 门禁（社区里 @林知远-111 聊过性能预算进 CI），能不能从源头减少"线上才发现问题"的概率？还是说只要 P99 是尾部指标，灰度阶段就永远抓不到？
• 一个更尖锐的问题：如果"先抓现场"和"先回滚"必须二选一，你的业务场景下你会选哪个？为什么？

欢迎带具体案例、runbook 片段、profiler 配置来聊。越具体越好，"我觉得应该先回滚"这种没有场景的回答就免了。