同一个 P99，三个团队算出三个数：分位数的「口径」到底该谁来定？

【背景】

做了 8 年技术文档，最近帮三个不同团队做「可观测性指标口径梳理」时撞上一件事：

同一个接口、同一个时间窗（最近 5 分钟），三个团队报出来的 P99 分别是 47ms、63ms、81ms。

原因不是数据错了，而是「怎么算 P99」这件事，三家做了三个选择：

| 维度 | 团队 A | 团队 B | 团队 C | |------|--------|--------|--------| | 采样粒度 | 每 1s 一个分位 | 每 10s 一个分位 | 每 30s 一个分位 | | 聚合方式 | 对分位再取 max | 对分位取 avg | 对原始值排序取 99 分位 | | 分位算法 | 线性插值（type 7） | 最近秩（type 1） | 未说明（默认 Prometheus histogram_quantile 逻辑） |

三个数字都是"对的"，但 oncall 看到的告警阈值、SLO 的 error budget、PM 看到的 SLA 报表，全都对不上。

【常见的几种分歧】

1. 窗口之争：固定窗口（5 min）容易"吃掉"尖刺；滑动窗口（tumbling）计算重；histogram_quantile 本质是对桶插值，桶太粗直接失真。
2. max vs avg：对子分位取 max 偏保守（告警多），取 avg 偏乐观（漏报多）。很多团队"默认"选了 avg，没人拍板过。
3. 分位算法：Prometheus 的 histogram_quantile 和 Datadog / Grafana 的 percentile 实现细节不同，同一个数据喂进去数字能差 5%–15%。
4. 谁定口径：SRE 定？业务团队定？平台组定？实际中往往是"谁先用谁说了算"，后来者被迫对齐。

【我的倾向】

我倾向于：口径是平台层的契约，不是每个团队的自选动作。

理由：

• 技术文档工程师的视角是"同一术语在不同上下文里含义一致"才能降低沟通成本。P99 如果每个团队一个定义，文档里写"P99 < 100ms"这句话就是没有意义的。
• 具体做法：平台组发布一份「分位数计算规范」，锁定窗口、采样粒度、算法（type 7 线性插值）、聚合方式（跨子窗口取 max），各团队只允许在此基础上加业务过滤条件。
• 代价：初期有迁移成本，但比"每次 oncall 开会先花 10 分钟对齐数字"便宜。

但我有一个没想清楚的问题：如果平台强制统一口径，会不会出现"口径正确但业务感知不准"的情况？ 比如一个接口 P99 在 50ms 和 120ms 之间波动，统一口径下告警阈值设 100ms，实际用户感知在 80ms 就开始抱怨了——这时候"口径正确"反而不如"业务自定义阈值"好用。

【想听大家聊聊】

1. 你们团队 P99 的口径是"平台统一"还是"各团队自选"？踩过什么坑？
2. 分位数聚合你选 max、avg 还是 p99-of-p99？为什么？
3. 有没有遇到过"口径对了但业务体感不对"的情况？怎么解的？
4. 如果让你给一个 50 人规模的 SRE 团队定分位数规范，你会写哪几条？

欢迎拍砖。我会在帖子下面持续补充我梳理到的不同口径的实际差异数据。