背景

線上故障是技術成長中不可避免的一部分，我們從中能夠吸取寶貴的教訓並變得越來越有經驗。然而，並非每個團隊或技術同學都能以合理和科學的方式處理故障。基於日常實際工作經驗和個人心得，我整理了一份團隊遇到故障問題或者疑似問題快速排查的三字經清單及正確✅案例和錯誤❌案例。這份清單將幫助你在遇到問題時進行快速排查，無需擔心在高壓環境下忙中出錯，遺漏關鍵步驟環節。掌握這份清單，你將能夠更好地掌控現場，從而避免因疏忽而造成的損失。讓我們面對故障時保持冷靜，有條不紊地進行排查，不斷提升我們的技術水平和問題解決能力。

三字經

備註：下面不是嚴格的順序，需要根據實際情況調整可多路並行，比如清楚問題大概環節，先止血。如不清楚，報備分工，初步定位大概環節再快速止血。

在故障處理過程中採取的所有手段和行動，一切以恢復業務為最高優先順序，恢復現場快速止血方案高於尋找故障原因等其他所有環節。

別慌張，先報備

先組會，明分工

描現象，非結論

先止血，再定位

看監控，看紀錄檔

找規律、先試驗

看輸入，看輸出

留現場，時反饋

別慌張，先報備

1、在處理緊急事件（線上問題或者疑似問題）時，先把問題上報組內。

2、充分發揮團隊的力量，通過集思廣益的方式，可以更加快速地找到問題的根源，並採取相應的措施進行解決。

✅正例：

• 假設一個團隊中一名成員遇到了一個業務或者其他團隊研發反饋的線上問題。他首先將問題上報給了組內TL/架構
• 然後通過線上會議或即時通訊工具與團隊成員分享問題的細節。團隊成員們迅速展開討論，集思廣益，共同分析問題的原因和可能的解決方案。
• 經過大家的共同努力，最終找到了問題的根源，併成功解決了問題。這個過程中，團隊成員們充分發揮了團隊共同作業的力量，提高了解決問題的效率。

❌反例：

• 假設一個團隊中一名成員遇到了一個業務或者其他團隊研發反饋的線上問題。他沒有將問題上報給組內，而是試圖自己解決。 結果，這個問題沒有得到及時的解決，反而加重影響了線上損失。

先組會，明分工

