線上故障處理手冊

stoneFang發表於2020-05-27

摘要

通常處理線上問題的三板斧是重啟-回滾-擴容,能夠快速有效的解決問題,但是根據我多年的線上經驗,這三個操作略微有些簡單粗暴,解決問題的概率也非常隨機,並不總是有效。這邊總結下通常我處理應用中遇到的故障的解決方案。

原則

處理故障的時候必須遵循的一些原則

  • 提早發現問題,避免故障擴散
    故障的出現鏈路一般如下圖所示
    在這裡插入圖片描述
    每一層都有可能出現問題,越底層出現問題,影響面越大。所以每一個層次都需要有相應的問題監控機制,這樣越早發現問題,越能儘早解決故障,避免問題的擴散。比如服務依賴的一個資料庫主庫有問題了,如果等到使用者報過來,這時候可能服務已經掛了幾分鐘了。再等你分析問題,解決問題,切換主備什麼的,可能幾分鐘又過去了。影響訪問比較大了。如果在資料庫出問題時,就已經收到警報,迅速解決,可能沒等使用者報過來,問題解決了。

  • 迅速廣播
    當收到一個P0警報,判斷應用出現問題了,第一時間在組內廣播。全部人員進入一級戰鬥狀態,發現可能和其他依賴的服務/中介軟體/運維/雲廠商有關,立即通知相關責任人,要求進入協同作戰。

  • 快速恢復
    保留現場很重要,有助於發現root cause。但是發生故障了,必須要爭分奪秒,不能為了保留現場浪費幾分鐘的時間去幹什麼dump記憶體,jstack執行緒狀態的事。必須第一時間內先恢復服務,之後再根據當時監控資料,去找root cause

  • 持續觀察
    為了解決問題,可能需要線上上進行了重啟/回滾/mock/限流等操作,一定要檢視是否達到了預期效果。
    需要持續觀察一段時間,服務是否真的正常。 有時候可能只是短暫下去了,還會反撲。

處理手段

處理手段無非是重啟、擴容、回滾、限流、降級、hotfix

以下是我一般處理線上問題的流程
在這裡插入圖片描述
主要分為四大塊

step1: 是否有變化

和造成大部分車禍的原因是由於變化導致一樣,線上故障通常也是由於變化導致的。外部的變化很難感知到,但是服務自身的變化很容易感知,當有服務釋出、配置變更等變化時。那麼首先判斷是否可回滾,可回滾的立馬回滾。

step2: 是否單機

現在一般是叢集部署,服務高可用。如果只是一臺機器有問題,在服務可摘除的情況下立即摘除。不可立即摘除的,先擴容再摘除。

step3: 是否叢集

整個服務叢集都出問題了,問題就相對比較複雜一些了,需要分為單個API與多個API錯誤。

  • 單個API錯誤
    是否對應用內其他API,模組、下游的儲存有影響。有影響的話,可降級的及時降級。由於請求量增加引起的,限流。對其他模組無影響,再排查問題,hotfix。
  • 多個API錯誤
    這種通常是step4出錯了,可以直接到step4檢視。
    如果不是step4錯誤,如果流量超預期,限流擴容操作。如果不是,找程式碼問題,hotfix上線

step4: 依賴的服務/儲存有問題

立即找到相關團隊,一起看問題。如果是自身服務不正常的請求引起的,再做相應的fix。如果是正常操作引起的,那需要緊急擴容,升級配置。

如何預防

從上述操作可以看出,故障發生時需要做的判斷還是很多的,如果經驗不夠豐富,處理不得當,很容易引發故障升級、資產損失。
所以需要提前預防。

瞭解你的服務

像哲學家剖析自己一樣去了解你的服務。一般包含以下內容

繪製應用系統架構圖

需要包含以下模組,

  • 服務給誰用
    出了問題應該通知到誰
  • 包含哪些模組
    應用了哪些功能模組。使用者報問題過來的時候知道大體屬於哪個服務出了問題
  • 系統流程
    模組間如何流轉的
  • 依賴的中介軟體
    依賴了哪些中介軟體,對應負責人是誰
  • 依賴的儲存、訊息佇列
    依賴了哪些儲存,儲存運維負責人是誰
  • 依賴的服務
    依賴了哪些服務,什麼功能依賴了什麼服務,出了問題,找誰。是否是弱依賴,可降級的。

繪製應用系統部署圖

系統是如何部署的,部署在什麼環境。如何登陸、擴容、升配。

梳理系統故障等級

哪些模組是核心的,哪些模組是沒那麼重要的,可以降級的。

壓測演練

當前系統能夠支援的單機QPS是多少,可能存在的效能瓶頸是什麼,需要通過壓測來得出來。

當前應用的API讀寫比是多少,對應到各個儲存層面的比例是多少。當應用QPS上升,哪個依賴最先掛掉。redis/mysql 還是依賴的服務,還是應用本身。

定期盤點

無論是使用者反饋故障,還是監控警報,基本都晚了,因為這時候已經累積了一定錯誤量的呼叫了。所以需要再搶先一步,定期盤點應用。衡量的指標一般圍繞使用率、飽和度、吞吐量以及響應時間
盤點的內容包括所有的依賴。

  • 應用層面
    磁碟cpu,記憶體,load數,jvm gc情況

  • 系統層面
    qps

  • 依賴的儲存
    磁碟,cpu, IOPS, qps。

  • 訊息佇列
    消費速度是否正常

另外系統日誌是第一手的故障資訊來源,應用owner需要定期對錯誤日誌進行查詢,能夠有效的將潛在問題扼殺在搖籃裡。

監控警報

監控警報有助於提早發現故障,所以確保監控項完備,警報能夠有效報出來。
以下是常用的一些監控項

型別 監控項
主機狀態 磁碟使用率>85
主機狀態 5分鐘load > 核數*1.5
主機狀態 5分鐘記憶體使用率 > 80
主機狀態 5分鐘CPU > 50
API 5分鐘API錯誤率>0.1
SQL 慢查詢 耗時>100ms
日誌 1分鐘錯誤數>10
日誌 5分鐘錯誤數>50

相關文章