故障树分析怎么做？从顶事件、与门和或门找到风险组合

故障树分析（FTA）从一个明确的不希望发生的结果出发，逐层拆出会导致它的事件组合。它最有用的地方，是分清“任意一项发生就足够”和“几项必须同时发生”：前者用或门，后者用与门。只有把这种关系画对，才看得出哪些是单点故障，哪些看似有备份却仍依赖同一个条件。

团队可以在 Boardmix 在线白板上先画事件、逻辑门与依据，再共同核对模型。绘图前不要急着列几十种故障；先写清顶事件、系统边界、运行条件和判断时限。

先确定你需要故障树，还是排查决策树

ASQ 对故障树分析的说明强调从系统层面的不期望事件，推导可能导致它的故障组合。它适合回答“哪些条件共同出现，会使结果失败”，而不是规定值班同事先点哪个页面。

例如，库存查询偶发失败时，故障排查决策树指导检查日志和请求；故障树则可以用于评审“主服务和备用服务都不可用时会怎样”。需要按环节盘点失效模式时，再参考FMEA 分析方法。这些方法可以互相提供材料；把排查顺序画清，并不代表已经找全失效组合。

把顶事件写成可判断的失败状态

“系统有问题”太宽，“服务器坏了”又过早选定了原因。顶事件应描述你要避免的结果，并说明它在什么条件下成立。

下面用一个简化的库存查询案例：网关已经收到有效请求，但在团队约定的响应时限内，没有取得可用的查询响应。系统有主、备两个查询服务，任一健康服务都能独立完成这类请求；网关负责把请求送到可用服务。两者使用同一份访问凭据。

这些是演示模型的边界，不是对某个生产系统的描述。如果实际备份只允许人工启用，或切换后已经超过时限，就不能照搬下面的“主、备同时不可用”关系。

与门、或门：用一句话检查逻辑

或门（OR）：任意一个输入事件发生，就足以使输出事件成立。例如，网关无法把请求路由到可用服务，或者主备查询能力整体不可用，都可能使本例的顶事件成立。

与门（AND）：所有输入事件在所定义的条件下共同发生，输出事件才成立。在任一服务健康就能提供响应的前提下，只有主服务和备用服务都不可用，才会失去查询能力。

把“与”或“或”读出来，是比检查连线是否整齐更重要的一步。每个逻辑门都可以做两次提问：

• 只发生其中一个输入，会怎样？主服务不可用，但备用服务可以及时响应，顶事件就不应沿这条与门分支成立。
• 输入全部成立，是否真的足够？如果主、备都不可用，系统还有第三条有效路径，就需要继续补模型；不能省略它后直接认定失败。

逻辑门不是时间顺序。两条线接到与门，不表示“先主服务失败，再备用服务失败”；它描述的是分析条件下的组合。故障先后、维修恢复、备用唤醒顺序明显影响结果时，需要更细的时序或动态分析。

沿一个主备服务案例展开故障树

先给事件统一编号。G 表示网关路由不可用；P 表示主服务不可用；B 表示备用服务不可用。顶层关系写成：

T = G OR（P AND B）

这一步能看出：增加备用服务并没有消除网关这条单点路径。下一步继续拆 P 和 B，检查主备是不是独立。

假设主服务自身的故障记为 P1，备用服务自身的故障记为 B1；共同凭据无效记为 C。P1、B1 不包含由 C 导致的不可用，以免同一个原因藏在不同名字里。本例中，共同凭据失效会让两边都无法完成查询，因此：

• P = P1 OR C：主服务自身故障，或共同凭据无效，都会使主服务不可用。
• B = B1 OR C：备用服务自身故障，或同一个共同凭据无效，都会使备用服务不可用。

C 可以在图上出现两个引用位置，但编号、定义和依据必须相同。不能把它画成 C1、C2 后当成两个互不相关的事件；同样，也不能只看有两套服务，就认定它们的失败概率能够相乘。

画到 P1、B1、C 这一层是否停止，取决于分析任务。若团队要决定凭据治理和主备隔离是否足够，此层可能已经能暴露关键问题；若要定位主服务自身的失效机制，就继续展开 P1。尚未调查的事件标为“待展开”，不能为了填满叶子就叫它根因。

最小割集：找出足以导致失败的最小事件组合

割集是能够导致顶事件发生的一组基本事件。最小割集的“最小”，指删掉其中任意一项后，这组事件就不再足以导致顶事件；不是指概率最小，也不是指整改成本最低。

将上面的关系代入，可得到：

T = G OR［（P1 OR C）AND（B1 OR C）］
T = G OR C OR（P1 AND B1）

这比“有备用服务，所以安全”更具体：备份只改变部分故障组合，没有消除共同凭据和网关依赖。措施应针对已经识别的组合提出，再结合实施成本、实际发生情况与影响判断优先级。

小型模型可以像上面这样逐项展开；事件多、存在重复引用或复杂逻辑时，应使用适合的分析工具核算，并保留输入定义。Boardmix 用于表达和评审关系，不把手工图当作自动求解结果。

在 Boardmix 中组织事件、逻辑与核对记录

先在画布上方写顶事件与边界，在其下放一个标有“OR”的逻辑节点，再分出 G 和“查询能力不可用”两条支路。后者通过“AND”连接 P、B；P、B 分别用“OR”连接自身故障与 C。使用形状、文本和连接线即可完成关系草图。

如果团队采用正式故障树符号，应沿用本项目选定的符号规则并补图例；初次讨论可以用清楚标记 AND、OR 的节点，避免用没有标签的菱形让读者误以为是“是／否”的流程判断。

将证据放在树旁，而不是挤进节点。建议记录“事件编号、定义、依据位置、当前状态、核对人”：C 的依据可以是架构与配置说明，P1 的细分可能仍待日志核实。图上的逻辑关系、实际事件有没有发生、采取措施后有没有改善，是三件不同的事，分别记录。

让没有参与绘图的同事按这四种组合走读。若必须靠作者口头补一个隐藏条件，先改边界或节点定义，再讨论措施。准备执行生产调整时，另走团队的变更与审批流程。

没有可靠数据，先做定性分析

与门不是“看到两个概率就相乘”，或门也不是把所有概率简单相加。事件是否独立、能否同时发生、统计窗口是否一致，都影响计算；共同凭据这样的重复事件尤其容易被算错。NASA 故障树手册专门讨论了重复事件、共同原因和定量分析的前提。

暂时没有可信失效数据时，可以先交付清楚的顶事件、逻辑树、最小割集和待验证事项。不要填“0.1%”之类没有来源的数字，让图看起来精确。对于安全关键或监管要求的分析，还需要由具备相应职责与能力的人员按适用规范完成。

一张可用的故障树，应当让读者看懂：什么结果算失败、什么条件共同导致它、哪些依赖被重复使用，以及下一步要补什么证据。做到这些，再讨论增加备份、隔离依赖或调整控制措施，才有具体依据。