資訊專欄INFORMATION COLUMN
摘要：平均解決事件解決時間是衡量業務準備的最佳標準。平均每小時折合損失。說明整個團隊的響應及時率是不錯的。小結致力減少告警數量及時響應如果不能及時響應，能夠升級處理，最終提升解決時間，個核心關鍵指標是運維支撐工作非常關鍵的指標。
很難說，生活在這個數據大爆炸的時代對運維同學是福還是禍。靈活的監控系統、開放 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分鐘內響應。說明整個團隊的響應及時率是不錯的。同時也看到在第3、4周六的時候，明顯的響應時間延遲較大，說明一個問題，周末的支撐工作有提升空間。
恢復時間 MTTR ，基本保持在20分鐘左右，說明恢復比較及時，但是也有可能存在事件無需關注，自動恢復。后者需要針對事件的類型、根源進一步分析，后續文章再剖析。
升級，目前該團隊基本上是5分鐘升級，所以會看到在大部分問題能在5分鐘內響應完成。
小結致力減少告警數量、及時響應 MTTA 、如果不能及時響應，能夠升級處理，最終提升解決時間 MTTR，4個核心關鍵指標是運維支撐工作非常關鍵的指標。
運維是結合管理流程、工具、人員三方面的綜合化工作，OneAlert 期望構建一個告警平臺，能夠幫助運維同學更有效率的完成支撐工作。
OneAlert 是北京藍海訊通科技股份有限公司旗下產品，中國首個 SaaS 模式的云告警平臺，集成國內外主流監控/支撐系統，實現一個平臺上集中處理所有IT事件，提升IT可靠性。想了解更多信息，請訪問 OneAlert 官網 。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/7946.html
摘要：為了掌握你的告警事件響應時間，在你已經開始處理告警時，強烈建議及時響應認領，例如通過移動端微信頁面移動等方式及時認領。這一點國外做的很棒，在短信電話移動都可以很容易確認認領在微信端可以認領和關閉。 這是《運維不容錯過的4個關鍵指標》的姐妹篇，上篇文章介紹了優秀運維團隊需要關注的4個關鍵指標，我們分享了平均恢復時間 MTTR、平均響應時間 MTTA 等概念。這篇是介紹一些實踐方法，更好的...
摘要：總故障時間是關于告警事件數量與各告警事件時長的函數。一個月的告警數據顯示平均響應時間為分鐘平均解決時間為分鐘。確定團隊領導人此人將在解決故障期間帶領團隊工作。找到并解決問題事件解決時間大部分花在確定告警問題的過程中。 前不久，我們討論了運維不容錯過的 4個關鍵指標，其中平均解決時間（MTTR）被認為是衡量業務的最佳標準，隨后也分析了「告警等級」對MTTR的重要性。 正確看待 MTTR ...
摘要：告警當一個問題通過告警系統將消息以短信電話郵件等方式告知給用戶時，我們稱之為一條告警。圖統一告警系統結構圖告警收斂對于告警平臺每天會產生數以萬計的告警，這些告警對于運維或開發人員都需要去分析甄別優先級并處理故障。 一、背景一套監控系統檢測和告警是密不可分的，檢測用來發現異常，告警用來將問題信息發送給相應的人。v...
摘要：阻塞，非阻塞首先，阻塞這個詞來自操作系統的線程進程的狀態模型網絡爬蟲基本原理一后端掘金網絡爬蟲是捜索引擎抓取系統的重要組成部分。每門主要編程語言現未來已到后端掘金使用和在相同環境各加載多張小圖片，性能相差一倍。 2016 年度小結（服務器端方向）| 掘金技術征文 - 后端 - 掘金今年年初我花了三個月的業余時間用 Laravel 開發了一個項目，在此之前，除了去年換工作準備面試時，我并...
摘要：阻塞，非阻塞首先，阻塞這個詞來自操作系統的線程進程的狀態模型網絡爬蟲基本原理一后端掘金網絡爬蟲是捜索引擎抓取系統的重要組成部分。每門主要編程語言現未來已到后端掘金使用和在相同環境各加載多張小圖片，性能相差一倍。 2016 年度小結（服務器端方向）| 掘金技術征文 - 后端 - 掘金今年年初我花了三個月的業余時間用 Laravel 開發了一個項目，在此之前，除了去年換工作準備面試時，我并...
閱讀 3104·2021-08-03 14:05
閱讀 2147·2019-08-29 15:35
閱讀 685·2019-08-29 13:30
閱讀 3173·2019-08-29 13:20
閱讀 2536·2019-08-23 18:15
閱讀 1803·2019-08-23 14:57
閱讀 2222·2019-08-23 13:57
閱讀 1317·2019-08-23 12:10
