高并发接口的 SLO 到底该盯 P99、P999 还是干脆只看错误率？聊聊分位数之争

背景

我做了 8 年数据工程，长期泡在高并发链路的性能调优里。这几年我发现一个奇怪的现象：社区里关于"怎么把 P99 打下来"的文章汗牛充栋（连接池、超时重试、Kafka 幂等、慢查询都写透了），但很少有人正面回答一个更前置的问题——我们到底该把 SLO 定在哪个分位数上？ 是 P99？P999？还是干脆只看错误率 + P50？

我见过太多团队在这上面"各打各的"：监控大盘挂着一排分位数，但真正做容量规划、做 oncall 告警、做业务方 SLA 谈判时，大家用的根本不是同一个数。结果就是"看起来 P99 达标了，但用户骂声不断"或者"P999 很好看，但 99% 的长尾用户根本感知不到"。

几种常见做法（也是分歧点）

1. P99 派：认为 P99 是"用户体验底线"，能覆盖 99% 用户，且比 P999 稳定、可解释，告警噪声小。代表理由：分位数越高，单个慢请求的抖动对指标的放大越夸张，P999 在低 QPS 接口上几乎是"一个请求定生死"，不可作为稳定 SLO。
2. P999 / 长尾派：认为对交易、支付、下单这类链路，真正伤害用户的是"那 1% 的长尾"，P99 达标但 P999 爆炸照样出事故（比如一次 GC 抖到 300ms，P99 几乎不动，P999 直接翻 3 倍）。主张盯长尾 + 错误率双指标。
3. 错误率 + P50 派：认为分位数天然不稳定、不可加、难做容量模型，主张用"错误率 + 中位数 + 绝对阈值"组合，把"长尾"交给专门的 tail-attributable 监控（比如把超过某阈值的请求单独打点计数），而不是靠 P999 这种统计量。
4. 混合派：对外 SLA 用 P99（好谈、稳定），对内 oncall 用 P999 + 错误率（早发现），容量规划用 P50 + 绝对并发（好建模）。

我的倾向与理由

我偏向混合派，但有一个原则：分位数的选择必须和"该指标用来做什么"对齐，而不是和"业务有多重要"对齐。

• 对外 SLA：用 P99。理由是它稳定、可加性好、能被业务方理解，且"99% 用户"这个语义本身就是谈判单位。
• 对内 oncall：用 P999 + 错误率 + 一个"绝对超时计数"（比如 >500ms 的请求数），因为 oncall 要的是早发现，长尾抖动必须被放大。
• 容量规划：用 P50 + 绝对并发 + 错误率。理由是 P99/P999 在容量模型里几乎不可用（不可加、不可预测），硬用它建模必然失真。

核心是：别用一个分位数去回答所有问题。P99 回答"用户体验"，P999 回答"系统健康"，P50 回答"系统容量"。混着用，就会出现"指标达标但事故照出"的悖论。

想听大家

1. 你们的 SLO 到底定在哪个分位？对外和对内是不是同一个数？
2. 低 QPS 接口（比如日均几千次）你们还敢用 P999 吗？还是直接退化成错误率 + 绝对阈值？
3. 有没有团队真的把"绝对超时计数"（比如 >500ms 请求数）作为一级告警指标？效果如何？
4. 容量规划时，你们是怎么处理"分位数不可加"这个问题的？有没有可复现的建模方法？