**IT告警管理的現狀
**

IT系統良好穩定的運行，離不開系統監控報警。監控為整個IT系統提供了更好的可用性，如果能配置正確警報策略，可以使得IT團隊更快地響應事件，消滅潛在故障。以上理念在IT系統的相互獨立的時代是百分百正確的。但是，隨著企業規模的增長IT環境也隨之擴張，您如果有辦法應對即將到來的告警風暴——否則您很快就會被各種告警信息所淹沒，以至于無法正常工作。

更加不幸的是，隨著時間的推移，未來會有越來越多的系統可以產生告警，而且它們的速度會更快，數量也會更多。目前大多數IT團隊的告警都是自動生成的，然而告警處理卻是人工的。更要命的是，他們所處理的告警都是孤立的很少進行過關聯或歸并處理。

目前在收到大量警報的IT機構（告警數量1000次／日以上）中，只有17％能夠在24小時內完成故障排查和修復。大量分散的且不相關的告警，讓企業別無選擇只能增派工程師來解決。即使是增派了人員來處理，但是仍然有告警會被忽視，造成響應不及時，業務停機時間持續增長。因此告警風暴會為企業帶來個多方面的損失。

IT告警風暴是如何產生的？

在討論告警風暴所帶來的支出增長之前，讓我們先仔細分析下導致告警風暴的原因：

首先，當今的IT系統環境比以前更加復雜

IT部門只需要監控少數幾臺服務器的日子已經一去不復返了，現在IT團隊必須處理更加復雜的虛擬機、多云、容器等等IT環境。因此監控的IT系統的規模以及產生的告警的數量也要比五年前大一個數量級。

與此同時，應用程序的結構也越來越分散

應用程序分解為各種“微服務”組件的做法已經成為主流。當然微服務也有很多優點，它們使代碼更加模塊化和動態化，也避免了IT系統的單點故障，但是在告警方面，采用微服務架構加劇了告警噪音問題，因為一套IT系統現在有數十甚至數百個組件，它們的健康狀態同時也必須得到持續監控。

再次，“立體化”監控成為標配

IT基礎架構和軟件架構在過去十年中發生了巨大變化，因此20世紀遺留的基礎監控工具已無法滿足現代IT環境的需求，于是各公司開始采用一種新的監控體系：使用各種不同專業工具針對IT棧中不同層面進行“立體化”監控。在“立體化”監控工具體系中，至少會使用六個以上的監控工具，例如：系統監控、應用監控、跟蹤誤差 、日志分析、APM、異常檢測、業務性能監控、云監控、自動化部署監控、協作工具、工單系統等。然而所有這些不同的工具都會導致更多數量的告警產生；同時它們輸出的大量混亂不一的告警，也使得發現相互之間的關聯關系變得更加困難，從而無法發現嚴重的問題，至于查找故障的根本原因更是妄想。

此外，隨著組織轉向持續集成/持續交付，開發周期比以往任何時候都更加敏捷。

雖然基礎設施和代碼的變化還是在預定的窗口系統中進行，但是已經由過去的月度，季度甚至每半年度變化一次，演變為現在每天都在不斷的進行版本迭代。當版本更新順利時，可以進行更快的新功能上線、提高更好的客戶滿意度。但是，基礎架構和代碼中變化的速度越快，變更就越多，告警的數量也越多。

以上因素加起來就不可避免的產生了告警風暴，為企業造成了大量隱 形 的 生 產 成 本

1.停機成本

因為維護人員的擴充永遠趕不IT系統所產生的數據和報警的指數級增長速度，所以如果不改變人工運維的方式，將使得IT部門陷入癱瘓。

事實上，維護人員無法跟隨數據和告警的指數級增長而隨時擴充，當他們用傳統的手工方式去解決告警風暴的時候，關鍵的告警可能會掩蓋在海量數據之下。因此，當找到這些關鍵問題之前，IT故障造成的業務中斷將會一直存在。所以，告警風暴帶來的第一個隱形成本就是業務中斷時間。

