Blog.4 故障排查

測試提Bug的基本要素，主要包括：

1. 指望獲得的結果
2. 實際獲得的結果
3. 如何重現問題

生產環境出了故障，固然也脫離不開這3個要點。只不過相對重現問題會略微複雜。畢竟，故障老是咱們意外以外的狀況。

根據Bug發生的現象，咱們會提出不少假設，而後進行逐步排除。

當問題發生時，最應想到的是：系統最近是否有過改動。很大機率上，一個正常工做的服務會一直維持工做，直到某種外力出現。若是確實是新功能上線致使的，能夠結合具體狀況，考慮是否回滾到老版本。但有些時候，回滾可能還會引起二次問題，須要特別注意。

接下來：

繼續保存冷靜，簡要評估問題的嚴重程度，及時給外部做出反饋。這裏的反饋特別重要，不只可讓你們瞭解故障的進展狀況，並且，你們還可能提供很是有價值的建議。

接下來：

仔細分析故障發生的現象，不要忽略錯誤日誌的任何細節。這個過程當中，日誌顯得尤其重要。一個好的日誌記錄，必須能還原或推斷出當時故障的現場。日誌信息主要包括：上下文信息、報錯信息。

固然，有時候故障會涉及多個微服務，最好能有一個trace_id，用來跟蹤故障的發生過程，以及具體是微服務中的哪臺服務器發生的故障。

接下來：

若是沒法絕對肯定故障的緣由，咱們須要復現Bug，也就是前文提到的逐個排除。這開發過程當中，追加劇要服務的測試用例很是重要，可能會節約好多寶貴的時間。

但也存在難點，好比一些僞相關的緣由誤導咱們的判斷。故障通常都有連鎖反應，有時候會很難分辨問題的主次。

Go開發排查問題

Q1

服務發生panic時，結合日誌中打印的堆棧信息，能夠很容易定位到出錯的代碼，並做出不少可能的推測。而後，結合具體的上下文信息，能很快復現問題。整個過程當中，日誌是問題排查的關鍵。

日誌必須包含panic的堆棧信息，最好有鏈路的trace_id信息。若是在開發過程當中，有對應的Test就更好了。

Q2

對於接口響應慢的狀況，能夠依靠pprof工具進行診斷。其中，最可能的是調用外部服務慢，好比經典的MySQL慢查詢。

若是排除了外部依賴的問題，那極可能是程序代碼自身問題。經過pprof的各類信息展現，也能很快定位。

珍惜Bug

不要放過任何Bug，對Bug的處理過程要作好梳理、總結。下面是總結的模版：

-- 細節
-- 災難響應
-- 過後總結
    -- 作的好的地方
    -- 作的很差的地方