在《AIOps在美團的探索與實踐——故障發現篇》一文中，我們探討了AIOps在異常檢測的實踐。Horae（美團AIOps平台）在單時序異常檢測方面已有較多積累，智能告警功能作爲底層能力支撐了監控系統和異常檢測場景。服務運維團隊在此基礎上開展AIOps在事件管理領域的相關工作，本文主要分享過去兩年的探索與實踐，希望能對大家有所幫助或啓發。
事件管理的複雜性體現在兩個方面：
數據繁多：
數據多樣化：運維工作需要各種類型的數據來識別、診斷、處理問題，包括告警、鏈路、指標、日志、變更（含發版）等。數據實時性強、關系複雜：運維數據通常需要實時采集和處理。這些數據之間的關系錯綜複雜，如鏈路數據與告警數據、指標數據與日志數據等可能存在密切的關聯，需要精細的統一處理。領域知識強：運維領域涉及的知識廣泛，包括網絡、硬件、系統、數據庫、應用等多個層面，業務運維更需要不同的領域知識，這對運維人員和運維工具提出了較高的要求。流程複雜：
事件管理的時間線如下，每個環節都需要提效才能達成事件管理的效率提升。
面對上述挑戰，美團運維團隊在過去幾年建設了豐富的工具體系，基于專家經驗、規則配置、流程管控等方式進行事件管理。本文聚焦的AIOps實踐，是對上述工作的賦能，可拆解爲四個模塊：
風險預防——變更風險智能檢測：以用戶和實體爲對象，結合規則以及機器學習模型，對用戶行爲進行分析和異常檢測。故障發現——智能識別指標異常：基于統計算法和機器學習算法識別指標的異常模式，幫助用戶快速發現故障。事件處理——診斷和預案推薦：通過多模態數據和算法規則引擎來幫助用戶快速定位故障，推薦止損預案。事件運營——相似故障推薦：基于NLP技術推薦相似故障複盤，挖掘共性問題。2 事件管理中AI能力總覽AIOps在事件管理領域中的能力框架如下：
變更檢測分成前、中、後三個階段。變更前風險預警的收益相對較高，因爲它能夠攔截異常的發生。但由于變更動作尚未發生，變更前檢查所能獲取到的參考信息少，檢測難度比較大。變更中、後檢測可以參考灰度組的變化情況以及是否有異常指標的出現，檢測的參考信息更多，准確度更高。我們和MCM-線上變更管理平台（美團變更管控系統，後文簡稱MCM）合作，共同探索了對變更前、變更中和變更後的一些異常進行檢測與識別。
變更前
配置變更風險的檢測和識別。當用戶進行配置變更時，我們會進行配置項變更風險檢查。我們根據該配置項的曆史合法變更數據挖掘出該配置項的約束規則，對當前變更值進行風險檢測。約束項包括結構文本合法性、分隔符合法性、前後結構一致性等風險規則。
變更中/後
當灰度變更時部分系統指標會變化，比如集群中灰度機器的QPS、4XX、5XX指標可能會因爲變更發生變化。系統需要識別出因爲錯誤變更而導致的異常，屏蔽灰度變更影響導致的異常。
我們需要注意，如果直接采用全量未變更分組進行參考組對待檢測組進行異常識別，會有一些幹擾和噪聲。同一個集群的機器會由于自身配置、承載流量任務等差異，其機器指標會産生出不同的分布和聚類情況。將實際差異較大的機器指標作爲參考組，會幹擾異常檢測的結果。因此，我們需要篩選出和待檢測指標相近的數據作爲參考組，再在類內距離較近的多指標數據中識別出該指標是否符合正常模式。
以灰度變更組的數據爲待檢測數據點，以未變更組時序數據、變更曆史時序數據作爲參考組進行異常識別。算法思路如下：
剔除參考數據的離群序列：找到和檢測數據相近的參考組，再做異常檢測。我們使用優化後的自適應DBSCAN[1]進行聚類，排除參考組的離群時序序列。檢測待檢測數據是否異常：識別待檢測的時序數據在參考組中是否存在異常情況，包括點異常、上下文異常、子序列模式異常等異常特征。
表1 異常集群變更 vs 正常集群變更該功能已經上線到MCM，用于某核心平台系統集群變化後的變更複檢。檢測效果效果如下：
圖3 多指標複檢效果圖當用戶進行集群變更時，會觸發集群維度和機器維度的變更檢查，識別核心指標（QPS、4XX、5XX）是否有一些異常。當指標中存在異常時，指標數據詳細展示區會有額外展示：
異常點標記線：檢測異常的時間點上會有紅色的豎線標記。異常項詳細展示區：詳細展示出檢測到異常的服務器主機名、時間點、指標值、與比對基線的偏離情況。標記誤報按鈕：如果發現異常爲誤報，可以點擊按鈕進行標記，便于後期算法複盤優化。| 3.2 事中快恢當故障事件發生後，需要盡可能降低服務的異常對其他用戶的影響，提升服務的可用性。可以從MTTD（平均檢測時間）、MTTT（最短定位時間）、MTTR（平均修複時間）這三個指標入手。
圖4 事件處理手段3.2.1 異常發現故障發現需要快速、准確。爲避免誤報，服務運維團隊開發了一種基于曆史上鄰近的點分布相似（時序特征相似）思想的智能異常檢測算法。如果當前待檢測點相較其他曆史參考點相對異常（存在點異常或者模式異常），檢測流程會將異常點識別出來，並告知用戶待測指標出現異常現象。
圖5 異常發現能力流程圖在進行實時檢測流程中，待檢測點會先進入預檢測流程。預檢測組件會攔截絕大多數正常點，而當預檢測異常時，才會執行特征提取階段，進入模型異常分類；同時分類結果通過反饋機制可以增加到樣本集，提高模型泛化能力和精召率。整個算法流程訓練、檢測、反饋閉環。
該項能力爲美團監控系統提供無阈值的時序檢測能力。目前檢測流程中的分類器在真實線上樣本的精確率和召回率均在98%以上。團隊會每周定時抽樣核心指標並對檢測結果進行複盤，核心指標的異常檢出准確率在90%左右。
3.2.2 根因診斷在事件處理階段，事件根因的自動定位可以大幅度降低定位時間（MTTT），幫助用戶快速處理事件。由于美團現有系統規模極其龐大且複雜，因此不能用一種簡單的定位方式來涵蓋所有的錯誤根因。我們從多個方面來定位故障根因，包括鏈路異常、日志堆棧異常、服務異常等故障場景。這裏我們將從兩個方面來探討根因定位的探索和實踐。
異常鏈路拓展
雷達系統是美團的統一的事件管理平台，用于高效處理告警、事件和故障，同時也提供對公司內微服務系統的根因定位能力（後文簡稱爲雷達）。識別微服務系統中的故障鏈路是重要且具有挑戰性的工作，根據服務的調用情況構建服務調用圖，並通過異常檢測進行擴展和剪枝，以獲得准確的異常鏈路圖。拓撲圖過大或過小都不利于根因定位。鏈路異常檢測工作有如下要求：
實時性高：由于服務調用實時變化，異常計算工作不能過于耗時，過長的滯後結果將會導致拓撲圖更新的延遲，異常檢測沒有價值。計算量大：美團每分鍾産生幾十萬級別的鏈路數據，並且每一種鏈路數據都包含調用次數、TP耗時等關鍵指標。精召率高：我們需要准確識別出當前鏈路是否存在異常，精准識別可以防止拓撲爆炸或者根因節點缺失。爲了解決以上問題，我們和數據庫平台研發組合作，研發了一套基于預訓練的大容量異常檢測服務來進行鏈路異常檢測，其具有大容量，低時延，准確率高的特點。算法使用了曆史長時序來挖掘時序特征參數，並在實時檢測中參考臨近120分鍾進行了波動過濾，可以在較短的時間內快速識別指標的異常程度，實現了每分鍾百萬級別的異常檢測。整體檢測的平均流程耗時在1.5-3ms，檢測的異常點精確率在81%，異常點召回率在82%，F1值爲81%。
圖6 百萬級別異常檢測能力框架圖我們使用編排好的訓練流程對單指標進行單模型參數建模，存放到離線模型數據庫中。在實時檢測過程中從數據庫中加載對應的預訓練參數，根據檢測流程進行實時監測。
該工作的核心思想是：將大量的複雜的計算異步化，在實時流檢測的過程中，大幅度降低實時浮點計算量，提高整體的計算容量。該項工作對接了雷達鏈路中的流量和TP線的識別，支持雷達在故障診斷的過程中，獲取異常節點與鄰接節點之間的調用量、耗時的波動，來獲取准確的故障全景圖，並獲取節點間調用異常的准確情況。
圖7 鏈路拓撲異常計算異常拓撲圖效果如下圖所示，雷達鏈路的拓展根據流量異常、失敗率上漲、耗時等多個方面進行拓展，可以有效地找到核心故障鏈路圖：
圖8 雷達異常鏈路指標多維度根因定位
大盤有一部分是多維度的指標，由于其業務特性比較強，這些指標波動很難用通用系統指標進行異常定位。我們目前探索了從指標自身維度的異常特征來進行異常維度定位的工作。
總的KPI指標異常，需要處理人員人工下鑽到不同維度分析。如果指標的維度較多，人工分析成本巨大。該項工作的困難和挑戰有以下兩個方面。
首先，不同的組合的KPI是相互依賴和影響的，真正的根因元素的KPI異常，可導致其他維度的KPI也發生變化，很難對KPI指標的根因做一個量化的判斷。其次，由于KPI擁有多維度的屬性，因此隨著維度的增加或粒度的細化，元素的數目往往呈現指數級增長的趨勢，可能需要從成千上萬的多維屬性空間進行搜索；此外，對如此多的維度快速做預測也是一個挑戰。在算法的應用場景中，我們需要考慮算法的可落地性。什麽時候觸發、如何提升結果的准確度、有效性是我們需要解決的問題。
圖9 指標異常維度定位流程圖上圖是我們執行異常維度定位的簡易流程，我們在Squeeze2的基礎上針對美團業務特性做了優化， 其具有以下特點：
自動化框定檢測時間範圍：使用變點檢測等算法自動框定時間區間，用戶無需人工框定所需要的檢測時間區間即可自動化的進行異常維度定位操作，並且該項工作提高了下鑽的性能和准確度。多時間戳下鑽，定位結果彙總：爲了減少因爲單點抖動而産生的錯誤下鑽，提高算法的精確度，通過多時間戳的方式並行下鑽分析，然後根據各個指標的不同特征，區分彙總結果，提高結果的可用性。裁剪非關鍵根因，減少幹擾維度的影響：對于最後的根因維度，會計算每一個子維度的整體重要占比，裁剪非重要根因，減少無意義維度帶來的幹擾。將下鑽的根因編碼解析，提高定位結果的可讀性。結果展示
當核心大盤指標出現異常時，系統就會自動觸發下鑽分析，將異常維度的分析結果推送到群裏，幫助用戶快速定位該指標的異常維度是什麽。
表2 告警與異常維度定位3.2.3 相似事件推薦雷達系統中經常出現相似事件，它們往往有著相似的根因，如同一個業務的促銷活動、某個中間件故障等。如果我們能夠根據當前事件的異常現象，找到曆史上最相似的一些Case推薦給處理人，則能爲事件的定位和處理提供參考，提高處理效率。我們實現了一套相似事件推薦算法，通過NLP技術和規則過濾，找到每個事件的Top曆史相似事件並推薦給處理人。算法的整體流程如下：
圖10 相似事件算法流程整體而言，算法在離線階段使用NLP技術，將每個曆史雷達事件進行向量化並存儲；在實時推薦時，算法將新的雷達事件進行向量化後，通過向量相似度搜索到最接近的曆史事件，並通過一些規則計算的特征進行排序和過濾，得到最終可推薦給用戶的Top相似事件。下面對一些實現細節進行介紹。
離線訓練階段
1）數據類型區分
一個雷達事件中包含的數據可以分爲兩種類型：結構化數據和文本數據。它們主要的區別如下：
表3 事件數據結構如上表所示，這兩類數據的特點和作用有著很大的不同，且它們的可重複度也不一樣。如果我們把兩類數據都放到一個語料庫中去訓練一個向量化模型，會導致在後續的實時推薦階段中，對于文本數據較多的事件産生“不公平”的現象：由于用戶生成的文本數據的可重複度低，它們之間的相似度“天花板”會遠低于結構化類型的數據，這就意味著一個事件的群聊越豐富，就越不容易找到相似的事件，這不符合我們的預期。
所以我們針對這兩類數據分別構建語料庫，通過文本向量化算法分別得到兩個向量集，以便後續做更精細化的控制。
圖11 事件建模過程2）分詞&向量化
分詞（Tokenization）是將文檔分解爲以字詞爲單位的基本要素，方便後續處理。對于雷達事件中的文本類型數據，需要采用分詞器進行分詞，並去除停用詞後得到tokens（即分詞後的詞語列表）；對于結構化字段，則直接提取屬性值或通過一些規則處理得到tokens。
爲提升文本分詞效果，預先加載了IT領域詞庫、公司Appkey列表、公共服務名稱作爲分詞器的詞庫。經過分詞後，對事件進行詞頻統計，再通過Tfidf算法計算各詞語的權重。Tfidf算法得到的向量長度等于詞庫的大小，向量第i個位置上的值表示詞庫中第i個詞在事件中的權重，計算方式會綜合考慮詞語在當前事件的出現次數和在曆史所有事件中的出現次數：
詞權重詞在當前事件中的出現次數詞在多少個曆史事件中出現一個詞語在當前事件中出現得越多，且在越少的曆史事件中出現過，說明它是一個比較關鍵的詞語，Tfidf算法將給予它比較大的權重。注意，以上公式只是概念化表示，不是Tfidf算法的實際公式，對于Tfidf算法的具體實現感興趣的讀者可自行搜索了解。我們對事件的結構化數據和文本數據分別經過以上步驟進行處理，每個事件將被用兩個Tfidf向量表征並存儲起來，用于後續在實時推薦階段計算事件相似度。
實時推薦階段
1）基于向量相似度召回候選事件
在實時推薦階段，我們同樣將新的雷達事件分爲結構化和文本類型數據，分別進行分詞並向量化。然後，我們計算它們與曆史事件向量的相似度，得到結構化和文本數據與所有曆史事件的相似度。我們設定不同的阈值來召回候選的曆史相似事件，在實踐中，設定的文本數據相似度阈值要低于結構化數據的相似度。兩類數據召回的相似事件取並集，作爲候選的相似事件列表，它們是與當前事件具有一定相似度的曆史事件，量級在1000個以下。
2）基于規則計算特征進行排序
一個曆史事件是否值得推薦給用戶，除了與當前事件的相似度之外，還需要考慮更多的維度，例如事件本身是否具有足夠的文本內容可以參考，以及距離當前事件的時間是否比較接近。爲了使值得推薦的事件被展現給用戶，我們對每個候選事件通過規則計算一系列特征，用于後續的排序：
文本豐富度：衡量曆史事件的內容質量，其中群聊、通告、反饋等文本數據較豐富的，能夠提供更多關于處理、定位過程的信息，爲當前事件的處理提供更多參考。時效性：衡量曆史事件發生時間與當前事件的距離，越臨近當前事件發生時間的曆史事件，參考價值越大。根因匹配度：判斷曆史事件診斷根因是否與當前事件診斷根因一致，如果一致那麽很有可能背後是同一個原因導致的問題。告警匹配度：衡量兩個事件告警列表的相似程度，計算過程中會降低通用兜底類告警的權重，提高具有明確業務含義告警的權重。以上特征，再加上召回階段已經計算好的結構化數據、文本數據相似度，進行加權求和，得到最終的推薦得分，用于對候選事件進行排序。我們還需要對其進行過濾，去除不希望推薦給用戶的曆史事件。過濾的依據主要包括：對于系統發現事件，告警匹配度需要足夠大，對于人爲發現事件，推薦的曆史事件的文本內容需要足夠豐富。
3）關鍵信息提取&用戶展示
爲了使用戶能夠更快速地從曆史事件中獲取有效信息輸入，我們從每個待推薦的曆史事件提取出關鍵信息，包括由用戶反饋的曆史事件的根因、解決方案等信息，把這些附在推薦項上，在事件處理過程中推送到群裏，輔助用戶提高事件處理效率。同時，在Web端頁面也會展示Top相似事件列表，以供用戶參考。
案例展示：
表4 相似事件能力結果展示該功能上線後，有相似事件的Case覆蓋率爲70%左右，對于系統發現且有推薦曆史相似事件的Case，其平均故障處理時長比無相似事件的Case縮短28%。爲了評估推薦的准確率，我們對有推薦相似事件處理經驗且用戶反饋了真實根因的Case進行了人工複盤，若推薦的曆史事件與當前事件有類似的根因或解決方案，則標記爲推薦准確，由此統計得到的推薦准確率約爲76%。
在複盤過程中，我們發現，推薦的准確率很大程度上取決于用戶所配置的告警質量，對于粒度較粗的通用兜底類告警（如域名5xx告警）所産生的事件，推薦准確率會低于細粒度的、具有明確業務含義的告警所産生的事件。原因也是顯然的：粗粒度的告警背後的根因可能千差萬別，所以即使一個曆史事件有著同樣的告警，也會有很大可能不是同一個根因導致的故障；而細粒度的告警則與之相反。
在後續的優化中，對于相似事件的排序策略，我們可能需要根據事件中告警的粒度，來調整不同告警類型對于相似度的貢獻大小，而告警的粒度如何衡量，則需要結合公司具體的現狀和我們的經驗判斷。總而言之，在數據驅動的算法之外，需要結合一些專家知識來彌補數據的不足，從而使算法的輸出更好地服務于用戶。
| 3.3 事後運營在故障事後，用戶對于故障的運營和複盤有利于經驗沉澱，避免相同的問題再次發生，對于穩定性的長期提升有著重要作用。
COE（Correction Of Error）是美團的故障複盤系統，以文本形式記錄了公司大量的曆史故障複盤內容。我們在COE系統中基于主題分析等NLP技術，實現了故障複盤的主題展示和相似推薦能力，旨在幫助用戶找到更多相似的故障，挖掘出共性問題。目前該功能處于初期建設階段，正在叠代和探索的過程中。
4 總結和未來展望本文簡單介紹了團隊在AIOps在事件管理這一領域的探索和實踐。我們從三個關鍵的運維階段——事前預防、事中處理以及事後運營，深入探討AIOps在這些場景中的具體應用和優勢。
之後我們也會從多個方面進一步探索AIOps在美團場景下的可能性。這裏我們簡單列舉了幾個可能且有價值的發展方向。| 智能日志檢測
圖12 日志檢測日志異常檢測通常由四個模塊組成，包括日志收集上報、日志解析、特征提取以及異常檢測器。我們期望通過提取日志的計數、序列、語義等特征，來動態識別當前服務的日志是否存在異常情況，我們計劃從兩個方面進行探索：
日志模版時序異常：通過Drain3等日志模版挖掘技術，將服務日志轉化成日志模版時序。基于時序異常檢測算法，可以識別日志模版徒增、異常日志出現等風險點。
日志模版語義異常：通過解析日志模版的語義特征，結合機器學習和深度學習算法，識別當前日志是否存在語義異常。| 智能化變更識別
圖13 配置變更挖掘與識別對于配置類型的變更（如：分布式內存配置變更、營銷活動配置變更等），一旦變更人員疏忽填寫錯誤或遺漏，會導致線上問題。同時，這類配置可能數量極其龐大，我們需要去動態分析識別每一配置對應的模型信息。
對于曆史上正常完結沒有回滾的配置變更，根據其變更值進行特征提取，學習該配置的Key、Value變化規律，從統計學、數據建模等多個角度構造每個配置值的特征組。當新變更到來時，就轉化成了特征相似匹配，從而發現人工填寫錯誤的問題。5 本文作者政東、迎港、張霖、俊峰等，均來自美團基礎研發平台。6 參考文獻[1] Ester M, Kriegel H P, Sander J, et al. A Density-Based Algorithm for Discovering Clusters in Large Spatial Databases with Noise. AAAI Press. 1996.[2] Li Z, Pei D, Luo C, et al. Generic and Robust Localization of Multi-dimensional Root Causes. 2019 IEEE 30th International Symposium on Software Reliability Engineering (ISSRE), IEEE. 2019.[3] He P, Zhu J, Zheng Z, et al. Drain: An Online Log Parsing Approach with Fixed Depth Tree. 2017 IEEE International Conference on Web Services (ICWS), IEEE. 2017.[4] M Du, F Li. Spell: Streaming Parsing of System Event Logs. 2016 IEEE 16th International Conference on Data Mining (ICDM). 2016.[5] IBM. Drain3. https://github.com/IBM/Drain3[6] Akiko A. An information-theoretic perspective of tf–idf measures. Information Processing and Management. 2003.[7] David B, Andrew Ng, Michael J. Latent Dirichlet Allocation. Journal of Machine Learning Research. 2003.[8] 曹臻, 威遠. 基于AI算法的數據庫異常監測系統的設計與實現.---------- END ----------
本文由高可用架構轉載。技術原創及架構實踐文章，歡迎通過公衆號菜單「聯系我們」進行投稿
