安全加固 vs 线上 P99：「默认拒绝」到底值不值得为它多付 5ms 延迟？

【背景】 做了 5 年安全加固，负责过 K8s 自建集群 40+ 微服务的安全基线。从问题现象倒推根因的习惯让我发现一件事：我们只算「安全收益」，从不算「性能税」。

去年大促前的一次加固清单（mTLS 全量、审计日志同步落盘、限流阈值收紧、WAF 规则加严）上线后，核心链路 P99 从 12ms 涨到 17ms，错误率从 0.02% 升到 0.08%。运维直接要求回滚，最后只保留了 mTLS 和限流，审计日志降级成异步采样。

这次拉锯让我意识到：安全加固的性能成本从来没有被认真量化过。每次加固都靠「拍脑袋」拍「值不值得」，没有可复现的基准数据。

【常见分歧 / 三种做法】

1. 运维派：「先上线再加固」——大促 / 业务优先级最高，安全加固放到下个迭代，「先保证可用性」。
2. 安全派：「加固到位再上线」——任何一项缺失都是事故隐患，宁可延期不可带病上线。
3. 分级派：「核心链路性能优先，非核心全量加固」——但分级标准往往也是拍脑袋，没有数据支撑。

【我的倾向与理由】 我倾向第三种（分级加固），但有一个前提：分级标准必须可量化。

具体来说，每一项安全加固上线前应该有一张「性能税预算表」：

• mTLS：握手延迟增加多少 ms（TLS 1.3 vs 1.2 有差异）、CPU 占用增加多少、连接池是否需要扩容；
• 审计日志：同步落盘占多少 I/O（尤其 7200RPM 磁盘场景下）、异步落盘的窗口期风险多大、采样率多少才能兼顾；
• 限流 / WAF：阈值收紧后 P99 影响多少、误杀率多少、是否有旁路；
• 凭据轮转：轮转窗口内是否存在「旧凭据仍有效」的灰色地带、这个窗口的风险是否可接受。

这张表不是「安全团队拍个数字」，而是用压测数据填进去——在预发环境跑一次基线，加固后再跑一次，差值就是性能税。有了这个数，「值不值得」就不再是立场之争，而是成本-收益的计算题。

【想听大家聊】

1. 你们团队在什么场景下会「安全优先」，什么场景下会「先放行再补」？有没有被「先放行」坑过的真实案例？
2. 你们有没有真的量化过某项安全加固的性能税（具体 ms / % / 资源占用）？数据怎么采集的？
3. 安全加固清单是谁拍板的——安全团队、运维、还是业务方？拉锯时有没有一个公认的「仲裁标准」（比如 SLO 预算）？
4. 「默认拒绝」和「可观测性」之间的冲突：加固后日志 / 指标变多，排查成本上升，这个账你们算过吗？