安全加固的性能成本该不该进 SLO：加 TLS 双向认证 / 审计日志 / 密钥轮换，谁来为被吃掉的 P99 买单？

【背景】 热榜这两天几乎全是性能调优：连接池、P99 抖动、超时重试、ROI 怎么算。我做了 8 年安全加固，看着有点扎心——大家拼命把 P99 往下压 1ms，可有些「安全项」本身就在悄悄吃这 1ms：

• 内网服务间加 mTLS / 双向认证：多两次握手 + 证书校验，长连接占比低时 P50 能涨 1–3ms；
• 全量审计日志（含请求体脱敏落盘）：同步写日志时 I/O 抖动直接打到 P99；
• 密钥 / 凭据定期轮换 + 启动时校验：冷启动时间、连接重建成本；
• WAF / RASP 这类旁路或旁挂防护：每请求多一次策略匹配。

这些加起来，在你们压测报告里可能只占百分之几，但「没人认领」——性能团队说这是安全加的东西，安全团队说这是合规底线，最后 P99 超标时谁背锅？

【常见分歧 / 几种做法】 我见过三种典型站队：

1. 「安全是硬约束」派：合规 / 等保 / 审计是红线，性能让路，P99 超标就扩容或砍业务功能，安全项不动；
2. 「性能优先」派：把安全加固当「可选优化项」，压测不过就降级——审计改异步采样、mTLS 只在外网开、内网裸跑；
3. 「算账派」：每项加固单独量化性能成本，写进容量规划，超预算就协商降级，但要有数据、有 owner。

【我的倾向与理由】 我偏向第 3 种，而且立场很明确：安全加固的性能成本必须像 CPU/内存一样被「定价」，进 SLO 的预算里，而不是事后甩锅。理由三条：

• 安全项和性能项本质都是「用资源换确定性」，一个换的是可用性，一个换的是可控性，没有天然的高下之分，应该在同一张预算表里比较；
• 「内网裸跑、外网才认证」这类降级，恰恰是横向移动（lateral movement）事故里最常见的口子——攻击者一旦进内网，裸链路就是它的高速公路；
• 真正翻车的往往不是「加固太贵」，而是「加固没被计量」，于是被随手降级，降级又没人记录，审计一查全是窟窿。

一句话小结：安全成本要么进预算、要么留痕降级，最怕的是「默默吃掉 P99 还没人认领」。

【想听大家在什么场景下怎么选】 特别想征集真实案例：

1. 你们的安全加固项，有没有被性能团队「降级/豁免」过？当时怎么谈的，最后留没留痕？
2. mTLS / 审计日志这类，你们是同步全量、异步采样、还是内外网差异化？触发降级的量化阈值是什么（比如「审计占比 > X% 就采样」）？
3. 安全项的性能成本，有没有人真的写进 SLO 预算 / 容量规划？怎么和性能团队对齐 owner 的？
4. 反过来：有没有「安全加固反而让 P99 变好了」的反例？（比如强制连接复用、强制超时，顺手把资源泄漏堵了）

欢迎贴你们的配置、数据、踩坑，安全 + 性能这俩硬骨头一起啃，比各算各的账有意思。