| name | five-whys |
| description | Use for incident/bug root-cause analysis, postmortem, recurring-problem diagnosis, or process improvement. Triggers on Chinese phrases 复盘 / 根因 / postmortem / 又坏了 / 老是 / 重复出现 / 这不是第一次 / 为啥总是 / RCA, and English signals "this keeps happening", "RCA", "post-mortem", "incident review". Ask "why?" 3-7 times (5 is average not rule) until hit a process/system/design root that can be changed — not the symptom. Do NOT use for one-off random events (could be noise — observe first), Cynefin Complex-domain problems (5 Whys assumes linear causality, complex systems have multi-cause emergence), teams in blame-mode (Why will become 因为 X 不靠谱 chain), or truly unknowable causes (ML model outputs — use statistics not 5 Whys). |
| license | MIT |
| metadata | {"author":"JackJin","version":"1.0","category":"反思/复盘类","framework_author":"Sakichi Toyoda / 大野耐一","source":"《丰田生产方式》(1978)","related":"pre-mortem, ooda-loop, second-order-thinking"} |
5 Whys · 五个为什么
一句话定位： 对一个问题连问「为什么」3-7 次（不是严格 5 次），从症状挖到可改的流程/系统/设计 — 不要在症状层面修补。
何时使用 (TRIGGER)
- 事故 / bug 复盘（postmortem）
- 同类问题重复出现（不是首次偶发）
- 表层修复显然不够（每次都「下不为例」但又复发）
- 流程问题诊断
- 用户报告「为什么我们老是 X？」— 信号需要根因分析
何时不要用 (ANTI-PATTERN)
- 单次偶发、无规律可循 — 可能是噪声，先观察
- 复杂系统问题（Cynefin Complex 域）— 5 Whys 假设线性因果，复杂系统是多因 + 涌现
- 团队氛围是「找罪人」— 5 Whys 容易变成「Why X 没做好 → 因为 Y 不靠谱」的责备链
- 真正的 unknowable（如 ML 模型某次输出为啥这样）— 用统计方法不是 5 Whys
操作步骤 (STEPS)
1. 准确陈述问题
必须含：指标 + 时间 + 范围。不要笼统说「登录有问题」，要说「2026-05-25 14:00-15:00 us-east-1 登录失败率 32%」
2. 问 Why #1，得到答案 A1
A1 必须是事实而非评价。错：「因为团队不仔细」对：「auth-service 14:05 deploy 引入了 null 检查 bug」
3. 把 A1 当作问题，问 Why #2
对 A1 再问「为什么 A1 发生？」得到 A2
4. 重复直到到达「可改流程 / 可改系统 / 可改设计」的根因
通常 3-7 层。5 是平均值不是规则。判断终止：根因属于「下次能从流程层面预防」而非「这次具体哪个人疏忽」
5. 验证因果链
从根因正向推演能不能解释最初问题。不能 → 链条断了，需要重做
6. 提出针对根因的行动
不是针对症状的临时补丁。「加 lint rule」「改 oncall 流程」「重设计权限模型」— 都是流程/系统级行动
决策 Checklist
真实案例
案例 1: 丰田经典（大野耐一原始示例）
- 问题：机器停了
- Why #1：保险丝烧了 → Why?
- Why #2：轴承没润滑 → Why?
- Why #3：油泵不工作 → Why?
- Why #4：泵轴磨损 → Why?
- Why #5：没装过滤器（金属屑进入轴）→ 根因
- 行动：加过滤器 + 定期检查（流程级）
- 如果只问 1 层（保险丝烧了）→ 解决方案是「换保险丝」→ 一周后还会再坏
案例 2: 工程师 — 登录失败 5 Whys
- 问题：14:00-15:00 us-east-1 登录失败率 32%
- Why #1：服务器 500 → 因为 DB 连接池满
- Why #2：连接池为什么满？→ 因为某 batch job 持有长事务 12 分钟
- Why #3：为什么 batch job 没释放？→ 因为没设 timeout
- Why #4：为什么没 timeout？→ 因为 code review 漏了
- Why #5：为什么 review 会漏？→ 因为没有 lint rule 强制 SQL transaction timeout
- 根因：缺少 lint rule（流程级）
- 行动：加 lint rule 强制所有 transaction 必须有 timeout（系统级预防）
案例 3: 产品 — 新功能 DAU 只有 1%
- 问题：上线一周新功能 DAU 仅 1%
- Why #1：用户找不到入口
- Why #2：为什么找不到？→ 入口埋在三级菜单
- Why #3：为什么三级菜单？→ PRD 没要求一级露出
- Why #4：为什么 PM 不要求？→ 担心一级菜单太拥挤
- Why #5：为什么没空间预算？→ 没有「一级菜单空间分配」的 RFC 流程
- 根因：缺一级菜单空间分配的决策流程
- 行动：制定一级菜单 RFC 流程（流程级）+ 本次功能补救上浮一级
与其他框架的关系
- Pre-Mortem 是事前 5 Whys：「如果失败了，可能因为为什么的为什么...」
- 配合 OODA Loop 的 Orient 步骤：5 Whys 是 Orient 质量的工具
- Second-Order Thinking 是「向未来追」，5 Whys 是「向过去追」 — 时间方向互补
常见陷阱
- 数到 5 就停（5 是平均值不是终点）— 应对：判断标准是「到了流程/系统/设计层」而非「问了 5 次」
- 找罪人（Why 后面跟人名）— 应对：硬性规定 Why 后面必须是事件/机制
- 没验证因果链（root cause 推不回原 symptom）— 应对：必须双向因果链能解释
- 一棵树主义（只走一条 why 链，忽视并行多因）— 应对：必要时画鱼骨图（Ishikawa），有多个分支
- 过早跳到方案（问 1-2 次就动手）— 应对：强制走完 3-5 层再讨论行动
参考
- 大野耐一, 《丰田生产方式》(1978)
- Eric Ries, 《The Lean Startup》(2011) — 推广到软件创业
- Toyota Production System: "ask 'why?' five times about every matter"
- 衍生：鱼骨图（Ishikawa Diagram）= 多分支 5 Whys
