P99 是不是我们集体「迷信」的指标：用户投诉的到底是那 1% 的长尾，还是 P50 的体感？

【背景】 做了 15 年产品和技术，我发现一个挺有意思的现象：几乎所有团队的技术评审、SLO、告警阈值都在围着 P99 转，但真正决定续费率 / 用户口碑的，往往是另外一批人。

我见过两种典型场景，方向完全相反：

• 场景 A：一个 To C 产品，P50 = 80ms，P99 = 800ms。技术团队天天优化那 1% 的长尾，但客服工单里投诉最多的用户，其实是因为「加载超过 2 秒我就以为卡死了」——他们的耐心阈值大概在 P50~P95 之间，根本等不到 P99 那一波。
• 场景 B：一个企业级 API，P50 = 5ms，P99 = 500ms。客户合同里写的是「99.9% 的请求 < 200ms」，所以 P99 超标直接违约。这里 P99 就是硬边界，不能含糊。

两个场景里，「优化 P99」这个动作的价值完全不同，但很多团队用的是同一套 KPI 模板。

【常见分歧 / 几种做法】

1. 技术派：P99 是 SLO 的天然选择，因为 P999 成本太高、P50 又掩盖长尾，P99 是工程成本与用户体验的「甜点」。
2. 产品派：用户根本不会看分位数，他们只看「我自己那一次卡没卡」。P99 优化完，投诉率可能纹丝不动，因为投诉者集中在 P95~P99 区间的「高频踩中者」，而不是分布最右端。
3. 数据派：应该直接盯「用户会话中超过 X 秒的会话占比」或「重试率 / 放弃率」，这才是业务语言，分位数只是内部诊断工具。
4. 合同派：B 端场景下，SLO 写进合同的那一刻，P99 就不再是「指标」而是「法律条款」，争论优化它值不值得已经没有意义。

【我的倾向与理由】 我倾向于「对内用 P99 做工程诊断，对外用业务语言做 SLO」：

• 对内：P99 的价值在于它是一个可复现的、有明确优化路径的工程信号（连接池、GC、慢查询都能落到 P99 上），而「用户满意度」太模糊，没法拆到 owner。
• 对外：跟客户 / 老板沟通时，把 P99 翻译成「每 100 个请求里有 1 个会慢于 X 秒」+「对应的业务损失估算（重试、放弃、客诉、合同违约金）」。这样讨论就从「P99 值不值得降 1ms」变成了「这个 1% 的用户，我们愿意为他们的体验付出多少」——后者才是产品决策该有的框架。
• 但我也承认一个盲区：如果用户的行为模式是「短会话、高频次」（比如搜索、IM），那 P95~P99 区间的「高频踩中者」比 P99 末端的「低频极端用户」重要得多。这种情况下，分位数本身可能选错了，应该盯 P95 或者「会话级延迟分布」。

【想听大家在什么场景下怎么选】

1. 你们团队现在对外承诺的 SLO 是分位数（P99/P999）还是业务语言（可用性、延迟上限）？合同里到底写了什么？
2. To C 和 To B 产品，你们用同一套 P99 目标吗？还是两套标准？
3. 有没有遇到过「P99 降了 50%，客诉反而涨了」的情况？根因是什么？
4. 你们怎么向非技术老板解释「为什么不能只看 P50」？有没有被说服过的金句？

抛砖引玉，期待不同角色（开发 / SRE / PM / 客服 / 商务）的视角。