智能運維繫列專題簡介：智能運維（AIOps），根據Gartner的最新闡釋，意指整合大數據和機器學習能力，通過鬆耦合、可擴展方式去提取和分析數據量（volume）、種類（variety）和速度（velocity）這三個維度不斷增長的IT數據，進而爲IT運維管理產品提供支撐。在此，微衆銀行智能運維團隊根據一線工作的實踐經驗與心得體會，特別撰寫了《智能運維繫列》文章，敬請持續關注。
點擊回顧：智能運維繫列（二）| 智能化監控領域探索
點擊回顧：智能運維繫列（三）| 淺析智能異常檢測——“慧識圖”核心算法
點擊回顧：智能運維繫列（四）| 曝光交易路徑
點擊回顧：智能運維繫列（五）| 淺析基於知識圖譜的根因分析系統
保障業務的穩定運營一直是IT運維人員的首要任務。爲了實現這一目標，微衆銀行正式啓動了”異常事件根因分析 (RCA) 項目”。經過包括運維人員在內的多個角色的共同努力，最終該項目取得較爲理想的效果。作爲一線運維人員，筆者從運維管理的目標切入，介紹如何通過智能化手段將運維管理要求落地的實踐過程，期望能給讀者們帶來新的思路與深層思考。
異常檢測：快速、準確識別異常
管理目標
IT異常事件管理的首要目標是快速發現業務異常。微衆銀行異常事件管理規範中對異常事件從影響的對象、用戶量、時長等方面給出明確定義和分級，並要求在10分鐘完成異常事件的通報。
具體到項目目標中，就是對關鍵產品的異常能夠做到快速發現，首先有異常要能快速識別到並通報出來，同時避免過多誤報對運維人員造成騷擾。此外，需要使用智能化識別方法和手段，摒棄規則、閾值等各種繁雜的人工配置方式。
總結起來就是兩個字：“快”、“準”。
具體實踐
雖然以上管理要求簡單明確，然而現實情況卻相對複雜。由於應用監控、基礎組件監控分別由不同的運維團隊獨立維護，很多情況下需要依賴人工識別和收集，因此常規操作無法滿足10分鐘完成通報的要求。
對於異常檢測來說，我們要求自動發現業務產品交易行爲的異常表現。首先確定異常檢測範圍，關注業務產品的關鍵場景，特別是可能影響產品可用性的交易，如貸款產品的登錄、開戶、借款、還款等。其次，需要通過機器學習算法識別這些交易場景的成功率、交易量、平均時延三種指標在一段時間內的波動是異常的，自動推送消息到微信公衆號或微信羣，實現異常的自動通報。
要做到及時、準確，不漏報、也不誤報絕非易事。異常檢測和使用漁網捕魚類似：漁網網眼太大，會有漏網之魚，導致有些異常識別不到；漁網網眼太小，可能會網起一堆泥沙，效果和一般的同環比監控策略沒有差別，讓真正需要關注的異常淹沒在大量異常預警中。
針對上述技術難題，我們採取了以下措施：
1、對納入檢測範圍的交易場景，我們根據發生頻率即單位時間內的交易量大小，用聚類算法分爲高頻、中頻、低頻三類交易，並針對不同頻率的場景指標，採用了不同的識別靈敏度和不同的通知策略。如果高頻出現異常立即通報異常；對於低頻異常，可以持續檢測多個異常點後再通報。
2、根據業務特性，不同時段的交易頻率採取不同的針對措施。有些產品在工作日交易量較大，非工作日交易量較小。因此，我們將多個指標的曲線做關聯分析，如在分析成功率異常時，同時分析交易量指標，只有在失敗的交易量達到一定的級別後才升級爲異常。
3、對檢測到的異常進行分級。根據產品或場景重要程序確定各個異常的關注度程度，以觸發後續的通知機制和響應機制。
4、對不同指標曲線的特徵採取不同的針對措施。規律性強、取值範圍較穩定的指標，異常識別會更容易和準確一些；而波動較大的曲線異常識別難度則相對較大。在實踐中，我們一方面需要分析指標波動是否合理，另一方面還需要分析異常識別結果的有效性，對異常識別算法需要不斷調整和優化，從而減少誤告或漏告。
5、其他注意事項。
- 算法並不能解決所有問題，對於特殊曲線，應根據實際的運維需要將自動識別算法和規則相結合。
- 動態快速學習，人爲標記後能夠快速動態調整，如標記爲誤告後類似波動不再識別爲異常。
- 異常檢測應支持灰度，在累積一定的歷史數據，或觀察異常檢測準確率達到期望範圍內再開放給用戶。
實際效果
通過採用以上措施，我們已做到異常的自動識別和自動通知時間控制在3-4分鐘內。另外，針對當前的一些高頻交易曲線，我們已經實現了秒級檢測，異常的自動識別和自動通知時間從3-4分鐘縮短到30s以內，微衆銀行異常事件主動發現率已達95%以上，平均通報時長也較之前縮短50%以上。
異常事件根因定位：快速、準確判斷異常原因
管理目標
出現異常後，需要快速響應並處理異常，以降低對IT服務影響。因此，異常事件30分鐘內恢復率也是我們持續監測的管理指標之一。
要快速恢復，多數情況下需要先找到引起異常的原因。以往運維人員要通過人工排查告警、回顧變更記錄、查看日誌等多個方面來尋找原因，一般需要多個組件的運維和業務運維共同參與，信息的溝通和排查需要較長時間。從我們對異常事件處理過程的持續分析來看，異常定位環節耗時佔比最高。
針對以上問題，我們的解決之道是通過智能化手段快速、準確找到引發事件的真正原因，爲後續事件恢復爭取寶貴的時間。
具體實踐
檢測到異常後，我們需要快速收集業務服務調用鏈上各節點的異常證據，進行根因分析。另外，我們還需要匹配是否曾經發生過類似事件，給出歷史根因信息供參考。
調用可以分爲兩個維度：橫向調用、縱向調用。橫向調用是指對從入口子系統開始至後端所有交易路徑上經過的所有子系統進行分析；縱向調用指對支撐應用層子系統運行的所有邏輯層、物理層，包括數據庫、網絡、主機等進行分析。
微衆銀行大部分子系統之間的相互調用使用統一的消息總線，因此可以通過消息日誌自動分析橫向調用關係。未通過消息總線的調用也基本上有CMDB記錄，可通過CMDB中記錄的各類CI之間的關係進行分析。
證據收集過程中遇到的最大挑戰是保證證據的全面性，避免過於依賴單方面信息造成綜合根因分析的誤判。應根據調用鏈的每類節點分析可能存在的異常表現和原因，並對這些信息進行全面收集和相互佐證。如數據庫異常的表現包括應用日誌有錯誤信息、在監控系統中有告警、數據庫的CPU/IO等曲線有異常波動等。若僅僅依賴數據庫告警來判斷DB是否有異常，當告警配置有缺失時可能就無法識別到正確原因，此時還應該主動對數據庫指標曲線做異常趨勢監測。
變更及IT操作也是造成異常的主要原因之一。應收集每類可能帶來業務影響的變更操作的記錄，包括停服維護、版本發佈、底層基礎架構變更、業務人員/運維人員批量操作、外部變更等；收集方式可以採取變更過程中自動上報、主動採集等方式。
實際效果
在異常發生後2-5分鐘內自動推送根因分析結論，該功能給運維人員帶來很大的便利，在確認原因屬實後，可以快速實施相應的恢復方案，異常恢復時效自然得到很大的提升。經過近一年的不斷優化，微衆銀行根因定位準確率趨勢提升至80%以上，將近70%的異常也都能在30分鐘內恢復。
建立持續優化機制
爲了衡量異常事件根因定位的實際效果，我們重點關注兩個指標，異常識別準確率、根因分析準確率，並作爲我們持續優化的目標。每次異常發生後，運維人員需要確認實際根因，並且通過覆盤，從以下維度對異常進行檢視和分析：
-
是否及時識別到？未識別到的原因是什麼？需要如何調整保障下次能識別到？
-
根因定位是否準確？爲什麼沒有定位到正確的根因？缺失的證據如何才能收集到？
-
業務層面應該做哪些優化？
通過以上檢視和分析，我們會形成需要進一步跟進和落實的行動項，可能包括算法優化、業務邏輯優化等多個方面，進而持續跟蹤直至解決。正是通過這種良性的持續優化機制，我們才能推動根因定位準確率和效率不斷提升。
綜上所述，通過智能化手段的運用並持續優化，微衆銀行實現了異常事件快速發現和恢復的目標，極大提升了運維工作的效率。如需瞭解我們在異常檢測和根因定位中使用的機器學習算法，請參閱該系列其他文章。
作者簡介
本文作者系微衆銀行智能運維繫統資深經理 張娟