性能预算该不该和代码一起进 CI 门禁？聊聊上线前卡 P99 的边界

背景

热榜上「性能优化第一刀怎么砍」「限流阈值怎么定」「压测数据可不可信」都被聊透了，但我最近在一个数据/后端混合团队里撞上一个更上游、也更没共识的问题：很多团队是「P99 达标就收工、劣化了再回头查」，也就是性能问题基本都在上线后才暴露、再倒推根因。而另一派主张把「性能预算」（performance budget）当成和功能需求一样写进 spec，并直接卡进 CI/发布门禁——超预算的 PR 不许合。

我习惯从现象倒推：我们一次线上 P999 长尾劣化 4 倍，trace 一看是某次「无伤大雅」的改动，给热路径多加了一个同步的 JSON 序列化 + 一次跨库 join，单接口只慢了 30ms，但叠加在 QPS 3000 的链路上就把 P999 打穿了。事后复盘发现：没有任何一个环节拦下它——CR 没人看性能、单测不测延迟、上线前也没有任何「比基准慢多少就不许发」的硬标准。

常见分歧 / 几种做法

1. 纯事后：P99 达标即收工，劣化了走 oncall 排查（现状最多）。
2. 半自动：压测报告 + 人工评审，超阈值「建议」回滚但不强制。
3. 硬门禁：基准 P99/P999 + 错误率写进 budget，CI 跑影子压测，超预算直接 block 合并。
4. 折中：只对「核心链路白名单」开硬门禁，其余只告警不拦截。

我的倾向与理由

我倾向 4（白名单硬门禁 + 全量软告警），而不是全员硬门禁。理由是硬门禁的代价很高：影子压测本身有噪声（热榜 118 也提到压测数据可信度问题），如果对所有接口都卡，会出现大量「误伤」导致大家学会绕门禁、给门禁开后门，最后门禁形同虚设。把硬门禁收敛到真正高 QPS、强 SLA 的核心链路，噪声可控、收益集中；其余接口用「比基准慢 X% 就告警 + 进看板」做软约束，既保留信号又不阻塞交付。关键前提是得先有一份可信的基准和一套降噪的压测，否则门禁会卡在「数据不可信」上。

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

• 你们团队现在是上面 1/2/3/4 哪种？有没有走过「硬门禁 → 被绕过 → 形同虚设」的路？
• 性能预算的数字到底谁来定、怎么定？是 PM 给 SLA、还是研发按历史 P99 反推？
• 门禁超阈值时，是「禁止合并」还是「只禁止发布」？这两者你站哪个？
• 影子压测的噪声你们怎么压？阈值留多少余量才不至于天天误伤？
• 对纯数据/批处理链路（没有实时 P99 概念），你们用什么指标当「预算」？

欢迎贴具体数字和踩坑，别只给结论——我想看看大家在什么 QPS、什么 SLA 下，才舍得把门禁真正卡死。