AIOps?人工智能和IT運營支撐 Ops 之間的故事，愈演愈烈火本，已經(jīng)成為當(dāng)今運維圈的熱門話題窟感，我打算從2篇文檔分享我們在 AIOps 上一些探索和實踐习贫。(上篇)主要介紹了為什么事件(告警)處理需要 AIOps；(本篇)主要分享OneAlert 事件處理平臺在 AIOps 方面的探索兄淫。

上篇提到規(guī)耐驮叮化的 IT 事件管理中，需要人工智能識別重要信息捕虽，去除噪音氓润，甄別關(guān)鍵信息，減少人力工作量薯鳍。

舉個栗子：假設(shè)某企業(yè)的 IT 環(huán)境中的某個底層基礎(chǔ)設(shè)施咖气，如網(wǎng)絡(luò)或存儲設(shè)備出現(xiàn)異常挨措，相關(guān)聯(lián)的主機、中間件數(shù)據(jù)庫崩溪、消息隊列浅役、緩存，應(yīng)用程序伶唯，業(yè)務(wù)服務(wù)會受到影響觉既。當(dāng)監(jiān)控和管理系統(tǒng)全面的探測發(fā)現(xiàn)這些問題的話，會瞬間(數(shù)十秒)產(chǎn)生大量的事件乳幸，而且這些事件隨著時間的推移不斷的發(fā)生(1-2分鐘)瞪讼，假設(shè)都加入通知提醒的話，郵箱瞬間爆滿粹断。實際上符欠，隨著規(guī)模化和復(fù)雜度增加瓶埋，這些現(xiàn)象經(jīng)常性發(fā)生希柿。

OneAlert?在事件(告警)處理方面經(jīng)營多年，借助人工智能技術(shù)养筒，在以下幾個方面進行探索曾撤，嘗試解決上述問題：

降噪，消除不重要的事件晕粪，識別重要關(guān)鍵信息挤悉，避免告警疲勞。

聚類巫湘，將相關(guān)的事件聚合起來装悲，分門別類，特別是在告警風(fēng)暴方面應(yīng)用剩膘。

識別根因衅斩，在數(shù)千事件中識別出可能是根因的問題。

決策支持怠褐，相似問題推薦畏梆，實現(xiàn)知識復(fù)用。

基本核心思路是對數(shù)據(jù)進行處理奈懒，將成千上萬的事件過濾奠涌、甄別、篩選磷杏，如漏斗般溜畅，多層過濾雜質(zhì)，沉淀下金沙极祸。

降噪

當(dāng)大量的雜音事件頻發(fā)騷擾我們工程師慈格，會引發(fā)告警疲勞怠晴，就是所謂的無感。體現(xiàn)為事件太多浴捆，跟己相關(guān)的較少蒜田，重要的事情淹沒在汪洋大海中。

降噪的目的选泻，就是去除噪音冲粤，留下樂章。事件處理過程中页眯，傳統(tǒng)的做法是去重梯捕，將重復(fù)的事件去除掉，簡單有效窝撵。OneAlert 早期版本就是這樣傀顾，從時間維度上，相同的事件僅發(fā)生一次忿族，之后再發(fā)生只會在事件的計數(shù)器上體現(xiàn)锣笨◎蛎基本上該方法能達到 80%-95% 左右的壓縮率道批，刨去雜音，將數(shù)萬數(shù)千事件縮減為數(shù)百和數(shù)十入撒。

OneAlert 的新用戶會有一個習(xí)慣過程隆豹，從?Zabbix?或者其他監(jiān)控工具過來的相同事件，只會合并為一條茅逮，通過分發(fā)升級機制通知到位璃赡，提醒快速處理。習(xí)慣后献雅，基本上通知到位的事件都需要關(guān)注下碉考。

去重的做法簡單有效，然而不能完全解決栗子中的很多不同類型事件發(fā)生問題挺身，特別規(guī)模大的時候侯谁，幾百主機、數(shù)十中間件章钾、數(shù)百應(yīng)用墙贱、數(shù)千微服務(wù)、數(shù)十業(yè)務(wù)服務(wù)的告警事件的過濾贱傀。所以我們引入了新的算法惨撇，借鑒信息論熵的概念。

