找到bug的根源，问五次为什么

在学习《问题分析与解决》时学到了一种找到问题根源的方法——问五次为什么。具体内容是：当遇到一个问题，不要只看当前答案，要继续往下问，为什么，连问五次，就能够找到更深层次的问题。
最近在复盘bug的时候，也使用了这种方法，屡试不爽。

案例

前端发布后，页面按钮点击失效，用户反馈问题，前端回滚代码后恢复。
问题一、为什么按钮点击会失效？
因为前端代码写出了一个bug，没有对空对象进行判空，导致页面js抛出异常，按钮失效。
一般到这里就结束了，把代码加上对象判空，继续发布就完成了。
但是大家集思广益，问五次为什么，看看是否有新的发现。
之后又问了几个为什么，果真有收获。
问题二、为什么是用户反馈，而不是告警发现？
因为当时发现了告警，但是看日志没有查出什么异常，就忽略了。
问题三、为什么没有查出日志，是没写日志，还是写了没查到？
有写日志，但是当时查日志系统特别慢，平时要十多分钟才能查出来，那天一个小时都没出来。
问题四、为什么系统会查不出日志？
不知道。后来找维护系统的人查了下，发现硬盘有问题，紧急更换了磁盘。
问题五、为什么平时要十多分钟才能查出来日志，这么慢？
因为查询日志没有用主key查询，日志量太多，导致查询慢。改进：记录日志时把key值写好，精简不需要的日志。

总结

经过问五个为什么，把一个看似简单的线上bug，挖出了更多可以修改的点。为以后及时发现问题，少出事故，做了很大的贡献。
如果只问一个为什么，那么修改的只有表象问题，把代码判断空加上就结束了。
问了五个为什么之后，做了这几件事：

1. 修复代码判空的bug。
2. 发现了日志系统的磁盘问题。
3. 发现了系统的冗余日志，要精简掉。
4. 发现记录日志的方式不对，修改。
   特别是2，如果不找出来，其他系统也会掉到这个坑里，也算是举一反三。发现一个问题，把关联问题，和根本问题都解决了
   很多时候，我们遇到的问题都有更深层次的原因。一个问题出现，也都是多个问题同时发生的结果。在大问题发生之前，一定有很多次小问题出现。问5个为什么，就像进行了5次深度和广度的搜索，把问题又向四周和更深的地方挖掘。
   每次出问题时都能多问几次为什么？才是从根本上消除问题的一个好方法！

​