怕什么真理无穷,进一寸有一寸的欢喜。

——胡适

初识root cause

在上一章中，我分享了复盘思维，也介绍了复盘的整个过程。

在复盘的过程中，有一个环节不容忽视，那就是要找到引起问题的根因。

根因，也就是一个事件的根本原因（root cause）。

判断一个工程师成熟与否的方法之一，就是看他在遇到问题时，是流于表面、只看到第一层原因就急着下结论，还是能够熟练地使用根因（分析）思维，透过现象看到本质，然后从根本上解决问题。

工作了这么久，无论是只看到第一层、乱带节奏的小朋友，还是一眼就能看到第五层、每次都能一语成谶的大神——这两种类型的人我都见过。而他们在解决问题的能力上的差异，我只能说是天壤之别。

下面，为了说明萌新和老手之间的这种巨大的差别，不妨让我分享一个我自己的故事。

我，萌新，排查问题！

在工作最初几年里，我们使用的研发环境并不像现在这样稳定。对于糟糕的研发环境，那时大家的普遍说法是：

联调一天，光是排查环境问题浪费的时间就用去了大半天事件。

那个时候我刚入职没多久，还是个做事毛糙的愣头青。对于环境问题的排查，虽然当时我排查问题的速度很快，但是每次都只能看到表面问题——当时的我似乎从来就没有深刻过。

于是，在遇到问题的时候，就会出现如下对话：

“小王，这个服务调用失败的问题你看一下。”师傅丢过来一个问题。

“哦，下游返回失败了，”看过之后，我说，“我让下游的同学看一下。”

“等一下，”师傅抬头看着我，“下游为什么会返回失败，你不能自己看一下吗？你自己登一下他们的服务器很难吗？这不是分分钟的事吗？”

师傅说得对，于是我麻利地登陆到下游的服务器上，看过之后说：“我看下游系统抛系统异常了。”

“为什么会抛系统异常，”师傅再次反问，“你能不能仔细一点？”

我连忙认真检查服务器上的日志，基本看出了眉目，说：“看起来是数据库连接不上……”

“为什么数据库会连接不上？”师傅再次追问。

“……”

当时我直接愣住了，关于数据库的问题已经触及了我知识的盲区，我完全答不上来。

“不知道吗？不知道就去问DBA啊！”见我半晌没有动静，师傅骂道，“还愣着干嘛呢？！”

按照师傅的“指示”，我咨询了DBA，这才知道问题的原因是测试数据库日志打满之后宕机了，所以才会有后面的数据库连接问题。

央求之下，DBA手工删了多余的日志，重启了数据库，问题得以解决。

回到工位上，我向师傅报告了一通，本以为会受到表扬。

结果没想到师傅板着脸，劈头盖脸地骂道：

“为什么数据库的日志会打满？为什么日志打满之后数据库会宕机？有什么办法可以避免？这些问题你问清楚了吗？太不主动了吧？你的脑子是装饰品吗？稍微用一下会死吗？”

在工作的最初几年里，我就是在这样的“PUA”下度过的。

只是解决的问题多了，我发现自己变得不那么的毛糙了，遇到问题不会只看表面了，知道多向前走几步了。甚至，有时候即便这个问题和自己并没有直接关系，我也会主动去推动问题的解决。

换言之，我学会了探寻根因的思考方式和行事方式。

再后来，等到我也有机会指导新人的时候，我惊奇地发现熟悉的一幕以另一种方式循环了起来：

比如，当新人在钉钉上发来一个问题截图、向我求救的时候，我知道他不是不会，他是压根儿就没有主动去问为什么，没有主动去思考。

对于没有经过训练的新人来说，这倒也正常，这也是师傅存在的价值。

虽然，通过截图我已经大概知道了问题的原因，但是我不打算直接告诉他答案。只有自己动手找到的答案才是真正属于自己的答案。在萌新成长为大神之前，他总得经历这样的磨练——就像现在这样，他需要用自己的双手，从一台服务器登陆到另一台服务器，循环往复这个过程无数次，直到找到引起问题的根因……而且，这事儿没有一点捷径，以后他在生活中遇到问题时不也得如此吗？

于是，没经过太多的思考，我在对话框里打出了我的师傅经常提醒我的话：

