根因分析基础：RCA、5Why与鱼骨图在体量异常中的应用

体量异常报警了，你第一反应是什么？

很多人会直接去看监控大盘，找哪个指标突变了。然后呢？改阈值、重启服务、回滚代码——先让报警消停再说。这没错，应急处理就该这样。但问题往往第二天又来了，或者换个马甲继续报。

这时候就需要根因分析（RCA）了。说白了，就是问一句：“到底为什么？”

什么是根因分析（RCA）

RCA不是找“谁干的”，而是找“为什么发生”。我见过太多团队把RCA做成了追责会，最后变成“某同事上线没通知”之类的结论。这其实偏离了RCA的本意。

在体量异常场景下，RCA要回答三个层次的问题：

• 症状层：什么指标异常了？（比如QPS从1万掉到3千）
• 直接原因层：哪个组件或行为直接导致了异常？（比如数据库连接池耗尽）
• 根因层：为什么那个组件会出问题？（比如连接池配置从未根据流量增长做过调整）

很多人做到第二层就停了。我个人习惯是，一定要追问到第三层，否则同样的故障换个姿势还会来。

5Why分析法：追问的艺术

5Why是丰田佐吉发明的，后来被丰田生产系统发扬光大。方法很简单：对一个问题连续追问“为什么”，直到找到根本原因。

但注意，5Why不是死板的“必须问5次”。有时候3次就够了，有时候需要7次。关键在于追问到系统层面可修复的原因为止。

我拿一个真实的体量异常案例来演示：

层次	问题	回答
1	为什么用户下单失败率从0.5%飙升到15%？	因为订单服务的接口超时了
2	为什么订单服务接口超时？	因为数据库查询耗时从10ms涨到了800ms
3	为什么数据库查询变慢？	因为某条SQL走了全表扫描，扫描了500万行
4	为什么那条SQL会走全表扫描？	因为联合索引的第二个字段被OR条件跳过了
5	为什么这个SQL之前没出问题？	因为之前数据量只有50万行，索引失效的影响不明显

看到没？第5个Why才真正触及根因：数据量增长导致原本可接受的SQL变成了性能炸弹。修复方案不是加索引那么简单，而是需要建立SQL性能基线，并在数据量增长时自动触发审查。

鱼骨图（因果图）在体量异常中的应用

5Why适合线性追问，但体量异常往往是多个因素共同作用的结果。这时候鱼骨图就派上用场了。

鱼骨图也叫石川图，是日本质量管理专家石川馨发明的。它把问题作为“鱼头”，把可能的原因分门别类列在“鱼骨”上。在体量异常场景下，我通常把原因分为这几类：

• 人：配置错误、上线失误、操作不当
• 机器：硬件故障、资源耗尽、网络抖动
• 方法：架构缺陷、限流策略不当、降级方案缺失
• 数据：数据倾斜、缓存穿透、热点Key
• 流量：突发流量、爬虫攻击、业务促销

下面这张图是我做RCA时常用的框架：

使用鱼骨图时，我建议团队做一次头脑风暴。把所有人叫到白板前，先别管对不对，把所有可能的原因都列出来。然后再逐一验证、排除。

5Why + 鱼骨图：组合拳

在实际的体量异常RCA中，我通常把两种方法结合起来用：

1. 先用鱼骨图做广度覆盖：把可能的原因分类列出来，避免遗漏
2. 再用5Why做深度挖掘：对每个疑似原因追问到底

举个例子，有一次线上支付成功率突然下降。鱼骨图帮我们快速锁定了几个方向：支付网关超时、回调丢失、订单状态不一致。然后对每个方向做5Why，最后发现根因是支付网关的SDK版本升级后，超时重试策略变了——从指数退避变成了固定间隔重试，直接把网关打挂了。

体量异常RCA的常见陷阱

做RCA这么多年，我踩过不少坑。这里列几个最常见的：

陷阱	表现	正确做法
停止在直接原因	找到“连接池满了”就收工	追问“为什么连接池会满”
归因于人	结论是“某同事没加索引”	找系统缺陷，而不是个人失误
忽略环境变化	只关注故障时刻，不看趋势	对比故障前后的数据量、流量变化
单一原因论	认为只有一个根因	接受多个根因并存的可能性

嗯，这里要特别强调一下“归因于人”这个陷阱。我见过太多RCA报告写着“某开发上线前没做压测”。然后呢？换个人就解决了？不，下次还会有人犯同样的错。正确的做法是：为什么上线流程没有强制要求压测？为什么压测环境不可用？这才是系统层面的根因。

小结

根因分析不是玄学，是有方法可循的。5Why帮你挖深度，鱼骨图帮你扩广度。两者结合，基本能覆盖90%的体量异常场景。