1、故障指揮官(問題發現人或者小組長/架構），有權召集相應的業務、產品、開發或其它必要資源，快速組織會議。

2、故障指揮官明確各角色職責，分工明確，這樣可以有效地提高故障處理的效率。

✅正例：

• 故障指揮官（問題發現人或者TL/架構）有權召集相關的業務、產品、開發等團隊成員，快速組織一個會議。在會議上，明確各成員的角色職責
• 如產品人員、開發人員、測試人員等，並分工明確。這樣，每個人都能清楚地知道自己需要完成的任務，從而有效地提高故障處理的效率。
• 通過集思廣益，團隊成員們能夠迅速找到問題的根源，並採取相應的措施進行解決。

❌反例：

• 故障指揮官（問題發現人或者TL/架構）沒有及時召集相關的業務、產品、開發等團隊成員開會。他試圖自己解決問題，但由於缺乏專業的業務 知識和經驗，問題沒有得到及時的解決。同時，其他團隊成員也因為不知道問題的嚴重性而沒有給予足夠的關注。這種情況下，故障指揮官需要 花費更多的時間和精力去協調各方資源，最終可能導致問題得不到有效解決，影響整個專案的進度。

描現象，非結論

1、讓問題發現者描述發現的現象（時間、影響範圍、影響程度），而不是判斷的結論（因為判斷的結論可能是錯誤的，這樣會誤導大家排查方向）

2、請大家避免在描述問題現象時，過多地表達自己的判斷和看法，因為這可能會影響到大家的排查方向。我們需要保持客觀和理性的態度，以便更好地分析問題。

3、同時，也請大家注意自己的思維方式，避免讓自己的大腦成為別人思想的跑馬場。在討論問題時，我們可以提出自己的觀點和建議，但請確保這些觀點是基於事實和證據的，而不是個人的主觀臆斷。

✅正例：

假設在一個軟體開發團隊中，當遇到一個效能問題時，問題發現者描述瞭如下現象：

• 時間：2023年8月18日上午9點至10點之間，使用者在使用過程中發現了明顯的效能下降。
• 影響範圍：影響到使用者登入、資料查詢等主要功能模組。
• 影響程度：由於效能下降，使用者的請求響應時間明顯增加，部分使用者無法正常完成操作。

在這個例子中，問題發現者提供了具體的現象資訊，使得團隊成員能夠迅速定位問題所在，並採取相應的措施進行優化和修復。

❌反例：

假設在一個軟體開發團隊中，當遇到一個效能問題時，問題發現者僅給出了自己的判斷結論：

• 時間：2023年8月18日上午9點至10點之間。
• 影響範圍：可能是資料庫連線池的問題。
• 影響程度：很嚴重，導致大部分使用者都無法正常使用系統。

在這個例子中，問題發現者沒有提供具體的現象資訊，而是僅僅給出了自己的判斷結論。這可能會導致團隊成員在排查問題時產生困惑， 無法準確地找到問題的根源。同時，由於判斷結論可能是錯誤的，這也可能誤導團隊成員，導致他們在排查問題上浪費時間和精力。

先止血，再定位

1、在故障處理過程中採取的所有手段和行動，一切以恢復業務為最高優先順序，恢復現場止血方案高於尋找故障原因。

2、快速止血：我們可以採用開關技術、回滾技術等手段，迅速恢復系統功能，避免服務中斷。

3、日常應急預案：請大家提前制定好應急預案，包括關鍵業務的容災策略、故障切換流程等，以便在發生故障時能夠迅速啟動預案，降低故障對業務的影響。

4、請大家在故障處理過程中，不要過於關注故障原因的尋找。雖然找到故障原因是解決問題的關鍵，但在緊急情況下，我們需要優先考慮如何快速止血，恢復業務。只有在確保業務穩定執行的前提下，我們才能有更多的時間和精力去深入分析故障原因，從根本上解決問題。

✅正例：

• 案例1：假設在一個軟體開發團隊中，當遇到一個系統故障時，問題發現者迅速採取了快速止血措施，恢復了系統功能。同時，團隊成員在日常工作中 制定了詳細的應急預案，使得在類似的故障發生時能夠迅速啟動預案，降低故障對業務的影響。在這個例子中，問題發現者和團隊成員將恢復業務作為最高優先順序， 迅速採取了快速止血措施，確保了系統的穩定性和可用性。同時，他們也注重日常應急預案的制定，為將來可能出現的故障做好了充分的準備。
• 案例2：在上線釋出期間，如果開始報錯，並且釋出前一切正常？那什麼也別管，先回滾再說，等恢復正常後再排查問題。
• 案例3：應用已經穩定執行很長一段時間，突然開始出現程序退出的現象？則很可能是記憶體洩露，可採用重啟大法，重啟部分機器後觀察看看是否止血了。

❌反例：

• 假設在一個軟體開發團隊中，當遇到一個系統故障時，問題發現者花費了大量的時間去尋找故障原因，而忽略了快速止血和恢復業務的重要性。 同時，團隊成員在日常工作中沒有制定詳細的應急預案，導致在類似的故障發生時，處理過程混亂，無法迅速恢復系統功能。在這個例子中，問題發現 者和團隊成員過於關注故障原因的尋找，而忽視了快速止血和恢復業務的重要性。這導致了在故障發生時，處理過程效率低下，無法及時恢復系統功能， 給業務帶來了較大的影響。

看監控，看紀錄檔：

1、收集和分析UMP效能指標、Logbook錯誤紀錄檔、MDC系統執行狀態等資訊，以便更準確地判斷問題所在。

2、與相關團隊進行溝通，共同分析問題原因，制定解決方案。在解決問題的過程中，要保持冷靜和耐心，遵循故障處理的最佳實踐，確保問題得到及時有效的解決。

✅正例：

• 假設在一個生產環境中，系統突然出現效能下降的問題。作為oncall人員，在接到問題報告後，首先通過各種監控工具收集系統執行狀態和 效能指標等資訊。然後，根據收集到的資訊分析問題可能的原因，並與相關團隊進行溝通和共同作業。最後，制定解決方案並進行實施， 成功解決了系統效能下降的問題，恢復了正常的生產環境。

❌反例：

• 假設在一個生產環境中，系統突然出現故障，導致業務無法正常執行。作為oncall員，在接到問題報告後，沒有先定位大體方向，也沒有通過監控工具收集相關資訊進行分析。而是直接嘗試修復問題，但由於缺乏準確的資訊和分析，很難找到問題的根本原因，導致問題得不到有效解決，影響了業務的正常執行。

找規律、先試驗

1、通過各種監控工具，如UMP（流量、tp99、可用率）和紀錄檔分析，我們可以查詢規律並瞭解系統在上線前後的表現。比如，我們可以對比昨天、上週的紀錄檔資料，看看是否也存在類似的問題。同時，我們還可以監測UMP流量的變化，以判斷系統是否受到異常的影響。

2、如果我們發現之前也存在類似的疑問點，那麼這可能意味著問題與今天的上線無關。我們需要繼續深入研究，找出根本原因。

3、對於每一個疑問點，我們應該按照優先順序進行試驗和驗證。這樣可以確保我們首先解決最關鍵的問題，避免影響系統的正常執行。

4、如果在試驗過程中發現問題仍然存在，我們應該及時調整方案並重新進行試驗。這樣可以幫助我們更快速地找到問題的根源，並採取相應的措施進行修復。

5、在整個排查過程中，我們應該保持溝通和共同作業。如果遇到困難或不確定的情況，可以與其他團隊成員交流，共同解決問題。

✅正例：

• 假設在一個生產環境中，系統突然出現效能下降的問題。作為oncall人員，通過各種監控工具收集了UMP和紀錄檔資料，並行現在昨天和上週也存在類似的問題。 同時，監測到UMP流量與之前相比沒有明顯變化。基於這些資訊，運維人員可以初步判斷問題與今天的上線無關，可能是由於其他原因導致的。 他們按照優先順序進行試驗和驗證，最終發現問題是由於某個設定引數設定不正確導致的。通過調整設定並重新試驗，問題得到了解決，系統效能恢復正常。

❌反例：

• 假設在一個生產環境中，系統突然出現故障，導致業務無法正常執行。作為oncall人員，沒有經過詳細的監控和分析，直接嘗試修復問題。 然而，由於缺乏準確的資訊和分析，問題得不到有效解決，甚至可能因為錯誤的操作而導致更嚴重的錯誤。這種情況下，oncall人員需要及時調整 方案並重新進行試驗，以確保問題得到正確處理。

看輸入，看輸出

1、首先，確認需要比對的輸入和輸出引數。這些引數可能包括請求引數、響應資料等。確保你清楚地知道需要比對的內容。在比較過程中，注意觀察引數值的差異。如果發現有差異，進一步分析可能的原因，例如引數傳遞錯誤、介面邏輯問題等。

2、如果發現問題是由於介面邏輯導致的，可以嘗試某N臺機器回滾到之前的版本，然後再次測試介面是否正常工作。如果問題仍然存在，可能需要進一步排查並修復程式碼。

3、根據比對的結果和排查的過程，總結經驗教訓，提出改進建議，以避免類似問題再次發生。

✅正例：

• 假設在一個生產環境中，系統突然出現效能下降的問題。作為運維人員，通過技術回滾某臺機器或者引流比對，發現輸入引數與預期不符，導致介面無法正確處理請求。 通過仔細排查，發現是由於一個設定引數錯誤導致的。修復該問題後，系統效能恢復正常，業務正常執行。

❌反例：

• 假設在一個生產環境中，系統突然出現故障，導致業務無法正常執行。作為運維人員，沒有進行任何比對和排查，直接嘗試修復問題。 然而，由於缺乏準確的資訊和分析，問題得不到有效解決，甚至可能因為錯誤的操作而導致更嚴重的錯誤。這種情況下，運維人員需要及時 調整方案並重新進行試驗，以確保問題得到正確處理。

留現場，時反饋

1、在進行故障排查和處理時，保留現狀並記錄已採取的措施和嘗試過的解決方法是非常重要的（比如不要全部機器都重啟，可保留1臺現場機器）

2、詳細地記錄下來包括已採取的措施和嘗試過的解決方法。

3、沒有進展也是進展，也要及時反饋。

✅正例：

• 假設在一個生產環境中，系統突然出現效能下降的問題，值班運維人員保留了1臺機器並且摘除了流量，其他機器分批重啟了，快速止血恢復了現場， 同時安排其他人員去分析未重啟的機器，Dump應用快照（常用的快照型別一般就是執行緒堆疊和堆記憶體對映）分析原因。

❌反例：

• 假設在一個生產環境中，系統突然出現效能下降的問題，值班運維人員直接把機器都重啟了， 這樣快速止血恢復了現場，但由於沒有保留現場，導致現場關鍵資訊丟失，可能無法繼續排查根因

如果你發現我提供的資訊有誤或者有更加合適的清單，請隨時指正並且聯絡我補充完善。非常感謝你的反饋和幫助！我將盡快進行修正並提供更準確的資訊。

作者：京東物流 馮志文

來源：京東雲開發者社群  自猿其說Tech 轉載請註明來源