什么是熵?

“說不清楚的事就叫傷(熵)!”府寒。信息是一個很抽象的概念魁衙，信息多少很難說清楚报腔。如一本小說有多少信息量?一個事件有多少信息量?

知道1948年，香農(nóng)提出了“信息熵”的概念剖淀，才解決了信息的量化度量問題榄笙。熱力學(xué)的熱熵表示分子狀態(tài)混亂程度，香農(nóng)用信息熵來度量信源的不確定性祷蝌。

再舉個栗子～

小明不愛學(xué)習(xí)茅撞，小李愛學(xué)習(xí)，小明考試十有八九不及格巨朦，小李經(jīng)常滿分米丘。

事件A：小明考試及格，對應(yīng)的概率 P(xA)=0.1糊啡，信息量為 I(xA)=?log(0.1)=3.3219

事件B：小李考試及格拄查，對應(yīng)的概率 P(xB)=0.999，信息量為 I(xB)=?log(0.999)=0.0014

小明及格率低棚蓄，如果有一次及格了堕扶，大家會很驚訝，小明居然及格了!!! 信息量好大呀!

從熵的角度看：

小明的熵：HA(x)=?[p(xA)log(p(xA))+(1?p(xA))log(1?p(xA))]=0.4690

小李的熵：HB(x)=?[p(xB)log(p(xB))+(1?p(xB))log(1?p(xB))]=0.0114

小明結(jié)果不確定梭依，畢竟10次有9次不及格稍算，小李比較確定(1000次考試只有一次可能不及格，結(jié)果相當(dāng)確定)

熵越大役拴，信息的不確定性高糊探，利用熵的特性，我們嘗試來解決告警事件信息的過濾問題河闰。

熵和自然語言處理 NLP

由于 OneAlert 接收的事件是非結(jié)構(gòu)化的文本數(shù)據(jù)科平，通過人工智能算法，結(jié)合自然語言處理 NLP 技術(shù)姜性。使用 NLP 文本的分詞瞪慧、命名實體識別等特性，實現(xiàn)數(shù)據(jù)處理部念。

從內(nèi)容信息上的信息量(熵)弃酌。例如 CPU 使用率超過閾值，和存儲設(shè)備宕機是完全不同的印机，后者明顯重要和信息量更大矢腻。做到這一點需要解決兩個問題：

1. 需要從自然語言內(nèi)容的角度去理解信息。特別要指出的是 IT 運營支撐專業(yè)術(shù)語和電商語言射赛、新聞類語言是有差異的多柑。例如電商里面，面膜和護膚詞語有很大關(guān)聯(lián)楣责，而監(jiān)控里面交換機 Switch 和端口 Port 有很大關(guān)聯(lián)竣灌，通用的自然語言處理技術(shù)應(yīng)用到專業(yè)領(lǐng)域里面有一定的難度聂沙。

2. 某個用戶的告警事件有可能從來沒有發(fā)生過，意味著第一次發(fā)生的時候這些數(shù)據(jù)(內(nèi)容)需要在識別出來初嘹。如新上的存儲設(shè)備3月來運行良好及汉，結(jié)果今天剛好故障。

解決這兩個問題屯烦，依賴于 OneAlert 多年來?SaaS?運營積累了各行各業(yè)的告警事件數(shù)據(jù)坷随，通過對這些數(shù)據(jù)進行處理，建立起專業(yè)的監(jiān)控告警自然語言文本語料庫驻龟，這個庫可以說是當(dāng)今中國少見的温眉。

1. 覆蓋各行各業(yè)，感謝金融(招行翁狐、借貸寶类溢、盛開金融)，出行(馬蜂窩露懒、ofo闯冷、摩拜)，電信運營商懈词，云服務(wù)商(網(wǎng)宿蛇耀、七牛、云牛)钦睡、制造業(yè)( TCL蒂窒、美的)躁倒、游戲(殼木荞怒、靈刃、閑來胡娛)秧秉、以及用友褐桌、良品鋪子、德電象迎、銅板街荧嵌、供銷大數(shù)據(jù)、趨勢科技砾淌、華大基因等各行業(yè)優(yōu)秀公司啦撮。

