P99 到底是「目标」还是「预算」：你们团队给接口定 SLO 时，是逐接口拍一个数，还是从端到端链路倒推？

【背景】 做高并发后端五年，最近一次复盘把我搞沉默了：我们某个核心下单接口的 P99 SLO 定在 80ms，达标率全年 99.5%，业务方非常满意。但后来拆链路才发现，这个接口的 P99 有 60% 的时间花在一个下游「风控评分」上——而风控那边自己的 SLO 是 120ms。也就是说：一个 120ms 的下游，居然能稳定满足一个 80ms 的上游 SLO。靠的是上游把超时压到 60ms、超时后走降级兜底。表面上 SLO 很漂亮，实际上我们把「延迟」换成了「功能可用率」，只是没人把它写进任何指标里。

这件事让我开始怀疑一个更基础的问题：我们平时给接口定 P99 SLO 的方式，可能从一开始就拧了。

【常见的几种做法，各有硬伤】

1. 逐接口拍脑袋定：「这个接口 P99 定 50ms」「那个定 200ms」，通常参考竞品或历史 P99 打个折。问题：每个接口各自达标，但端到端链路上每个环节都在「消耗」用户能感知的延迟预算，没人加总，最后用户体感很差而每个接口都绿着。
2. 从用户体验倒推「端到端预算」再切分：先定「用户从点击到看到结果」的 P99 预算（比如 300ms），再按调用链拆到每个下游。听起来正确，但实际落地时：调用链深、分支多、还有异步消息，切分方案经常和业务方来回拉扯三轮，最后又退化成方案 1。
3. 不定 SLO，只盯 P99 趋势 + 告警：P99 环比涨 20% 就告警。问题：没有「达标/不达标」的语义，P99 从 400ms 涨到 480ms 也会触发，而 400ms 本身可能早就该红了。

【我的倾向】 我偏向「预算倒推为主、逐接口兜底」的混合做法，但有几个前提必须成立，否则不如退回方案 1：

• 预算切分不是按调用次数平摊，而是按「该环节对总延迟的实际贡献占比 + 该环节的可压缩空间」来分。比如一个环节当前 P99 贡献 40ms、且历史上压缩过 3 次已经到瓶颈了，就不该再压它，而是去压另一个 20ms 但还没动过的环节。
• SLO 必须绑定「错误预算的消耗者」：谁超了预算，谁承担降级/熔断的决策，而不是让网关或上游默默吞超时。
• 对每个接口同时暴露 P99 和「超阈值计数」（比如 >100ms 的请求数），因为低频接口 1 分钟窗口里 P99 样本根本不够看（社区里 #1625 也在讨论这个），超阈值计数才是稳定可比的信号。

但我自己也没想透两个点：预算倒推在「异步链路」（消息队列、定时任务、离线对账）里基本失效，因为「用户等待时间」这个锚点消失了；另外，预算切分方案一旦定下来，业务加接口、链路重构时维护成本很高，我怀疑很多团队不是不想做，是维护不起。

【想听大家聊聊】

1. 你们团队的 SLO 到底是怎么定的？逐接口拍、链路倒推、还是干脆不定只盯趋势？定完之后多久 review 一次？
2. 「下游 P99 高于上游 SLO、靠超时降级兜底」这种模式，你们是有意为之还是无意识形成的？有没有把它显式化（比如降级率单独成指标）？
3. 异步链路（MQ 消费、批处理）你们怎么做延迟承诺？「端到端延迟」这个概念在异步场景下你们是怎么定义和度量的？
4. 有没有团队真的把「延迟预算」做到了自动化——链路变了预算自动重切？还是全靠文档 + 人肉对齐？

欢迎贴具体的数字和链路结构，空谈方法论的咱们评论区接着掰。