5/27晚上，擎創科技CEO楊辰爲大家帶來了智能運維繫列分享會第五期直播演講。從本期開始，將陸續爲大家講述智能運維AIOps建設的三項原則及六步走路線圖。本次分享主要探討智能運維建設第一步——集中監控的智能化改造，AIOps爲傳統集中監控添智慧。以下爲演講實錄~
關於AIOps建設的實現方法，擎創科技提出來了三大原則和六步走路線（參考上篇推送文章《智能運維建設，下一步可以做什麼》），許多讀者可能會希望瞭解，AIOps建設這盤大棋究竟爲何六步走的第一步要落子於集中監控的改造？集中監控智能化的改造都需要考慮哪些方面，收益在哪裏？如何通過集中監控的改造進一步的展開智能運維相關場景的建設？這裏面的邏輯和銜接關係是怎樣的？
帶着這些問題，我們來談一談AIOps智能運維如何爲集中監控這項傳統運維領域最重要的手段（沒有之一）添加智慧的引擎。
一 傳統集中監控之殤
如下圖所示，運維體系中最重要的使命是及時發現問題，這在任何企業組織中都是不言而喻的。正是因爲如此，企業纔會在經年累月中佈局了諸多監控手段，有些是商業化的工具，有些是運維人員爲了獲取被管理對象的狀態寫的形形色色的腳本，但總體都是爲了及時發現問題。
但是，當業務運行出現問題時，往往有許多監控工具都會產生多樣化的事件（或者俗稱告警），這些事件分散在各自不同的監控工具或者由腳本採集或者觸發，沒有一個統一的視角進行一站式的管理，這就是構建集中監控（或稱統一監控）平臺的主要動因。當然，集中監控還可以根據運維需要將事件分配給不同的運維人員進行處理，提高分工管理效率。
集中監控固然是視野夠寬廣，但隨之而來的是另外一些問題，原始的事件裏有許多重複性的、雜亂的噪音信息，而且某一個組件發生問題，往往會引發相關的組件都產生報警，這樣在短時間內就會產生告警風暴，這也會嚴重影響運維人員的判斷，因此傳統的集中監控，都是依賴運維人員的經驗梳理規則，並將事件歸併、關聯的規則運用於平臺，實現告警抑制。
這種方式在傳統運維領域已經有超過二十年曆史，早在2002年，世界上第一家利用內存處理技術運行事件處理規則的產品Netcool Omibus就在國內開始了業務，後來這家公司被IBM收購，至今還是IBM監控產品Tivoli的旗艦產品，國內也還有大量客戶在使用。爲什麼要使用In memory DB技術，就是因爲規則會越積累越多，而基於規則匹配去處理事件，需要很多計算資源，否則處理速度趕不上事件產生的速度，就會丟漏事件，這是監控的大忌。
後來，BMC、HP等公司都開始用這種技術做集中監控產品，近年來國內的諸多公司也紛紛跟進，集中監控用設定規則處理告警的方式已經成爲慣例。唯一的不同在於，由於業務逐漸走向分佈式架構，近年來告警的量級達到一種一般關係型數據庫難以企及的架構後，有些公司採用分佈式數據庫來替代傳統架構，但上層的應用邏輯仍然是基於規則匹配處理。從表面上看，集中監控的出現確實實現了以集中視角看到各類告警的需求，一線人員對於告警有了一站式處理平臺，效率相對於分散的監控工具確實得到了提升。
運維的世界真的就此安寧了嗎？並非如此。
衆所周知，規則，是一種經驗的總結。只有出現過，甚至反覆出現的規律，才能被總結爲規則。因此傳統集中監控仍然存在一些無法根治的弊端：
1 經驗規則是有侷限性的
若運維人員缺乏足夠的經驗，就無法梳理出有效的規則；再者，運維人員往往對自己負責的局部領域有經驗，但對於其他部分則是小白，業務應用的載體一定是複雜的多個組件構成，不同領域的經驗兼具才能發現一些相關性規則，而這些相關性無法僅僅通過“集中”就能發現，所以規則只能解決一部分問題。
2 對於新發生的或者偶發的事件關注度非常不夠
告警雖然集中了，但卻無法甄別出告警是否是全新的或者偶發的，這種類型的告警任何既有規則都無法覆蓋，但往往蘊含殺機。舉例來講，任何變更後新增告警事件都應該給予高度關注，現在應用的敏捷迭代造成變更頻發，一旦發現變更後出現罕見的事件，往往是故障發生的端倪。
3 缺乏優秀的綜合排障和覆盤分析機制
集中監控平臺雖然能及時看到全局的告警，但是每條告警是分列的，缺乏分析某一個故障究竟和哪一些告警存在關係的能力，也無法甄別哪些告警可能是週期性出現的，或者每次故障發生前某一類告警存在一種數量遞增的相關性趨勢，這樣的覆盤分析能力缺失導致平臺不能支持運維工作可持續改進，就很難進一步有效梳理出有利於故障發現的經驗規則，持續提升運維一線處理效率，縮短MTTR也就難上加難。
正因爲存在這些不足，傳統集中監控往往是上線初期耳目一新，但經過一段時間使用後，仍然呈現出“沒什麼故障時，事件很少也沒有人看，故障一旦發生時事件多得看不過來”的尷尬局面。
二 AIOps如何進行傳統集中監控的智慧賦能
AIOps智能運維對於已經構建的傳統集中監控系統首先是一種賦能的作用，也就是新建立的AIOps智能告警系統可以和既有的系統協同工作，這裏會有一個並存的過程；在第二階段，就可以隨着智能監控的日益成熟逐步完成轉型，也就是將主要的工作舞臺遷移到智能集中監控系統；當然，對於還未構建集中監控的企業，完全可以換道超車，直接建立具備智能運維能力的集中監控系統。
我們下面以擎創科技的夏洛克AIOps告警辨析中心爲例，來展開分析這種AI賦能的幾種方式：
1 對既有的完全基於經驗進行規則梳理的處理方式的智慧賦能
夏洛克AIOps首先可以通過算法甄別重複性、相似性、相關性事件來進行告警事件的自動化抑制，從而使運維人員無須費心費力總結這些規則就能夠達到很高的降噪壓縮比，而同時，既有的規則仍然可以同時運行，因此夏洛克AIOps能夠有效結合機器學習的洞察能力和既有運維經驗所梳理的規則，充分提升了告警質量。
2 對事件的精細化分析能力的智慧賦能
僅僅是在告警處理時降低噪聲是遠遠不夠的，傳統監控往往是敗在告警的分析能力不足上，看似監控是實時性更重要，但對於已發生的事件是否能進行有效的分析，直接關係到未來類似事件的處理能力是否能夠提升，這一點往往在管理上重視度不夠，任何事件發生，都應該以這樣一種管理思路去分析。
（1）這究竟是什麼性質的事件：這就要求做歷史事件的特徵分析
只有瞭解歷史，纔有機會認識未來。
歷史事件給予的許多線索，通過算法洞察會比人的經驗觀察有效許多，夏洛克AIOps的告警智能辨析能力，能夠有效的通過分類分析歷史告警，從而瞭解事件的性質。究竟哪些是偶然發生的，哪些是首次出現的，哪些是經常且週期性發生的，而哪些是隻在某個特殊階段纔出現的，這些分析有很重要的意義，因爲這會使那些偶發或者突發新增的故障事件得到更多的關注，也可以降低對那些時常發生但並不影響業務的白噪聲告警的關注度，這種智能分析力提升了對傳統監控來說難以企及的數據洞察力。
（2）還有哪些相關性的事件：多種維度的相關性分析
很少有告警是孤立發生的，因爲業務服務架構複雜，往往牽一髮而動全身，但告警間的關係也比較複雜，一般要從三個維度去考慮：第一是發生時間的關係，第二是告警內容邏輯上的關係，第三是拓撲結構的關係。
第一種，時間維度比較容易理解，告警發生的先後順序往往對於指出根因有意義，但因爲各個告警來源的不同造成時鐘不同步，所以這種關係未必完全準確，只能作爲參考；
第二種是內容邏輯維度，也就是語義上的相關性，比如通過算法可以識別出包含同某一種服務器名或者IP、URL地址的告警，進行聚類合併；
第三種最爲重要，可以引入來自於CMDB的拓撲關係的維度來分析，當然這種維度也有其不確定性，比如源數據存在變更後未及時維護的錯誤。但是，AI和大數據的妙用在於利用模糊的信息得出相對可靠的推論，夏洛克AIOps利用專利的多維熵值算法模型，兼顧多種因素綜合判斷，從而使一些隱藏的規律被機器“學習”出來供運維人員使用。
（3）影響了何種業務：故障場景化的事件分析
相關性的發現最重要的價值在於故障排查，也就是了解哪些告警和具體的故障現象有聯繫，在夏洛克AIOps系統中，這種和某種故障有聯繫的多個告警組合稱之爲“場景”，若根據業務的基本架構，把同一業務服務的各個組件中那些可能存在相關性的告警匯聚到一個場景後，往往可以找到故障的根因，至少也可以給複雜排障提供一種前所未有的視角，從前一條條分列的告警，需要多個人分頭排查，而有了自動生成的場景，多個不同專業的運維人員可以第一時間看到故障相關告警平鋪在面前，對於協同排障和發現根因都很有幫助。
3 通過建立人工和智能相融合的迭代反饋機制促使監控持續優化
人不是萬能的，有其侷限性，但AI同樣也有其侷限性。因此關鍵在於如何利用AI的洞察力結合人的經驗迭代反饋。在夏洛克AIOps告警辨析中心，告警的處理機制就是人機融合的典型例證。
（1）通過不斷分析反饋優化事件處理規則，提升監控準確度
通過多維相關性分析能力生成的業務故障場景，其準確性初期一定不會是100%的，但卻可以通過運維人員的經驗有效甄別，原來集合專家排障的喧鬧的War room，現在可以革新爲在夏洛克告警辨析中心獨創的機器學習沙盒中一起審覈“場景”，機器推薦的優先級可以在這裏得到判定，準確率高的場景推薦會被認可爲留存知識，而其中的場景組合和根因可以被AI記錄爲算法迭代的要素，從而持續改進算法模型，爲更準確的推薦故障場景做鋪墊。同時，確定性高的場景還可以被規則化，爲未來匹配度高的告警序列提供預警。這就形成了一種有持續改進智慧的集中監控系統。
（2）通過告警分析結果指導解決監控的覆蓋面和有效性問題
持續改進不僅僅體現在告警處理和分析機制，事實上，我們還可以從分析結果中得到更多指導建議。
比對業務故障和既有場景中的相關事件，我們不難發現兩種問題。第一是存在大量的被抑制的誤報事件，而進一步分類分析則可以發現這些類別的噪音事件是由哪些對象產生的，具體反映若是指標類告警的，往往是由於該指標閥值設定得不合理，這就要考慮對於該類指標處理的智能化改造，具體的改進方式我們可以在下一講再分享；
第二則是要比對哪些故障的根因是無法在既有發現的告警中找到的，這就是漏報，這是很嚴重的問題，要考慮擴大監控手段，有時可能比較簡單，比如是監控集中的覆蓋度不夠，還存在未被納管的指標、未被集中進來的監控工具或者未被有效利用的運維數據，比如APM的告警或者調用鏈信息；有些可能就比較複雜，特別是業務類的故障，往往在基礎架構側確實沒有什麼告警指向該問題，這時要考慮日誌數據的利用，比如引入日誌模式實時異常檢測，幫助在第一時間發現異類業務日誌模版或者某類日誌量級上的異常變化，這些異常往往意味着故障根因，或者提升日誌分析中的實時告警能力，這也會在後續文章中進一步講解。
三 總結
綜上所述，集中監控作爲運維的“雙眼”，應該是AIOps智慧賦能的第一站，賦能後的智能化集中監控將具備三大優勢：
- 能夠以更低的人力成本更及時有效地發現問題端倪，提高了業務保障能力；
- 能夠更深入的洞察和分析告警，提升了故障排查效能；
- 能夠利用人機融合的智慧，建立持續改進的機制，並且爲進一步進行基礎指標監控以及日誌分析等其他領域的智能化改造提供了指導方向。