你要学会多问几个为什么……

什么是根因分析？

一个问题发生了，在问题发生的那一刻，我们看到的都只是问题的外在表象，而引起问题发生的真正原因，往往被表象所掩盖，隐藏在一环套一环的原因和结果背后——因此，头痛医脚、屁股决定脑袋这种惨剧在我们的现实世界里反复出现真的一点都不奇怪。

而根因思维是正是一种避免惨剧发生的系统性思考方式，它的基本原则如下：

• 首先，根因思维承认世界本身的复杂性；
• 其次，根因思维认为问题和原因互为因果，组成了一条因果链；
• 最后，根因思维要求我们在因果链上从问题出发溯流而上，找到引起问题的根本原因。

比如，如下图的因果链，因为A所以B，因为B所以C，因为C所以D，而我们看到的只是D的表象，但是真正引起问题的原因却是A，此时我们就说A是这个问题的根因。

在前面的故事里，“我”看到的是自己系统中的服务调用失败，这其实就是表象D，而数据库日志打满才是这个问题的根因（A）。

当然，我们可以继续追问下去：数据库日志什么会打满？仔细深挖下去，我们一定能得到一个答案。得到答案之后，我们可以继续问下去，循环往复。理论上，因果链可以无限长。

于是，当一个问题发生了，如果我们不认真考察问题的发生的因果链，而是停留在表面问题上，我们就会把浅层次的原因——比如原因C——作为我们以为的“实际原因”来处理。

短期来看，好像解决了问题，但是长期下去却会发现问题并没有解决、还是会反复出现——这就是所谓的治标不治本。

解决问题最怕的就是不深刻。

因此，为了一劳永逸地解决问题，不管是哪个具体领域的工程师，都必须掌握根因思维。

但是，知道是一回事，应用又是另一回事，那么根因思维该如何使用呢？

如何进行根因分析？

实际上，应用根因思维最基本的方式，就是根因分析法。而典型的根因分析法当属丰田的5-why分析法了。

丰田5-why分析法

5-why分析法是丰田公司在汽车生产过程中总结出来的一种识别根因的方法。

简单来说，就是就眼前发生的问题层层递进地问5个问题（问题数量没有严格要求）。

这个分析法的创造者名叫大野耐一，他也是丰田生产法（TPS）的创造者，而丰田生产法就是后来大名鼎鼎的精益制造，有兴趣的朋友可以阅读《改变世界的机器》这本书（当然，这本书真的比较老）。

至于为什么叫5-why分析法，据说是大野耐一在一次回答记者的关于汽车质量的问题时说的。

他说：“我们遇到问题时至少要问5个为什么（why）。”

下面，让我们举一个5-why的例子，这个例子非常经典，例子当中的主角就是大野耐一。

有一次，大野耐一见到生产线上的机器总是停转，多次维修仍不见好转，于是大野询问现场的工作人员。

第一问

问：“为什么机器停了?”

答：“因为超过了负荷，保险丝就断了。”

第二问

问：“为什么超负荷呢?”

答：“因为轴承的润滑不够。”

第三问

问：“为什么润滑不够?”

答：“因为润滑泵吸不上油来。”

第四问

问：“为什么吸不上油来?”

答：“因为油泵轴磨损、松动了。”

第五问

问：“为什么磨损了呢?”

答：“因为没有安装过滤器，混进了铁屑等杂质。”

问到这里，机器停转的根因终于大白于天下——油泵没有安装过滤装器。那么对策就是检查所有机器的油泵，为没安装过滤器油泵安装过滤器。

看完这个例子，你可能会说这不就和前文中的故事里师傅问“我”问题的方法是一样的吗？

没错，虽然大野耐一和“我”遇到的问题和所处的领域不尽相同，但实际面对问题的分析方式却并无区别。

如何用好5-why分析法

然而，用好5-why分析法并不简单，在分析时需要格外注意下面四点：

第一，提问时抓住问题的主要矛盾。

5-why分析法非常考验提问者的经验，需要在提问时找到问题的主要矛盾。

不同角度的提问，会把分析导向完全不同的方向，最后导出的根因也不尽相同。比如下面这个例子：

问：为什么我们的系统奔溃了。

