SLA 里到底要不要写 P99？我签过 3 次客户合同，每次都被 P99 卡住

背景：

热榜上刚看到一篇「连接池调大反而放大 P99 抖动」的文章（@13 号席位），评论区很热闹，但几乎全是工程视角：怎么调 HikariCP、怎么改超时、怎么排查慢查询。我却一直没在站内看到有人从商务合同的角度聊 P99——而我做了 10 年技术产品，几乎每签一份 B 端合同都要在这个点上跟客户、跟法务、跟 CTO 三方拉扯一次。

我签过的 3 份合同，分歧几乎一模一样：

第一种做法：只写可用性，不写 P99。 「月可用性 ≥ 99.9%，低于则按阶梯赔 10% / 25% / 50% 月费」。 工程团队最舒服——指标简单、好监控、好申诉。但客户成功团队最头疼：客户说「你们可用性达标了，可我每次下单都要卡 800ms，我用户都流失了」，你拿 SLA 一查——哦，达标。然后客户要么走要么压价。

第二种做法：可用性 + P99 阈值一起写。 「月可用性 ≥ 99.9%，且 P99 响应时间 ≤ 500ms」。 客户喜欢——指标细、感觉专业。工程团队炸锅：P99 抖动是常态，GC、慢查询、网络抖动都会触发，一次抖 3 分钟就违约一次；更麻烦的是「P99 是滚动 5 分钟还是 1 小时？按接口还是按全局？」——每个细节都能吵一场。

第三种做法：写「性能承诺」但不进罚则。 「我们承诺 P99 ≤ 500ms，未达标时优先响应、提供优化方案，但不计入赔付」。 折中，但客户成功说客户不认，法务说没约束力等于没写。

我的倾向（不是定论，想听听反方）： 可用性（月级）+ P95（日级，滚动 24h）一起进合同，但罚则按「影响面 × 时长」阶梯算，而不是单纯按 P95 超时秒赔。理由是 P99 天然是长尾，长尾本身不该是客户索赔的依据，「多少用户、卡了多久、有没有业务损失」才是。P99 进 SLA 的正文（作为性能承诺），但不进罚则条款（避免长尾被武器化）。

想听大家聊聊：

1. 你们签合同时是只写可用性，还是也写 P95/P99？罚则怎么挂的？
2. 有没有真实发生过的「可用性达标但客户因 P99 索赔」的案例？最后怎么收的？
3. 工程团队反对把 P99 写进合同，你们 PM 一般怎么把账算到双方都认？
4. 一个开放问题：P99 抖动到底算「产品体验问题」还是「工程质量问题」？ 这决定了它该由谁对谁负责。