隨着IT基礎設施的雲化,應用運行環境的容器化,系統架構的微服務化,愈來愈多的企業不得不引入更多的工具、更復雜的流程和更多的運維人員,來提高IT系統管理的精細度,但新的問題也隨之而來。html
猶如蝴蝶效應,在如此龐雜的環境下,數據間緊密相連,一個指標的變化,可能引起一系列的告警連鎖反應。不一樣監控平臺的紅色標識、不斷涌入的告警郵件和短信,緊牽着運維人員的神經,告警的精細化管理勢在必行。算法
充滿挑戰的運維告警管理數據庫
如何抑制告警風暴?如何保障重要告警不漏不丟?如何快速的甄別根因告警?如何沉澱告警處置經驗?如何快速恢復業務運行? 這些都是每個運維團隊在工做中面臨的最棘手的問題。究竟是什麼緣由致使如此頻發的告警風暴,給告警管理帶來如此之高的複雜度呢?微信
完成一筆業務每每須要跨越多個應用系統,應用調用鏈路上每一個IT單元的問題,都有可能致使業務故障。系統中任何一個監控對象的告警均可能引起其餘多個相關策略的告警,海量告警的相關度高達90%,也就是說90%的告警都是能夠被歸因到一個根源告警上。架構
太高的告警閾值,容易漏掉系統運行故障;而太低的告警閾值,又會帶來大量的無效告警,影響運維團隊的工做效率。一樣,告警檢查週期的長短設置也存在相似的問題。每每運維團隊爲了避免落掉告警,不得不提高告警的靈敏度,而這樣告警重複率可能高達60%。運維
多我的參與同一類告警的處理是目前大部分運維團隊的工做模式,少則2-3人,多到9-10人,同一個告警會被推送到多個運維人員的手中。可是,一般在一些特殊時段只有一個值班員負責處理告警,這就給其餘團隊成員生活帶來了巨大的干擾。由於缺乏高效的分派和排班管理機制,加上大量重複的無效信息,這將會在必定程度上形成告警處理的延時和遺漏,從而引起告警風暴。微服務
「告警管理能力成熟度模型」呼之欲出工具
爲了提高 IT 系統的運維管理效率,最大程度下降運維管理難度,AIOps 成了技術發展的必然選擇。而告警管理做爲AIOps的重要組成部分,上接監控工具,下接ITIL流程和自動化平臺,是整個運維監控體系中承上啓下的中樞。告警管理能力的高低成爲了掣肘IT運維SLA(Service-Level Agreement,服務等級協議)的關鍵。學習
爲了幫助企業更加量化的評估當下告警管理能力,明確告警管理平臺建設目標和演進路線,咱們將告警管理能力分爲5個級別,整合出了「告警管理能力成熟度模型」,每一個級別按照管理能力的不一樣程度,呈現遞進的方式,高級別內容包含低級別內容。人工智能
Level 1,告警分散管理
咱們的運維團隊爲了儘量全面的覆蓋IT系統的各個環節,不得不引入多個監控工具,不一樣的監控工具會產生數以萬計的告警,這些告警都須要去分析、優先級甄別、並執行預案操做。隨着時間的推移,多是數十萬、百萬的告警事件須要被關注。
由於缺乏了告警的集中管理和分派,不一樣對象的告警信息在運維人員間無序的傳遞,致使告警響應和處理效率低下。嚴格意義上來講,這個級別的成熟度還談不上管理。
Level 2,告警統一管理
愈來愈多的運維團隊已經意識到了無序所帶來的高額的管理成本和低下的故障處理效率。據統計,有超過20%的企業經過運維開發團隊自建或利用第三方平臺來進行告警的統一管理。
將不一樣監控工具或系統產生的告警接入到統一管理平臺之中,並可以基於必定的規則對告警進行去重,過濾和壓縮。這個級別的管理能力成熟度打破了監控工具的邊界,以業務或場景爲視角,根據運維團隊的職能分工,如按照業務或者IT架構分工,將告警分門別類,結合更加高效的協做工具,如釘釘、企業微信、Slack等,在必定程度上提高了故障處理的效率。
Level 3,告警智能管理
業務在變,監控需求也在變,由於告警去重規則的死板而帶來的問題不言而喻。經過大量的數據統計分析,只有不到40%的告警可以經過規則進行壓縮。
隨着人工智能技術的不斷髮展,特別是NLP(Natural Language Processing,天然語言處理)技術的成熟,針對告警這類文本數據的分類、聚類、模式發現算法,成爲了有效抑制告警風暴,提高告警有效性的主要手段。能夠經過時間相關性、文本類似度、故障溯因圖、CMDB(Configuration Management Database,配置管理數據庫)等手段,對海量數據中類似、相關的告警進行聚合。針對告警中的異常、新奇等重要信息,經過時間熵和內容熵進行標識,越是不頻發、無規律、嚴重度高的告警越須要被重視,熵值越大信息越重要。告警智能管理將極大減小告警處理量,提高告警故障分析效率。
Level 4,根因告警定位
根因定位一直是告警管理皇冠上的那顆明珠。因爲告警的傳遞性和多面性,要在衆多錯綜複雜的信息中迅速定位根因對全部運維團隊來講都是巨大的挑戰。
關於根因定位的探索大體能夠分爲如下三個方向,一是基於動態獲取的系統調用鏈路和承載關係,並結合時間相關性開展根因分析;二是基於CMDB構建一個實時反映系統環境的配置項和關係二元組羣,經過告警在其中的投射關係進行根因定位;三是創建全面覆蓋IT運維管理全域的實體、屬性、關係三要素庫,再運用知識圖譜算法得到根因告警。固然不管是哪種方案,都須要創建在對IT系統架構的深度學習和理解基礎之上,才能真正作到明辨真僞,洞悉根因。
Level 5,告警自愈
告警自愈是一套完備的故障自動化處理流程,經過打通監控工具、告警平臺、任務調度平臺、CMDB、ITIL等相關係統,實現從告警接收,根因定位,規則匹配,腳本執行,故障恢復,人工確認,最後到告警恢復,真正實現告警的全生命週期管理。
除了Level 4中根因告警定位這個技術難點外,整個告警自愈過程還有另外一個關鍵點,就是告警故障知識庫的創建,這是平常運維工做經驗的積累和沉澱,也是故障恢復方案的基礎。但這也偏偏是咱們不少企業的軟肋,大量的故障處理經驗都存在於運維人員各自的大腦中,平常中更多的依靠我的能力去排查和恢復故障。隨着運維人員的流動,這些最爲寶貴的資產也隨之流失,這使得一個重複故障的處理也須要進行從新分析,沒必要要的拉長了故障恢復時間。
告警自愈能幫助運維團隊第一時間查明問題緣由,實現故障的快速修復。同時還能幫助運維團隊沉澱問題處置經驗,防範潛在風險,最終造成系統運維的閉環管理。
目前,愈來愈多的企業在告警管理領域展開探索,而且在告警風暴抑制上取得了必定的成效。睿象雲的智能告警平臺也在幫助不一樣行業的運維團隊解決告警集中和智能管理的問題。運維之路,艱苦漫長,告警的持續改進也不能一蹴而就,相信隨着技術的發展和經驗的積累,告警管理必將迎來跨越式發展的盛夏。咱們也但願經過你們對告警管理能力成熟度模型的探討和實踐,引領咱們共同步入無人值守這個運維終極目標。