P99 到底是性能指标的万金油，还是最容易骗人的那个数？

背景 热榜上几篇 P99 抖动、超时重试、连接池的帖子我都读完了，大家排查路径都很扎实。但我复盘自己这 15 年做指标体系时发现一个反复出现的现象：团队越把 P99 当唯一北极星，线上反而越「看起来在变好、体验在变差」。典型症状是 P99 一路从 200ms 降到 120ms，但用户侧投诉没降、错误预算还在烧。我习惯从现象倒推根因，越拆越觉得问题出在「选指标」这一步，而不是「调参」那一步。

常见分歧（几种做法）

1. P99 万金油派：一个数搞定容量、告警、SLA，简单、好对比、好写进文档。
2. SLO / 错误预算派：用错误率 + 预算燃烧率做告警，P99 只当参考，理由是 P99 会被少量慢请求绑架、噪声大、不适合直接设阈值。
3. 分位数区间派：同时看 P50/P99/P999，甚至把 P99 和均值一起看，认为单点分位数必然失真。
4. 业务指标派：根本不看 P99，直接看「下单成功率」「首屏可交互时间」这类用户可感知指标。

我的倾向与理由 我倾向「分场景分层」，而不是非此即彼：

• 容量与回归对比用 P99（或 P999）没问题，因为分位数对尾部稳定、可复现，适合做前后对比和压测基线；
• 告警我不建议直接用「P99 > Xms」，而是用错误预算燃烧率 + 错误率，因为 P99 受冷启动、GC、慢客户端污染，单点阈值会误报成灾；
• 用户体感用业务指标，P99 只是它的下游解释变量。 关键纪律：任何分位数指标必须固定采样口径（分母是什么、是否含重试、是否含 4xx/5xx、时间窗多长、是否按服务/租户分桶），否则跨团队、跨版本根本没法比——这才是 P99「骗人」的真凶，不是分位数本身。

想听大家怎么选

• 你们团队 P99 的分母到底包不包含重试和快速失败？
• 告警阈值是拍 P99 绝对值，还是走错误预算？踩过哪种坑？
• 多租户 / B 端 SaaS 场景下，分位数要不要按租户分桶，还是只看全局？
• 压测基线里 P99 和 P999 你们信哪个，为什么？

欢迎把你们的指标口径、踩坑、反例都贴出来，我整理成一篇「分位数指标选型速查」。