事故通常由多层防御同时失效造成
别名: 多层防御失效 · 瑞士奶酪模型 · defence in depth
概念解释
多层防御失效（layered defence failure）是工业与安全关键系统里对"重大事故为什么会发生"的标准解释框架：危险不是被某一个环节直接放出来的，而是依次穿过了预防、检测、控制、缓解等多道本应独立的屏障，恰好每一道都在同一时刻处在失效或削弱状态。这个框架背后的组织事故模型（organizational accident model，常以瑞士奶酪模型指代）在人因分析里已经把"防御为什么能叠加起作用、共因失效如何抵消这种叠加"的机制讲清楚了；这里要讲的是另一件事：一家工厂、一座电站、一家医院要怎么把这套框架变成日常能执行的安全管理实践，而不是停留在"画几层奶酪片"的比喻上。
机制
在真实的工业现场，"防御层"不是抽象概念，而是对应到一串具体、性质完全不同的机制：操作者的培训与资质、书面操作规程、人机界面上的约束（比如非法操作路径在界面上就走不通）、物理联锁与硬件表决逻辑、独立的监督检查与审计。这些机制分别来自不同的部门、不同的预算科目、不同的更新周期，这本该是它们互相独立的来源。但安全管理体系（safety management system，SMS）如果只按科室分别管理这些层——培训部门管培训、维护部门管联锁、质量部门管审计——就会漏掉一种真实存在的风险：某一次上游决策同时压到了好几层上。最常见的情形是一次预算削减：削减金额分摊到培训时长、备件库存、维护频率、监督检查排班上，表面看是四个不同部门的四项独立调整，实际上共享同一个触发原因，会在同一时间窗口里一起变弱。这种共因关系不会在任何一层的常规台账里单独暴露，因为每个部门看到的都只是"我这层今年紧张一点"，没有人拼出全貌。
怎么研究
工业安全里核实这套框架有没有真落地，靠的不是重新论证瑞士奶酪模型成立与否，而是独立性审查（independence review）这类具体做法：把某个危险场景涉及的每一层防御列出来，分别标出它们各自依赖的人员、预算来源、供应商和信息系统，再检查这些依赖项之间有没有交叉。常见的操作是拉出近几年的预算调整记录、人员编制变化记录、供应商合同变更记录，逐条对照防御清单，看一次变更是否同时触及了两层以上。另一类做法是复盘"近失事件"（near miss）而不只是复盘已发生的事故——近失事件里往往只有一层真正拦住了危险，检查那唯一起作用的一层当时是否也已经被同一压力削弱到临界状态，只是还没被压穿。方法论上要注意：独立性审查得出的"这两层共享失效原因"结论，事后核对容易显得理所当然，但审查本身必须在事故发生前基于台账和合同记录推进，不能靠调查组事后归纳。
边界
这套组织实践在两种情况下会落空。其一，如果安全管理体系把审查做成一次性的项目评审（比如只在新建工程投运前做一次依赖关系图），而不是随预算和人事变动持续重跑，那么审查完成之后发生的任何一次共因决策都不会被捕捉到，纸面上的独立性图谱会随时间推移而失真。其二，对那些高度依赖现场人员实时协调、层与层边界会随异常处理动态重组的场景（比如经验丰富的班组在设备异常时临时互相补位），预先画好的静态依赖关系图本身就不能完整代表当时的防御结构，独立性审查能覆盖的只是常规配置下的共因风险，不能替代对动态适应过程的单独分析。
怎么落地
- 把安全管理体系里原本分散在各部门的防御层台账合并成一张跨部门依赖表，标出每一层背后的预算科目、人员编制和外部供应商，作为独立性审查的基础数据，而不是等出事之后再现拼凑。
- 任何一项涉及预算、人员编制或外包合同的决策，在审批流程里附带一步"是否同时影响两层以上防御"的检查，由安全管理体系而不是提出决策的部门自己判断。
- 把日常安全巡检和培训记录、维护记录、审计记录做定期交叉核对，重点找同一时间窗口内多层同时收紧或同时松弛的模式，而不是分别看各层是否达标。
- 验证办法：抽取最近一到两年的预算调整、人事变动、外包合同变更记录，逐条对照关键危险场景的防御清单，统计有多少条变更实际触及了两层或以上；如果几乎每条变更都只标记了一层，说明台账的颗粒度不够细，审查形同虚设。