智能運維在金融行業的應用研究

李俊

摘 要：如何高效地進行大規模系統運維，一直是金融行業數據中心思考的問題。人工智能技術的發展正慢慢改變運維體系，讓運維更加智能成為了可能。本文介紹了智能運維的產生和發展，探討了智能運維的系統建設和關鍵場景以及技術。

關鍵詞：大數據；智能運維；人工智能

1 引言

隨著互聯網、移動互聯網、金融科技等技術的迅速發展，當前各個行業的企業紛紛進行數字化轉型以應對日益激烈的市場競爭，企業的數字化服務越來越依賴于大型復雜的IT系統。為了更好的用戶體驗，這些IT系統需要可以穩定、連續地運轉，系統的部署、運行和維護都需要專業人員負責。傳統運維方式在大規模系統運維的時候常常會碰到一些問題。例如：百度在定位系統瓶頸時，影響網站PageView的屬性有運營商、省份、城市、移動設備類型、軟件版本號、移動模塊號、瀏覽器版本、服務器模塊等十幾個屬性，每個屬性有幾百億條數據，運維人員人工分析其中的規律是不可行的。如何區分“正常狀態下實時交易量為零”與“故障狀態下實時交易量為零” 的不同情形，這需要結合多方面的數據進行智能判斷。

2 智能運維的產生與發展

智能運維（AIOps）這個概念最早由Gartner于2016年提出，將人工智能應用于運維領域，基于已有的運維數據（日志、監控信息、應用信息等），通過人工智能的方式來進一步解決傳統運維沒辦法解決的問題。

學術上，多倫多大學的Geoffrey Hinton的教授和Yoshua Bengio、Yann LeCun一起提出了可行的深度學習方案，大幅的提高了計算機視覺在圖片識別的正確率。2012年Google Brain用16000個CPU核的計算平臺訓練10億神經元的深度網絡，無外界干涉下自動識別出了貓。最近5-6年，人工智能特別是深度學習在圖像、聲音和語義等各個領域取得了長足的進步，為人工智能算法應用于智能運維領域提供了理論基礎。

近幾年一些互聯網公司不斷在智能運維進行探索和實踐，也取得了一定成果。Google使用“類神經網絡”技術分析其眾多數據中心的工作情況，決定何時管理數據中心的設備，比如清理熱交換器，提高設備冷卻性能，大大提高數據中心的運維效率。百度實現了一套基于日志 Trace 的智能故障定位系統及其背后的一套技術方案，最終能夠實現PageView根因定位能力，并能夠根據根因做統計上的多維度匯聚，該系統應用于百度核心搜索系統，極大的提升了重大異常問題定位效率。

3 金融行業的智能運維應用研究

3.1 特色和挑戰

和互聯網行業一樣，金融機構IT系統規模都比較大，需要管理萬臺服務器級別以上的大規模基礎設施。但是和互聯網行業不同的是，金融機構面臨著嚴格的金融監管要求，需要維持穩定的金融秩序，系統的穩定性和連續性要求極高，允許大的系統變更的次數要遠遠少于互聯網公司。金融機構IT架構以前采用大型機，現在是小型機為主，部分采用了X86服務器，云計算正在小規模試點，整體IT環境是多代共存。同時，商業軟件和開源軟件不同，面臨接口不開放，集成成本高的問題。所以，金融行業智能運維的場景和要求有一定的行業特色。

3.2 智能運維系統設計

圖1 智能運維系統邏輯架構圖

智能運維系統分成數據接入層、數據存儲層、數據分析層和智能運維應用層。邏輯架構示意圖（圖1）如下。1）數據接入層：通過開放的API接口，廣泛接入企業IT系統的服務器、網絡、中間件、業務系統日志以及CMDB等與運維相關的數據。接入數據的形式不僅包括離線的歷史數據、還包括流式的實時數據。2）數據存儲層：對接入的運維大數據進行統一集中、高效的存儲和管理。流式數據通過消息隊列緩存以實現高速交換的需求，流式數據和離線數據最終進入運維數據倉庫。3）數據分析層：對集中整合的各個系統的運維數據，采用多維分析、搜索、時間序列、知識圖譜、預測等多種分析技術以支撐智能運維應用。4）智能運維應用層：針對不同的智能運維場景，支持不同的應用。包括實時智能監控、日志聚合和檢索、異常檢測、根因分析、告警聚合服務和容量規劃等。

3.3 智能運維系統和CMDB的關系

CMDB是IT架構中設備的各種配置信息，與服務支持和交付流程緊密相連，它是系統運維最底層最核心的數據庫。智能運維系統接入了CMDB的數據，在CMDB基礎上建設了運維數據倉庫。運維數據倉庫和CMDB是整個運維系統的最重要的兩個資料庫。CMDB側重于操作、流程支持，是IT運營的核心數據庫。運維數據倉庫是海量運維數據存儲，用于做運維大數據分析，是智能運維的核心資料庫。

3.4 關鍵場景與技術

3.4.1 實時智能監控

