2. 软件FTA核心概念与术语体系
各位同学，咱们今天聊 FTA 的数学基础。说实话，很多人一听到「集合论」「布尔代数」就头大，觉得这是纯数学，跟软件安全没关系。我当年刚入行时也这么想，直到有一次做 Linux 内核的故障分析，发现一个条件判断写反了，整个故障树逻辑全乱套。嗯，从那以后我老实了——基础不牢，地动山摇。
2.1 集合论基础
故障树里的每个事件，本质上都是一个「集合」。顶事件是「系统失效」这个集合，底事件是「某个模块出错」的集合。它们之间用「并集」和「交集」来组合。
- 并集（∪）：只要有一个底事件发生，顶事件就发生。对应故障树里的「或门」。
- 交集（∩）：所有底事件同时发生，顶事件才发生。对应故障树里的「与门」。
- 补集（¬）：事件不发生。在 FTA 里用来表示「非门」或条件取反。
关键点：故障树的最小割集，其实就是一组底事件的交集。这些交集不能再简化，去掉任何一个底事件，顶事件就不会发生。找最小割集，说白了就是在找「系统最脆弱的组合」。我在项目中遇到过，一个看似简单的 5 层故障树，最小割集竟然有 47 个——不画集合图根本理不清。
2.2 布尔代数基础
布尔代数就是故障树的「运算规则」。你想想看，故障树里那么多门，怎么化简？怎么消除冗余？全靠布尔代数。
| 布尔运算 | 符号 | FTA 中的含义 | 示例 |
|---|---|---|---|
| 与运算 | A · B | 两个事件同时发生 | CPU 过热 · 散热风扇停转 |
| 或运算 | A + B | 至少一个事件发生 | 内存错误 + 磁盘错误 |
| 非运算 | Ā | 事件不发生 | 电源正常（即电源故障不发生） |
| 吸收律 | A + A·B = A | 简化冗余路径 | 如果 A 已经发生，A·B 是多余的 |
我的习惯：拿到一个故障树，先用布尔代数把表达式写出来，然后做化简。很多看起来复杂的树，化简完就剩几个关键路径。我曾经帮一个团队分析 Android 系统的启动故障，原始故障树有 30 多个节点，化简后只剩 8 个——问题一下子就清楚了。
2.3 概率论基础
FTA 不只是定性分析，还要定量。定量靠什么？概率论。每个底事件都有一个发生概率，通过故障树的门结构，可以算出顶事件的发生概率。
- 或门概率：P(A ∪ B) = P(A) + P(B) - P(A ∩ B)。如果事件独立，简化为 P(A) + P(B) - P(A)P(B)。
- 与门概率：P(A ∩ B) = P(A) × P(B)（事件独立时）。
- 条件概率：P(A|B) = P(A ∩ B) / P(B)。在 FTA 里用来处理「顺序相关」的故障。
避坑指南：我曾经犯过一个低级错误——假设所有底事件相互独立。结果算出来的顶事件概率比实际低了一个数量级。后来发现，两个底事件共享同一个电源模块，它们根本不独立。记住：独立假设是 FTA 概率计算的「阿喀琉斯之踵」，一定要先做相关性分析。
2.4 可靠性工程基础
FTA 和可靠性工程是「亲兄弟」。可靠性工程提供底事件的数据，FTA 用这些数据算顶事件的可靠性。
| 可靠性指标 | 符号 | FTA 中的用途 |
|---|---|---|
| 失效率 | λ | 底事件的发生率，单位是 FIT（10⁻⁹ 小时） |
| 平均无故障时间 | MTBF | 系统平均多久出一次故障，MTBF = 1/λ |
| 可用度 | A | 系统正常工作的概率，A = MTBF / (MTBF + MTTR) |
| 平均修复时间 | MTTR | 故障后恢复的平均时间，影响可用度 |
我建议你在做 FTA 之前，先确认底事件的失效率数据来源。是来自供应商？来自历史数据？还是来自行业标准？数据不准，FTA 算出来的概率就是「精确的错误」。
2.5 FTA 与其他安全分析方法的比较
FTA 不是万能的。每种方法都有自己的「脾气」。我整理了一张对比表，你看看就明白了。
| 方法 | 分析方向 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|---|
| FTA（故障树分析） | 自上而下 | 已知顶事件，找原因 | 逻辑清晰，可定量 | 构建复杂，依赖经验 |
| FMEA（失效模式与影响分析） | 自下而上 | 已知底事件，评估影响 | 系统全面，适合早期 | 无法定量，容易遗漏组合 |
| HAZOP（危险与可操作性分析） | 引导词驱动 | 流程系统、化工、软件 | 结构化，覆盖偏差 | 耗时，需要多人协作 |
| STPA（系统理论过程分析） | 控制论视角 | 复杂系统、人机交互 | 考虑组件交互 | 抽象，难以定量 |
我的经验：在软件安全分析中，我通常先用 FMEA 做一遍「扫雷」，找出所有可能的失效模式。然后挑出最关键的几个顶事件，用 FTA 做深度分析。FTA 和 FMEA 是互补的，不是互斥的。你想想看，FMEA 告诉你「哪里可能出问题」，FTA 告诉你「问题怎么一步步发生」——两个结合起来，效果最好。
2.6 本章知识体系
下面这张图，把 FTA 的基础理论串起来了。你可以把它当作「知识地图」，学完本章后对照着检查自己有没有遗漏。
这张图把本章的五个核心模块串起来了。你从「集合论」出发，经过「布尔代数」的运算规则，再到「概率论」的定量计算，然后结合「可靠性工程」的数据支撑，最后用「方法比较」来定位 FTA 在整个安全分析工具箱里的位置。嗯，这就是 FTA 基础理论的全貌。