分析事故根本原因的利器——5Why分析法-技术圈

笔者最近接触到5Why分析法，觉得该方法简单实用，有助于分析问题的原因，因此尝试用来分析今年的一次生产事故。在开始分析前，先对5Why分析法进行介绍。

5Why分析法，是一种分析问题根本原因的方法，由丰田集团创始人丰田佐吉提出，后来成为丰田汽车公司获得成功的重要方法，并且被融入到各种管理方法中。该方法的字面意思是 5 个为什么，指的是对一个问题连续问出 5 个为什么，以分析其根本原因。丰田汽车前副社长大野耐一举过这样一个例子：

问题 1 ：为什么机器停了？

答：因为机器超载，保险丝烧断了。

解决方案：换保险丝（防堵措施）

问题 2 ：为什么机器会超载？

答：因为轴承的润滑不足。

解决方案：加润滑剂（改善措施）

问题 3 ：为什么轴承会润滑不足？

答：因为润滑泵失灵了。

解决方案：修理润滑泵（改善措施）

问题 4 ：为什么润滑泵会失灵？

答：因为它的轮轴耗损了。

解决方案：换轮轴（改善措施）

问题 5 ：为什么润滑泵的轮轴会耗损？

答：因为杂质跑到里面去了。

解决方案：给润滑泵安装过滤器（根本措施）

从上述 5 个问题，可看出，通过问题 1 只能看到问题的表象，而问题 2 到问题 4，仍只能对问题进行改善，而直到问题 5，才暴露出了根本原因，得以从根上解决问题。随着追问为什么，我们更容易去接近造成问题的根本原因。

5Why分析法的注意事项有：

问题数量不是关键，关键是找出根本问题。虽然叫5Why分析法，但不是必须要问 5 个为什么，一般 3 ~ 7 个都行，少于 3 个可能找不到根本原因，超过 7 个还没找到，那需审视问题本身是不是有问题，关注的焦点是不是偏移了。
追问的时候不要偏离主题。要朝着解决问题的方向进行分析，不要只从外界不可控因素寻找问题，而应寻找可控的因素。

下面用5Why分析法分析一个笔者遇到的实际生产事故。

事故即将发生时，数据库中正在执行的线程数超过预先设置的阈值 32 个，于是系统监控发出报警，随后数据库的CPU使用率开始飙高，紧接着系统的所有模块访问数据库失败，然后整个系统呈不可用状态。

当时的应急解决办法是查看数据库正在执行的SQL，然后定位SQL所涉及功能，将该功能所在模块进行重启，重启后CPU使用率开始下降，系统慢慢开始恢复，但随着问题模块重启完成后，CPU又逐渐呈现上升趋势，但这时已经给定位问题争取了一定的分析时间，定位到是一批特殊数据造成的，于是对这批数据进行了应急处理，最后事故解决，系统顺利恢复了。

下面笔者尝试从三个角度进行分析

角度一 “制造”，为什么会发生？

问题 1：为什么数据库的线程数会增加？

答：正在执行的SQL执行时间长。

问题 2：为什么正在执行的SQL执行时间长？

答：因为正在执行的SQL发生了死锁。

问题 3：为什么SQL会发生死锁？

答：同时删除相同的一批数据，而删除时出现乱序。

问题 4：为什么删除相同的一批数据？

答：代码逻辑问题，不需要重复删除。

解决方案：更改代码逻辑，避免重复删除。

角度二 “检验”，为什么没有发现？

问题 1：为什么代码上线几个月都没有发现？

答：未出现大量的死锁情况。

问题 2：为什么没有出现大量的死锁情况？

答：未出现这种造成大量并发的数据，测试用例也未覆盖。

问题 3：在小量并发数据的情况也可能发生死锁，为什么没有发现该逻辑会产生死锁？

答：未能及时从错误日志中发现问题。

问题 4：为什么未能及时从错误日志中发现问题？

答：错误日志中有较多无用的日志，扰乱了日志分析。

解决方案：清理代码中无用的错误日志打印，及时检查错误日志，并解决问题。

角度三 “系统”，为什么没有从系统上预防事故？

问题 1：为什么没有从系统上预防事故？

答：已经做了数据库正在执行线程数的预警，但发现时，数据库的CPU上升速度已经很快了，提供的反应时间不多。

问题 2：为什么单个模块的问题，会影响系统全部模块？

答：因为各模块都有使用到base数据库，base数据库一旦不可用，便影响了全部模块。

问题 3：为什么各模块都需要使用base数据库？

答：系统设计时，未将各模块所使用的数据库进行隔离。

解决方案：将各模块使用的数据库进行隔离，即使单模块出现问题，也不会通过数据库影响到其他模块（但是该方案的成本较高，相当于进行整体的重构了）

以上笔者通过三个角度来对此次事故进行分析，随着追问，对问题的认识也会更加清晰。希望这个5Why分析法的案例能对你有启发，可将其作为一种思维方式，应用于实际的问题分析中。

我是草捏子，一只热爱技术和生活的草鱼，我们下期见！