第4章 构建故障树顶层事件：顶事件定义与子事件分解
4.1 从现象识别到故障树
在问题排查中，完成“现象识别”与“数据采集”后，需要将模糊的系统级失效现象转化为可定量/定性分析的逻辑结构。故障树分析（FTA） 是原因定位阶段的核心工具。它将最不希望发生的系统失效（顶事件）作为根节点，向下逐层分解为导致该事件发生的中间事件和基本事件，形成树状逻辑图。
排查路径： 现象识别 → 定义顶事件 → 分解子事件（逻辑门链接） → 建立故障树 → 定量/定性分析 → 定位根本原因。
4.2 顶事件定义
顶事件是故障树的最上层事件，必须满足：
- 唯一性：一次只分析一个顶事件。
- 可观测性：事件必须有明确的、可测量的失效表现。
- 可分解性：能通过逻辑门（AND/OR）向下分解为更基本的子事件。
示例（某稳压电源输出失效）：
顶事件：稳压电源模块5V输出失效（电压低于4.5V或高于5.5V）
常见错误：将顶事件定义得过于宽泛（如“系统故障”），导致无法聚焦。应基于现象识别阶段的精确失效现象来定义。
4.3 子事件分解与逻辑门
子事件是导致顶事件发生的直接原因或中间原因。分解使用两种标准逻辑门：
| 逻辑门 | 符号 | 含义 | 示例 |
|---|---|---|---|
| AND | ∩ | 所有子事件同时发生，顶层才发生 | “输入电压丢失” AND “备用电池故障” → “电源输出失效” |
| OR | ∪ | 任意一个子事件发生，顶层即发生 | “稳压器芯片损坏” OR “反馈电阻开路” → “输出失效” |
分解时应遵循 MECE原则（相互独立，完全穷尽），确保子事件之间不重叠且覆盖所有可能原因。一般分解深度到基本事件（不可再分或数据可获取）为止。
4.4 故障树初建案例
以“服务器CPU温度超限导致宕机”为例，建立顶层故障树：
- 顶事件：服务器CPU温度超过85°C导致宕机。
- 第一层子事件（OR门）：
- 散热系统失效
- CPU负载异常升高
- 温度传感器误报
- 第二层进一步分解：
- 散热系统失效 → 风扇停转 AND 散热片堵灰
- CPU负载异常升高 → 挖矿程序 OR 死循环进程
- 温度传感器误报 → 传感器损坏 OR 接触不良
故障树构建检查点：
- 顶事件是否来自现象识别？
- 每个中间事件下是否至少有两个子事件？
- 基本事件是否有数据采集手段支持（日志、测量、测试）？
4.5 故障树顶层结构图
4.6 排查表：顶事件与子事件关系
将上述故障树转化为排查表，便于数据采集与原因定位：
| 事件层级 | 事件描述 | 逻辑门 | 依赖的数据源 |
|---|---|---|---|
| 顶事件 | CPU温度>85°C宕机 | — | 系统日志、温度监控 |
| 第一层（中间事件） | 散热系统失效 | OR | 风扇转速传感器、灰尘情况 |
| 第一层（中间事件） | CPU负载异常 | OR | 进程列表、CPU利用率日志 |
| 第一层（中间事件） | 传感器误报 | OR | 历史温度曲线、校准记录 |
| 基本事件 | 风扇停转 | AND | IPMI传感器读数 |
| 基本事件 | 散热片堵灰 | — | 物理检查/照片 |
4.7 故障树与排查主线的衔接
- 现象识别 → 顶事件定义：将观察到的系统失效现象（如“服务器宕机”）转化为精确的顶事件。
- 数据采集 → 子事件验证：根据故障树中的基本事件，确定需要采集的数据（如风扇转速、CPU温度、进程列表）。
- 原因定位 → 最小割集：通过布尔代数化简，找到导致顶事件发生的最小事件组合（如“风扇停转 AND 散热片堵灰”）。
- 修复动作 → 针对基本事件：更换风扇、清理灰尘、杀掉异常进程、更换传感器。
- 复测 → 验证顶事件不再发生。
- 预防 → 更新监控告警阈值、定期清理计划。
重要提醒：故障树不是静态的。实际排查中，若发现无法解释的数据，需要回溯修改故障树结构（增加或合并子事件）。FTA 是一个迭代精化过程。