答：因为外部请求的流量太大了，我们的在瞬间系统处理不了这么多的流量。

此时的下一个问题，可以是——为什么外部请求的流量会这么大？也可以是——为什么我们的系统在瞬间处理不了这么多请求量？

前者往下推，可能会得出我们要对流量进行限制的结论，而后者推下去则可能会推出我们需要对系统进行性能优化的结论。

如果在分析时问错了问题，即便结果再正确也没有意义。

甚至，这真的会让人崩溃——尤其是在排查线上问题的时候，某人问了错误的问题把大家带到了错误的方向上，错过了故障恢复的良机——这种情况，用曾经被坑过的同事的话来说：

那可真是杀人的心都有了（我确定他不是在开玩笑，他真的是认真的）。

第二，要客观分析引起问题的原因

寻找问题的原因时，一定要避免主观臆断，应该从事实依据出发进行假设，最好能够拿到一手证据和数据来佐证。

比如，在师傅和我排查问题的例子里，我不能在还没登录服务看到日志的情况下（一般来说，日志是不会骗人的），就信口胡诌，随便编一个原因。如果我不负责任地乱说一通，那么后续的分析，都会建立在这个错误的原因之上。

因此，为了避免主观臆断带来的错误分析，丰田的5-why分析法非常推崇去现场实际勘查——也就是所谓的“现实”，“现场”以及“现物”。

第三，5-why分析不是推卸责任。

和复盘一样，在做5-why分析的时候，要让参与者聚焦在问题本身上，就事论事，而不是推卸责任。

一旦开始推卸责任，即便能够用5-why分析法找到问题的根因，这个根因必然也是立场扭曲的产物，无法为后续的改进提供指导。

第四，一定要有改进措施并有所行动

同复盘思维一样，分析根因的目的很明确，就是要让问题不再发生。

所以，根因分析之后一定要有改进措施和实际的实施动作，要能看到实际结果。

否则，我们对根因分析做得再漂亮，那都是纸上谈兵。

以上，就是对根因分析法——5-why分析法的所有介绍。虽然本节只是简单介绍了5-why分析法，但是本节的内容已经足以让我们将5-why分析法应用在我们的工作和生活当中。

两类问题

下面，我们将从日常工作和生活中遇到的两类不同类型的问题展开，继续对根因分析法的探讨。

在进入讨论之前，我想解释一下问题分类的必要性。

之所以要对问题分类，是因为对于不同类型的问题，我们所用的分析方法是不同的。

在遇到问题时，我们应该首先判断问题的类型，然后再考虑用与之匹配的分析方法，这样才会事半功倍。

一般来说，我们遇到的问题可以在很多种维度上进行分类。本文主要从因果链的复杂度上出发，将问题分为两类

1. 线性问题
2. 非线性问题

线性问题

所谓的线性问题，就是由一组组因为和所以关系前后咬合组成的单一链条，这条链没有旁路和分支，你可以从根因一路走到表象。

在线性问题里，因为“因为-所以”的关系链是单一而和稳定的，是在相同情况下可以反复验证的（也即，可复现的），所以这种问题总是可以被我们总结和归纳成一般性知识和智慧的。

比如，开篇故事中，“我”遇到的宕机问题其实就是一个线性问题。这个问题的因果关系非常明确，以至于如果下次还出现同样的问题，我可以在不登录服务器的情况下作出正确的判断。而如果我把问题的排查思路写下来，那么别人就可以照着我的文章学习排查的过程和解决方案。

事实上，我们在工作中遇到的绝大多数技术问题，都属于线性问题。

因为线性问题是稳定的，所以为了解决这类问题，我们可以在因果链上一路回溯而不用担心自己走错了路。这种回溯的方法，一般称为逆推法。

实际上，我在前文中已经花了大量篇幅描述一种逆推法——5-why分析法。

非线性问题

至于非线性问题，不同于线性问题中原因和结果的明确性，非线性问题并没有一个明确的原因，它的表象往往是多个原因交叉作用的结果。

直观来说，线性问题是前后关系明确的因果链，而非线性问题则是一个关系错综复杂的因果网。

因此，我们又把非线性问题称为复杂问题。我们在现实生活中接触到的绝大多数问题，都是非线性问题。

