線上故障處理

於 2016 年 12 月 09 日

處理流程

故障後處理

前段時間在團隊內整理了乙份線上事故處理的流程，修改後在這裡分享。

1.1 系統&業務報警

這個是獲取故障最常用的手段。

一般的系統正常運營過程中都會有一定的指標監控。如：在系統層面某種報錯出現的次數，系統常規指標，如可用記憶體，jvm gc，連線池等資訊；業務指標，如業務的曲線異於基準線。

如配置一些基本的業務曲線：

當業務曲線發生異常抖動的時候，就可以主動報警，可以實時的開發

這種報錯出現之後比使用者反饋的要好排查，因為這種bug影響範圍較大，可重現的。

1.2 使用者反饋

這裡的使用者主要是公司的客服人員，一般客服人員會手機普通使用者的問題，並做分類統計，如果發現某種現象比較集中，就很可能是系統出現故障。

一般當系統&業務監控不夠全面的時候會部分依賴使用者反饋來發現系統問題。

2.1 判斷影響範圍

收到故障報告之後需要迅速判斷故障的影響範圍，系統/業務報警類的故障影響範圍都會比較大，很多時候都會是事故；使用者反饋的bug，因為情況複雜，比如裝置問題、網路問題、使用者操作邏輯等，而且因為使用者並非專業人員所以使用者的現場資料難以收集全面，所以針對這類bug的影響範圍就難以判斷。

針對第二種bug的影響範圍判斷，需要根據已有的使用者描述現象以及相關後台資料，判斷使用者是在什麼情況下出現這種bug；特別需要檢查後台資料是否大量類似資料，以輔助判斷bug是否為大範圍影響，是否已經達到事故的影響範圍。

2.2 回滾，重啟，擴容

這個是線上處理最常用也是最管用的三種方法。

根據我的工作經驗，線上近80%的故障是因為新上線導致的，所以遇到線上問題的時候，如果短期內有專案上線，如果該故障影響範圍較大，需要優先考慮將專案回滾或者將新功能的入口關閉以降低風險。

還有一些故障是系統執行到一段時間後系統自身的連線池，記憶體等耗盡，為了盡快解決問題需要馬上重啟；不過為了後續繼續分析問題，一般會留一台線上機器屍體做後續分析。

還有一些問題是線上流量突然增大，如運營活動上線，這時候需要聯合運維一起判斷，該如何擴容來解決問題。一般的擴容方式是增加線上機器，增大資料庫連線池，增加資料庫讀庫等方式。

2.4 降級/臨時方案

事故出現之後，首先要考慮的就是消除線上現象，這時候需要一些降級方案或者臨時方案，可以讓系統繼續執行，不影響後續使用者的正常使用。

降級/臨時方案一般是通過削減非必要功能來保證核心功能的正常執行，比如h5頁面替代native之後，通過降低體驗可以讓使用者繼續使用功能。

經過以上處理之後，線上故障基本消除了，但有些故障需要深入分析之後才能**；還有些故障修復之後，但會有些髒資料已經寫入，需要針對這些髒資料針對性的修復。有些在雖然消除了線上出錯，但還需要繼續對**進行調整以消除bug。

一般事故後處理主要包括以下內容：

#系統事故處理