運維不容錯過的4個關鍵指標！

很難說，生活在這個數據大爆炸的時代對運維同窗是福仍是禍。靈活的監控系統、開放 API 和易用的數據可視化資源能夠將任何想要的數據圖表化地顯示出來，可是，過多的數據容易產生干擾，反而不利於具體信息提取和操做。

關於監控哪些指標，以及爲何要從系統化的角度出發，咱們進行過深刻的思考。本文中，咱們想與你們分享一些具體的指標和準則，進一步幫助團隊衡量並提升運維性能。如下整理了4個關鍵性運維指標：

##告警事件數量

若是團隊中的事件數量呈現上升趨勢，那麼頗有多是哪裏出了問題：要麼是基礎設施有故障，要麼是監控工具配置錯誤須要調整。

隨着公司的發展，組織結構會調整，同時業務產品也會不斷升級，配套監控也會同步上線，告警事件數量會急劇增長。「咱們浪費了大量時間來關閉冗餘報警。」－－相信不少同窗都會有相似的體會。告警事件數量是可控的：

• 告警數量可統計，如這周告警數量是多少，與新發布的產品系統有沒有關係，發生哪些問題？
• 告警數量是可操做的，意味着每個告警都是有意義而且是須要處理和操做的，若是僅僅是瞅一眼的數據，請不要經過告警方式。例如100＋機器時，每臺機器的「CPU 使用率高」告警是沒有啥用的，你知道機器 CPU 使用率高後，你能作什麼操做呢？你可能直接忽略掉，當數量大到你把須要處理的告警也忽略掉時，告警就失去了意義。相似指標徹底能夠經過週報／日報進行數據的性能分析，而不是告警。

##平均解決事件（ MTTR ）

解決時間是衡量業務準備的最佳標準。當事件發生時，你的團隊須要多長時間才能解決？ 宕機不只會影響你的收入，還會傷害客戶用戶體驗和忠誠度，因此確保團隊對全部事件能夠快速響應極爲關鍵。

• 全球500強企業平均每週出現嚴重故障時間長達1.6小時。
• 平均每小時摺合損失$96,000。

固然，跟蹤解決時間當然重要，但對其進行規範每每很難，企業能夠根據環境的複雜性、團隊和基礎設施的責任制、行業及其餘因素，進一步觀測 MTTR 的差別。可是，規範化的操做手冊、自動化的基礎設施管理、可靠的告警升級策略都有助於減小事件，和提高 MTTR。

優秀的團隊減小事件數量，並及時解決（ MTTR ），因此平均解決事件須要和上面告警數量同樣，須要記錄和統計分析，目前大多監控工具每每不具有相似能力，若是沒有精力或者資源自行開發的話，咱們就建議使用第三方平臺OneAlert 。

有關如何減小事件數量，避免告警疲勞的事情，後續將會有獨立文章進行發佈。

##平均響應時間（ MTTA ）

若是說平均解決時間是結果，那麼平均響應時間就是重要的過程指標，這一點每每被大多團隊忽略掉。能夠理解爲告警越快發現，越快有人響應，就可以越快的解決（更好的MTTR）。

提高 MTTA 的核心是找對人、找到人。上圖中若是02:01可以及時通知到位就能夠節省至少4個小時時間。

提及來簡單，實際上找對人有些工做（只1人運維的請忽略），通常是從職責責任制、協調機制、工做進程透明、工做量和時間可衡量等幾點進行，後面針對「有序分派」再補充一篇。

除了以上機制，還有一點，就是須要記錄誰何時確認響應告警，並作了哪些處理，可以持續跟蹤，以及統計分析。

響應時間很是重要，由於它能幫助你瞭解哪些團隊和我的處於隨叫隨到的狀態。快速響應時間是一個戰備文化的表明，你會發現具有快響應觀念和工具的團隊每每能夠更快地修復事件。

若是使用像 OneAlert 的事件管理系統，[升級超時]有助於推動響應目標。例如，若是你但願全部事件都應該在5分鐘內回覆，能夠將超時設置爲5分鐘，從而確保下一個接收人會收到提醒。再根據團隊的總體表現，來決定是否須要調整目標，而後再跟蹤升級事件的數量。

##升級

對於大多數使用事件管理工具的組織而言，告警升級是一種異常現象，該跡象代表首次應該響應的時候，沒法及時應對事件，或許相關工具和人員技能失效。升級策略是事件管理的必須，各個團隊應努力推進升級，實現升級事件數量的降低。

優秀的運維團隊須要創建起有效的一線、二線、甚至三線響應機制，告警及時通知到一線，若是一線沒有及時處理，能夠自動升級至二線運維，保障每個重要事件可以獲得及時響應和處理。

有些狀況下，升級是標準做業實踐的一部分。例如，你可能有一個 NOC，一線支持團隊或者自動修復工具，可根據內容來升級或分診輸入事件。這種狀況下，一線更多像一個路由轉發器，能夠經過人工＋工具自動化方式實現。

##示例分析

這是某個團隊一個月的告警數據剖析：

• 告警數量在11-18前相對穩健，平均在3-5個告警。第3周告警日新月異，緣由是新的業務上線，引起突增。通過週迴顧，優化監控策略，在第4周通過初步優化，告警數量有所下降，運維團隊工做初見成效，還須要繼續優化。

• 告警響應時間 MTTA ，基本上都可以比較好的響應，基本在5分鐘內響應。說明整個團隊的響應及時率是不錯的。同時也看到在第三、4週六的時候，明顯的響應時間延遲較大，說明一個問題，週末的支撐工做有提高空間。

• 恢復時間 MTTR ，基本保持在20分鐘左右，說明恢復比較及時，可是也有可能存在事件無需關注，自動恢復。後者須要針對事件的類型、根源進一步分析，後續文章再剖析。

• 升級，目前該團隊基本上是5分鐘升級，因此會看到在大部分問題能在5分鐘內響應完成。

##小結

致力減小告警數量、及時響應 MTTA 、若是不能及時響應，可以升級處理，最終提高解決時間 MTTR，4個核心關鍵指標是運維支撐工做很是關鍵的指標。

運維是結合管理流程、工具、人員三方面的綜合化工做，OneAlert 指望構建一個告警平臺，可以幫助運維同窗更有效率的完成支撐工做。

OneAlert 是北京藍海訊通科技股份有限公司旗下產品，中國首個 SaaS 模式的雲告警平臺，集成國內外主流監控/支撐系統，實現一個平臺上集中處理全部IT事件，提高IT可靠性。想了解更多信息，請訪問 OneAlert 官網 。