寫在最前
文中所提及的事件並不僅限於故障，還包括運維工作中的告警、異常等。
"An incident is an unplanned interruption to an IT Service or a reduction in the Quality of an IT Service." Source: Incident Management -ITIL
一、背景
在《AIOps在美團的探索與實踐——故障發現篇》一文中，我們探討了AIOps在異常檢測的實踐。Horae（美團AIOps平臺）在單時序異常檢測方面已有較多積累，智能告警功能作為底層能力支撐了監控系統和異常檢測場景。服務運維團隊在此基礎上開展AIOps在事件管理領域的相關工作，本文主要分享過去兩年的探索與實踐，希望能對大傢有所幫助或啟發。
事件管理的復雜性體現在兩個方面：
1.數據繁多
- 數據多樣化：運維工作需要各種類型的數據來識別、診斷、處理問題，包括告警、鏈路、指標、日志、變更（含發版）等。
- 數據實時性強、關系復雜：運維數據通常需要實時采集和處理。這些數據之間的關系錯綜復雜，如鏈路數據與告警數據、指標數據與日志數據等可能存在密切的關聯，需要精細的統一處理。
- 領域知識強：運維領域涉及的知識廣泛，包括網絡、硬件、系統、數據庫、應用等多個層面，業務運維更需要不同的領域知識，這對運維人員和運維工具提出了較高的要求。
2.流程復雜
事件管理的時間線如下，每個環節都需要提效才能達成事件管理的效率提升。
圖1 事件管理時間線
面對上述挑戰，美團運維團隊在過去幾年建設了豐富的工具體系，基於專傢經驗、規則配置、流程管控等方式進行事件管理。本文聚焦的AIOps實踐，是對上述工作的賦能，可拆解為四個模塊：
- 風險預防——變更風險智能檢測：以用戶和實體為對象，結合規則以及機器學習模型，對用戶行為進行分析和異常檢測。
- 故障發現——智能識別指標異常：基於統計算法和機器學習算法識別指標的異常模式，幫助用戶快速發現故障。
- 事件處理——診斷和預案推薦：通過多模態數據和算法規則引擎來幫助用戶快速定位故障，推薦止損預案。
- 事件運營——相似故障推薦：基於NLP技術推薦相似故障復盤，挖掘共性問題。
二、事件管理中AI能力總覽
AIOps在事件管理領域中的能力框架如下：
圖2 AIOps事件管理領域能力框架
三、AIOps之事件管理場景
1.事前預防
1）風險識別
變更檢測分成前、中、後三個階段。變更前風險預警的收益相對較高，因為它能夠攔截異常的發生。但由於變更動作尚未發生，變更前檢查所能獲取到的參考信息少，檢測難度比較大。變更中、後檢測可以參考灰度組的變化情況以及是否有異常指標的出現，檢測的參考信息更多，準確度更高。我們和MCM-線上變更管理平臺（美團變更管控系統，後文簡稱MCM）合作，共同探索了對變更前、變更中和變更後的一些異常進行檢測與識別。
①變更前
配置變更風險的檢測和識別。當用戶進行配置變更時，我們會進行配置項變更風險檢查。我們根據該配置項的歷史合法變更數據挖掘出該配置項的約束規則，對當前變更值進行風險檢測。約束項包括結構文本合法性、分隔符合法性、前後結構一致性等風險規則。
②變更中/後
當灰度變更時部分系統指標會變化，比如集群中灰度機器的QPS、4XX、5XX指標可能會因為變更發生變化。系統需要識別出因為錯誤變更而導致的異常，屏蔽灰度變更影響導致的異常。
我們需要註意，如果直接采用全量未變更分組進行參考組對待檢測組進行異常識別，會有一些幹擾和噪聲。同一個集群的機器會由於自身配置、承載流量任務等差異，其機器指標會產生出不同的分佈和聚類情況。將實際差異較大的機器指標作為參考組，會幹擾異常檢測的結果。因此，我們需要篩選出和待檢測指標相近的數據作為參考組，再在類內距離較近的多指標數據中識別出該指標是否符合正常模式。
以灰度變更組的數據為待檢測數據點，以未變更組時序數據、變更歷史時序數據作為參考組進行異常識別。算法思路如下：
- 剔除參考數據的離群序列：找到和檢測數據相近的參考組，再做異常檢測。我們使用優化後的自適應DBSCAN[1]進行聚類，排除參考組的離群時序序列。
- 檢測待檢測數據是否異常：識別待檢測的時序數據在參考組中是否存在異常情況，包括點異常、上下文異常、子序列模式異常等異常特征。
表1 異常集群變更 vs 正常集群變更
該功能已經上線到MCM，用於某核心平臺系統集群變化後的變更復檢。檢測效果效果如下：
圖3 多指標復檢效果圖
當用戶進行集群變更時，會觸發集群維度和機器維度的變更檢查，識別核心指標（QPS、4XX、5XX）是否有一些異常。當指標中存在異常時，指標數據詳細展示區會有額外展示：
- 異常點標記線：檢測異常的時間點上會有紅色的豎線標記。
- 異常項詳細展示區：詳細展示出檢測到異常的服務器主機名、時間點、指標值、與比對基線的偏離情況。
- 標記誤報按鈕：如果發現異常為誤報，可以點擊按鈕進行標記，便於後期算法復盤優化。
2.事中快恢
當故障事件發生後，需要盡可能降低服務的異常對其他用戶的影響，提升服務的可用性。可以從MTTD（平均檢測時間）、MTTT（最短定位時間）、MTTR（平均修復時間）這三個指標入手。
圖4 事件處理手段
1）異常發現
故障發現需要快速、準確。為避免誤報，服務運維團隊開發了一種基於歷史上鄰近的點分佈相似（時序特征相似）思想的智能異常檢測算法。如果當前待檢測點相較其他歷史參考點相對異常（存在點異常或者模式異常），檢測流程會將異常點識別出來，並告知用戶待測指標出現異常現象。
圖5 異常發現能力流程圖
在進行實時檢測流程中，待檢測點會先進入預檢測流程。預檢測組件會攔截絕大多數正常點，而當預檢測異常時，才會執行特征提取階段，進入模型異常分類；同時分類結果通過反饋機制可以增加到樣本集，提高模型泛化能力和精召率。整個算法流程訓練、檢測、反饋閉環。
該項能力為美團監控系統提供無閾值的時序檢測能力。目前檢測流程中的分類器在真實線上樣本的精確率和召回率均在98%以上。團隊會每周定時抽樣核心指標並對檢測結果進行復盤，核心指標的異常檢出準確率在90%左右。
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）相似事件推薦
雷達系統中經常出現相似事件，它們往往有著相似的根因，如同一個業務的促銷活動、某個中間件故障等。如果我們能夠根據當前事件的異常現象，找到歷史上最相似的一些Case推薦給處理人，則能為事件的定位和處理提供參考，提高處理效率。我們實現了一套相似事件推薦算法，通過NLP技術和規則過濾，找到每個事件的Top歷史相似事件並推薦給處理人。算法的整體流程如下：
圖10 相似事件算法流程
整體而言，算法在離線階段使用NLP技術，將每個歷史雷達事件進行向量化並存儲；在實時推薦時，算法將新的雷達事件進行向量化後，通過向量相似度搜索到最接近的歷史事件，並通過一些規則計算的特征進行排序和過濾，得到最終可推薦給用戶的Top相似事件。下面對一些實現細節進行介紹。
①離線訓練階段
- 數據類型區分
一個雷達事件中包含的數據可以分為兩種類型：結構化數據和文本數據。它們主要的區別如下：
表3 事件數據結構
如上表所示，這兩類數據的特點和作用有著很大的不同，且它們的可重復度也不一樣。如果我們把兩類數據都放到一個語料庫中去訓練一個向量化模型，會導致在後續的實時推薦階段中，對於文本數據較多的事件產生“不公平”的現象：由於用戶生成的文本數據的可重復度低，它們之間的相似度“天花板”會遠低於結構化類型的數據，這就意味著一個事件的群聊越豐富，就越不容易找到相似的事件，這不符合我們的預期。
所以我們針對這兩類數據分別構建語料庫，通過文本向量化算法分別得到兩個向量集，以便後續做更精細化的控制。
圖11 事件建模過程
- 分詞&向量化
分詞（Tokenization）是將文檔分解為以字詞為單位的基本要素，方便後續處理。對於雷達事件中的文本類型數據，需要采用分詞器進行分詞，並去除停用詞後得到tokens（即分詞後的詞語列表）；對於結構化字段，則直接提取屬性值或通過一些規則處理得到tokens。
為提升文本分詞效果，預先加載了IT領域詞庫、公司Appkey列表、公共服務名稱作為分詞器的詞庫。經過分詞後，對事件進行詞頻統計，再通過Tfidf算法計算各詞語的權重。Tfidf算法得到的向量長度等於詞庫的大小，向量第i個位置上的值表示詞庫中第i個詞在事件中的權重，計算方式會綜合考慮詞語在當前事件的出現次數和在歷史所有事件中的出現次數：
一個詞語在當前事件中出現得越多，且在越少的歷史事件中出現過，說明它是一個比較關鍵的詞語，Tfidf算法將給予它比較大的權重。
註意，以上公式隻是概念化表示，不是Tfidf算法的實際公式，對於Tfidf算法的具體實現感興趣的讀者可自行搜索了解。我們對事件的結構化數據和文本數據分別經過以上步驟進行處理，每個事件將被用兩個Tfidf向量表征並存儲起來，用於後續在實時推薦階段計算事件相似度。
②實時推薦階段
- 基於向量相似度召回候選事件
在實時推薦階段，我們同樣將新的雷達事件分為結構化和文本類型數據，分別進行分詞並向量化。然後，我們計算它們與歷史事件向量的相似度，得到結構化和文本數據與所有歷史事件的相似度。我們設定不同的閾值來召回候選的歷史相似事件，在實踐中，設定的文本數據相似度閾值要低於結構化數據的相似度。兩類數據召回的相似事件取並集，作為候選的相似事件列表，它們是與當前事件具有一定相似度的歷史事件，量級在1000個以下。
- 基於規則計算特征進行排序
一個歷史事件是否值得推薦給用戶，除了與當前事件的相似度之外，還需要考慮更多的維度，例如事件本身是否具有足夠的文本內容可以參考，以及距離當前事件的時間是否比較接近。為了使值得推薦的事件被展現給用戶，我們對每個候選事件通過規則計算一系列特征，用於後續的排序：
- 文本豐富度：衡量歷史事件的內容質量，其中群聊、通告、反饋等文本數據較豐富的，能夠提供更多關於處理、定位過程的信息，為當前事件的處理提供更多參考。
- 時效性：衡量歷史事件發生時間與當前事件的距離，越臨近當前事件發生時間的歷史事件，參考價值越大。
- 根因匹配度：判斷歷史事件診斷根因是否與當前事件診斷根因一致，如果一致那麼很有可能背後是同一個原因導致的問題。
- 告警匹配度：衡量兩個事件告警列表的相似程度，計算過程中會降低通用兜底類告警的權重，提高具有明確業務含義告警的權重。
以上特征，再加上召回階段已經計算好的結構化數據、文本數據相似度，進行加權求和，得到最終的推薦得分，用於對候選事件進行排序。我們還需要對其進行過濾，去除不希望推薦給用戶的歷史事件。過濾的依據主要包括：對於系統發現事件，告警匹配度需要足夠大，對於人為發現事件，推薦的歷史事件的文本內容需要足夠豐富。
- 關鍵信息提取&用戶展示
為了使用戶能夠更快速地從歷史事件中獲取有效信息輸入，我們從每個待推薦的歷史事件提取出關鍵信息，包括由用戶反饋的歷史事件的根因、解決方案等信息，把這些附在推薦項上，在事件處理過程中推送到群裡，輔助用戶提高事件處理效率。同時，在Web端頁面也會展示Top相似事件列表，以供用戶參考。
案例展示：
表4 相似事件能力結果展示
該功能上線後，有相似事件的Case覆蓋率為70%左右，對於系統發現且有推薦歷史相似事件的Case，其平均故障處理時長比無相似事件的Case縮短28%。為了評估推薦的準確率，我們對有推薦相似事件處理經驗且用戶反饋了真實根因的Case進行了人工復盤，若推薦的歷史事件與當前事件有類似的根因或解決方案，則標記為推薦準確，由此統計得到的推薦準確率約為76%。
在復盤過程中，我們發現，推薦的準確率很大程度上取決於用戶所配置的告警質量，對於粒度較粗的通用兜底類告警（如域名5xx告警）所產生的事件，推薦準確率會低於細粒度的、具有明確業務含義的告警所產生的事件。原因也是顯然的：粗粒度的告警背後的根因可能千差萬別，所以即使一個歷史事件有著同樣的告警，也會有很大可能不是同一個根因導致的故障；而細粒度的告警則與之相反。
在後續的優化中，對於相似事件的排序策略，我們可能需要根據事件中告警的粒度，來調整不同告警類型對於相似度的貢獻大小，而告警的粒度如何衡量，則需要結合公司具體的現狀和我們的經驗判斷。總而言之，在數據驅動的算法之外，需要結合一些專傢知識來彌補數據的不足，從而使算法的輸出更好地服務於用戶。
3.事後運營
在故障事後，用戶對於故障的運營和復盤有利於經驗沉淀，避免相同的問題再次發生，對於穩定性的長期提升有著重要作用。
COE（Correction Of Error）是美團的故障復盤系統，以文本形式記錄了公司大量的歷史故障復盤內容。我們在COE系統中基於主題分析等NLP技術，實現了故障復盤的主題展示和相似推薦能力，旨在幫助用戶找到更多相似的故障，挖掘出共性問題。目前該功能處於初期建設階段，正在迭代和探索的過程中。
四、總結和未來展望
本文簡單介紹了團隊在AIOps在事件管理這一領域的探索和實踐。我們從三個關鍵的運維階段——事前預防、事中處理以及事後運營，深入探討AIOps在這些場景中的具體應用和優勢。
之後我們也會從多個方面進一步探索AIOps在美團場景下的可能性。這裡我們簡單列舉了幾個可能且有價值的發展方向。
1.智能日志檢測
圖12 日志檢測
日志異常檢測通常由四個模塊組成，包括日志收集上報、日志解析、特征提取以及異常檢測器。我們期望通過提取日志的計數、序列、語義等特征，來動態識別當前服務的日志是否存在異常情況，我們計劃從兩個方面進行探索：
- 日志模版時序異常：通過Drain3等日志模版挖掘技術，將服務日志轉化成日志模版時序。基於時序異常檢測算法，可以識別日志模版徒增、異常日志出現等風險點。
- 日志模版語義異常：通過解析日志模版的語義特征，結合機器學習和深度學習算法，識別當前日志是否存在語義異常。
2.智能化變更識別
圖13 配置變更挖掘與識別
對於配置類型的變更（如：分佈式內存配置變更、營銷活動配置變更等），一旦變更人員疏忽填寫錯誤或遺漏，會導致線上問題。同時，這類配置可能數量極其龐大，我們需要去動態分析識別每一配置對應的模型信息。
對於歷史上正常完結沒有回滾的配置變更，根據其變更值進行特征提取，學習該配置的Key、Value變化規律，從統計學、數據建模等多個角度構造每個配置值的特征組。當新變更到來時，就轉化成了特征相似匹配，從而發現人工填寫錯誤的問題。
>>>>
參考資料
- [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算法的數據庫異常監測系統的設計與實現.
作者丨政東、迎港、張霖、俊峰等（美團基礎研發平臺）
來源丨公眾號：美團技術團隊（ID：meituantech）
dbaplus社群歡迎廣大技術人員投稿，投稿郵箱：[email protected]