4、5 Whys分析法：起源与原理、如何正确追问、常见追问陷阱、实战案例演练
4.1 起源与原理：一个简单到让人怀疑的方法
5 Whys分析法，最早来自丰田生产系统。大野耐一说过一句话，我印象特别深：「解决问题，要回到现场，问五次为什么。」
说白了，这个方法就是连续追问「为什么」，直到找到问题的根本原因。不是表面原因，不是中间原因，是那个你一旦解决了，问题就不再重复出现的根因。
我刚开始接触这个方法时，觉得太简单了。不就是问几个为什么吗？谁不会啊？后来在项目中栽了跟头，才明白——简单不等于容易。
核心原理：
- 症状 vs 原因：我们看到的通常是症状，不是原因
- 因果链：每个原因背后还有更深层的原因
- 停止规则：当追问到「流程/系统/管理」层面时，通常就是根因了
举个例子。你想想看，一个线上服务挂了。第一反应是什么？「重启一下」。但重启只是治标。真正要问的是：为什么会挂？
4.2 如何正确追问：不是随便问五次
很多人以为5 Whys就是机械地问五次。错。追问是有技巧的。我个人习惯遵循三个原则：
- 基于事实，不是猜测——每个回答都要有数据或证据支撑
- 追问方向要对——往流程、系统、管理方向走，别往人身上甩锅
- 问到自己能行动——找到你能改变的那个点，停下来
我在项目中遇到过这样一个案例。一个数据库连接池耗尽的问题，团队问了几轮：
问题：数据库连接池耗尽，服务拒绝连接
为什么1？——因为连接没有被及时释放
为什么2？——因为某个查询执行时间过长，占用了连接
为什么3？——因为那个查询没有走索引
为什么4？——因为表数据量增长，原来的索引失效了
为什么5？——因为没有定期维护索引统计信息
你看，到第五个为什么，我们找到了一个可以行动的点：建立索引维护的自动化流程。而不是停留在「程序员写了个慢查询」这种表面原因上。
追问技巧：
- 每次追问都要基于上一个回答，不能跳步
- 如果卡住了，回到现场去观察，别在会议室里猜
- 问「为什么会发生」而不是「谁做的」
4.3 常见追问陷阱：我踩过的坑
嗯，这里要注意。5 Whys看着简单，但陷阱特别多。我曾经犯过不少错，分享几个典型的：
陷阱一：停在人的层面
「为什么出错了？——因为小王写错了代码。」
然后呢？你总不能把小王开除了吧？要追问：为什么小王会写错？是需求不清晰？是代码审查没发现？是测试覆盖不够？
陷阱二：问出多个分支
有时候一个为什么会有多个答案。比如「为什么服务慢了？」——可能是数据库慢，也可能是网络慢，还可能是代码逻辑问题。
这时候要分别追问，不能混在一起。我建议画个因果图，每个分支单独走5 Whys。
陷阱三：问得太浅或太深
问三次就停了，可能没找到根因。问七次八次，可能问到「宇宙起源」去了。
怎么判断？我的经验是：当你找到的答案是一个「流程改进点」或「系统设计变更」时，基本就到根因了。
4.4 实战案例演练：一个真实的生产事故
好，我们来看一个完整的案例。这是我在某电商平台经历过的真实事故。
背景：双十一大促期间，订单系统突然大面积超时，持续了12分钟。
我们团队用5 Whys做了根因分析：
| 追问轮次 | 问题 | 回答 | 证据 |
|---|---|---|---|
| 第1次 | 为什么订单超时？ | 因为Redis集群响应变慢 | 监控显示Redis P99延迟从2ms飙升到800ms |
| 第2次 | 为什么Redis变慢？ | 因为某个热点key被大量并发访问 | Redis慢查询日志显示同一个key |
| 第3次 | 为什么这个key成为热点？ | 因为秒杀活动把库存信息放在了一个key里 | 代码审查发现设计如此 |
| 第4次 | 为什么秒杀库存只用单个key？ | 因为开发时没考虑到大促流量 | 设计文档中没有容量评估 |
| 第5次 | 为什么没有做容量评估？ | 因为上线流程中没有要求做容量评估 | 流程文档缺失该环节 |
根因：上线流程缺少容量评估环节，导致热点key设计未被审查。
改进措施：
- 在上线checklist中增加「容量评估」步骤
- 对Redis热点key设计规范进行全员培训
- 增加自动化工具，检测单key访问量是否超过阈值
这个案例告诉我们什么？
表面原因是「Redis慢」，但根因是「流程缺失」。如果不改流程，下次还会出现类似问题。只是换一个key，换一个场景而已。
4.5 我的建议：把5 Whys变成习惯
说实话，5 Whys不是那种学一次就能用好的工具。它需要刻意练习。我建议你：
- 每次线上事故复盘，强制用5 Whys走一遍
- 写根因分析报告时，把追问过程写清楚
- 和团队成员一起做，别一个人闷头想
我曾经带过一个团队，刚开始大家觉得5 Whys太小儿科。坚持用了三个月后，所有人都说：「以前我们都在治标，现在终于知道怎么治本了。」
嗯，这就是5 Whys的魅力。简单，但有效。关键是——你得真的去用。