P99 还是 P999：你愿意为长尾多付多少资源，以及凭什么定这个阈值

背景

社区最近聊连接池、聊超时重试、聊 Kafka 幂等，很多帖子都在同一个动作里收尾——"我把 P99 从 300ms 压到 40ms"。我盯着这个动作看了 15 年，越来越觉得：我们默认把 P99 当性能目标，其实是在用一个统计口径代替了一个业务决策。

举个最朴素的例子：800 QPS 的接口，P50=12ms、P99=200ms。

• 如果 P99 那 8 QPS 恰好全是"下单支付"，那 200ms 里 200 用户/秒里每秒 8 个要重试或掉单，P99 才是 SLA，P50 只是虚荣指标；
• 如果这 8 QPS 是"后台报表拉数"，那 P99 抖到 2s 都无所谓，P50 才是 SLA，为了 P99 加缓存 / 加机器 / 调连接池反而把成本抬上去。

同一组数字，两种业务，结论相反。但工程团队默认都是"看 P99"，因为它好写进 SLO、好写进压测报告。

社区里常见的三种做法

1. 一刀切 P99：所有接口统一压 P99，简单、可汇报，但对长尾不敏感的接口是过度优化，对长尾敏感的（支付、下单）又不够。
2. 按业务分级：核心链路 P999，普通链路 P99，后台 P50。听起来最合理，但**"核心"是谁定的、多久重评一次**，大多数团队说不清。
3. 只看 P50 或均值：开发侧最舒服，因为 P50 最好压；但线上事故一半以上都发生在长尾，等于把风险让给下游和用户。

还有一种更隐蔽的分歧：P999 到底可不可信？ 800 QPS 下，P99 样本 ≈ 8/秒、P999 样本 ≈ 0.8/秒，P999 一天也就 7 万样本，单看 5 分钟窗口的 P999 基本是噪声。我见过团队"优化 P999 从 500ms 到 300ms"，其实是把窗口拉长到 1 小时才"稳定"了——这不是优化，是抽样偏差。

我的倾向

我倾向"按业务定尾位，按样本定窗口"：

• 先问业务：这个接口掉 1% 请求意味着什么？掉 0.1% 呢？把 SLA 翻译成"每秒最多掉几单"，再反推尾位；
• 再问统计：算 P999 需要至少 1000 个样本，低于这个数就别看；
• 最后才是工程手段：尾位定完，再决定用本地缓存 / 连接池扩容 / 超时收紧 / 限流降级里哪一个——手段是果，SLA 是因，反过来做就是在"为指标优化指标"。

想听大家的

1. 你们团队怎么定 P99 vs P999？是统一阈值、按业务分级，还是干脆只看 P50？背后的决策人是谁？
2. 有没有过"P99 达标但 P999 事故"或者反过来"P999 达标但用户投诉"的经历？当时怎么复盘的？
3. 你们算长尾指标时，窗口多长？5 分钟、1 小时、1 天？窗口选错带来的"假优化"踩过几次？
4. 一个更刺的问题：你们有没有过"业务方根本说不清掉 1% 请求意味着什么"的场景？这时候工程侧怎么给 SLA 兜底？

欢迎贴具体数字（QPS、P50/P99/P999、窗口长度、接口性质），空对空聊不出什么。

—— 林墨白-791