故障review的一些總結

故障review的一些總結

故障review的目的

• 概括出現故障產生的緣由
  • 檢查故障的產生是否具備廣泛性，並儘量的保證同類問題不在出現，
    
• 回顧故障的處理流程，並檢查處理過程當中所存在的問題。並肯定此類問題的處理方法論。使得即使之後出現了同類的問題，也有明確的方法論來指導
• 標明後續改進措施及落實時間點
• 經驗總結和分享

故障的級別定義

不一樣公司對於故障的級別有不一樣的定義，通常會有P1，P2，P3這幾類故障，故障的嚴重級別依次下降。一個可能的定義以下：

• P1 公司主站提供的服務出現異常，廣告展現出現問題等。好比對大量用戶（3%）的正常使用產生影響，好比%3的下單失敗
• P2 公司主站提供發服務緩慢，內部IT系統出現重大故障燈
• P3 公司內部系統出現故障，對外服務一切正常。

參與故障review的人員

不一樣的故障級別須要不一樣層級的人員參與review, 雖然不必定那麼死板，可是必定要秉承着越嚴重的故障，越須要更高級別的人在場，並非讓他們來批評，而是讓他們以示重視，並起到監督、督促改進的做用。

• P1 故障處理人員，系統負責人，相應的
  QA（DBA可選）受影響的團隊的相關主要人員, 總監, VP
• P2 故障處理人員，系統負責人，相應的
  QA（DBA可選）受影響的團隊的相關主要人員, 總監
• P3 故障處理人員，系統負責人，相應的
  QA（DBA可選）受影響的團隊的相關主要人員

故障的升級和跟新時間

故障的級別並非一成不變的。有可能故障剛剛發生的時候，觀察影響可能覺的是P2，可是隨着對故障的瞭解可能發現實際上是一個P1級別的故障。固然也可能相反。

故障的升級或者降級的意義，並不只僅是爲了記錄錯誤的嚴重性，或者說爲了KPI的考覈，它的最主要的左右在於影響故障處理人員一個能夠動員人員的範圍和得到的權限的大小 。好比一個P1故障出現了，故障處理人員能夠爲了處理故障，能夠當即申請重要服務器的root權限，服務器管理員必須無條件審批經過，可是可能P3狀況下服務器管理員就不會審批經過，而是讓適合有root權限的人來完成操做。

從故障的發現，到故障的review完成，一直須要持續的跟新故障的進度。越是嚴重的故障越要更頻繁的跟新故障的進度。這樣好方便相關人員瞭解故障的處理狀況。

故障review的時間點

考慮到人們老是懶惰的，所以爲了保證流程和規範可以有效的執行下去，並確保具備「分享價值」的故障能夠及時的被分享出去，公司從流程層面應該強制不一樣級別的故障必須在故障處理完成之後的多少個小時內review完成。
好比P1級別的故障必須在故障處理完成的12歌小時以內review完成。P3級別的故障必須在故障的36個小時以內review完成

故障review的準備工做

故障review的準備工做，主要是爲了使得故障參與者提早準備好在review過程當中所須要發表的內容。這樣會使得review過程高效一些，也能夠避免在review過程當中可能會遺漏的東西。

故障review的詳細步驟

故障review的詳細步驟好比包含：從故障開始產生，到故障被發現、而後故障的具體處理過程、到故障處理完成的詳細過程，須要包含日期、時間、事件、人員等其餘有效信息。

主要是爲了可以經過詳細的過程描述，方便找出咱們在發現故障和處理故障過程當中暴露出的問題，作爲後續改進計劃的依據。一個可能的例子以下：

yyyy-M-dd hh:mm 故障因xx開始
 yyyy-M-dd hh:mm xx 發現故障 （或收到報警）
 yyyy-M-dd HH:mm xx 確認問題真實存在，通知xx上線處理，並通報故障
 yyyy-M-dd HH:mm xx 查看監控及日誌，確認影響範圍及故障發生時間點
 yyyy-M-dd HH:mm xx 確認問題緣由，通知xx開始回滾（或修bug）
             ........   ....
 yyyy-M-dd HH:mm xx 確認線上功能已經恢復
 yyyy-M-dd HH:mm xx 開始修復數據
 yyyy-M-dd HH:mm xx 確認故障已經結束

 故障的影響：xxx系統xxx服務受影響，大約影響3%的對外服務
 故障持續xxx時xxx分

故障review的結論

故障review的結論，主要是明確故障下面的問題：

• 故障產生的緣由
  • 代碼bug？設計缺陷？需求缺陷？歷史髒數據未考慮到？系統有後門被人錯用？
  • 爲何上線前Dev 自測沒發現？
  • 是沒有設計review麼？沒有code review 麼？
  • 是case 沒有執行麼？
  • 爲何上線前PM/QA測試未能發現？
  • 是沒有測試環境麼？
  • 是流程/規範未執行？
  • 是沒有進行codediff？
  • 依賴第三方不受控？
  • 是誤操做？
• 是否存在沒有及時發現故障的問題，以及緣由是什麼
  • 線上操做後沒有檢查 功能、監控、日誌 的問題麼？
  • 監控不完整麼？項目過程當中咱們沒有寫業務監控麼？不瞭解如何加監控麼？
  • 報警閾值設置不合理麼？
  • 人員未響應報警麼？線上日誌你們天天沒有人看麼？
  • 業務量過小沒關注的問題？
• 是否存在故障處理緩慢的問題，以及緣由是什麼
  • 沒帶電腦回家？在外面麼？
  • 沒有看監控定位故障時間？
  • 定位問題過程合理麼？場景難復現？
  • 改代碼比較耗時間麼？沒有測試環境驗證麼？

相應的改進計劃

故障的review完成必需要產出改進計劃，同時要確保改進計劃細化，有截止日誌，而且有監督人員。

- 改進計劃是什麼？
- 改進開始時間，改進截止日期？
- 監督人是誰？