資訊專欄INFORMATION COLUMN
摘要：平均解決事件解決時間是衡量業(yè)務(wù)準(zhǔn)備的最佳標(biāo)準(zhǔn)。平均每小時折合損失。說明整個團隊的響應(yīng)及時率是不錯的。小結(jié)致力減少告警數(shù)量及時響應(yīng)如果不能及時響應(yīng)，能夠升級處理，最終提升解決時間，個核心關(guān)鍵指標(biāo)是運維支撐工作非常關(guān)鍵的指標(biāo)。
很難說，生活在這個數(shù)據(jù)大爆炸的時代對運維同學(xué)是福還是禍。靈活的監(jiān)控系統(tǒng)、開放 API 和易用的數(shù)據(jù)可視化資源可以將任何想要的數(shù)據(jù)圖表化地顯示出來，但是，過多的數(shù)據(jù)容易產(chǎn)生干擾，反而不利于具體信息提取和操作。
關(guān)于監(jiān)控哪些指標(biāo)，以及為什么要從系統(tǒng)化的角度出發(fā)，我們進行過深入的思考。本文中，我們想與大家分享一些具體的指標(biāo)和準(zhǔn)則，進一步幫助團隊衡量并提高運維性能。以下整理了4個關(guān)鍵性運維指標(biāo)：
告警事件數(shù)量如果團隊中的事件數(shù)量呈現(xiàn)上升趨勢，那么很有可能是哪里出了問題：要么是基礎(chǔ)設(shè)施有故障，要么是監(jiān)控工具配置錯誤需要調(diào)整。
隨著公司的發(fā)展，組織結(jié)構(gòu)會調(diào)整，同時業(yè)務(wù)產(chǎn)品也會不斷升級，配套監(jiān)控也會同步上線，告警事件數(shù)量會急劇增加。「我們浪費了大量時間來關(guān)閉冗余報警。」－－相信很多同學(xué)都會有類似的體會。告警事件數(shù)量是可控的：
告警數(shù)量可統(tǒng)計，如這周告警數(shù)量是多少，與新發(fā)布的產(chǎn)品系統(tǒng)有沒有關(guān)系，發(fā)生哪些問題？
告警數(shù)量是可操作的，意味著每一個告警都是有意義并且是需要處理和操作的，如果僅僅是瞅一眼的數(shù)據(jù)，請不要通過告警方式。例如100＋機器時，每臺機器的「CPU 使用率高」告警是沒有啥用的，你知道機器 CPU 使用率高后，你能做什么操作呢？你可能直接忽略掉，當(dāng)數(shù)量大到你把需要處理的告警也忽略掉時，告警就失去了意義。類似指標(biāo)完全可以通過周報／日報進行數(shù)據(jù)的性能分析，而不是告警。
平均解決事件（ MTTR ）解決時間是衡量業(yè)務(wù)準(zhǔn)備的最佳標(biāo)準(zhǔn)。當(dāng)事件發(fā)生時，你的團隊需要多長時間才能解決？
宕機不僅會影響你的收入，還會傷害客戶用戶體驗和忠誠度，所以確保團隊對所有事件可以快速響應(yīng)極為關(guān)鍵。
全球500強企業(yè)平均每周出現(xiàn)嚴(yán)重故障時間長達(dá)1.6小時。
平均每小時折合損失$96,000。
當(dāng)然，跟蹤解決時間固然重要，但對其進行規(guī)范往往很難，企業(yè)可以根據(jù)環(huán)境的復(fù)雜性、團隊和基礎(chǔ)設(shè)施的責(zé)任制、行業(yè)及其他因素，進一步觀測 MTTR 的差異。但是，規(guī)范化的操作手冊、自動化的基礎(chǔ)設(shè)施管理、可靠的告警升級策略都有助于減少事件，和提升 MTTR。
優(yōu)秀的團隊減少事件數(shù)量，并及時解決（ MTTR ），所以平均解決事件需要和上面告警數(shù)量一樣，需要記錄和統(tǒng)計分析，目前大多監(jiān)控工具往往不具備類似能力，如果沒有精力或者資源自行開發(fā)的話，我們就建議使用第三方平臺OneAlert 。
有關(guān)如何減少事件數(shù)量，避免告警疲勞的事情，后續(xù)將會有獨立文章進行發(fā)布。
平均響應(yīng)時間（ MTTA ）如果說平均解決時間是結(jié)果，那么平均響應(yīng)時間就是重要的過程指標(biāo)，這一點往往被大多團隊忽略掉。可以理解為告警越快發(fā)現(xiàn)，越快有人響應(yīng)，就能夠越快的解決（更好的MTTR）。
提升 MTTA 的核心是找對人、找到人。上圖中如果02:01能夠及時通知到位就可以節(jié)省至少4個小時時間。
說起來簡單，實際上找對人有些工作（只1人運維的請忽略），一般是從職責(zé)責(zé)任制、協(xié)調(diào)機制、工作進程透明、工作量和時間可衡量等幾點進行，后面針對「有序分派」再補充一篇。
除了以上機制，還有一點，就是需要記錄誰什么時候確認(rèn)響應(yīng)告警，并做了哪些處理，能夠持續(xù)跟蹤，以及統(tǒng)計分析。
響應(yīng)時間非常重要，因為它能幫助你了解哪些團隊和個人處于隨叫隨到的狀態(tài)?？焖夙憫?yīng)時間是一個戰(zhàn)備文化的代表，你會發(fā)現(xiàn)具備快響應(yīng)觀念和工具的團隊往往可以更快地修復(fù)事件。
如果使用像 OneAlert 的事件管理系統(tǒng)，[升級超時]有助于推進響應(yīng)目標(biāo)。例如，如果你希望所有事件都應(yīng)該在5分鐘內(nèi)回復(fù)，可以將超時設(shè)置為5分鐘，從而確保下一個接收人會收到提醒。再根據(jù)團隊的整體表現(xiàn)，來決定是否需要調(diào)整目標(biāo)，然后再跟蹤升級事件的數(shù)量。
升級對于大多數(shù)使用事件管理工具的組織而言，告警升級是一種異常現(xiàn)象，該跡象表明首次應(yīng)該響應(yīng)的時候，無法及時應(yīng)對事件，或許相關(guān)工具和人員技能失效。升級策略是事件管理的必須，各個團隊?wèi)?yīng)努力推動升級，實現(xiàn)升級事件數(shù)量的下降。
優(yōu)秀的運維團隊需要建立起有效的一線、二線、甚至三線響應(yīng)機制，告警及時通知到一線，如果一線沒有及時處理，可以自動升級至二線運維，保障每一個重要事件能夠得到及時響應(yīng)和處理。
有些情況下，升級是標(biāo)準(zhǔn)作業(yè)實踐的一部分。例如，你可能有一個 NOC，一線支持團隊或者自動修復(fù)工具，可根據(jù)內(nèi)容來升級或分診輸入事件。這種情況下，一線更多像一個路由轉(zhuǎn)發(fā)器，可以通過人工＋工具自動化方式實現(xiàn)。
示例分析
這是某個團隊一個月的告警數(shù)據(jù)剖析：
告警數(shù)量在11-18前相對穩(wěn)健，平均在3-5個告警。第3周告警突飛猛進，原因是新的業(yè)務(wù)上線，引發(fā)突增。經(jīng)過周回顧，優(yōu)化監(jiān)控策略，在第4周經(jīng)過初步優(yōu)化，告警數(shù)量有所降低，運維團隊工作初見成效，還需要繼續(xù)優(yōu)化。
告警響應(yīng)時間 MTTA ，基本上都能夠比較好的響應(yīng)，基本在5分鐘內(nèi)響應(yīng)。說明整個團隊的響應(yīng)及時率是不錯的。同時也看到在第3、4周六的時候，明顯的響應(yīng)時間延遲較大，說明一個問題，周末的支撐工作有提升空間。
恢復(fù)時間 MTTR ，基本保持在20分鐘左右，說明恢復(fù)比較及時，但是也有可能存在事件無需關(guān)注，自動恢復(fù)。后者需要針對事件的類型、根源進一步分析，后續(xù)文章再剖析。
升級，目前該團隊基本上是5分鐘升級，所以會看到在大部分問題能在5分鐘內(nèi)響應(yīng)完成。
小結(jié)致力減少告警數(shù)量、及時響應(yīng) MTTA 、如果不能及時響應(yīng)，能夠升級處理，最終提升解決時間 MTTR，4個核心關(guān)鍵指標(biāo)是運維支撐工作非常關(guān)鍵的指標(biāo)。
運維是結(jié)合管理流程、工具、人員三方面的綜合化工作，OneAlert 期望構(gòu)建一個告警平臺，能夠幫助運維同學(xué)更有效率的完成支撐工作。
OneAlert 是北京藍(lán)海訊通科技股份有限公司旗下產(chǎn)品，中國首個 SaaS 模式的云告警平臺，集成國內(nèi)外主流監(jiān)控/支撐系統(tǒng)，實現(xiàn)一個平臺上集中處理所有IT事件，提升IT可靠性。想了解更多信息，請訪問 OneAlert 官網(wǎng) 。
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://systransis.cn/yun/7946.html
摘要：為了掌握你的告警事件響應(yīng)時間，在你已經(jīng)開始處理告警時，強烈建議及時響應(yīng)認(rèn)領(lǐng)，例如通過移動端微信頁面移動等方式及時認(rèn)領(lǐng)。這一點國外做的很棒，在短信電話移動都可以很容易確認(rèn)認(rèn)領(lǐng)在微信端可以認(rèn)領(lǐng)和關(guān)閉。 這是《運維不容錯過的4個關(guān)鍵指標(biāo)》的姐妹篇，上篇文章介紹了優(yōu)秀運維團隊需要關(guān)注的4個關(guān)鍵指標(biāo)，我們分享了平均恢復(fù)時間 MTTR、平均響應(yīng)時間 MTTA 等概念。這篇是介紹一些實踐方法，更好的...
摘要：總故障時間是關(guān)于告警事件數(shù)量與各告警事件時長的函數(shù)。一個月的告警數(shù)據(jù)顯示平均響應(yīng)時間為分鐘平均解決時間為分鐘。確定團隊領(lǐng)導(dǎo)人此人將在解決故障期間帶領(lǐng)團隊工作。找到并解決問題事件解決時間大部分花在確定告警問題的過程中。 前不久，我們討論了運維不容錯過的 4個關(guān)鍵指標(biāo)，其中平均解決時間（MTTR）被認(rèn)為是衡量業(yè)務(wù)的最佳標(biāo)準(zhǔn)，隨后也分析了「告警等級」對MTTR的重要性。 正確看待 MTTR ...
摘要：告警當(dāng)一個問題通過告警系統(tǒng)將消息以短信電話郵件等方式告知給用戶時，我們稱之為一條告警。圖統(tǒng)一告警系統(tǒng)結(jié)構(gòu)圖告警收斂對于告警平臺每天會產(chǎn)生數(shù)以萬計的告警，這些告警對于運維或開發(fā)人員都需要去分析甄別優(yōu)先級并處理故障。 一、背景一套監(jiān)控系統(tǒng)檢測和告警是密不可分的，檢測用來發(fā)現(xiàn)異常，告警用來將問題信息發(fā)送給相應(yīng)的人。v...
摘要：阻塞，非阻塞首先，阻塞這個詞來自操作系統(tǒng)的線程進程的狀態(tài)模型網(wǎng)絡(luò)爬蟲基本原理一后端掘金網(wǎng)絡(luò)爬蟲是捜索引擎抓取系統(tǒng)的重要組成部分。每門主要編程語言現(xiàn)未來已到后端掘金使用和在相同環(huán)境各加載多張小圖片，性能相差一倍。 2016 年度小結(jié)（服務(wù)器端方向）| 掘金技術(shù)征文 - 后端 - 掘金今年年初我花了三個月的業(yè)余時間用 Laravel 開發(fā)了一個項目，在此之前，除了去年換工作準(zhǔn)備面試時，我并...
摘要：阻塞，非阻塞首先，阻塞這個詞來自操作系統(tǒng)的線程進程的狀態(tài)模型網(wǎng)絡(luò)爬蟲基本原理一后端掘金網(wǎng)絡(luò)爬蟲是捜索引擎抓取系統(tǒng)的重要組成部分。每門主要編程語言現(xiàn)未來已到后端掘金使用和在相同環(huán)境各加載多張小圖片，性能相差一倍。 2016 年度小結(jié)（服務(wù)器端方向）| 掘金技術(shù)征文 - 后端 - 掘金今年年初我花了三個月的業(yè)余時間用 Laravel 開發(fā)了一個項目，在此之前，除了去年換工作準(zhǔn)備面試時，我并...
閱讀 3105·2021-08-03 14:05
閱讀 2152·2019-08-29 15:35
閱讀 688·2019-08-29 13:30
閱讀 3176·2019-08-29 13:20
閱讀 2541·2019-08-23 18:15
閱讀 1806·2019-08-23 14:57
閱讀 2224·2019-08-23 13:57
閱讀 1320·2019-08-23 12:10