在处理复杂问题时，我们还是会用到逆推法。但此时我们不能直接溯流而上，而应该就当前问题在不同的层面上找到不同的原因。然后，再以这些原因作为新的问题，继续向下追问，重复上一步的动作。

最后，我们会得到一颗因果树，或者一张网。

但是，因果树（或者网）还不能直接使用，因为这棵树上的内容可能会非常庞杂和琐碎。此时我们还需对这棵树进行裁剪，找到主要矛盾（原因）和次要矛盾（原因），找到主要矛盾（原因）的主要方面。

至于如何寻找这些原因、又如何做剔除和裁剪，这除了需要大量的实验外，还需要分析者有足够的耐心。

作者的能力有限，也就只能写到这里了。

由果到因再由因到果

通过5-why分析法，我们从结果推到了根因，我们甚至采取了行动，一劳永逸地解决了这个问题，真是皆大欢喜。

但请务必注意，这还不是根因思维的全部，根因思维的使用到这里其实才刚刚过半。

再进一步，当我们推导出根因之后，我们还不能停止思考，此时我们应该切换思维方式。

因为在因果链上思考的时候，我们使用的思维方式是纵向模式。

在纵向模式下，我们会把我们的精力集中在具体的问题上，我们会思考很得深入，直至找到根因。

然后，这一部非常关键，我们应该把思维模式从纵向模式切换到横向模式。

横向思考模式，要求我们脱离问题的具体细节，而是退一步，在更广的视角下横向思考，这个思考要试图回答一个问题——这个根因是不是在其他情况下也是适用的——这是一个由具体问题到一般问题推进的过程——当然也是一个让人头大的过程。

比如，在开篇故事中数据库因为日志打满宕机的问题里，“我”想到了一种避免方案。

那么，横向思考时，我就要回答这个方案是否可以在其他的场景下使用，而不只是局限在当下的这个问题里。如果这个问题的回答是肯定的，那么我可能找到了防止数据库宕机的通用解决方案，甚至，我可以注册一个专利，或者提供一套技术解决方案，然后因此而发一笔横财。

总之，根因思维的完整路径应该是由果索因然后再由因推果。经过这样的两轮思考，我们才敢说我对这个问题的认识已经足够全面和深刻了。

时间的洗礼

根因思维说起来似乎简单，但是实际操作起来，其实非常吃经验。

以笔者曾从事过的支付业务为例，在这个领域里，你不摸爬滚打个三五年，不对业务、对系统、对组织（人）、甚至对三者的动态关系有一个实实在在的理解，在你的心里没有建立起一套完备的模型，你是不可能在这个领域用好根因思维的。

这一点在其他行业都是一样的，因此我们应该戒骄戒躁，不要总想着怎么走捷径，反而忽视了成长当中最重要的一环——耐心地接受时间的漫漫浸润。

耐心的缺失，往往才是我们遇到的问题里最大的根因。

本章小结

根因思维和根因分析法，是我们在日常中处理问题时必然会使用的思维工具。

根因思维认为引起问题的原因是由一个前后咬合的因果链构成的，我们可以通过逆推的方式（比如5-why分析法）找到根因并从根本上解决问题。

除了由果索因外，我们还需要切换到横向思考模式，再由果推因，把对具体性问题的解决推向对一般性问题的解决。

扩大问题的适用范围，相当于加了思维杠杆，我们的解决方案自然也会因此而变得更有价值。

当然，根因思维的娴熟应用建立在拥有丰富经验的基础之上，这里没有捷径可走，我们所能做的就是耐心地做好眼前的事情，慢慢积累经验。

毕竟，在根因思维里，当下的事情在未来还会有另外一个名字。

那就是——根因。

(本章完，版权归作者王晓辰所有，若要转载，请标明出处)

作者简介

王晓辰，软件研发工程师，8年+金融科技从业者，文字价值和文字理想的信仰者和践行者，公众号“架构师的白日梦”的作者。

他坚信用心写就的文字具有无穷的能量，可以穿越时空的阻隔，向读者传达最纯粹的经历、最质朴体悟以及最深邃的思索，最终完成思想的启迪和灵魂的交流。

架构创造未来，文字打败时间！