P99 抖了，先止血还是先定位？——线上故障响应的第一个动作，你们团队的 SOP 到底是什么？

【背景】

我做了 3 年后端，最头疼的不是开发新 feature，而是线上 P99 突然从 20ms 抖到 200ms+ 的那个时刻。告警响了，群里@我了，所有人都在看 dashboard。

我经历过两次典型的 P99 抖动，感受完全不同：

• 第一次：下游 MySQL 慢查询把连接池打满，P99 从 18ms 飙到 800ms，持续 4 分钟。当时我的第一反应是打开 HikariCP 的 metrics，看到 pending 线程数从 0 跳到 200，立刻知道是连接池的问题，5 分钟内定位到那条慢 SQL，kill 掉后恢复。这次「先定位」是对的，因为根因在 metrics 里一眼可见。
• 第二次：上游一次 Full GC 导致请求堆积，P99 从 12ms 抖到 1.2s，但 GC 只持续了 2 秒，等我看日志的时候已经恢复了。我花了 2 小时才从 GC log 里找到证据。复盘时我发现——如果当时先加了限流，P99 根本不会超过 50ms，我也不需要花 2 小时去追一个「已经消失」的问题。这次「先定位」是亏的。

两次经验让我开始认真想一个问题：P99 抖动后的第一个动作，到底该是什么？

【常见分歧 / 几种做法】

团队里对「P99 抖动后的第一个动作」至少有三派，我各带过不同人，都见过：

1. 止血派：告警响了 → 先限流 / 降级 / 熔断 → 保住 P99 → 再慢慢查。 理由：用户先于根因重要，P99 每多抖 1 秒都是真金白银的 SLA 损失。而且你不确定根因是什么，盲目查可能查偏方向。

2. 定位派：告警响了 → 先看 metrics / 日志 / trace → 5 分钟内定位根因 → 针对性修。 理由：盲目限流可能误伤——比如你限的是正常流量，根因其实是一次配置变更或一次上游发布。而且事后没有根因，同样的抖动下次还会来，你只是在「贴创可贴」。

3. 流程派：告警响了 → 按 SOP 走 checklist → 止血和定位并行。 理由：人的判断在高压下不可靠，SOP 才是可靠的。不要依赖「这个 oncall 当天状态好不好」。

三派都有道理，但落到具体操作时经常打架：止血派说「你先限流，我 5 分钟后再查」，定位派说「你限了我怎么查，现场都没了」。

【我的倾向与理由】

我个人偏向「定位优先，但设一个硬 deadline」，具体分三段：

• 前 3 分钟：只做只读操作。 看 metrics（连接池 pending/active、GC pause、慢 SQL count、网络 RTT）、看日志（error rate 有没有跳、有没有新异常堆栈）、看 trace（如果采样率够的话）。不动任何线上配置，不重启，不限流。
• 3 分钟没定位到：立刻切止血模式。 限流 / 降级 / 熔断，先保住 P99。同时保留现场：jstack dump、GC log、metrics 快照打到文件。
• 止血后：再回头定位。 这时候时间压力小了，可以慢慢查。

为什么是 3 分钟？因为 P99 抖动的根因，我统计过自己经手的 20 多次，80% 的情况在 metrics 里「一眼可见」——连接池 pending 跳了、GC pause 超了、慢 SQL 数涨了、网络 RTT 飙了。3 分钟足够扫一遍。但如果 3 分钟看不出来，说明问题可能更隐蔽（内核态、网络中间件、DNS 抖动），硬查的时间成本会指数增长，不如先止血保 SLA。

关键的一点：止血不等于放弃定位。 我在每次止血操作后都会立刻做三件事，加起来不超过 30 秒： ① jstack 留现场（jstack -l <pid> > /tmp/jstack_$(date +%s).log） ② 把当前 metrics 快照打到文件（Prometheus instant query 结果存到 oncall 目录） ③ 在 oncall 群里记一条「时间 + 操作 + 原因」

事后复盘时，这三样东西能省 2 小时。我见过太多团队止血之后现场全丢了，复盘时只能靠「我记得当时好像……」来还原，结论自然不可靠。

【想听大家怎么选】

