thinking-five-whys-plus

五个为什么 Plus

从已知的近因故障构建一条有证据支持的因果链，追溯到可采取行动的系统性根因，然后提出能够阻止故障发生的对策。

适用场景

• 故障已定位到某个组件、路径或子系统。
• 近因已知，但尚不清楚故障复发的原因或系统性根因。
• 以往只处理症状的修复未能奏效，故障再次发生。
• 你需要采取预防措施，解决近因得以发生的原因。

不适用场景

• 故障尚未定位，或仍有多个可能原因——先进行区分。
• 根因已有证据支持且可采取行动——直接修复。
• 没有证据可以回答下一个“为什么”——先收集证据。
• 一次性错误，且没有流程、工具或设计方面的促成因素。
• 需要使用 IS/IS-NOT 分析的选择性缺陷。
• 在作出承诺前预测未来可能发生的故障。

流程

1. 陈述已定位的问题。 记录可观察到的症状、已确认的组件/路径、时间范围、影响范围和影响。若尚未定位，则停止。
2. 用证据串联各个“为什么”。 将上一步的答案作为新的结果，提出一个原因；引用日志、代码、配置、指标或目击者证词；指出并排除其他可能性。若仅有猜测，则停止。
3. 继续追溯前先展开分支。 询问还有什么可能导致相同结果；保留所有有证据支持的独立路径。将保留的分支视为一个因果集合，不要强行归结为单一根因。
4. 通过反事实检验每条路径及其集合。 对每个候选原因，询问：“移除这个原因能否阻断这条路径？”然后询问：“移除保留的原因集合能否阻止观察到的故障？”保留那些单独移除后能够阻断自身路径且各自独立充分的分支；不要仅仅因为另一个分支仍可能导致故障，就排除它们。
5. 对每个分支执行停止标准。 只有当原因有证据支持、可控、可采取行动、能防止复发且不归咎于个人（而不只是“有人犯错”），并且通过该路径的反事实检验时，才停止追溯此分支。若追溯到人为错误，则继续询问为什么会发生该错误。
6. 为每个保留的根因提出对策。 说明系统性修复、责任方可执行的行动，以及如何检查故障是否复发。优先消除促成故障的条件，而非只修补近因症状。
7. 验证完成或受阻时停止。 当停止标准通过且已提出对策时，或后续步骤缺乏证据时，停止。不要为了遵循惯例而凑步骤。

输出

Problem: <localized symptom + component>
Chain:
  Why1: <cause> | Evidence: <...> | Ruled out: <...>
  WhyN: ...
Causal set check: would removing all retained roots block the failure? yes/no
Roots:
  - <systemic cause> | Pathway counterfactual: <...>
    Countermeasure: <action that removes the enabling condition>
    Verification: <how to confirm this pathway is blocked>

验证

• 如果任何一步缺乏证据、从未考虑其他可能性、某个保留的根因未通过其路径的反事实检验，或完整的因果集合无法解释故障，则证伪这条因果链。
• 根因修复并验证后，或问题仍未定位时，停止使用此技能。
• 避免过度应用：单个已知的一行缺陷无需进行完整的因果链分析；不要以归咎于个人告终；不要在缺乏数据时凭空增加追溯层次。