對于金融交易系統一次小小的故障都會造成不小的經濟損失，所以不僅需要監控歷史數據，同時需要監控當前運行數據，實時監控反而更加重要。對于離線歷史數據的管理，系統將他們存放在運維數據倉庫中，這些數據大多為非結構化數據、半結構化數據，可以采用分布式的Hadoop HDFS存儲，支持海量數據而且便于擴展。對于流式實時數據的管理，系統接入層將數據實時推送到消息隊列Kafka組件中，然后通過Kafka交換，以減少對業務系統的影響。在數據分析層，對于流式數據的處理，系統通過Spark Streaming組件去獲取各平臺剛剛傳入Kafka的系統日志、應用日志、監控數據等數據，實時發送到智能運維應用，智能監控通過可視化技術動態地將數據展現給運維人員。HDFS、Kafka、Spark Streaming這些都是Hadoop組件，它們被良好的集成在Hadoop技術體系中。

3.4.2 日志聚合與檢索

當運維人員需要排錯時，需要逐臺登錄服務器查看。另外，日志查詢方式比較單一， Windows 服務器需要手動查看Event Log，Linux服務器需要通過less、grep和awk等常見的Linux指令，無法從時間段、關鍵字、字段值統計等方面進行多維度查詢。智能運維平臺對日志聚合，統一存儲。而且通過ElasticaSearch組件對數據建立索引，便于檢索。不同于以往每次僅可查看數量有限的幾種日志，運維人員可通過智能運維平臺所提供的關鍵字、統計函數、單條件、多條件、模糊查找等功能，在多個系統中快速定位故障信息，幫助運維人員從全局視角查看系統的運維數據信息，大大縮短了故障分析的時間。

3.4.3 異常檢測

金融機構通常會實時監控交易系統的業務狀態，每分鐘交易信息進行匯總統計。匯總信息包括業務量、交易成功率、交易響應時間三個指標，各指標解釋如下：1）業務量：每分鐘總共發生的交易總筆數；2）交易成功率：每分鐘交易成功筆數和業務量的比率；3）交易響應時間：一分鐘內每筆交易在后端處理的平均耗時（單位：毫秒）。當分支機構網絡傳輸節點故障，前端交易無法上送請求，會導致業務量陡降。當分支機構側參數數據變更或者配置錯誤，數據中心后端處理失敗率增加，影響交易成功率指標。當數據中心后端處理系統異常（如操作系統CPU負荷過大）引起交易處理緩慢，影響交易響應時間指標。當數據中心后端處理系統應用進程異常，導致交易失敗或響應緩慢。當這三個指標出現業務量陡降、響應時間陡升等情況，系統可能存在著潛在故障。通常可以從交易量、交易類型、地域分布、交易時間段等多個維度進行分析，通過歷史和當前數據對比。但是金融系統的交易數據存在時間波動：工作日和非工作日的交易量存在差別，一天內交易量存在業務低谷時間段和正常業務時間段。簡單的對比前一段時間的業務量，往往不夠精確，基于時間序列的Holt-Winters分析方法可以對數據進行二次指數平滑，提高異常檢測的精確度。

3.4.4 根因分析

異常檢測發現異常后，如何快速找到異常的根本原因？在傳統運維中，我們通常通過自上而下的方式逐級人工排查，也就是先從應用系統，再到數據庫、再到操作系統，最后是服務器硬件、網絡等底層資源。這種方式可以分析出比較簡單、明顯的系統故障，但是無法有效的分析出性能瓶頸、內存泄漏等一些復雜的多因素影響的問題。智能運維系統通過結合CMDB中的配置信息以及其他一些運維數據，學習出故障的傳播路徑，幫助運維快速定位問題。同時運維專家也可以對故障根原因信息進行標注以改善人工智能的準確性，同時改善智能運維系統的智能水平。再進一步，當智能系統的智能水平達到一定程度后，系統甚至可以考慮自動采取措施來修復故障。

3.4.5 告警聚合

在傳統運維中，運維人員有時會陷入重復告警的困擾。例如一個服務器宕機，在它恢復運行的這段時間內，會不斷收到告警信息。與此同時，其關聯的應用系統、中間件的各級資源也會不斷地產生報警。智能運維系統通過CMDB系統中的配置信息獲取監控對象之間的依賴關系，自動尋找故障的底層故障點進行告警，忽略關聯告警信息。對于一段時間窗口告警信息，系統智能合并成一條信息，而不是反復重復告警。智能運維系統還可以通過CMDB系統中的變更信息，智能地忽略應版本變更引起的告警信息。

3.4.6 容量規劃

在傳統運維中，容量規劃會更根據業務量的規模等因素來人為預估服務器的節點數、硬件配置等資源。通過基于運維系統產生的實際、真實的數據，通過一些模型例如：ARMA 和GARCH 模型，來預測未來3個月或者1年需要的資源配置。這種基于數據的預測方法相對經驗預估相對要科學，并且準確得多，從而避免了資源的浪費。特別是在云計算的環境中，結合云計算彈性計算，按需分配的特點，極大的提高了數據中心的資源利用率。

4 結語

綜上所述，由于開源大數據技術和人工智能技術的發展，金融機構在接入運維大數據、分析和存儲運維大數據以及一些智能運維場景的應用已經沒有技術障礙。但是，通過人工智能技術檢測出故障的根原因后，如何通過采取”自動修復“技術自動修復故障，在無需人工干預的場景下，還存在如何保證整體系統穩定、安全等一系列的問題，還需要進一步研究和探索，以滿足金融機構對高安全、高穩定性的要求。

參考文獻

[1]袁俊德.以“七臺兩庫”領銜智能化運維[J].金融電子化，2017（08）：75-77.

[2]高建.陽光保險邁入智能運維1.0時代[J].金融電子化，2017（08）：84-85.

[3]楊斌.大數據技術領航智能運維[J].金融電子化，2017（08）：86-87.