五问法（5 Whys）

🎯问题定义 #

不带形容词、可测量的一句话

开头不是“部署经常出问题”，而是带着数字和期间的句子：“最近 4 周 12 次部署中有 3 次被回滚”。问题陈述一模糊，从第一个“为什么”起，与会者就在各自分析不同的问题。一次五问法只处理一个事件，把多个事件搅在一起，原因也会被搅烂。

为什么 1 #

直接原因：那一刻发生了什么

第一个“为什么”的答案大多是看得见的技术或物理事实，例如“迁移脚本执行失败了”。如果这里冒出多个答案，挑贡献最大的那一个，其余拆成单独的链条另行处理。这一层的答案必须能用日志、记录、复现立即验证。

为什么 2 #

那个直接原因为什么会发生

从第二个开始，答案从事实转向条件，比如“预发环境没有和生产一致的数据”。“好像是”从这里开始混进来，所以在每个答案旁边写上确认方法，确认之前不下探到下一个“为什么”。搭在猜测之上的第三个“为什么”，全都是白费功夫。

为什么 3 #

那个条件为什么一直被放任

到第三个左右，个人的行为很容易登场：“负责人跳过了检查”。想在这里停下的诱惑最大。一旦出现人的失误，就换个问法：“为什么这个失误在结构上是可能的”“为什么失误没有被拦住”。允许失误发生的系统，才是下一个“为什么”的对象。

为什么 4 #

结构与流程缺陷浮出水面的一层

链条走得顺的话，到第四个左右，答案就不再是某个具体事件，而是可重复的模式：“检查清单里没有这一项”“根本不存在负责这项验证的环节”。如果答案仍然是某个人或某一天的特殊情况，说明链条走岔了，回到为什么 2 或 3，重新选一条岔路。

🧨为什么 5 = 根本原因候选 #

修好它就能挡住复发的那个点

根本原因的判定标准不是深度而是效果：把它修好，同一族的问题是否就不再发生。用反向测试来确认：从为什么 5 开始，用“所以”一路倒推，能自然地接回问题陈述，链条就成立。凑满五问不是目的，第三问就到了，就在第三问停下。

在哪里停下 #

触到可控的流程就结束

无止境往下钻的链条不是分析，是逃避。停下的位置，是我们团队能控制的最深一层流程。答案变成“经济不景气”“人性使然”这类够不着的东西时，往上退一层，把那里定为根本原因。控制范围之外的原因不是修理对象，而是要设计成能扛住的前提条件。

🛠️制定对策 #

要么消除原因，要么吸收失误

对策有两种：把原因本身消除，以及即使原因还在也不至于酿成事故的缓冲装置。“多加注意”“加强培训”不是对策，是愿望；必须是不依赖人类记忆的结构改动（自动化、改默认值、强制检查）。每条对策会带来的新副作用，也在这个阶段一并写下。

对策验证 1：复发指标 #

定好用数字观察效果的期限

在应用对策之前，先定好观察什么、观察多久才算成功，例如“上线后 8 周内同类型回滚 0 次”。没有指标和期限就关闭的五问法，下次事故时只能从头再来。真的复发了，先怀疑原因诊断错了，再怀疑对策失效。

对策验证 2：反向阅读 #

用“所以”测试审计整条链

在敲定对策之前，把整条链倒过来读一遍。从根本原因出发，用“所以”逐级往上接，句子读起来别扭的地方，就是逻辑跳跃藏身之处。请第三方反向读一遍，是最便宜也最快的审计：写的人看不见自己的跳跃。

⚠️常见陷阱 #

毁掉追问链的三个习惯

五问法沦为走过场的仪式，原因不在工具而在运用。停在怪人身上、满足于第一个答案、用猜测衔接，这三样占了失败的大头。开会前把这三条作为明确规则公示出来，链条的质量就会不一样。

陷阱 1：停在怪罪个人 #

出现“谁”的时候，才走了一半

“新人失误了”不可能是根本原因：那个人明天离职，同样的事故还是会发生。名字一出现，就把问题拉回结构：为什么这个失误能穿过整个系统？免责（blameless）原则不是仁慈问题，而是准确性问题：一旦预感会被处罚，从下一次事故起，信息就开始躲起来。

陷阱 2：满足于第一个答案 #

听起来合理的答案最危险

第一个冒出来的合理答案，多半是症状的换个说法，或者大家早就相信的假设。在每一层问一次“还有别的解释吗”，链条就能加深一层。尤其当答案在开会 5 分钟内就全票通过时，要起疑心：未经验证的共识不是分析，是记忆。

陷阱 3：不经验证就衔接 #

假设串成的链条必然崩塌

每个“为什么”的答案，都必须有数据、日志、当事人确认三者之一作支撑。哪怕只有一环是猜测，它下面的一切都立在沙滩上。出现无法确认的答案时，先停链，从确认做起。五问法不是必须在一场会议内结束的仪式，而是允许在确认之间花上几天的调查。

🌿原因分岔时 #

不再是链条，而是一棵树

现实的问题往往不止一个原因。一个“为什么”冒出两个以上答案时，不要硬选一个，按岔路各分一条链。但不必把每条岔路挖到同样深：先挖贡献最大的那条，其余明确标注“暂缓”。分岔的记录本身，就是下次类似事故的地图。