有了人工智慧技術，告警管理會發生什麼變化？

網際網路時代 IT 相關的衍生產品多種多樣，其中監控工具成為了其中的佼佼者。多種多樣的監控工具對於確保網站和應用的平穩執行做了非常多的工作，但是，對於告警產生到通知運維人員的過程，還有很大的改善空間。

舉個例子：假設某企業的 IT 環境中的某個底層基礎設施，如網路或儲存裝置出現異常，相關聯的主機、中介軟體資料庫、訊息佇列、快取，應用程式，業務服務會受到影響。當監控和管理系統全面的探測發現這些問題的話，會在數十秒鐘產生大量的告警事件，而且這些事件隨著時間的推移不斷的發生。設想一下如果把所有的告警全部都加入通知提醒的話，想必運維人員的郵箱會瞬間爆滿。實際上，隨著規模化和複雜度增加，這些現象經常性發生。

告警管理需要降噪

其實對於事件管理，其基本的核心思路就是對資料進行處理，將成千上萬的事件過濾、篩選、甄別，讓整個事件管理的流程體系如漏斗般，透過多層過濾雜質，沉澱下金沙。

當大量的雜音事件頻發騷擾我們工程師，就會引發告警疲勞，就是帶來所謂的無感。體現為事件收到的太多，跟自己相關的卻很少，重要的事情淹沒在汪洋大海中，根本無從下手。降噪的目的，就是去除噪音，留下樂章。事件處理過程中，傳統的做法是去重，將重複的事件去除掉，簡單有效。從時間維度上，相同的事件僅發生一次，之後再發生只會在事件的計數器上體現。這個方法基本就能達到 80%-95% 左右的壓縮率，去掉噪音告警，數萬數千條的事件就會縮減為數百和數十。

去重的做法簡單有效，然而不能完全解決上述例子中的很多不同型別事件發生問題，特別規模大的時候，幾百主機、數十中介軟體、數百應用、數千微服務、數十業務服務的告警事件的過濾。所以這個時候引入了新的人工智慧演算法成了告警管理的救命稻草。

資訊熵和自然語言處理

資訊是一個很抽象的概念，資訊多少很難說清楚。如一本小說有多少資訊量?一個事件有多少資訊量?直到 1948年，資訊理論之父夏農提出了“資訊熵”的概念，才解決了資訊的量化度量問題。熱力學的熱熵表示分子狀態混亂程度，夏農用資訊熵來度量信源的不確定性。熵越大，資訊的不確定性就越高，利用熵的特性，我們嘗試來解決告警事件資訊的過濾問題。

從內容資訊上的資訊量(熵)。例如 CPU 使用率超過閾值，和儲存裝置當機是完全不同的，後者明顯重要和資訊量更大。做到這一點需要解決兩個問題：

1. 需要從自然語言內容的角度去理解資訊。特別要指出的是 IT 運營支撐專業術語和電商語言、新聞類語言是有差異的。例如電商裡面，面膜和護膚詞語有很大關聯，而監控裡面交換機 Switch 和埠 Port 有很大關聯，通用的自然語言處理技術應用到專業領域裡面有一定的難度。

2. 某個使用者的告警事件有可能從來沒有發生過，意味著第一次發生的時候這些資料(內容)需要在識別出來。如新上的儲存裝置3月來執行良好，結果今天剛好故障。

解決這兩個問題，依賴於智慧告警平臺多年來 SaaS 運營積累了各行各業的超過2億條原始告警事件資料，透過對這些資料進行處理，建立起專業的監控告警自然語言文字語料庫。

1. 覆蓋行業多：包括金融、運營商、雲服務商、遊戲、電商等;

2. 覆蓋層次多：基礎設施、中介軟體、應用、大資料、業務以及微服務，生產製造過程中各類資訊。

透過建立專業的告警事件自然語言語料庫，幫助我們深入的從內容的角度去告警事件資訊。A 使用者首次發生的儲存故障，其實在 B 使用者已經發生過了，我們能夠識別該資訊的內容熵，比 CPU 使用率告警更重要(每家每戶都發生)。

除了資訊內容的理解，建立內容熵，我們還考慮時間維度，我們稱為時間熵。例如同樣是 MySQL Slave Down 程式故障，天天發生和幾個月發生一次的資訊量也不同，所以我們還要考慮時間維度的發生頻率問題。結合內容熵和時間熵，我們標識事件(告警)的重要度，幫助工程聚焦問題，實現降噪處理。

資訊熵的應用還很廣，在事件處理上，應該還要考慮上下文、IT 環境等一系列因素，我們也在探索。例如儲存裝置/網路故障會比主機故障更為重要，拓撲依賴關係、層次結構等上下文因素會對資訊的識別有更大影響。透過資訊理論技術和人工智慧演算法，對符合特定特徵的事件進行分類、聚合、降噪，生成對應的事件集，並自動監測和發現事件流中的異常情況，提升問題發現能力。

智慧化事件處理，幫助使用者對海量事件進行實時的自動化篩選和甄別，主動發現事件、告警中蘊含的業務執行風險和使用者體驗問題，降低超過95% 的 IT 噪。

透過智慧聚類實現事件事物化

