前言

說起線上故障，程式設計師應該都經歷過，從故障處理恢復過程中我們能快速提高。踩坑多了，慢慢也就成了大牛。這道題也是大廠的面試官們特別喜歡問的問題之一，從候選人對這道題的回答過程中，面試官至少能獲取到兩個方面的反饋。第一是你平時負責的專案是不是核心專案，如果你說你負責的是後管系統，出了問題重啟就OK了，那結果只能是出門右轉了。第二是候選人系統化處理問題的能力。你是如何快速止血；如何一步步快速定位到具體問題；故障前的準備工作是否充分，風險點有沒有緊急應對方案。

下面我們就一起來聊聊線上故障的排查過程

快速止血

在分散式系統環境中，最重要的就是快速止血。在網際網路公司呆過的同學知道，恐怖的覆盤大會往往第一個問題就是為什麼故障花了半個小時，業務都投訴了才知道。或者是為什麼花了15分鐘才知道是慢SQL問題，被按在地上摩擦的不要不要的。

原因是在分散式系統中，故障很容易產生“多米諾骨牌效應”。比如一個基建服務因為一個慢sql導致請求響應變慢，就會導致上游的請求堆積，執行緒無法釋放，進而導致上線的系統也變的很慢，出現大量error。這個雪崩過程有時候很快，到時候測試，運維，上游系統的負責人在各種電話，資訊轟炸你的時候，這時候的你肯定是

怎麼辦？如果問題定位了很長時間還沒定位到，那就只能先用殺手鐗了：

• 重啟系統不可用時先重啟，先保證系統的可用性，具體功能問題還要繼續定位，重啟幾分鐘又出現大量error就尷尬了
• 限流重要介面要提前準備好限流配置，隨便可以動態更改介面QPS
• 線上回滾如果前一天剛有上線動作，那十有八九就是上線導致的，這種情況如果問題暫時沒排查出來可以先回滾，然後組織一堆人去扒新提交的程式碼吧
• 緊急擴容首先服務必須是無狀態的，支援動態擴充套件，而且瓶頸必須在應用服務，如果瓶頸在DB或者在別的地方也沒辦法

故障排查過程

前面說到如果前一天有上線，然後出現故障回滾了，這種情況十有八九是迴歸測試不徹底，影響之前的邏輯了，最壞情況就是一堆人一行行去扒程式碼。現在我們討論的是如果生產服務變得很慢，error告警不斷增加的情況下怎麼處理？

• 服務監控系統高可用設計手段中很重要的一條就是服務監控，系統上線了不能裸奔，不然怎麼死的都不知道。安利一下美團開源的CAT監控系統，CAT能實時監控各個指標，各個鏈路事件。包括伺服器的CPU負載，JVM記憶體，GC資訊，執行緒資訊，慢URL，慢SQL，請求響應耗時平均線、95線、99線，以及配置單位時間內多少服務error告警等。

• 故障排查命令面試官經常喜歡問候選者線上故障有哪些排查命令，怎麼去排查的。一般是先整體後區域性的順序來排查

1.查詢整機首先通過top命令檢視整體情況，比較重要的指標有Load AVg，CPU usage，每個程序的CPU和MEM。

也可以通過uptime檢視精簡版

2.CPU通過vmstat工具查詢CPU的情況，vmstat包含兩個引數，第一個引數是取樣隔間時間，但是是秒，第二個引數是取樣次數。如：

vmstat-n23

表示每隔2秒取樣一次，一共取樣3次

1. proces

• r 執行和等待CPU時間片的程序數
• b 等待資源的程序數

1. cpu

• us 使用者程序消耗CPU時間百分比，如果長期大於50%，可能存在CPU洩漏的危險，需要優化程式
• sy 核心程序消耗CPU時間百分比

3.記憶體

free
free -g
free -m

一般應用程式可用記憶體/系統實體記憶體<20%代表記憶體不足，需要增加記憶體

4.硬碟

df-h

5.磁碟IO

iostat-xdk23

大部分場景下如果系統慢，一是CPU導致，還有一個就磁碟IO。常用的排查工具用iostat，引數含義跟vmstat一致

6.網路IO

ifstatl

ifstat命令如果不支援需要安裝，可以檢視各個網絡卡的in，out；觀察網路負載情況；網路情況是否正正常等

CPU佔用過高分析思路

• 先用top命令找出CPU佔比最高的程序
• 通過ps -ef命令或者jps(java程序)命令進一步定位這個佔用CPU最高的程序是一個什麼後臺程式
• 定位到具體執行緒

ps -mp 程序ID -o THREAD,tid,time

-m表示顯示所有的執行緒，-p程序使用cpu的時間，-o後面是自定義引數

• 將定位出來的執行緒ID轉換為16進位制

printf"%x\n"執行緒ID

• 定位到具體程式碼

jstat程序PID｜grep16進位制執行緒tid

以上排查過程讀者可以在本地跑一個死迴圈的程式，跟著步驟one by one分析一遍，肯定會有所收穫

系統上線前的風險評估及應急方案

為了出現故障時能夠有條理的處理，事先必須有完善的準備工作。

• 系統監控，再次強調，線上系統不能裸奔
• 設定故障等級，阿里是根據影響使用者量來定故障等級，不同的故障等級有不同的止血時效要求，規定時間內沒止血就會上升，觸發更高階的流程
• 故障演練，核心介面壓測必不可少，像秒殺系統，瞬間大流量怎麼處理，redis掛了怎麼處理，DB CPU快打滿了怎麼處理，都要事先演練好，準備好止血或者降級job或指令碼

故障覆盤

終於說到最核心的了，對程式設計師來說，每次線上事故踩坑都是一次大的成長，為了茁壯成長，事後覆盤必不可少

常見的覆盤流程三部曲

• 故障處理過程，從發現故障到處理完故障詳細記錄幾點幾分分別幹了什麼事，把事故從發生到解決的所有細節記錄下來
• 故障原因分析，說明故障的原因和分析報告，簡單一點就是定事故責任人了
• 後續整改TODO

總結

故障排查過程就講完了，你平時工作中碰到過哪些印象深刻的故障，事後是怎麼覆盤的，歡迎留言交流。筆者的一個同事說起在前東家的一個故障處理的趣事。半夜系統割接上線後，流量灰度切換過來後沒過久系統開始瘋狂告警，然後一堆大佬坐著同事後面看著他處理故障，同事緊張的查詢資料庫select單詞都敲不對。

感謝關注

可以關注微信公眾號「回滾吧程式碼」，第一時間閱讀，文章持續更新；專注Java原始碼、架構、演算法和麵試。

來源：飛機頭怎麼弄