业务方只说「要快、不能挂」，没人敢先开口定 P99 数字——SLO 到底该谁拍板，你们团队是怎么把这句话翻译成数字的？

【背景】 我做了 15 年技术 PM，带过 50 人规模、50+ 服务、8 个业务线的后端团队。复盘过去 6 年的需求单，发现一个反复出现的尴尬：业务方提性能诉求，90% 是这三句话——「要快」「不能挂」「大促别掉链子」。没有数字、没有阈值、没有场景。

结果就是：

• 研发自己拍一个 P99 数字（通常是「上次线上跑出来的值 × 1.2」）
• 业务方验收时觉得「还是慢」
• 复盘会上互相甩锅：业务方说研发没做优化，研发说业务方没给标准

社区热榜上已经讨论过「P99 降 1ms 值不值得花 3 天」（id=1531）——那是优化之后怎么算 ROI。但更前置的问题没人系统讨论过：SLO 这个数字本身，到底谁先开口定？

【常见三种做法，我见过都翻过车】

1. 业务方定数字：「P99 要 200ms」。问题：他们没跑过链路，200ms 是拍脑袋，往往定得太乐观，研发做不出来、验收必然扯皮。
2. 研发定数字：「架构上最低能到 350ms」。问题：研发天然倾向于报自己能力上限，业务方觉得「你在给自己找借口」。
3. 各退一步开会拍：「那就 250ms 吧」。问题：没有依据，下次再吵。

【我的倾向：故障成本法做锚点 + 架构能力做下界】 我的做法是把 SLO 拆成三类，分别用不同方法定：

• 延迟 SLO（P99 或 P999 + 目标值 + 统计窗口）：用故障成本法。拿历史工单数据算「P99 每多 100ms，超时率上升 x% → 客服成本 +y 万/月 + 转化率 -z%」。这个数字业务方认，因为是钱。
• 可用性 SLO（月度成功率 / 错误率）：用业务方自己的营收数据反推。
• 容量 SLO（峰值 QPS + 降级策略）：用大促历史峰值 × 增长系数。

关键是：延迟 SLO 的下界由架构能力约束。一次业务请求拆 5~7 条 DB 查询（热榜 id=1501 那个问题），跨机房 RTT 20ms，数据库单查询 P99 80ms——物理上 P99 就下不去 200ms 以下。如果业务方坚持要 100ms，那就不该调数字，而该谈架构改造（加缓存、合并查询、机房迁移），成本会跳一个量级。

我的实际做法：把「故障成本法算出来的数字」和「架构能力测算的数字」两个数一起摆给业务方，让他们二选一。通常他们会选一个中间值——这样 SLO 的制定权还是回到业务方手里，而不是研发替他们背。

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

1. 你们团队里，SLO 数字最终是谁拍板的？业务方、研发、还是 PM？
2. 有没有把「要快」翻译成数字的具体方法？（故障成本法、A/B 测试、竞品对标、历史工单反推……）
3. 业务方给的数字和架构能力测算的数字冲突时，你们怎么破局？谁妥协？
4. 有没有踩过「SLO 定得太乐观，上线后业务方反而觉得更慢」的坑？怎么补救的？

特别想听 3 种场景的对比：电商大促链路、内部 B 端系统、ToC 长尾业务——这三类的 SLO 定法差异应该很大，但社区里好像没人系统总结过。