InfiniSynapse
什么是5个为什么根因分析？
5个为什么根因分析（5 Whys）是从一个明确问题出发，连续追问每一层“为什么会发生”，并用证据把症状、直接机制、促成条件和系统控制缺口连接起来的方法。“五”只是提醒团队不要停在第一个解释；高质量分析可以少于五层、超过五层，也可以在因果分叉时形成多条链。
每个回答都应是可检验的因果命题，而不是意见。团队要记录事实来源、未知、替代解释和反证，并在措施实施后验证复发风险是否真正下降。否则，五问法很容易退化成一串听起来合理但无法审计的故事。
什么时候适合使用5 Whys？
问题边界清楚；主要过程链相对线性；团队能快速获得日志、记录或现场事实；目标是从表面症状深入到一个或几个可行动的流程、设计或控制条件。
事件严重且受监管、系统有多条并行路径或冗余、时间顺序复杂、统计波动可能主导、候选很多或意见冲突。此时五问法只能作为完整调查中的一项工具。
| 问题特征 | 建议方法 | 五问法的角色 |
|---|---|---|
| 单一流程偏差，链条清楚 | 5 Whys＋证据核查 | 主分析方法 |
| 候选方向多，容易遗漏 | 鱼骨图 | 对优先分支继续追问 |
| 存在冗余或多条件组合 | 故障树分析 | 解释某个基本事件的上游原因 |
| 发布、操作和症状顺序关键 | 时间线＋变更分析 | 在关键转折点追问 |
| 指标波动或群体差异 | 统计分层与对照 | 解释已确认的差异模式 |
需要比较更广泛的方法，可阅读根因分析技术选择指南。
开始追问前，先写对问题陈述
第一问的质量取决于起点。建议用“对象＋偏差＋时间＋范围＋基线＋影响”描述事实，并列出发生/未发生边界。问题陈述不要包含未经验证的原因，也不要把多个后果混在同一句中。
| 不合格表述 | 问题 | 更好的起点 |
|---|---|---|
| 员工操作失误导致返工 | 预置个人原因，没有分母和边界 | 过去两周，夜班A线标签返工率由0.6%升至4.1%，日班和B线未升高 |
| 数据库太慢 | 对象、指标、时间和受影响请求不清 | v4.8发布后，大客户订单查询P99从420毫秒升至2.8秒，P50基本不变 |
| 客户体验很差 | 不可判定，也无法确认改善 | 周一9–11点企业客户首次响应达标率由92%降至68%，其他时段稳定 |
如果团队无法对“问题是否发生”给出一致判断，应先收集数据和统一口径，而不是开始问为什么。关于边界与原因接受，可参考根因分析方法论指南。
五问会前准备哪些事实和角色？
- 时间线：问题前后发生了什么，哪些变更、报警、操作和恢复动作有时间戳。
- 发生/未发生对照：受影响与正常的机器、客户、班次、地区、版本或批次。
- 过程与系统图：实际流程、接口、责任边界、控制点和依赖，而不仅是书面程序。
- 原始证据：日志、记录、照片、检测、工单、版本、访谈和现场观察的可追溯位置。
- 跨职能参与者：掌握现场、数据、设计、维护和下游影响的人；避免只由一位管理者给出答案。
- 主持与记录角色：主持人追问和控制偏见，记录人保存每层命题、证据、未知和负责人。
先分清事实和推断。“夜班返工率4.1%”可能是事实；“夜班人员培训不足”是待验证假设。把两者写在同一列会让后续问题沿着未经证实的方向前进。
如何执行5个为什么根因分析：八步流程
- 确认问题与边界。让参与者对对象、偏差、时间、分母、基线和影响达成一致。
- 独立提出第一层解释。先分别写下候选，减少从众；用数据快速排除与边界不符的答案。
- 选择可验证的直接原因。回答必须紧邻上层结果，并说明作用机制，避免一次跨越多层。
- 为回答附证据状态。标注已观察、假设、未知或被反驳，同时写明来源和下一步检验。
- 继续追问上游条件。问“为什么这个条件存在”“什么控制本应预防或发现它”，而不只寻找谁执行了动作。
- 遇到分叉就保留分支。如果两个因素各自必要或共同促成，分别编号，不为了得到一条整齐链而丢弃。
- 用停止闸门判断是否继续。检查原因是否可行动、可控制、能解释边界且替代解释已充分处理。
- 映射措施并验证。针对已接受原因设计措施、负责人、效果指标、护栏、观察窗和重开条件。
怎样提出不会引导答案的“为什么”？
| 引导式或低质量问题 | 风险 | 中性改写 |
|---|---|---|
| 为什么操作员没有按程序做？ | 假设程序适用且个人偏离已经证实 | 当时实际执行了哪些步骤？与适用标准的差异是什么？ |
| 为什么培训不够？ | 把候选原因写进问题 | 完成任务所需信息、能力和反馈如何提供？证据显示了什么？ |
| 为什么系统总是失败？ | 绝对化且无边界 | 受影响请求与正常请求在哪个条件上首次分离？ |
| 为什么没有早点发现？ | 容易变成事后归责 | 哪个控制本应在何时检测到该状态？它当时输出了什么？ |
除了“为什么”，主持人还应问：“你怎么知道？”“如果这个原因成立，我们还应看到什么？”“什么证据会反驳它？”“为什么相似对象没有发生？”这些问题把叙述转成可区分的假设。
复杂问题不能强迫只有一条为什么链
实际事件常同时包含触发因素、直接机制、促成条件和控制缺口。例如，API延迟既可能需要某段代码在大数据量下产生N+1查询，也可能因为性能测试没有覆盖长历史客户而未被发布前发现。这是两条角色不同但都应保留的链。
| 情况 | 处理方式 | 不要做什么 |
|---|---|---|
| 两个因素共同才产生结果 | 明确AND关系，分别向上追问 | 随意选一个写成“主因” |
| 任一因素都可能产生结果 | 保留OR分支，按边界和证据验证 | 把可能性列表当成已证实原因 |
| 多个分支指向相同上游条件 | 合并共享原因并保留引用 | 重复计算或重复分配措施 |
| 分支过多、逻辑复杂 | 切换到故障树分析或鱼骨图 | 用无限缩进掩盖逻辑门 |
5 Whys示例：数据管道延迟
教学问题：8月12日09:00发布v3.6后，企业客户日终报表到达时间由06:10延迟到09:35；只影响包含跨区退款明细的账户，普通账户和上一版本正常。以下为假设案例，不代表真实产品表现。
| 层级 | 回答 | 证据与状态 |
|---|---|---|
| 为什么1 | 退款明细分区任务处理时间由18分钟升至205分钟 | 调度日志与阶段耗时支持 |
| 为什么2 | 任务对每条退款记录重复读取完整订单历史 | 查询追踪显示调用次数随退款数线性增长 |
| 为什么3 | v3.6把批量映射改成逐记录权限校验 | 代码差异和回滚对照支持 |
| 为什么4 | 共享权限接口没有面向批处理的调用契约 | 接口说明只有单记录语义；设计审查未定义批量需求 |
| 为什么5 | 数据平台与权限团队的接口评审没有负载与调用形态字段 | 模板和历史评审记录支持；为系统控制缺口 |
这条链解释了延迟的直接机制和上游设计控制缺口，但还需要第二条“为什么未提前发现”的链。
| 层级 | 回答 | 证据与状态 |
|---|---|---|
| 为什么1 | 发布前性能测试通过 | 测试报告事实 |
| 为什么2 | 测试集没有包含跨区退款与长订单历史的组合 | 样本分布对比支持 |
| 为什么3 | 性能用例按平均账户构造，没有边界分层 | 用例生成脚本支持 |
| 为什么4 | 发布闸门只检查整体P95，没有关键群体P99 | 流水线配置和仪表盘支持 |
| 为什么5 | 风险评审未把数据分布变化映射到性能场景 | 评审清单缺项，为检测控制缺口 |
反证检查：若逐记录权限调用是主要机制，耗时应随退款记录与历史长度上升，并在回滚或批量实现后下降；普通账户应保持稳定。若这些预测不成立，就要重开候选，而不是维护原有故事。
问到什么时候可以停止？
可以在少于或多于五层时停止，但至少要通过以下闸门：
- 边界解释：原因能同时解释发生和未发生的对象、时间、版本或条件。
- 机制连贯：每一层与上一层有直接、可说明的因果关系，没有跨层跳跃。
- 证据支持：时间顺序、来源、对照或测试支持该命题，关键替代解释已处理。
- 可行动性：组织可以改变设计、流程、信息、控制或条件，而不是停在天气、个人性格等标签。
- 控制层级：至少问到为什么现有预防或检测控制没有阻断该路径。
- 范围透明：继续追问若超出本次权限或系统边界，要明确移交，而不是宣称已到“终极根因”。
预算或权限不足不是根因。它们可能是约束，但仍要说明具体哪个决策、规则、优先级或信息机制使风险未被控制；如果不能继续调查，应标为未决而非已验证结论。
如何验证每一层原因而不是只记录观点？
| 维度 | 要问的问题 | 常用证据 |
|---|---|---|
| 来源 | 回答来自直接观察、原始记录还是转述？ | 日志、照片、测量、版本、工单 |
| 时间 | 原因是否在结果之前存在，并在相关窗口变化？ | 同步时间线、审计记录 |
| 机制 | 该条件怎样产生上一层结果？有可检验预测吗？ | 系统图、物理原理、追踪、受控测试 |
| 边界 | 为什么发生在A却没有发生在B？ | 分层、正常对照、发生/未发生矩阵 |
| 替代解释 | 其他候选能否产生相同观察？ | 区分性检验、敏感性和反证 |
| 干预 | 针对该原因的安全改变是否按预测改善结果？ | 试点、回滚、前后对照和护栏 |
优先级不等于接受。即使一个解释最容易验证或最受团队欢迎，也必须通过证据闸门。更完整的证据链可结合失效根因分析指南。
五问法常见错误及修正
| 错误 | 后果 | 修正 |
|---|---|---|
| 机械问满五次 | 过早停止或为了凑数继续抽象 | 用停止闸门决定深度 |
| 第一问就跳到管理层原因 | 丢失直接机制，措施难验证 | 逐层连接紧邻状态 |
| 只有一条链 | 遗漏共同必要条件、检测缺口和替代路径 | 允许分支并明确逻辑关系 |
| 答案写“人员粗心” | 个人归责且无法系统预防 | 追问任务条件、信息、控制和错误容忍 |
| 凭多数投票接受原因 | 共识替代证据 | 记录预测、来源和反证 |
| 把纠正措施写成“加强培训” | 与原因不匹配、效果不持久 | 优先设计消除、工程控制和强检测，再评估培训角色 |
从已验证原因到纠正措施和复发验证
每个措施必须对应具体原因节点，并说明它是消除原因、降低发生率、打断路径、提高检测还是降低后果。不要从五问链直接跳到最熟悉的解决方案。
| 字段 | 示例 |
|---|---|
| 原因节点 | 性能闸门未按关键数据群体检查P99 |
| 措施 | 按账户历史长度和退款状态分层构造性能数据，并设置群体P99闸门 |
| 实施证据 | 流水线配置、样本分布报告、失败阻断记录 |
| 效果指标 | 受影响群体P99、延迟批次数、复发率 |
| 护栏 | 测试时长、误阻断率、计算成本 |
| 观察窗与重开 | 连续四个发布周期；任何同类群体延迟即重开分析 |
把每层为什么连接到原始证据与行动记录
准备问题陈述、时间线、分支ID、事实状态、日志和文档来源、验证负责人及访问权限。InfiniSynapse可辅助检索、归并和对照多源材料；原因接受、专业调查、纠正措施批准与结案仍由相应责任人员完成。
打开在线工作区主持一次高质量5 Whys会议
- 先让参与者独立写第一层候选，避免权威意见锚定。
- 每次只处理一个清楚的上层事件；分支时创建新的链编号。
- 要求回答使用“具体条件＋机制”，禁止只写“沟通不足”“管理问题”等抽象标签。
- 每层同时记录支持证据、反证、未知、负责人和截止日期。
- 有人提出解决方案时先放入停车区，不让措施反向塑造原因。
- 出现个人行为时继续检查任务设计、信息、工具、环境、负荷和屏障。
- 会后由独立人员审查逻辑跳跃、遗漏分支和证据质量。
5个为什么根因分析常见问题
5个为什么根因分析是什么？
它是一种逐层追问因果链的方法：从已定义的问题出发，反复询问“为什么会发生”，并用事实验证每个回答，直到找到可行动的系统条件或控制缺口。五次只是提示，不是必须停止或必须问满的规则。
一定要恰好问五次为什么吗？
不需要。简单问题可能三次就到达可验证原因，复杂问题可能需要更多层或多个分支。停止取决于证据、控制能力、调查边界和替代解释，而不是问题编号。
怎样写一个好的5 Whys问题陈述？
写明对象、偏差、时间、地点或版本、规模、基线和影响，保持中性并且不预置原因。例如“v4.8发布后，大客户订单API的P99延迟从420毫秒升至2.8秒”，比“数据库优化失败”更合适。
一个问题可以有多条为什么链吗？
可以，而且复杂事件通常必须分支。直接机制、触发因素、促成条件和检测缺口可能形成不同链。每条分支都要单独编号、验证，并在发现共同上游条件时合并。
怎样验证五问法找到的根因？
检查时间顺序、机制、发生与未发生边界、对照和替代解释；必要时使用日志、现场观察、测试或安全实验。实施针对性措施后，还要验证问题指标改善、护栏未恶化，并设定复发监测。
什么时候不应该单独使用5 Whys？
当问题涉及多条并行路径、冗余和AND/OR逻辑、统计波动、复杂软件依赖、严重安全事件或证据冲突时，不应只靠一条五问链。可结合鱼骨图、故障树、时间线、变更分析、FMEA或统计方法。
五问法怎样避免归责个人？
把“某人忘记了”继续改写为任务条件：当时应看到什么信息、检查如何设计、权限和负荷如何、为什么错误未被发现。人员行为可以是事件，但“粗心”通常不是可验证且可预防复发的系统终点。
5 Whys和5W2H是同一种方法吗？
不是。5 Whys反复追问因果，目标是理解原因链；5W2H用谁、什么、何时、何地、为什么、如何、多少来完整描述问题或计划。二者可配合使用，但回答的搜索意图和工作产出不同。
权威资料与延伸阅读
以下资料用于核对五问法的定义、使用步骤、追问次数、分支原因和与完整问题解决流程的关系。