如何讓運維指標變得更有價值？

這是《運維不容錯過的4個關鍵指標》的姐妹篇，上篇文章介紹了優秀運維團隊需要關注的4個關鍵指標，我們分享了平均恢復時間 MTTR、平均響應時間 MTTA 等概念。這篇是介紹一些實踐方法，更好的使用工具進行優化以上指標。

以 MTTA 為指導原則

MTTA 是衡量響應一個告警事件的關鍵性指標。為了掌握你的告警事件響應時間，在你已經開始處理告警時，強烈建議及時響應（認領），例如通過移動端、微信、頁面、移動 APP 等方式及時認領。特別是如果有多人運維、並且設定了升級處理的策略，該實踐會非常有用，你可以知道現在是誰在處理，處理進展怎樣，你就不用擔心告警沒通知到位或者是沒有處理了。

大多數優秀的運維團隊，往往會將 MTTA 作為最關鍵的指標之一，因為這是可控和可操作的。有故障時，我們很難控制最終的恢復時間，畢竟涉及問題較多；但是至少可以保證響應及時率。優秀的運維告警平臺很容易就能夠能夠跟蹤整個團隊的 MTTA ，包括現狀、歷史趨勢，團隊是否可以達到響應標準。

可能有同學會質疑，因為大家經常是第一時間就開始處理告警，往往忽略掉響應（認領），平時如果多個人協作同學坐一起，會吼一句「放著我來！」就能搞定，需要這麼複雜麼。

沒有資料記錄，就沒有優化基礎。比如如果人員不集中的話，或者是事情多了，就容易溝通不暢或遺漏，使用工具能夠避免該問題。

很多告警工具需要同學們在 PC 上登入到告警系統去認領一下（甚至撥 VPN 訪問內網），確實很麻煩。這一點國外 PagerDuty 做的很棒，在簡訊、電話、移動 APP 都可以很容易確認／認領； OneAlert 在微信端可以認領和關閉。移動化和快捷是實踐 MTTA 的重要保障。

解決問題需要記錄

我們強烈建議及時更新記錄告警的解決時間，當解決告警或者是告警自動恢復後，及時在告警系統上記錄／更新告警的狀態為關閉或者是恢復。例如使用 PagerDuty 、 VictorOps 、或者國內 OneAlert 時，可以人工記錄告警關閉。並且如果使用 API 或者其他工具整合方式，會自動化同步監控工具的告警狀態。

謹慎使用超時時間

不少監控工具都具備自動升級規則，一般會支援告警自動關閉，即如果長時間沒有關閉／恢復告警，告警系統會自動關閉掉，該引數會影響到最終的 MTTR 。

如果你沒有形成解決故障後，及時更新告警平臺上告警狀態的習慣，那麼超時自動關閉時間能夠避免該問題。PagerDuty 的服務和 OneAlert 的應用都支援超時自動關閉時間設定，一般是30分鐘－4小時。如果使用超時自動關閉，那麼可能會在資料統計週報中影響到最終 MTTR，統計資料會比實際更長，這一點不是很利於團隊執行效率優化，需要謹慎使用。

抖動告警（flapping alert）

抖動告警（flapping alert）是指告警觸發後，即刻恢復，之後又觸發並恢復，反覆多次。抖動告警的原因大多是監控指標在閾值範圍附近頻繁抖動。抖動告警會引發 MTTA 和 MTTR 資料異常，通常表現為大量的告警數量，但是很小的 MTTA 和 MTTR 值，甚至沒有 MTTA。因為告警還沒有來得及響應（認領）就已經被自動關閉了。

還有一點，非常重要的是抖動告警往往會引發告警疲勞，即大量無需處理的告警出現，會增加運維人員負擔，往往會忽略掉重要告警。所以非常有必要通過週報分析的方式識別出哪些抖動告警，大部分情況下可以通過優化閾值方式優化。如可參考 Nagios flapping 設定。

小結

上一篇《運維不容錯過的4個關鍵指標》和這篇文章，分享了國外PagerDuty、VictorOps和國內 OneAlert 的一些核心設計理念，希望對大家有些幫助。