安全校验挂了，系统是"开门放行"还是"关门拒客"？聊聊 fail-open 与 fail-closed 的取舍

先说背景，最近我在梳理一个内部网关的安全链路：请求进来要过三道门——身份认证（调 auth 服务）、权限校验（查策略中心）、风控规则（异步打分）。这三道门任何一道抖动，都会直接影响线上可用性。于是我们组里为"门挂了怎么办"吵了一架，越吵越发现这是个没有标准答案的问题，想拿出来和大家聊聊。

我把常见的分歧摊开看，大概是这么几种做法：

第一种是"全关"派：任何安全依赖不可用，一律 503 拒掉。逻辑很干净——安全是底线，宁可不可用也不能不安全。听起来很对，但现实是：auth 服务挂 5 分钟，等于全站挂 5 分钟；如果策略中心只是查询超时，风控那边其实有兜底分数，为什么也要跟着躺平？

第二种是"全开"派：安全组件挂了就走旁路，先保可用性，事后再补审计。电商秒杀、支付回调这类场景我见过这么干的，但代价是把"安全"从硬约束降级成了"尽力而为"，出了事回溯成本极高。

第三种是"分级"派：按调用方敏感度分流——白名单内部服务、只读接口、低价值操作走 fail-open；资金、写操作、敏感数据走 fail-closed。这个最贴近实际，但复杂度和维护成本也最高，而且"哪些算高敏感"的清单本身就是一份会过期的文档。

我个人的倾向，用打比方的话说：门锁坏了，你可以先放行快递员，但不能放行陌生人；而且放行的每一笔都要记在值班本上，事后逐条复核。 也就是说我倾向第三种的细化版——默认 fail-closed，但给明确豁免清单 + 豁免期间的强制审计留痕 + 豁免时长的硬上限（比如超过 60 秒自动收紧）。理由有三点：一是安全的本质是"信任边界"，边界失守的代价远高于短时不可用；二是全 fail-open 会让安全团队失去"事故后追责"的依据；三是豁免清单 + 时限，能把"临时妥协"约束成"可审计的临时妥协"。

但我知道这个答案太"正确"了，真正想听大家聊的是场景：

1）你所在系统里，哪些安全组件挂了会直接 fail-closed、哪些会放行？判断依据是什么——SLA、业务敏感度、还是历史事故？ 2）有没有遇到过"安全组件自己变成了单点"的怪圈？怎么破的？ 3）豁免期间只记日志不够，有没有人做过"豁免期间的操作回放 / 二次审计"？效果如何？ 4）在 AI 智能体调用工具的场景下（比如 MCP 工具链里的鉴权），fail-open 的爆炸半径是不是比传统服务更大？你们怎么设防？

欢迎直接贴你们的生产配置、事故复盘片段，哪怕是"我们就是这么干的，结果翻车了"也特别有价值。