特别想听几种场景下的选择：

• 你的服务是「状态型」还是「无状态型」？ 前者（有连接池 / 会话 / 本地缓存）限流会丢连接、丢会话，副作用大；后者（纯计算 / 透传）限流几乎无副作用，决策完全不同。你的场景下「止血」的代价是什么？
• 你的 P99 抖动是「高频低幅」还是「低频高幅」？ 高频低幅（每天抖几次，每次几百 ms）适合提前加限流兜底，把 P99 压在 SLO 以内；低频高幅（一个月一次，一次飙 10 倍）更值得事后深挖根因。你们的频率和幅度大概什么量级？
• 你的团队有没有成文的「P99 抖动响应 SOP」？ 如果有，第一个动作是什么？是写死在 wiki 里，还是靠 oncall 的直觉？有没有因为「没有 SOP」而翻过车的？
• 3 分钟这个 deadline 合理吗？ 你们团队的「定位窗口」一般是多久？太短怕误判，太长怕 SLA 崩，怎么定的？

欢迎拍砖，也欢迎分享你们团队的 SOP 和踩坑经历。我觉得这个话题比「怎么调连接池参数」更前置——参数调得再好，第一个动作选错了，一切都白搭。

【2026-10-20 修订补充：30 次实战后的数据修正 + 一个「止血反而放大故障」的反例】

发这篇之后我又处理了 10 多次 P99 抖动（累计 30+ 次），有几个数据修正和一个反例值得补上：

数据修正：

• 原来说「80% 在 metrics 里一眼可见」，30 次的实际分布是 72%（22/30）在 3 分钟内通过 metrics 定位，剩余 28% 需要超出 3 分钟。所以「3 分钟 deadline」的命中率其实比我最初估计的低 8 个百分点。
• 在 3 分钟定位失败的 8 次里，有 5 次的真正根因是节点级问题（runqueue 排队、内核态 DNS 解析抖动、同节点邻居 Pod 的 IO 抢占），这些在应用层 metrics 里完全看不到——应用层指标全绿但 P99 就是抖，这才是「3 分钟看不到」的典型指纹。
• 修正建议：如果 3 分钟内应用层 metrics 全绿（连接池、GC、慢 SQL、网络 RTT 都正常），不要继续硬查应用层，直接切到节点级：perf sched record、/proc/pressure/cpu（PSI）、iostat -x 1，大概率是邻居或内核的事。

反例：止血反而放大故障： 有一次下游 MySQL 主从切换（~8 秒），我们的 SOP 是「P99 超 200ms 就触发限流」。结果限流触发后，上游调用方（3 个服务）的超时是 500ms，限流导致的 503 响应让它们全部走 retry，retry 又撞上了正在切换的数据库——限流把「8 秒的短暂抖动」变成了「45 秒的级联超时风暴」。事后复盘：这次止血操作不仅没保住 P99，反而把影响面从 1 个接口扩大到 3 个服务的 500 个请求。

教训：止血操作本身也要有「副作用评估」这一步——限流前问自己：上游的超时是多少？retry 策略是固定间隔还是指数退避？如果上游 retry 是固定间隔 200ms × 3 次，你的限流窗口超过 600ms 就会触发 retry 风暴。我现在的 checklist 里加了一条：「限流前确认上游 timeout × retry_count > 预期限流持续时间，否则改用 429 + Retry-After 而非 503」。

状态型服务的止血代价（补充具体数据）： 我们的订单服务是有状态的（HikariCP 连接池 + Redis 会话 + 本地 L1 缓存），一次「紧急重启 Pod」止血，实际代价是：

• 连接池 200 个连接全部断开，上游 3 个服务同时重连，MySQL 的 Connections 在 2 秒内从 800 跳到 1400，触发了 max_connections 限流（1500）——重启止血反而把 MySQL 推到了连接数上限；
• Redis 会话丢失，约 12% 的活跃用户被踢出登录态；
• L1 缓存冷启动，前 30 秒 P99 从 20ms 回到 80ms（缓存 miss 打到 L2）。

所以状态型服务的「止血」选项其实比无状态服务少得多，重启往往是最后手段而非第一手段。