背景
大數據團隊負責很多公司核心服務，包括olap查詢、隊列、日志搜索、數據傳輸、存儲、計算等等服務，作為公司數據傳輸和存儲及計算的中樞，服務的穩定性直接影響用戶口碑和體驗，間接影響着公司的營收，線上服務的穩定性是每位同學需要重點關注的事情。當然線上服務發生故障，做技術每位同學幾乎都會遇到，也是作為技術RD成長中經常要經歷的事。從故障中我們可以吸取到很多教訓，變得越來越有經驗，把我們的服務做得越來越穩定。但是並不是每一個團隊/技術同學在應對故障的處理方式上，都能做到合理和科學地迅速止損，把業務影響和損失降到最小。那我們該如何做呢？才能讓我們工作做得更好呢？下面流程圖和詳細步驟就是我們要具體做得工作。
故障反饋
- 用戶部門主動反饋，使用集群服務超時或接口調用報錯
- 服務負責部門自行發現，通過系統報警發現大數據服務出現異常
確認故障
不管是收到報警信息，還是業務用戶反饋大數據組提供的服務有問題，我們都需要進一步確認驗證集群是否正常提供服務，確認的同時通知用戶我們正在跟蹤處理，讓用戶放心。收到反饋通過以下指標項迅速判斷，發現大數據集群可能遇到的問題
系統監控指標：
- cpu usage
- cpu load
- memory
- I/O 網絡與磁盤
- network flow
- swap
- 客戶端連接總數量
- mmap數量和usage
- File Description數量和usage
- ......
集群監控指標：
- jvm指標(gc、threads)
- 服務日志(錯誤日志、拋出異常)
- 上下文邏輯問題
- ......
用戶服務指標：
- 收集調用異常或錯誤信息(接口請求響應時間、接口調用QPS、返回錯誤內容或code)
- 從錯誤信息確認邊界，是用戶使用問題，還是集群服務運行異常
集群可能出現問題，示例如下
中間件層面監控(數據庫、緩存、消息隊列、存儲):
- 對數據庫的負載、慢查詢、連接數等監控
- 對緩存的連接數、占用內存、吞吐量、響應時間等監控
- 消息隊列的生產/消費時間、吞吐量、負載、堆積情況等監控
- 對存儲的寫入時間、TPS、讀取QPS等監控
- ......
故障通知
確認故障后，迅速拉群，把上下游用戶及自己項目負責人、部門負責人都加入進來，簡要整理下內容，告知用戶當前情況及解決預案或方案，不要給用戶感覺突然或帶來驚訝，讓用戶有心理准備，留好buffer時間做好應對措施。如果不能及時解決，不要等待或死磕問題，請迅速聯系自己的老板尋求支持和幫助(也可以請求能幫助自己的同事加入)。
故障恢復
故障確認后，首要做的就是故障止損和恢復，恢復常用手段如下：
- 服務回滾：如果屬於更新的代碼BUG導致的問題，一般可通過回滾上一個程序版本來迅速恢復，不過會導致部分新功能不可用
- 重啟：部分問題是可以通過重啟的手段來臨時恢復的，以保障系統的暫時可用，但后續還需有其他方法徹底解決問題
- 限流和降級：這其實是一個臨時手段，通過將部分非核心系統進行降級和限制流量處理，來避免核心業務受到影響
- 緊急更新：這個方式會經常被用到，明確定位問題源后，迅速修復代碼或組件，然后快速更新上線，比較依賴故障處理人技術和代碼邏輯、應急處理能力
寫故障casestudy
寫casestudy原則：並不是所有故障都需要寫casestudy，原則一如果我們服務能快速恢復且對用戶部門影響很小，就不用寫。原則二由各個服務SLA確定是否編寫casestudy
故障發生時間：
故障報告時間：
故障恢復時間：
故障持續時間：
故障影響范圍：
故障等級：PN
PN故障處理人：xxx、xxx、xxx
故障責任人：xxx
故障描述：xxx
故障處理過程：xxx
故障原因分析：xxx
故障總結：xxx
后續改進工作：xxx 改進任務列表(任務、執行人、Deadline)
|
組織故障review
邀請參與人員：用戶代表、集群服務負責人、部門負責人、部門相關同事
- 回顧故障處理全過程： 需要詳細的記錄下故障發現的時間，什么途徑發現的，用了什么樣的排查手段，什么樣子的處理流程，處理過程中，幾點幾分做了什么事情，將整個過程都一一的記錄下來。
- 分析故障原因： 需要將團隊成員聚在一起，進行討論，分析故障發生的原因，這里的原因不是指表象的原因，需要剖析出問題的根源。
- 故障改進計划： 針對當前故障要做哪些改進措施，應對類似問題，如何預防。給出可實施的方案以及時間計划。同時對故障等級進行認定，以及團隊成員責任的追究和備案（但不提倡懲罰）。
注意：review&復盤后，發送郵件給用戶部門，P0故障同時抄送CTO
改進措施列表
根據當前存在的問題制定出一套流程不難，難在對流程執行的跟蹤和監督。因此每個故障Action都是可執行的，且有明確的執行人和Deadline，跟進故障casestudy中改進工作列表進展情況，及時closed任務。隨着故障管理標准化建立和規范化，經過一段時間的積累，會沉淀一些寶貴的故障數據，為系統改進方向提供了參考，也增強了伙伴們的故障意識，避免小伙伴不會犯同類型故障，對線上環境的敬畏之心和對故障的緊急處理意識。
完善服務運維文檔
以上工作做完后，就要對運維文檔查漏補缺進行完善了。大數據團隊每個系統或方向的小組人數多寡有差異，多的有4人，少的可能只有1人負責。人都有打盹或休息/休假的時候，自己不能處理或外出，其他人可以根據運維文檔，根據故障常用恢復原則進行緊急處理。
- 管理平台使用文檔，能進行服務啟動/停止/重啟操作
- 服務程序部署、回滾版本操作流程等
- 服務程序部署目錄、日志目錄
- 常見故障列表及恢復手冊