根據IDC估算，一般的基礎環境故障每小時的成本約為10萬美元，而關鍵的應用程序的故障每小時損失高達50萬到100萬美元。 實際上停電造成的故障中有1/3的都持續1至12個小時，17%的基礎設施故障以及13%的應用程序故障會持續了一整天。每年IT中斷的成本是1000萬到25億美元之間。

以星巴克為例。由于“例行系統更新的故障”，這家咖啡巨頭在美國和加拿大的銷售網點都遭遇了大規模的業務中斷，無法進行收銀結算。這家零售商被迫免費贈送了數千杯咖啡，從而造成了300萬美元的損失。300萬美元不是因為安全漏洞，而是因為一個錯誤，一個常規的程序更新帶來的故障。

2.事故解決成本

當組織發現自己被淹沒在告警中時，通常的反應是投入更多的人來解決問題，也就是更多的工程師和更多的工作時間。這種方法雖然簡單，但成本高昂而且效率低下。近年來，機器數據和告警的數量以指數級速度增長，對于告警的檢測、處理、分析和糾正的需求已經遠遠超過了IT團隊的能力了。盡管許多企業已經將其NOC和IT團隊的規模擴大了一倍，但他們仍然無法跟上不斷增長的設備所生成事件和警報。雖然錢花了，但問題仍然存在——這意味著把錢打了水漂。

3.客戶滿意度

DevOps和CI/CD(持續集成/持續交付)的目標是減少IT中的摩擦。這樣做可以使產品更快地進入市場，并在不斷創新改進的過程中提高客戶滿意度。但是告警風暴的問題已經成為IT工作流中新的瓶頸。一方面CI/CD允許開發周期更快迭代，同時云自動化使得基礎設施擴展的速度更快，但是告警管理仍然是手動的。這樣造成的結果就是：服務的質量下降也變的更頻繁(系統迭代更加頻繁，同時停機更加頻繁)，而且問題也經常很長時間才被發現，甚至是被客戶投訴后才發現。這種故障會帶來切實的財務后果，也會損害客戶滿意度和品牌聲譽。當客戶如果不信任您服務的可用性和可靠性時，他們必將轉向競爭者。

告警治理行動

顯然，處理機器生成的數據的問題不應該用人工的方案來解決，人類根本無法處理持續增長的海量告警。公司應該將精力集中在利用機器處理上，以提高他們將信號與噪音分離的能力。好的方法是通過應用一個自動化的解決方案來識別不同的監控系統之間的相關告警。告警關聯是一種將高度相關的警報分組到高級別事件的方法，這些事件被按照各種各樣的參數合并，包括：

拓撲

主機、主機組、服務、應用程序、云或其他發出警報的基礎設施元素，當來自基礎設施的相同區域時，告警更有可能是存在關聯關系的。

時間

關聯警報發生的時間窗口，在同一時間段內發生的警報更有相關性，而不是時間間隔很遠的告警。

上下文

告警指標的類型。一些告警指標類型會暗示了它們和其他告警之間存在關系，當然也有部分告警類型是獨立的，與其他告警無關。

優锘智能事件管理平臺（Tarsier-EIM）的告警關聯的技術可以幫助客戶避免受到海量告警的影響，可以科學的自動完成警報關聯。這有助于IT團隊更快地發現和解決關鍵事件，并減少人力資源的占用。

優秀實踐案例

在國內某股份制銀行，通過優锘智能事件管理平臺（Tarsier-EIM）的告警的關聯能力對告警進行壓縮，壓縮率超過97%。

因此，運維工程師們不再盯著7套監控工具的57000個日常提醒，而是集中處理240個高度關聯的事件。告警關聯功能已經將最初孤立混亂的警報，變成了運維工程師可以輕松處理的故障隊列。在使用優锘智能事件管理平臺（Tarsier-EIM）的前三個月，客戶的故障處理的平均時間(MTTR)減少53%。與此同時，運維團隊發現，在不到一半的時間內，他們能夠解決兩倍多的突發事件，同時員工數量和資源并沒有變化。隨著IT規模不斷擴大，雖然產生了更多的告警，但他們的故障處理能力反而提高了。