如何應對線上故障

線上故障是我們技術同學經常遇到，也是技術成長中經常要經歷的事。從故障中我們可以吸取到很多教訓，變得越來越有經驗。

但是並不是每一個團隊/技術同學在應對故障的處理方式上，都能做到合理和科學。

下面就從工作中遇到的實際情況，結合最近讀陳皓文章心得，來聊一聊我對線上故障處理的看法。

故障發生時的處理：

1、快速定位故障

在複雜的系統架構中，尤其是微服務架構中，一旦發生故障可能會出現「多米諾骨牌效應」，系統會由一個故障點波及到其他關聯的模塊。

因此我們要有一套快速的故障定位方法。我比較推薦的就是 全鏈條投入排查。即一旦發現線上故障，當前系統以及相關係統所對應的開發、運維、測試等方向，各抽調對口人，全都叫到線上去處理問題，各自排查各自模塊/服務，如果排查自己負責的範圍沒有問題就可以在旁邊待命，以備在需要的時候進行配合。重點就是從一開始就一起介入。

不要小看這一點，看似平淡無奇，但實際場景下，要能保證有序的這麼去做到，還是挺難的，亞馬遜都是通過一套制度和任務分配系統來保障這種全鏈路排查方案得以持久實施的。

其實這麼做的目的就是在跟故障搶時間。

我們平時大多數情況下是怎麼做的呢，收到一個線上功能的錯誤報告，然後對應功能的前端同學開始排查，排查了半天，發現是後端介面不正常，將問題轉到後端同學繼續排查，後端同學經過一段時間排查後，發現是運維問題或者是依賴的其他模塊的問題，就再次將問題轉到運維或者其他項目組，然後後者接手開始排查。這樣來來去去，等定位到真正故障源的時候，黃花菜都涼了，不僅導致服務長時間的不可用，而且故障隨著時間的推移也在不斷擴大波及面，問題也越來越難以定位。

2、故障止損和恢復

在故障源定位之後，一般恢復系統的常用手段無非下面幾種：

• 重啟：部分問題是可以通過重啟的手段來臨時恢復的，以保障系統的暫時可用，但後續還需有其他方法徹底解決問題
• 限流和降級：這其實還是一個臨時手段，通過將部分非核心系統進行降級和限制流量處理，來避免核心業務受到影響
• 回滾：如果屬於更新的代碼BUG導致的問題，一般可通過回滾上一個程序版本來迅速恢復，不過會導致部分新功能不可用
• 緊急更新：這個方式會經常被用到，明確定位問題源後，迅速修復代碼或組件，然後快速更新上線，比較依賴整個團隊的上線協同能力

故障發生前的準備

• 設定故障等級：這是一個所有項目共同認定的等級劃分，一般無須為單獨項目設定
• 服務-資源圖：需要針對項目有完整的服務與資源對應圖，以便能速查
• 項目指標和應急方案：給系統設定風險閾值，超出閾值有應急方案提前準備著
• 故障演練：針對特定的重大的風險點，進行演練，以驗證上述的應急方案可用性
• 灰度發布：也就是對要發布的新版本進行A/B測試，是一種非常有效的產品驗證和功能改進的方法

故障發生後的復盤

說到故障後復盤，離不開的一個話題就是程序員的追責和懲罰。這其實是另一個要討論的主題了，不過這裡，我簡單的描述一下我的觀點：對於線上事故，理應追究責任，但無需懲罰（特別嚴重的問題或特別不能容忍的錯誤以外），最重要的其實是做好善後工作，避免下次再犯，從根本上反思，刨根問底，找出問題的根源。這其實也就是下面要聊到的 「Ask Some Whys」。

重點來聊聊復盤要做的事情吧

• 記錄故障處理全過程：
  需要詳細的記錄下故障發現的時間，什麼途徑發現的，用了什麼樣的排查手段，什麼樣子的處理流程，處理過程中，幾點幾分做了什麼事情，將整個過程都一一的記錄下來。
• 分析故障原因：
  需要將團隊成員聚在一起，進行討論，分析故障發生的原因，這裡的原因不是指表象的原因，需要剖析出問題的根源。
• 故障整改計劃：
  針對當前故障要做哪些改進措施，應對類似問題，如何預防。給出可實施的方案以及時間計劃。同時對故障等級進行認定，以及團隊成員責任的追究和備案（但不提倡懲罰）。

另外就是 Ask Some Whys：

多問幾個為什麼，這也是需要團隊成員在一起問自己和問對方的。比如：為什麼沒有進行灰度發布（如果灰度發布能避免問題的話），為什麼測試沒有覆蓋到，為什麼故障處理耗時這麼久，等等，根據當前故障進行層層反問和深挖。