5 Whys 是什么
5 Whys（五问法）是源自丰田生产系统的根因分析方法：面对一个问题连续追问为什么，每一问都用事实与数据回答，直到找到可整改的根因，通常三到五层即可触及流程或设计层面的问题。它的价值不在追问次数，而在逼团队跳过表象、用证据链条定位真正的失效环节。
基本信息
| 起源定位 | 丰田生产方式，轻量根因分析工具，常与鱼骨图搭配使用 |
|---|---|
| 适用问题 | 可复现的单链条失效问题；多因交叉问题先画鱼骨图分类 |
| 回答要求 | 每一问以事实、日志、代码或数据作答，拒绝大概、可能 |
| 停止条件 | 追问到外部约束或制度层，再往下不再产出可整改项 |
| 输出物 | 追问链、根因结论、整改措施、责任人、验证方式 |
| 常见深度 | 三层到五层；超过五层通常说明问题定义过宽 |
追问链示例
追问链示例
现象：订单页偶发超时
为什么 1：下游查询慢 # 因为查询未命中索引
为什么 2：没命中索引 # 因为新加的过滤条件没有索引
为什么 3：条件上线没建索引 # 因为改表脚本未走评审
为什么 4：脚本未走评审 # 因为存在绕过评审的发布通道
根因：变更流程缺强制检查；整改：堵住绕行通道并加发布前扫描
# 每一层都要有证据，答不上来就去查数据，不要猜典型使用场景
- 线上故障复盘：从现象倒推触发条件与设计缺陷，避免只修表象。
- 重复缺陷：同一模块反复出问题，用追问链找出流程缺口。
- 缺陷预防：把根因结论翻译成检查项或自动化用例，防止再犯。
- 流程改进：追问到评审、测试或发布环节，识别系统性薄弱点。
- 跨团队对齐：用同一条追问链把开发、测试、运维的认知拉到一起。
追问要基于事实：答不上来时先去查日志、代码或做实验，而不是继续凭印象猜。
多因并列时先分叉：单链条用 5 Whys，交叉多因问题先按类别展开再逐条追问。
问出人为失误不是终点：继续问为什么这个失误能造成事故，才能到制度与工具层。