**IT告警管理的現(xiàn)狀
**

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

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

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

IT告警風暴是如何產(chǎn)生的？

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

首先，當今的IT系統(tǒng)環(huán)境比以前更加復雜

IT部門只需要監(jiān)控少數(shù)幾臺服務器的日子已經(jīng)一去不復返了，現(xiàn)在IT團隊必須處理更加復雜的虛擬機、多云、容器等等IT環(huán)境。因此監(jiān)控的IT系統(tǒng)的規(guī)模以及產(chǎn)生的告警的數(shù)量也要比五年前大一個數(shù)量級。

與此同時，應用程序的結(jié)構(gòu)也越來越分散

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

再次，“立體化”監(jiān)控成為標配

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

此外，隨著組織轉(zhuǎn)向持續(xù)集成/持續(xù)交付，開發(fā)周期比以往任何時候都更加敏捷。

雖然基礎設施和代碼的變化還是在預定的窗口系統(tǒng)中進行，但是已經(jīng)由過去的月度，季度甚至每半年度變化一次，演變?yōu)楝F(xiàn)在每天都在不斷的進行版本迭代。當版本更新順利時，可以進行更快的新功能上線、提高更好的客戶滿意度。但是，基礎架構(gòu)和代碼中變化的速度越快，變更就越多，告警的數(shù)量也越多。

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

1.停機成本

因為維護人員的擴充永遠趕不IT系統(tǒng)所產(chǎn)生的數(shù)據(jù)和報警的指數(shù)級增長速度，所以如果不改變?nèi)斯み\維的方式，將使得IT部門陷入癱瘓。

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

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

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

2.事故解決成本

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

3.客戶滿意度

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

告警治理行動

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

拓撲

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

時間

關聯(lián)警報發(fā)生的時間窗口，在同一時間段內(nèi)發(fā)生的警報更有相關性，而不是時間間隔很遠的告警。

上下文

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

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

優(yōu)秀實踐案例

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

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