📚 课程目录第2章根因定位方法论

根因定位方法论：四种实战工具

做SLA故障排查这些年，我最大的体会是：找到根因比修复故障更难。很多时候我们修好了表象，过两天同样的问题又冒出来——那说明根因根本没挖到。

这一章，我把自己常用的四种根因定位方法掰开揉碎讲给你听。每种方法都有它的适用场景，也有它的坑。咱们一个一个来。

5Why，说白了就是连续问五次「为什么」。别小看这个简单的方法，我在项目中靠它翻过不少案。

举个例子。有一次线上支付接口超时率飙升，团队第一反应是扩容。我拦住了，问了一句：「为什么超时？」

真实案例：一次支付超时排查

你看，根因不是「数据库慢」，而是流程缺陷。如果只做扩容，明天还会出问题。

我的经验：5Why不是死板地刚好问五次。有时候三次就到底了，有时候要问七次。关键是每次回答都要基于事实，别猜。我曾经见过有人问「为什么服务器宕机？」答「因为运气不好」——这就不及格了。

鱼骨图也叫因果图，适合问题原因比较发散、不确定从哪入手的时候用。我习惯把它当作「头脑风暴的骨架」。

画法很简单：鱼头是问题，鱼骨是原因大类，鱼刺是具体原因。

常见原因分类（IT运维场景）：

举个例子。有一次数据库主从延迟严重，我们用鱼骨图把所有可能原因列出来：

然后逐一排查，最后发现是从库磁盘IO的问题。鱼骨图帮我们没漏掉任何一个方向。

避坑指南：鱼骨图容易变成「大杂烩」。我曾经见过一张鱼骨图列了50多个原因，根本没法排查。我的建议是：每个分支最多列3-5个最可能的原因，先聚焦，再扩展。

故障树（FTA）和鱼骨图正好相反——它是自上而下的。从顶层故障开始，逐层拆解成更小的子故障，直到找到基本事件。

我一般在复杂系统、多依赖链路的场景下用FTA。比如一个微服务调用链路上出了SLA违约，用故障树能把每个环节都拆清楚。

故障树基本符号：

举个例子。顶事件是「用户下单接口SLA违约（响应时间>500ms）」。拆解如下：

这样一层层拆下去，最后找到底事件，根因就浮出水面了。

我的习惯：FTA适合写在白板上，团队一起画。每个人负责自己那块的拆解，最后拼起来。这样既全面，又不会漏掉跨团队依赖。

这个方法最直观——把事故前后的时间线画出来，看什么时间发生了什么。我几乎每次排查都会先用这个方法搭个时间轴。

为什么？因为很多SLA违约是多个事件叠加的结果。单看一个点看不出问题，但放在时间线上，因果关系就清楚了。

时间线回溯的步骤：

举个例子。有一次凌晨3点SLA违约，时间线回溯发现：

你看，根因很明显——配置变更引发了连锁反应。如果没有时间线，你可能还在查数据库为什么慢。

避坑指南：时间线回溯最怕「事件遗漏」。我曾经有一次漏掉了某个中间件的重启日志，导致绕了一大圈。我的建议是：把监控系统、变更系统、告警系统的数据都拉出来，交叉比对，别只信一个来源。

下面这张SVG图总结了四种方法的适用场景和核心逻辑，我平时就贴在工位上。

说了这么多，你可能会问：到底用哪个？

我的习惯是这样的：

当然，这不是死规矩。有时候问题简单，一个5Why就搞定了。有时候问题复杂，四种方法轮着用。关键是别只依赖一种方法，也别在一种方法上死磕。

一个小技巧：每次排查完，把用到的根因方法和结论记下来。时间长了，你会发现自己对某些场景有「直觉」——一看就知道该用哪种方法。这个直觉，就是经验。