2. 覆蓋層次多，基礎(chǔ)設(shè)施汪厨、中間件赃春、應(yīng)用、大數(shù)據(jù)劫乱、業(yè)務(wù)以及微服務(wù)织中，生產(chǎn)制造過程中各類信息锥涕。

通過建立專業(yè)的告警事件自然語言語料庫，幫助我們深入的從內(nèi)容的角度去告警事件信息狭吼。A 用戶首次發(fā)生的存儲故障层坠，其實在 B 用戶已經(jīng)發(fā)生過了，我們能夠識別該信息的內(nèi)容熵刁笙，比 CPU 使用率告警更重要(每家每戶都發(fā)生)破花。

除了信息內(nèi)容的理解，建立內(nèi)容熵疲吸，我們還考慮時間維度旧乞，我們稱為時間熵。例如同樣是 MySQL Slave Down 進程故障磅氨，天天發(fā)生和幾個月發(fā)生一次的信息量也不同尺栖，所以我們還要考慮時間維度的發(fā)生頻率問題。

結(jié)合內(nèi)容熵和時間熵烦租，我們標(biāo)識事件(告警)的重要度延赌，幫助工程聚焦問題，實現(xiàn)降噪處理叉橱。

信息熵的應(yīng)用還很廣挫以，在事件處理上，應(yīng)該還要考慮上下文窃祝、IT 環(huán)境等一系列因素掐松，我們也在探索。例如存儲設(shè)備/網(wǎng)絡(luò)故障會比主機故障更為重要粪小，拓撲依賴關(guān)系大磺、層次結(jié)構(gòu)等上下文因素會對信息的識別有更大影響。

利用人工智能探膊、信息論等技術(shù)杠愧，我們在成千上萬的事件，挑選和甄別出重要事件逞壁，讓工程師更聚焦流济，從而更快處理。但是事件本身還是零散的腌闯，還是需要工程師去挨個查看绳瘟，所以我們引入了聚類技術(shù)。

聚類

回到文中第一個栗子姿骏，降噪將告警事件處理后上鞠，還有數(shù)十?dāng)?shù)百個事件娄涩，很多是類似的怎憋，例如存儲類 Lun1、Lun2故障畅卓，主機 A\B\C… 故障，數(shù)據(jù)庫 Master1蟋恬、Master2翁潘、Slave1… 應(yīng)用 Order_1_8080,order_2_8080…，業(yè)務(wù) 支付歼争、門戶等拜马。

其實就是有幾類事情，存儲類沐绒、主機類(支付類主機俩莽、門戶類主機)、數(shù)據(jù)庫集群乔遮、支付類應(yīng)用扮超、門戶類應(yīng)用等幾大類。從職責(zé)劃分和管理流程方面蹋肮，也是不同團隊負責(zé)出刷。如果能夠?qū)⑦@些零散的事件分門別類，就更清晰和有助于處理(職責(zé)劃分)坯辩。

常用做法一般是定義大量的規(guī)則馁龟，建立起專家系統(tǒng)(規(guī)則庫)，這種模式在IT系統(tǒng)規(guī)钠崮В或者是復(fù)雜度相對較小時坷檩，比較適用。例如同一個網(wǎng)絡(luò)設(shè)備上的端口故障合并在一起改抡。隨著時間的推移矢炼，配套的知識規(guī)則需要不斷的完善，對人力的要求和管理要求更高雀摘。當(dāng)IT環(huán)境變化和調(diào)整后裸删，如果配套的規(guī)則沒有更新，或者是規(guī)則不夠全面和完善阵赠，則有可能逐漸荒廢，淪落為無用肌稻。

也有不少用戶提出使用 CMDB清蚀，構(gòu)建完善的拓撲依賴關(guān)系的模式，去從根源上進行追溯實現(xiàn)聚類合并爹谭，然而CMDB和拓撲關(guān)系的維護枷邪，也面臨著動態(tài)化實時準(zhǔn)確性問題。而且在 CMDB 建設(shè)過程中往往會出現(xiàn)過大過重诺凡，蘿卜青菜一起管的情況东揣，實現(xiàn)管理職責(zé)清晰践惑、邊界明確的可能性很低，特別是在業(yè)務(wù)和服務(wù)驅(qū)動的情況下嘶卧，后端和底層IT支撐往往迫于形勢尔觉，CMDB 被迫納管更多內(nèi)容。

