找到bug的根源,问五次为什么
2019-01-25 22:04
513 查看
在学习《问题分析与解决》时学到了一种找到问题根源的方法——问五次为什么。具体内容是:当遇到一个问题,不要只看当前答案,要继续往下问,为什么,连问五次,就能够找到更深层次的问题。
最近在复盘bug的时候,也使用了这种方法,屡试不爽。
案例
前端发布后,页面按钮点击失效,用户反馈问题,前端回滚代码后恢复。
问题一、为什么按钮点击会失效?
因为前端代码写出了一个bug,没有对空对象进行判空,导致页面js抛出异常,按钮失效。
一般到这里就结束了,把代码加上对象判空,继续发布就完成了。
但是大家集思广益,问五次为什么,看看是否有新的发现。
之后又问了几个为什么,果真有收获。
问题二、为什么是用户反馈,而不是告警发现?
因为当时发现了告警,但是看日志没有查出什么异常,就忽略了。
问题三、为什么没有查出日志,是没写日志,还是写了没查到?
有写日志,但是当时查日志系统特别慢,平时要十多分钟才能查出来,那天一个小时都没出来。
问题四、为什么系统会查不出日志?
不知道。后来找维护系统的人查了下,发现硬盘有问题,紧急更换了磁盘。
问题五、为什么平时要十多分钟才能查出来日志,这么慢?
因为查询日志没有用主key查询,日志量太多,导致查询慢。改进:记录日志时把key值写好,精简不需要的日志。
总结
经过问五个为什么,把一个看似简单的线上bug,挖出了更多可以修改的点。为以后及时发现问题,少出事故,做了很大的贡献。
如果只问一个为什么,那么修改的只有表象问题,把代码判断空加上就结束了。
问了五个为什么之后,做了这几件事:
- 修复代码判空的bug。
- 发现了日志系统的磁盘问题。
- 发现了系统的冗余日志,要精简掉。
- 发现记录日志的方式不对,修改。
特别是2,如果不找出来,其他系统也会掉到这个坑里,也算是举一反三。发现一个问题,把关联问题,和根本问题都解决了
很多时候,我们遇到的问题都有更深层次的原因。一个问题出现,也都是多个问题同时发生的结果。在大问题发生之前,一定有很多次小问题出现。问5个为什么,就像进行了5次深度和广度的搜索,把问题又向四周和更深的地方挖掘。
每次出问题时都能多问几次为什么?才是从根本上消除问题的一个好方法!
相关文章推荐
- 纠结了很久,不知道为什么除了什么原因,用任何方查都查不到根源,后来ArrayList存放了Bitmap,结果出错了,终于找到了事情的根源,一阵无语,不能存放竟静态的,为什么不提示呢, 害我以为是那些自
- 修改bug时,尤其是别人的代码,永远不要钻牛角尖。应该利用debug,找到问题根源的突破口。
- 不要做丢狗的人—找到问题的根源
- 为什么我没有拔出钥匙 ——开锁引发的程序bug解决方案的思考
- 这样的bug能发现真不容易啊,花了我两天时间才找到
- 《暗黑3》BUG不断 玩家为什么还能继续容忍暴雪?
- 面试题:为什么你还没有找到工作?
- Linux:为什么要找到“商业感觉”?
- 为什么去别的地方总不能找到愉快的经历
- 为什么总有无数的Bug困扰着程序员
- 认识hasLayout——IE浏览器css bug的一大罪恶根源(转载网址http://neverned.blog.163.com/blog/static/1265524200933021130561/)
- 半天时间找到原因却仍未解决的Bug
- 为什么修复每个 bug 后都要问这 3 个问题?
- sfsx2 jar为什么没有找到服务器端扩展,折腾了三天终于找到原因了!
- 为什么我没有拔出钥匙 ——开锁引发的程序bug解决方案的思考
- Notify-osd是怎么让我找到Deepin音乐BUG的
- 为什么一个项目有那么多BUG
- 蓝桥杯寒假训练一1015特殊的数字(找到自己一个惊天大BUG)
- 为什么要记录Bug的制造者或引入者?
- 为什么总有无数的Bug困扰着程序员