「技術大牛」是如何縮短事件平均解決時間的？

前不久，咱們討論了運維不容錯過的 4個關鍵指標，其中平均解決時間（MTTR）被認爲是衡量業務的最佳標準，隨後也分析了「告警等級」對MTTR的重要性。

###正確看待 MTTR

MTTR 爲從故障發生到故障修復所經歷的時間。總故障時間是關於告警事件數量與各告警事件時長的函數。通過仔細地探討這兩項因素及其優先級，結合具體狀況，總結如下策略用來縮短MTTR：

####1）加快工做速度 = 然並卵

若是想經過加快工做速度下降 MTTR，理論上是完美的，可是骨感的現實根本不按咱們的劇本走！爲了對 MTTR 進行持續的、可衡量的改進，應該對故障事件進行深刻的調查，分析事件的複雜程度及重要程度，而後從人與系統的協做上，實現對流程進行優化。

####2）檢驗告警響應時間

一旦事件發生，「MTTR」時鐘便開始計時。經過調整通知流程，或許就能速戰速決。下圖爲常見故障處理過程：

還不夠直觀？數據來講話。 OneAlert 一個月的告警數據顯示：平均響應時間爲 2.8 分鐘；平均解決時間爲 27 分鐘。（不要問我爲何大家的響應時間要好幾個小時！）

若是你的響應時間較長，建議檢查一下團隊值班響應機制，告警是否可有效傳達給了正確的人？若是一線排版人員無響應，告警可否自動升級？升級時間閾值是多少？經過設定接近平均響應時間的適當指望值和目標，能確保全部成員儘快對告警做出響應。

####3）創建故障解決流程

告警響應時間過長，說明告警響應機制存在問題，故需創建有效的故障解決流程，即需確保如下內容：

• 創建有效溝通協議——明確每一個人的任務分工，確立有效溝通方式。以 OneAlert 爲例，團隊的溝通方式主要有 QQ 羣聊、WeChat 聊天室、釘釘等。

• 肯定團隊領導人——此人將在解決故障期間帶領團隊工做。須要作好記錄併合理安排工做。

• 作好記錄——應當詳細記錄故障期間發生的一切。這些記錄在你過後回顧之時將會很是有用。OneAlert 團隊領導人還會按期總結告警事件。

• 熟能生巧——確保團隊中每個人都不是告警響應的新手。

####4）找到並解決問題 事件解決時間大部分花在肯定告警問題的過程當中。因此，如何更快的明確問題的關鍵，是目前各大監控工具搶佔市場的核心武器。可是將來能夠確定的是，找到問題還不夠，自動化處理纔是發展的出路。這部份內容將在後期的文章中深刻探討。

OneAlert 是應用性能管理領軍企業 OneAPM 公司旗下產品，也是國內首個 SaaS 模式的雲告警平臺，集成國內外主流監控/支撐系統，實現一個平臺上集中處理全部 IT 事件，提高 IT 可靠性。想了解更多信息，請訪問 OneAlert 官網 。

本文轉自 OneAPM 官方博客