回到文章開始的例子，降噪將告警事件處理後，還有數十數百個事件，很多是類似的，例如儲存類 Lun1、Lun2 故障，主機 A\B\C… 故障，資料庫 Master1、Master2、Slave1… 應用 Order_1_8080,order_2_8080…，業務支付、門戶等。其實就是有幾類事情，儲存類、主機類(支付類主機、門戶類主機)、資料庫叢集、支付類應用、門戶類應用等幾大類。從職責劃分和管理流程方面，也是不同團隊負責。如果能夠將這些零散的事件分門別類，就更清晰和有助於處理(職責劃分)。

睿象雲希望透過輕量級的方式和重量級相結合來實現聚類的準確性。輕量級的意思是，透過演算法和簡化的策略規則，無需過多的前提條件，快速實現告警事件的聚合。將上述例子中的大量事件，劃分為儲存、資料庫、應用和不同業務。

告警事件之間是存在一定的關聯性的，將一組類似的有關係的事件聚合在一起就是一個場景。以場景為單位去實現團隊的分派/協作，最終解決問題，而不是單一事件的逐條解決。使用者可以透過組合服務可以將單個業務下多個物件產生的事件進行聚合，如將承載 OA系統的伺服器、網路、中介軟體、資料庫、應用等事件和告警從海量資訊中剝離出來，彙總到一個 OA 服務之中，交由負責該系統的團隊進行統一的管理和分析，從而提升業務管理的可見性。

利用人工智慧無監督學習技術，結合自然語言處理 NLP，我們從內容相似性、相關性進行資料探勘和學習。內容相似性上，我們利用在降噪過程中我們建立的專業語料庫，能夠識別出當下相似告警，將符合相似度(如80%)的事件聚合在一起。時間相關性上，可以根據事件發生的時間差，在一瞬間爆發的大量事件是存在一定關聯性的，特別是開篇的那個栗子。然而由於監控工具的資料採集問題，現實的事件並不是嚴格的按照時間序列過來的，例如業務故障和儲存故障，從直覺角度上看，應該是儲存故障先發生，之後才影響業務。實際上，兩者的事件時間有可能是相反的。

透過演算法，在沒有過多的前提條件下，實現將相似相關事件聚合稱為一個場景。與降噪一樣，演算法應該跟上下文和環境相關，所以未來在聚類的方面可以做的更深入，更重量級。

助力識別問題根因

到現在為止透過降噪將事件從數千數萬降低為數百數十，聚類降低為數類數十。對於告警已經基本上實現了更高效的處理問題，然而，我們總是期望能夠定位到根源，甄別是那些異常引發的，快速識別根因是所有IT支撐工程師的追求。

現實是很困難，如果想100%的確定根因，必須對 IT 環境的每個環節和設施進行管理，並建立資料模型。在當今的規模化、虛擬化、微服務化情況下，這是很困難的事情。所以往往依賴於有經驗的工程師進行分析和判斷，如果在跨職責、跨業務、跨團隊的時候，就需要多個不同領域的專家工程師去診斷和分析了。

藉助人工智慧演算法，透過有監督的訓練方式，透過歷史和人為標註的資料。工程師每一次的根源識別，都可以作為機器學習訓練的素材。隨著時間的推移，診斷標註的根源資料積累越多，機器就能夠準確的識別出因果關係，根源識別也越來越準確。像前文的例子中，如果有類似歷史資料，並且完成人工標註，那麼再次發生的時候，我們就可以判斷儲存或者是網路故障是根因，可能性85%。透過人工智慧方式，逐漸的擺脫嚴重依賴專家工程師的模式，讓運營支撐系統成為一個能夠自我學習和進化的智慧系統。

識別場景，甄選根因後，我們基本上就可以著手解決問題。在處理問題的過程中，會出現一個知識傳遞的問題。例如有經驗的工程師和新入職的工程師的差異，其實這就是一個集體知識共享的問題。我們也透過人工智慧的方式做了一些嘗試，讓整個事件(告警)處理更流暢起來。場景歷史推薦，對於新發生的場景，如果以前有類似的場景，系統會推薦出來，如在上個月有一個類似的故障，相似度80%，也是一個儲存類故障。透過檢視歷史場景的解決方案/過程，幫助我們做決策，可以快速的複用歷史知識。整個過程中，人工智慧自動學習和推薦，告別人工手動編輯知識文件的方式。所以經過一定時間的積累，這些解決方案將沉澱為企業特有的知識儲備，而不是一個泛泛的功能。為之後的發生相同或是類似事件提供可參考的解決辦法。

寫在最後

人工智慧技術的應用和實踐會越來越多，我們有理由相信 AIOps 會對 IT 運營支撐產生極大的影響力。我們的智慧告警平臺和智慧事件平臺也都還在這個領域裡不斷的探索中，歡迎大家登陸睿象雲官網進行 ，與我們一起探索。

隨著更多的使用者對人工智慧的瞭解應用，相信不久的將來，正如 Gartner 說的，未來將有越來越多的企業使用 AIOps 方式運營支撐，人工智慧對企業 IT 運營效率的提升和變革，也將促進這些企業的商業發展提速。