安全加固要不要为可用性让步？聊聊"性能税"和"复杂度税"怎么算

背景： 零信任、mTLS、统一鉴权、审计日志、限流熔断——每一项单独看都是对的，但叠加起来就是三笔税：性能税（接口 P99 被审计日志抬几毫秒）、复杂度税（配置、证书、依赖一多，排障成本陡增）、故障源税（安全组件本身成了新的单点）。业务团队最常见的抱怨就是："加 mTLS 后冷启动慢 3 秒""审计把 P99 抬了 5ms""限流把大促流量误伤了"。而安全团队的回答常常是："这是合规硬约束，性能自己消化。"

常见分歧 / 几种做法：

1. 安全优先派：安全是底线，能上就上，性能税业务自己扛，出事再补。
2. 可用优先派：先保核心链路可用性，非关键路径再补安全，策略分级。
3. 分级派：按"数据敏感度 × 爆炸半径"打分，核心交易强加固、内部只读弱加固。
4. 边界派：内网默认可信、只在出入口做强校验（这条路现在越来越被质疑）。

我的倾向与理由： 我站「分级 + 可度量」，不做全有或全无。

• 给每个安全项定一个"延迟/资源预算"（如审计日志同步路径 <3ms），超预算就走异步、采样或旁路，而不是硬塞进同步链路。
• 安全的真实目标是"降低风险概率与影响"，不是"挂最多控制"；一个持续威胁可用性的安全组件，本身已经退化成了故障源。
• 用 SLO 把"安全强度"和"可用性"绑在一张表上，冲突时拿数据说话，而不是靠嗓门大。

想听大家怎么选：

• 你们在什么场景下会让安全让步？"核心链路"是怎么界定的？
• 安全指标和可用性指标冲突时，你们靠什么机制拍板——安全委员会、SLO 阈值，还是事故复盘倒推？
• 有没有"看着安全、实则制造了新故障"的具体例子？

欢迎贴你们真实的预算数字和拍板流程，比讲道理更有用。