3、故障排查方法论：从现象到根因的5Why分析法
做运维这些年，我见过太多人一遇到故障就慌了神。
系统崩了，交易停了，领导在催，客户在骂。这时候最容易犯的错是什么？是「头痛医头，脚痛医脚」。看到CPU飙高就去加资源，看到网络超时就重启网卡——结果呢？过两天同样的故障又来一遍。
说白了，你只是把症状压下去了，根因还在那里。
今天我要讲的5Why分析法，就是帮你从现象一层层剥下去，直到揪出那个真正的「元凶」。
3.1 什么是5Why分析法？
5Why，不是让你必须问5个为什么。它是个工具，核心就一句话：对一个问题连续追问「为什么」，直到找到根本原因。
我在项目中遇到过，有人问3个Why就找到了根因，也有人问了7个Why才挖到底。数字不重要，重要的是「深度」。
核心原则：
- 现象 ≠ 原因。现象只是冰山一角
- 每个「为什么」都要基于事实，不是猜测
- 找到根因后，必须能验证——「如果我修复了这个，问题就不会再发生」
3.2 一个真实的券商故障案例
先看个例子。这是我在某券商做运维时亲身经历的。
现象：交易时段，某核心交易网关频繁报「连接超时」，持续约3分钟。
好，开始问Why。
| 层级 | 问题 | 回答 |
|---|---|---|
| Why 1 | 为什么连接超时？ | 因为网关到交易所前置机的网络延迟突然飙升到500ms以上 |
| Why 2 | 为什么网络延迟飙升？ | 因为核心交换机的一个端口出现了大量丢包 |
| Why 3 | 为什么这个端口丢包？ | 因为该端口连接的网线被机柜门夹住，导致物理层信号不稳定 |
| Why 4 | 为什么网线会被机柜门夹住？ | 因为布线时没有预留足够长度，线缆绷紧在机柜门铰链处 |
| Why 5 | 为什么布线没有预留长度？ | 因为机房布线规范里没有「线缆必须预留20cm余量」这条 |
你看，从「连接超时」到「布线规范缺失」，中间隔了5层。如果我在第一层就停手，最多换个端口，过几天另一根线又会被夹住。
我的经验：在券商系统里，很多故障的根因都不是技术问题，而是流程、规范、人为操作的问题。5Why能帮你跳出技术思维，看到更大的画面。
3.3 5Why的三种典型应用场景
我个人习惯把5Why分成三类，不同场景用不同问法：
场景一：系统故障类
比如交易系统崩溃、数据库死锁、中间件OOM。这类问题技术性强，问Why时要紧扣日志、监控数据、代码逻辑。
- Why 1：为什么OOM？ → 堆内存持续增长不释放
- Why 2：为什么堆内存不释放？ → 某个缓存对象没有被GC回收
- Why 3：为什么没被回收？ → 缓存key没有设置过期时间，且被全局引用
- Why 4：为什么没设过期时间？ → 开发人员不知道这个缓存会无限增长
- Why 5：为什么不知道？ → 代码评审没有覆盖缓存策略
场景二：流程操作类
比如误操作、配置错误、变更失败。这类问题根因往往是「人」或「流程」。
- Why 1：为什么配置错了？ → 运维人员手动修改了配置文件
- Why 2：为什么手动修改？ → 因为自动化工具不支持这个参数
- Why 3：为什么不支持？ → 需求提了但排期一直没做
- Why 4：为什么没排期？ → 管理层认为这个功能「不紧急」
注意：问流程类问题时，很容易变成「甩锅大会」。我曾经见过一个团队，问到最后全在说「是XX部门没配合好」。这时候要拉回来——我们找根因是为了解决问题，不是追责。
场景三：监控告警类
比如误告警、告警风暴、告警延迟。这类问题容易被忽视，但危害很大。
- Why 1：为什么半夜告警了？ → 某个指标短暂超过阈值
- Why 2：为什么指标会短暂超阈值？ → 因为定时任务批量处理数据
- Why 3：为什么定时任务会导致告警？ → 告警阈值设置得太敏感
- Why 4：为什么阈值设置敏感？ → 当初配置时没有考虑业务波峰波谷
3.4 5Why的常见陷阱
用了这么多年5Why，我踩过不少坑。给你列几个最常见的：
- 停在「人」上：问到最后说「因为运维人员粗心」。然后呢？你没法换掉所有人。要问「为什么粗心？是流程没约束？是工具没防呆？是疲劳值班？」
- 跳跃式追问：从「网络延迟」直接跳到「布线规范」，中间跳过了交换机端口和网线。这样会漏掉关键环节。
- 主观臆断：没有数据支撑，全靠猜。「我觉得是因为...」「我怀疑是...」——停，去看日志，去看监控，去复现。
- 问得太深：问到「为什么公司不重视运维？」这种问题就失控了。5Why的边界是「我能控制的范围」。
避坑指南：我曾经在一个故障复盘会上，有人问「为什么这个Bug没被发现？」然后一路问到「为什么测试人员不认真？」——这就偏了。正确的问法是：「为什么测试用例没覆盖这个场景？」→「因为测试数据构造工具不支持」→「为什么工具不支持？」→「因为需求文档里没写这个边界条件」。
3.5 5Why的实战技巧
嗯，这里说几个我自己的小技巧：
- 写下来：别光在脑子里想。拿张纸，或者开个文档，把每个Why和答案写下来。写的过程会让你更清晰。
- 拉人一起问：一个人问容易钻牛角尖。拉上开发、测试、DBA，不同视角能看到不同盲区。
- 验证根因：找到根因后，问自己一句：「如果我修复了这个，问题真的不会再出现吗？」如果答案是「不一定」，说明还没挖到底。
- 区分「原因」和「借口」：有些回答听起来像原因，其实是借口。比如「因为时间太紧」——这不是根因，这是条件。继续问：「为什么时间紧？是评估不准？是需求变更？是资源不足？」
3.6 5Why的进阶：结合故障树
有时候一个问题有多个分支原因，单条5Why线不够用。这时候我会画一个故障树。
下面是我用SVG画的一个5Why故障树示例，展示从「交易报单失败」到根因的完整链路：
你看，一个「交易报单失败」的现象，往下挖出了两条根因线。一条是物理层的布线问题，一条是策略层的配置问题。两条都要修，缺一不可。
3.7 写在最后
5Why不是什么高深理论，它就是个「追问的习惯」。但就是这个习惯，能让你从「救火队员」变成「防火专家」。
下次遇到故障，别急着动手修。先问自己五个「为什么」。你会发现，很多你以为的「原因」，其实只是「现象」。
一个小练习：回想你最近处理的一个故障，试着用5Why挖一下。看看你当时停在了第几层？如果继续问下去，会不会找到不一样的根因？
公众号:蓝海资料掘金营，微信deep3321