線上故障如何排查

語言: CN / TW / HK

前言

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

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

快速止血

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

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

凌亂

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

  • 重啟 系統不可用時先重啟,先保證系統的可用性,具體功能問題還要繼續定位,重啟幾分鐘又出現大量error就尷尬了

  • 限流 重要介面要提前準備好限流配置,隨便可以動態更改介面QPS

  • 線上回滾 如果前一天剛有上線動作,那十有八九就是上線導致的,這種情況如果問題暫時沒排查出來可以先回滾,然後組織一堆人去扒新提交的程式碼吧

  • 緊急擴容 首先服務必須是無狀態的,支援動態擴充套件,而且瓶頸必須在應用服務,如果瓶頸在DB或者在別的地方也沒辦法

故障排查過程

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

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

cat監控

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

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

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

vmstat -n 2 3 
複製程式碼

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

  1. proces
  • r 執行和等待CPU時間片的程序數
  • b 等待資源的程序數
  1. cpu
  • us 使用者程序消耗CPU時間百分比,如果長期大於50%,可能存在CPU洩漏的危險,需要優化程式
  • sy 核心程序消耗CPU時間百分比

3.記憶體

free
free -g
free -m
複製程式碼

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

4.硬碟

df -h
複製程式碼

df

5.磁碟IO

iostat -xdk 2 3
複製程式碼

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

6.網路IO

ifstat l
複製程式碼

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 | grep 16進位制執行緒tid 
複製程式碼

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

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

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

  • 系統監控,再次強調,線上系統不能裸奔

  • 設定故障等級,阿里是根據影響使用者量來定故障等級,不同的故障等級有不同的止血時效要求,規定時間內沒止血就會上升,觸發更高階的流程

  • 故障演練,核心介面壓測必不可少,像秒殺系統,瞬間大流量怎麼處理,redis掛了怎麼處理,DB CPU快打滿了怎麼處理,都要事先演練好,準備好止血或者降級job或指令碼

故障覆盤

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

常見的覆盤流程三部曲

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

總結

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

感謝關注

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