分析事故根本原因的利器——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分析法的案例能对你有启发，可将其作为一种思维方式，应用于实际的问题分析中。
我是草捏子，一只热爱技术和生活的草鱼，我们下期见！