以上兩類做法其實都是依賴于管理制度芥吟，并輔助工具的做法侦铜。特點是需要依賴人工大量干預(yù)。歷經(jīng)多年建設(shè)钟鸵，有些優(yōu)秀互聯(lián)網(wǎng)企業(yè)做的很極致钉稍，管理也很到位，效果明顯棺耍。

我們希望通過輕量級的方式和重量級相結(jié)合來實現(xiàn)聚類的準(zhǔn)確性贡未。輕量級的意思是，通過算法和簡化的策略規(guī)則蒙袍，無需過多的前提條件羞秤，快速實現(xiàn)告警事件的聚合。將上述栗子的大量事件左敌，劃分為存儲瘾蛋、數(shù)據(jù)庫、應(yīng)用和不同業(yè)務(wù)矫限。普適性更強哺哼，見效更快～

告警事件之間是存在一定的關(guān)聯(lián)性的，將一組類似的有關(guān)系的事件聚合在一起就是一個場景叼风。以場景為單位去實現(xiàn)團隊的分派/協(xié)作取董，最終解決問題，而不是單一事件的逐條解決无宿。在移動化今天茵汰，有什么事，臨時拉個討論組/微信群孽鸡，一起討論和解決問題;場景與此類似蹂午。

利用人工智能無監(jiān)督學(xué)習(xí)技術(shù)，結(jié)合自然語言處理 NLP彬碱，我們從內(nèi)容相似性豆胸、相關(guān)性進行數(shù)據(jù)挖掘和學(xué)習(xí)。

內(nèi)容相似性巷疼，一名普通工程師一眼就能看清楚 MySQL Slave1 和 Slave2 的相似性晚胡，然而程序和計算機能夠理解這事就有點困難了。幸運的是，我們利用在降噪過程中我們建立的專業(yè)語料庫估盘，能夠識別出當(dāng)下相似告警瓷患，將符合相似度(如80%)的事件聚合在一起。

時間相關(guān)性遣妥，這個可能會好理解一些擅编，就是根據(jù)事件發(fā)生的時間差，在一瞬間爆發(fā)的大量事件是存在一定關(guān)聯(lián)性的燥透，特別是開篇的那個栗子沙咏。然而由于監(jiān)控工具的數(shù)據(jù)采集問題，現(xiàn)實的事件并不是嚴(yán)格的按照時間序列過來的班套，例如業(yè)務(wù)故障和存儲故障肢藐，從直覺角度上看，應(yīng)該是存儲故障先發(fā)生吱韭，之后才影響業(yè)務(wù)吆豹。實際上，兩者的事件時間有可能是相反的理盆。

通過算法痘煤，在沒有過多的前提條件下，實現(xiàn)將相似相關(guān)事件聚合稱為一個場景猿规。

與降噪一樣衷快，算法應(yīng)該跟上下文和環(huán)境相關(guān)，所以未來在聚類的方面可以做的更深入姨俩，更重量級蘸拔。

識別根源

在現(xiàn)在為止，我們通過降噪將事件從數(shù)千數(shù)萬降低為數(shù)百數(shù)十环葵，聚類降低為數(shù)類數(shù)十调窍。到此為止基本上能夠更高效的處理問題，然而张遭，我們總是期望能夠定位到根源邓萨，甄別是那些異常引發(fā)的，快速識別根因是所有IT支撐工程師的追求菊卷。找到標(biāo)靶缔恳，拉弓射箭，中靶的烁，一氣呵成褐耳。

現(xiàn)實是很困難，如果想100%的確定根因渴庆，必須對 IT 環(huán)境的每個環(huán)節(jié)和設(shè)施進行管理，并建立數(shù)據(jù)模型。在當(dāng)今的規(guī)慕罄祝化刃滓、虛擬化、微服務(wù)化情況下耸弄，這是很困難的事情咧虎。

