智能運維繫列專題簡介：智能運維（AIOps），根據Gartner的最新闡釋，意指整合大數據和機器學習能力，通過鬆耦合、可擴展方式去提取和分析數據量（volume）、種類（variety）和速度（velocity）這三個維度不斷增長的IT數據，進而爲IT運維管理產品提供支撐。在此，微衆銀行智能運維團隊根據一線工作的實踐經驗與心得體會，特別撰寫了《智能運維繫列》文章，敬請持續關注。
點擊回顧：智能運維繫列（二）| 智能化監控領域探索
點擊回顧：智能運維繫列（三）| 淺析智能異常檢測——“慧識圖”核心算法
點擊回顧：智能運維繫列（四）| 曝光交易路徑
作爲中國首家開業的民營銀行和互聯網銀行，微衆銀行近年來業務發展非常迅速，海量客戶和交易使IT系統的輕微抖動就可能影響衆多用戶金融交易體驗。爲了保證業務正常運轉，全面提升MTBF(平均故障間隔)和MTTR(平均故障修復時間)這兩個數字化運維的關鍵指標，除了需要迅速檢測出異常，還需要快速、準確、有效地分析出異常的根因，迅速恢復。爲了實現這一目標，微衆銀行運維團隊在智能根因分析方面付諸了長期的努力，研發出了智能根因分析系統。目前基於該系統的根因分析準確率穩定維持在80%左右。下文將具體闡述該系統的設計理念。
數據基礎
“不積跬步，無以至千里；不積小流，無以成江海”。不論是人類專家或者是計算機，在進行分析、推理、決策時都需要數據的支撐。因此數據的準確性、及時性和完整性在根因分析中非常重要。在實現智能根因分析的道路上沒有捷徑，基於配置管理系統的IT運維繫統羣爲其提供了堅實的數據基礎。長期投入IT基礎工程的研發，構建了較爲完整的運維體系，在此基礎上開始了智能化運維實踐，接下來簡單介紹根因分析主要應用到的數據。
配置數據
配置數據主要從CMDB（配置管理）系統獲取。CMDB系統是衆多運維工程師較爲熟悉的系統，它包含了配置項全生命週期的信息以及配置項之間的關係(包括物理關係、邏輯關係和依賴關係)。從圖1可以看出，從業務層到基礎架構層，配置項與配置項間的關聯關係都完整保存在配置管理系統內。智能根因分析可以從中獲取到關聯配置數據進行相關性分析。
日誌
日誌主要包括WEMQ日誌、業務流水日誌和應用日誌。WEMQ日誌是微衆銀行研發的消息總線系統所產生的日誌，微衆銀行的系統間調用基本都要通過WEMQ系統來完成。業務流水日誌是業務模塊輸出的日誌（格式化的業務交易日誌），它的內容跟產品和場景息息相關，記錄了業務相關的信息。應用日誌是應用程序輸出的日誌，包括一些異常堆棧信息。通過WEMQ消息的日誌，我們可以分析出每一筆交易所經過的子系統及其調用情況，如下圖所示：
告警
監控系統可以說是IT運維的生命線，它集中採集了業務和基礎架構相關的指標數據，並支持指標的實時計算，通過監控策略可以從這些指標或用戶上報的數據中發現異常並生成告警，爲IT運維的故障診斷提供了完整的數據支持。
監控系統提供了兩部分的數據用於智能根因分析：一部分是實時採集的時間序列數據，即指標數據；另一部分是基於指標計算或者其他第三方系統上報的告警信息。
變更
變更系統提供了數據庫、系統版本發佈、主機、網絡等一系列的變更操作和記錄，所有的運維操作都要求必須在該系統上完成，因此該系統記錄了內部全量的變更數據。基於這些變更數據，智能根因分析系統能夠獲取到跟異常相關的運維操作數據，並結合其他數據來進行根因定位。
技術選擇
在根因分析技術的選擇上，我們初期進行了探討和調研。在異常檢測方面，我們採用了深度學習、機器學習等技術，取得了不錯的效果。但在根因分析方面，我們決定先採用專家系統的技術來實現，主要有以下原因：
首先，“業務異常”的數據是“小數據”。正常的公司運營過程中，真正影響業務的異常事件數據本身就會很少，數據累積的速度會很慢。在“小數據”的基礎上，機器學習在根因分析方面的應用相對有限。
其次，“根因分析”是需要有較強的解釋性的，每次業務異常後，運維工程師都會有完整的異常事件分析報告，機器學習在可解釋性上相對較弱，而專家系統能更好的解釋根因是如何分析出來的，更符合人類的思考邏輯。
最後，利用人類專家“舉一反三”的能力，可以短期內構建出根因分析系統。
因此我們先選擇了專家系統的解決方案，將IT專家的經驗總結起來形成推導規則。
專家系統和知識圖譜
早期我們採用Drools規則引擎實現了基於規則的根因分析系統，通過不斷豐富和完善推導規則，很快就使其具備了根因分析的能力。但在應用一段時間後，發現這個方案還存在不足的地方。主要有兩個方面：
首先是數據不透明。每一次異常發生過後，我們都需要檢視根因分析是否正確。如果根因正確，那麼就需要向團隊內同步是基於什麼樣的數據和推理邏輯推導出根因的；如果根因錯誤，則需要檢視是否存在數據缺失、推導規則錯誤等問題。團隊把這一類工作叫做案例覆盤。覆盤就需要依賴當時獲取到的異常數據來開展，原先我們把數據都放在TDSQL內，彼此之間相互不關聯，所以覆盤時這些數據都是碎片化的，數據透明程度差，覆盤也相對困難。後來引入了圖數據庫，將異常數據以知識圖譜的方式來存儲，即方便查詢，也方便展示。
最後是規則維護困難。在根因分析系統早期版本的時候，推理模塊是採用了Drools來實現的規則引擎，雖然它解決了知識和代碼的耦合問題，但規則越來越多以後，從單個規則來看也很難看出整體的推導邏輯，維護起來相對困難。經過調整，我們在圖數據庫的基礎上，按照不同的異常類型編寫了推導模型，通過模型就可以在圖數據庫中找到根因。這樣只需要維護好模型即可，降低了規則的維護難度。
根因分析設計
根因分析的總體思路是在異常事件發生時，系統收集信息並生成該異常事件的知識圖譜，在圖的基礎上運用演繹推理和歸納推理等方法來對事件根因進行分析。簡單理解就是圖 + 統計 + 規則。根因分析將針對四種指標類型的異常：時延、交易量、業務成功率、系統成功率，再經過三個步驟的處理和分析：信息收集、根因定位、根因補充，最終分析出根因。從這個思路來看，異常事件的知識圖譜如何設計，是我們根因分析設計的關鍵。接下來將詳細介紹該設計，進而闡述根因分析設計的細節。
異常事件的知識圖譜設計
異常事件的知識圖譜是結合“動”態和“靜”態數據來設計，“動”態數據包括業務流水相關的日誌、證據數據，“靜”態數據則來自於CMDB等配置系統。兩類數據共同構建起一個完整的異常事件圖譜。如下圖所示，從圖上可以看出，圖譜是有方向的，從左到右進行根因的分析和推導，最終分析出根因。
一般來說，知識圖譜設計及根因分析一般包括信息收集、根因定位、根因補充三個階段。
首先是信息收集階段，該階段將收集用於構建知識圖譜的完整信息，主要收集以下幾個維度的信息：
1、事件：異常事件的起點，包含了異常事件的相關信息，例如事件的開始時間等。
2、指標：產品的關鍵指標，我們選擇了四種類型的指標作爲黃金指標，用於檢測產品業務是否異常，每個場景都有其對應的黃金指標，其中包括：
（1）交易量：單位時間內的交易筆數。
（2）業務成功率：單位時間內的業務成功率，業務失敗時該指標會下降。業務失敗是指符合業務邏輯的失敗，例如驗證碼未通過。
（3）系統成功率：單位時間內的系統成功率，系統失敗時該指標會下降。系統失敗時指系統內部的失敗，例如連接數據庫異常。
（4）時延：單位時間內完成交易的總耗時時間。
3、業務流水：用戶在產品上操作所產生的編號，每一次操作都會產生一個唯一的編號，也稱爲一筆交易。這個編號可以關聯出業務日誌和實時樹日誌（WEMQ日誌）。
4、業務流水日誌：每個系統按照規範打印的業務相關日誌，可以從中查到具體的業務參數和相關調用信息。除了業務相關的信息外，日誌中還有交易發生的子系統、主機、DCN等信息。
5、實時樹日誌：之前提到的WEMQ日誌，可以將交易的完整調用路徑分析出來，其中還有經過的主機、耗時等明細數據。
其次是根因定位階段，該階段根據收集到的日誌數據，對交易進行統計分析，並定位到哪個子系統、主機纔是本次事件的根因。以系統成功率爲例，在異常發生時，有多筆交易產生了錯誤日誌，這時對異常時間點的交易信息進行提取，找到當時存在n筆交易是異常交易。對這n筆交易進行統計分析後，發現這些交易都在某個相同的子系統報錯了，說明該子系統就是根因子系統。
最後是根因補充階段。這個階段會採用告警、變更等數據來進行分析，並對根因進行補充。如果定位到一個子系統存在異常，該子系統如果還存在告警、變更等數據的話，就會進一步的補充到根因內，使得根因更加具體、明確。
實際案例
整個系統的根因分析工作分三個階段。接下來將以實際案例來簡單介紹智能根因分析系統是如何工作的。
階段一：信息收集
信息收集階段以事件中心，關聯查詢異常相關的日誌、告警、變更、配置等信息，用以構建該異常事件的完整知識圖譜。
1、以事件爲起點，關聯查詢本次異常事件相關的指標信息。
2、通過獲取到異常時間點的業務流水信息，連帶查詢出對應業務流水號可以關聯出來的業務流水日誌和實時樹日誌。
3、獲取當前存在的證據。
4、將所有數據寫入到圖數據庫，生成知識圖譜。
階段二：根因定位
根因定位階段是在異常事件知識圖譜的基礎上，應用推導模型，對存在異常的子系統，及其相關的、IP、DCN、服務信息進行提取，起到定位的作用，也對異常事件的知識圖譜進行了裁剪。
如圖7所示，應用圖分析的推導模型後，異常的子系統及其相關IP、DCN及其證據從知識圖譜中提取出來。
階段三：根因補充
根因補充是爲異常事件進行最終根因定性的階段，在階段二的數據基礎上，應用規則引擎最終推導出根因結論。
從階段二中已經可以清晰發現該事件的根因。所有高耗時實時樹日誌都指向的APS子系統，而此時高耗時實時樹日誌經過的主機和APS子系統都能關聯到應用版本發佈信息。通過該圖獲取到的信息，經過話術的加工，最終智能根因分析系統給的異常事件根因是：[應用版本發佈]子系統 6009 AOMP應用發佈。影響:上游 DSFS接口 激活,返回信息:激活成功(交易耗時異常升高)。
上述是時延異常的一個案例，通過三個階段的分析，最終定位到是應用版本正在發佈，導致服務的耗時異常升高。整體思路是通過收集系統異常時的相關信息，構建異常事件的知識圖譜，再應用推導模型對圖譜進行信息提取，最後應用規則引擎對根因進行推導。
結語
回顧這一年多的系統建設歷程，我們最初梳理了根因分析的數據基礎，在這些數據基礎上確定了根因分析的方法，即以業務流水日誌爲抓手，將各緯度數據進行整合和分析；選擇專家系統的方案來快速構建根因分析系統；還應用了圖數據庫和知識圖譜的技術來解決數據透明和根因推導的問題。根因分析系統後繼還會持續優化，歷史上異常事件的知識圖譜對我們也是寶貴的財富，記錄了所有異常當時的全貌，爲我們挖掘更多知識和優化推導邏輯提供了數據支持。
後續我們將持續推出關於智能根因分析更加詳細和深入的分享，歡迎大家持續關注。
作者簡介
微衆銀行智能運維繫統核心開發者 葉金瓚