在學習《問題分析與解決》時學到了一種找到問題根源的方法——問五次為什么。具體內容是：當遇到一個問題，不要只看當前答案，要繼續往下問，為什么，連問五次，就能夠找到更深層次的問題。
最近在復盤bug的時候，也使用了這種方法，屢試不爽。
案例
前端發布后，頁面按鈕點擊失效，用戶反饋問題，前端回滾代碼后恢復。
問題一、為什么按鈕點擊會失效？
因為前端代碼寫出了一個bug，沒有對空對象進行判空，導致頁面js拋出異常，按鈕失效。
一般到這里就結束了，把代碼加上對象判空，繼續發布就完成了。
但是大家集思廣益，問五次為什么，看看是否有新的發現。
之后又問了幾個為什么，果真有收獲。
問題二、為什么是用戶反饋，而不是告警發現？
因為當時發現了告警，但是看日志沒有查出什么異常，就忽略了。
問題三、為什么沒有查出日志，是沒寫日志，還是寫了沒查到？
有寫日志，但是當時查日志系統特別慢，平時要十多分鍾才能查出來，那天一個小時都沒出來。
問題四、為什么系統會查不出日志？
不知道。后來找維護系統的人查了下，發現硬盤有問題，緊急更換了磁盤。
問題五、為什么平時要十多分鍾才能查出來日志，這么慢？
因為查詢日志沒有用主key查詢，日志量太多，導致查詢慢。改進：記錄日志時把key值寫好，精簡不需要的日志。
總結
經過問五個為什么，把一個看似簡單的線上bug，挖出了更多可以修改的點。為以后及時發現問題，少出事故，做了很大的貢獻。
如果只問一個為什么，那么修改的只有表象問題，把代碼判斷空加上就結束了。
問了五個為什么之后，做了這幾件事：
- 修復代碼判空的bug。
- 發現了日志系統的磁盤問題。
- 發現了系統的冗余日志，要精簡掉。
- 發現記錄日志的方式不對，修改。
特別是2，如果不找出來，其他系統也會掉到這個坑里，也算是舉一反三。發現一個問題，把關聯問題，和根本問題都解決了
很多時候，我們遇到的問題都有更深層次的原因。一個問題出現，也都是多個問題同時發生的結果。在大問題發生之前，一定有很多次小問題出現。問5個為什么，就像進行了5次深度和廣度的搜索，把問題又向四周和更深的地方挖掘。
每次出問題時都能多問幾次為什么？才是從根本上消除問題的一個好方法！