所以往往依賴于有經(jīng)驗的工程師進行分析和判斷，如果在跨職責(zé)计呈、跨業(yè)務(wù)砰诵、跨團隊的時候，就需要多個不同領(lǐng)域的專家工程師去診斷和分析了捌显。

借助人工智能算法茁彭，通過有監(jiān)督的訓(xùn)練方式，通過歷史和人為標(biāo)注的數(shù)據(jù)扶歪。工程師每一次的根源識別理肺，都可以作為機器學(xué)習(xí)訓(xùn)練的素材。隨著時間的推移善镰，診斷標(biāo)注的根源數(shù)據(jù)積累越多妹萨，機器就能夠準(zhǔn)確的識別出因果關(guān)系，根源識別也越來越準(zhǔn)確炫欺。

前文的栗子中乎完，如果有類似歷史數(shù)據(jù)，并且完成人工標(biāo)注品洛，那么再次發(fā)生的時候树姨，我們就可以判斷存儲或者是網(wǎng)絡(luò)故障是根因，可能性85%毫别。

通過人工智能方式娃弓，逐漸的擺脫嚴(yán)重依賴專家工程師的模式，讓運營支撐系統(tǒng)成為一個能夠自我學(xué)習(xí)和進化的智能系統(tǒng)岛宦。

決策支持

識別場景台丛，甄選根因后，我們基本上就可以著手解決問題砾肺。在處理問題的過程中挽霉，會出現(xiàn)一個知識傳遞的問題。例如有經(jīng)驗的工程師和新入職的工程師的差異变汪，其實這就是一個集體知識共享的問題侠坎。

以往大多團隊會使用 Wiki 或者是別的工具建立知識庫，人工編輯文章和處理預(yù)案裙盾。以方便工程師參考借鑒实胸，但是也有很多團隊沒有建立起共享知識庫他嫡。

我們通過人工智能的方式做了一些嘗試，讓整個事件(告警)處理更流暢起來庐完。場景歷史推薦钢属，對于新發(fā)生的場景，如果以前有類似的場景门躯，系統(tǒng)會推薦出來淆党，如在上個月有一個類似的故障，相似度80%讶凉，也是一個存儲類故障染乌。通過查看歷史場景的解決方案/過程，幫助我們做決策懂讯，可以快速的復(fù)用歷史知識荷憋。整個過程中，人工智能自動學(xué)習(xí)和推薦域醇，告別人工手動編輯知識文檔的方式台谊。

隨著時間的推移，系統(tǒng)越發(fā)智能譬挚，信息積累越多锅铅，也會持續(xù)反復(fù)使用。

小結(jié)

AIOps 的應(yīng)用和實踐會越來越多减宣，我們有理由相信人工智能技術(shù)盐须，會對 IT 運營支撐產(chǎn)生極大的影響力。

OneAlert 在該領(lǐng)域的探索還屬于入門級漆腌，然而我們也迫不及待和大家分享贼邓。我們將發(fā)布 OneAlert AI 版，這應(yīng)該是國內(nèi)鮮見闷尿、SaaS 模式的人工智能事件處理平臺∷芫叮現(xiàn)在開始對新老用戶開放內(nèi)測 www.onealert.com，歡迎大家一起探索填具。

隨著更多的用戶對人工智能的了解應(yīng)用统舀，相信不久的將來，正如?Gartner?說的劳景，未來將有50%的企業(yè)使用 AIOps 方式運營支撐誉简，人工智能對企業(yè) IT 運營效率的提升和變革，也將促進這些企業(yè)的商業(yè)發(fā)展提速盟广。

未來已來闷串。

OneAlert?是北京藍海訊通科技股份有限公司旗下產(chǎn)品，是國內(nèi)首個?SaaS?模式的云告警平臺筋量，集成國內(nèi)外主流監(jiān)控/支撐系統(tǒng)烹吵，實現(xiàn)一個平臺上集中處理所有 IT 事件碉熄，提升 IT 可靠性。想了解更多信息年叮，請訪問?OneAlert?官網(wǎng) 具被，歡迎免費注冊體驗 玻募。

來源：http://blog.oneapm.com/apm-tech/824.html