📚 课程目录第4章故障排查思维模型

4. 故障排查思维模型：5W1H分析法、故障树分析（FTA）基础、因果链与根因分析（RCA）入门

在变更风险评估与可靠性评审中，故障排查不是随机试错，而是遵循结构化思维模型的过程。本节聚焦三种最核心的排查思维模型：5W1H分析法（界定问题边界）、故障树分析（FTA）（自上而下演绎）、因果链与根因分析（RCA）（自下而上归纳）。三者形成从“问题定义”到“逻辑拆解”再到“根源锁定”的完整闭环。

4.1 5W1H分析法：精准定义故障场景

5W1H是故障排查的起点。在变更评审中，若问题描述模糊（如“系统不稳定”），后续分析将失去靶向。5W1H强制团队用六个维度将故障场景结构化。

维度	英文	变更故障排查中的典型问题
What	什么	发生了什么异常？错误码、日志关键字、监控指标偏离值？
Why	为什么	初步怀疑的原因是什么？配置错误？依赖服务超时？
Where	哪里	故障发生在哪个模块、节点、地域或版本？
When	何时	首次发现时间、持续时长、是否与变更窗口强相关？
Who	谁	谁报告的？谁最近修改了相关配置或代码？
How	如何	故障如何被触发？复现步骤、流量特征、操作序列？

可靠性评审应用提示： 在变更风险评审的“故障场景描述”环节，强制要求变更申请人按5W1H填写故障预判表。若任一维度为空或模糊，评审组应退回补充。这能大幅减少因问题定义不清导致的排查方向错误。

4.2 故障树分析（FTA）基础：自上而下的逻辑演绎

FTA是一种演绎式故障分析方法。它以顶事件（系统级故障）为起点，逐层向下追问“导致该故障的直接原因是什么”，直到分解为底事件（基本失效或人为错误）。FTA使用与门（AND）和或门（OR）表达原因组合逻辑。

4.2.1 FTA核心符号与逻辑

符号	名称	逻辑含义	排查含义
矩形	顶事件/中间事件	需要进一步分解的故障	当前层故障未到根因，需继续向下
圆形	底事件	基本失效，不再分解	排查终点，需直接验证或修复
AND门	与门	所有输入事件同时发生，输出才发生	多个条件必须全部满足才触发故障
OR门	或门	任一输入事件发生，输出即发生	多个原因中只要有一个成立即可触发

  变更评审中的FTA应用场景： 当变更涉及多个组件或服务时，使用FTA分析“变更后系统不可用”这一顶事件。通过AND/OR门识别哪些失效组合是单点故障（OR门下的任一底事件），哪些是冗余失效（AND门下的所有底事件同时失效）。评审组据此决定是否需要增加冗余或熔断措施。

4.3 因果链与根因分析（RCA）入门：自下而上的归纳溯源

与FTA的“自上而下”相反，根因分析（RCA）通常采用自下而上的归纳路径。它从具体的故障现象或数据点出发，沿着因果链逐层追问“为什么会发生”，直到找到可纠正的系统性根因。RCA的核心工具是“5 Whys”和因果链图。

4.3.1 因果链的构建原则

直接因果：每一层原因必须是上一层结果的直接原因，不能跳跃。
可验证性：每个因果断言必须有日志、监控数据或测试结果支撑。
终止条件：当原因属于“流程缺失”、“设计缺陷”、“组织能力不足”等系统性因素时，停止追问，标记为根因。

4.3.2 5 Whys 示例（变更场景）

层级	问题	回答
1	为什么数据库连接池耗尽？	因为变更后新版本代码未正确释放连接。
2	为什么未释放连接？	因为异常分支缺少 finally 块关闭连接。
3	为什么代码审查没发现？	因为审查清单中未包含资源释放检查项。
4	为什么审查清单缺失该项？	因为团队未将“资源泄漏”纳入可靠性评审检查表。
根因	为什么检查表不完整？	可靠性评审流程缺少对资源管理类变更的专项检查模板。

常见误区： 很多团队在RCA时停在“人为疏忽”或“操作失误”层面，没有继续追问“为什么流程允许疏忽发生？”或“为什么操作没有防呆设计？”真正的根因必须是系统性的、可预防的，而不是归咎于个人。

4.4 三种思维模型的协同应用

在可靠性评审的故障排查任务中，三种模型不是互斥的，而是形成递进式协同：

5W1H 用于故障场景的结构化定义，确保团队对“发生了什么”达成共识。
FTA 用于逻辑拆解，从顶事件向下枚举所有可能的失效路径，识别单点故障和组合风险。
RCA（因果链） 用于根源锁定，从具体失效路径的底事件出发，向上归纳出流程或设计层面的系统性根因。

  评审实战建议： 在变更风险评审的“故障排查”环节，建议按以下步骤操作：

主持人引导团队用 5W1H 填写故障预判表。

针对高优先级故障，现场绘制 FTA 草图，识别关键失效路径。

对FTA中的关键底事件，执行 5 Whys 追问，输出根因及改进措施。

将根因纳入变更的 回退条件 或 验证清单。