故障處理流程和規範

目前架構團隊負責公司很多核心服務，包括商品中心、訂單中心、優惠券中心、使用者中心、閘道器等等服務。作為主鏈路的關鍵核心，服務的穩定性和可靠性直接到影響到使用者口碑和體驗，同時也影響到公司的營收，所以線上服務的穩定性和可靠性是每位同學都需要重點關注的事情。

當線上服務發生故障，我們希望每乙個團隊或技術同學在應對故障的處理方式上，都能做到合理和迅速地止損，把業務影響和損失降到最小。那我們該如何做呢？怎樣才能讓我們工作做得更好呢？下面詳細步驟就是我們要具體做得工作。

1）c端使用者反饋

2）產品反饋

3）業務反饋

1）系統報警發現異常

2）服務日常巡檢發現異常

不管是收到報警資訊，還是收到業務使用者反饋，我們都需要進一步確認並驗證服務或功能是否正常，確認問題的同時通知反饋方我們正在跟蹤處理，讓反饋方放心。

可根據經驗來快速判斷，若不能快速判斷問題所在，則可結合日誌和監控來分析。

包含arms、ahas、資料庫、redis、mq、es等維度的監控分析。

具體指標見日常巡檢計畫中的巡檢指標說明。

每隔30分鐘同步一次。

注：故障恢復後務必通知反饋方，告知問題已解決。

確認故障後，首先要做的就是恢復故障，常用手段如下：

如果屬於發版更新的**bug導致的問題，一般可通過回滾到上乙個程式版本來迅速恢復。

部分問題可以通過重啟的手段來臨時恢復，以保障系統的暫時可用，但後續還需有其他方法徹底解決問題。（如pod日誌太多導致磁碟告警就可通過重啟來臨時處理）

在明確問題所在後，迅速修復**，然後快速更新上線。比較依賴故障處理人技術和**邏輯、應急處理能力。

緊急修復**的情況下，需找乙個人進行review**，避免急而導致新的問題。

通過將部分非核心服務或介面進行降級和限流處理，來避免核心業務受到影響。

首先要明確，並不是所有故障都需要寫故障報告。如果能快速恢復且影響很小，就不用寫。

需要詳細的記錄下故障發現的時間，什麼途徑發現的，用了什麼樣的排查手段，什麼樣子的處理流程，處理過程中，幾點幾分做了什麼事情，將整個過程都一一的記錄下來。

需要將團隊成員聚在一起，進行討論，分析故障發生的原因，這裡的原因不是指表象的原因，需要剖析出問題的根源。

針對當前故障要做哪些改進措施，應對類似問題，如何預防。給出可實施的方案以及時間計畫。同時對故障等級進行認定，以及團隊成員責任的追究和備案（但不提倡懲罰）。

注意：覆盤後，傳送郵件給相關部門和同事。

隨著故障處理流程標準化和規範化，希望經過一段時間的積累，沉澱一些寶貴的故障資料，為系統優化提供參考。同時也希望小夥伴們對生產環境保持敬畏之心，並加強故障的處理意識。