故障處理流程和規範

背景

大數據團隊負責不少公司核心服務，包括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時間作好應對措施。若是不能及時解決，不要等待或死磕問題，請迅速聯繫本身的老闆尋求支持和幫助(也能夠請求能幫助本身的同事加入)。

故障恢復

故障確認後，首要作的就是故障止損和恢復，恢復經常使用手段以下：

1. 服務回滾：若是屬於更新的代碼BUG致使的問題，通常可經過回滾上一個程序版原本迅速恢復，不過會致使部分新功能不可用
2. 重啓：部分問題是能夠經過重啓的手段來臨時恢復的，以保障系統的暫時可用，但後續還需有其餘方法完全解決問題
3. 限流和降級：這實際上是一個臨時手段，經過將部分非核心繫統進行降級和限制流量處理，來避免核心業務受到影響
4. 緊急更新：這個方式會常常被用到，明肯定位問題源後，迅速修復代碼或組件，而後快速更新上線，比較依賴故障處理人技術和代碼邏輯、應急處理能力

寫故障casestudy

寫casestudy原則：並非全部故障都須要寫casestudy，原則一若是咱們服務能快速恢復且對用戶部門影響很小，就不用寫。原則二由各個服務SLA肯定是否編寫casestudy

caseStudy-YYYYMMDD-xxx操做引發xxx服務不可用

故障發生時間： 故障報告時間： 故障恢復時間： 故障持續時間： 故障影響範圍： 故障等級：PN PN故障處理人：xxx、xxx、xxx 故障責任人：xxx 故障描述：xxx 故障處理過程：xxx 故障緣由分析：xxx 故障總結：xxx 後續改進工做：xxx  改進任務列表(任務、執行人、Deadline)

組織故障review

邀請參與人員：用戶表明、集羣服務負責人、部門負責人、部門相關同事

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

注意：review&覆盤後，發送郵件給用戶部門，P0故障同時抄送CTO

改進措施列表

根據當前存在的問題制定出一套流程不難，難在對流程執行的跟蹤和監督。所以每一個故障Action都是可執行的，且有明確的執行人和Deadline，跟進故障casestudy中改進工做列表進展狀況，及時closed任務。隨着故障管理標準化創建和規範化，通過一段時間的積累，會沉澱一些寶貴的故障數據，爲系統改進方向提供了參考，也加強了夥伴們的故障意識，避免小夥伴不會犯同類型故障，對線上環境的敬畏之心和對故障的緊急處理意識。

完善服務運維文檔

以上工做作完後，就要對運維文檔查漏補缺進行完善了。大數據團隊每一個系統或方向的小組人數多寡有差別，多的有4人，少的可能只有1人負責。人都有打盹或休息/休假的時候，本身不能處理或外出，其餘人能夠根據運維文檔，根據故障經常使用恢復原則進行緊急處理。

• 管理平臺使用文檔，能進行服務啓動/中止/重啓操做
• 服務程序部署、回滾版本操做流程等
• 服務程序部署目錄、日誌目錄
• 常見故障列表及恢復手冊

引用博客來自李志濤：https://www.cnblogs.com/lizherui/p/11704523.html