德國科技管理專家斯坦門茨早年移居美國，他以非凡的才能成為美國企業界的佼佼者。一次，美國著名的福特公司的一組電機發生故障，在束手無策之時，公司請斯坦門茨出馬解決問題。 斯坦門茨在電機旁仔細觀察，經過計算，用粉筆在電機外殼划了一條線，說：“從這裡打開，把裡面的線圈減少16圈。”工人們照他說的一試，電機果 ...
德國科技管理專家斯坦門茨早年移居美國，他以非凡的才能成為美國企業界的佼佼者。一次，美國著名的福特公司的一組電機發生故障，在束手無策之時，公司請斯坦門茨出馬解決問題。
斯坦門茨在電機旁仔細觀察，經過計算，用粉筆在電機外殼划了一條線，說：“從這裡打開，把裡面的線圈減少16圈。”工人們照他說的一試，電機果然運轉如初，福特公司給他酬金時，他索價一萬美元。
公司老闆覺得一條線要一萬美元未免漫天要價。斯坦門茨回答：“用粉筆劃一條線一美元，而知道在哪裡劃要9999美元。”公司老闆認為言之有理，乃照付一萬美元。
這個勵志故事告訴咱們要懂得如何排查問題的重要價值。今天咱們就來總結一下排查問題的9種方法：
基礎方法
監控告警
問題發生常用的手段有生產測試、監控告警和人工客訴。人工客訴是咱們最不願意看到的，那就需要在產生業務影響前及早發現。監控告警是發現問題的有效手段，具體可以參考《通知&告警治理(降噪)的7種方法》這篇文章。
日誌埋點
埋點是瞭解用戶行為的重要步驟，但更重要的目的是識別用戶的關鍵路徑。註入特定的代碼以記錄關鍵指標是提升應用性能的重要步驟。
日誌和埋點之間存在著細微的差別。埋點可以看作是日誌的子集。被埋點的任何數據都應該記錄在日誌中。
埋點承擔了為聚合分析發佈關鍵性能數據的職責，日誌則提供了用戶在不同級別跟蹤應用的細節信息，從低到高依次為:
-
Verbose:幾乎提供了所有的細節，主要用於跟蹤執行過程中控制流
-
Debug:表示數據主要用於調試
-
Info:表示非錯誤信息
-
Warning:表示可恢復的錯誤
-
Error：表示不可恢復的錯誤
日誌的記錄會貫穿應用的整個生命周期，而埋點只應該用在開發的特定階段。通過埋點，可以把特定類型或有有價值的信息素材收集起來，基於這些素材可以做非常多的有價值的分析、追蹤。
問題復現
這個不用多解釋，聊聊復現的步驟：
● 確保所有的步驟都被記錄。記錄下所做的每一件事、每一個步驟、每一個停頓。無意間丟失一個步驟或者增加一個多餘步驟，可能導致無法再現軟體缺陷。在嘗試運行測試用例時，可以利用錄製工具確切地記錄執行步驟。所有的目標是確保導致軟體缺陷所需的全部細節是可見的。
● 特定條件和時間。軟體缺陷僅在特定時刻出現嗎？軟體缺陷在特定條件下產生嗎？產生軟體缺陷是網路忙嗎？在較差和較好的硬體設備上運行測試用例會有不同的結果嗎？
● 壓力和負荷、記憶體和數據溢出相關的邊界條件。執行某個測試能導致產生缺陷的數據被覆蓋，而只有在試圖使用臟數據時才會再現。在重啟 BUG 復現方法總結機器後，軟體缺陷消失，當執行其他測試之後又出現這類軟體缺陷，需要註意某些軟體缺陷可能是在無意中產生的。
● 考慮資源依賴性包括記憶體、網路和硬體共用的相互作用等。軟體缺陷是否僅在運行其他軟體並與其他硬體通信的“繁忙”系統上出現？軟體缺陷可能最終證實跟硬體資源、網路資源有相互的作用，審視這些影響有利於分離和再現軟體缺陷。
● 不能忽視硬體。與軟體不同，硬體Hi按預定方式工作。板卡鬆動、記憶體條損壞或者CPU過熱都可能導致像是軟體缺陷的失敗。設法在不同硬體不再現軟體缺陷。在執行配置或者相容性測試時特別重要。判定軟體缺陷是在一個系統上還是在多個系統上產生。
抓包分析
tcpdump命令配合Wiresshark等解析工具可對網路問題做初步的排查。比如http請求是明文傳輸，可以抓到完整的請求內容。但是如果是加密的，至少可以看到有沒有RST等異常。或者原本應該觀察的到返回包有沒有，判斷是哪個鏈路出的問題。
這需要對網路知識有比較深的瞭解。可通過《網路通信知識地圖》進行學習，特別是《白話TCP/IP原理》要瞭解。
高危方法
linux命令
有點命令危險性不高，比如TOP，使用方法可參考：《時刻掌握系統運行狀態-深度理解top命令》。但是線上上不能隨便用。比如程式正在寫一個文件，這時候用命令行執行vim，可能導致fd文件描述符失效。關於文件描述符可參考《白話linux操作系統原理》或《趣談IO多路復用的本質》。
感興趣的朋友甚至可以自己實現一下fd文件描述符失效：
第一步：進程打開日誌文件,使用lsof -p pid
第二步：vim沒打開文件前(或者打開vim沒進行wq保存)
第三步：當vim 修改文件後wq時,會提示
提示文件在讀期間被修改了,我們選擇yes
第四步：此時再使用lsof -p pid命令來查看打開的文件描述符，進程打開的文件描述符的狀態變為了deleted狀態。
linux命令可以作為排查問題的利器，比如我在《懂得三境界-使用dubbo時請求超過問題》里提到的netstat -s ，但是要註意不要對線上造成影響。
下麵用圖來總結常用命令使用場景，圖小需要手工放大看：
留後門法
很久之前我們使用Redis，但是管理端做的不太好，我就在程式里留了後門：可以通過http介面對Redis的進行增刪改查操作。但是用http介面做管理，意味著沒有標準的許可權控制和操作標準流程，很容易受到攻擊或者誤操作。
更正統的方法是用標準的運維工具代替這些後門。
線上調試
舉個例子，有次我們在進行測試環境演練，出現了個怪異的問題。後來有同事說其他一個同事也在用這個環境做調試，所以才會調用哪個介面的地方卡住，出現問題。這種問題要是出現線上上，就是故障了。
高級方法
代碼走查
邏輯推理
但很多大神的解決步驟是：第一，聽別人講述問題現象；第二，提出問題以求證；第三，推理出大致原因並給出可選方案及方案的註意點；第四，自己、更多情況下是他人進行驗證。為啥是他人，能達到這種境界多是領導或者幫別人排查問題的救火隊長，問題發生和自己並沒有直接關係。
想達到這種境界還是需要平時的積累和深入理解和深耕。源碼和網路知識學起來~~
總結
一張圖總結今天介紹的方法:
