AIOps代表運維操作的人工智能(Artificial Intelligence for IT Operations)， 是由Gartner定義的新類別，Gartner的報告宣稱，到2020年，將近50%的企業將會在他們的業務和IT運維方面采用AIOps，遠遠高於2017年的10%。
Gartner在為AIOps作出如下定義：AIOps平台是結合大數據、人工智能（AI）或機器學習功能的軟件系統，用以增強和部分取代廣泛應用的現有IT運維流程和事務，包括可用性和性能監控、事件關聯和分析，IT服務管理以及運維自動化。AIOps 可以被看作是對核心 IT 功能的持續集成和部署 (CI/CD)
國內對AIOps有深入研究的清華大學裴丹教授對AIOps的解釋：是將人工智能應用於運維領域，基於已有的運維數據（日志、監控信息、應用信息等），通過機器學習的方式來進一步解決自動化運維沒辦法解決的問題。AIOps 不依賴於人為指定規則。
早期的運維工作大部分是由運維人員手工完成的，這被稱為手工運維或人肉運維。這種落后的生產方式，在互聯網業務快速擴張、人力成本高企的時代，難以維系。
- 行業領域知識：應用的行業，如互聯網、金融、電信、物流、能源電力等，並熟悉生產實踐中的難題；
- 運維場景領域知識：包括異常檢測、故障預測、瓶頸分析、容量預測等；
- 機器學習：把實際問題轉化為算法問題，常用算法包括如聚類、決策樹、卷積神經網絡等。
二、AIOps 目標、原則及能力框架
AIOps，通俗的講，是對規則的AI化，即將人工總結運維規則的過程變為自動學習的過程。
具體而言，是對我們平時運維工作中長時間積累形成的自動化運維和監控等能力，將其規則配置部分，進行自學習的“去規則化”改造，最終達到終極目標：“有AI調度中樞管理的，質量、成本、效率三者兼顧的無人值守運維，力爭所運營系統的綜合收益最大化”。
2.1、AIOps 目標
利用大數據、機器學習和其他分析技術，通過預防預測、個性化和動態分析，直接和間接增強IT業務的相關技術能力，實現所維護產品或服務的更高質量、合理成本及高效支撐。
2.2、AIOps 能力分級
AIOps的建設可以先由無到局部單點探索、再到單點能力完善，形成解決某個局部問題的運維AI“學件”，再有多個具有AI能力的單運維能力點或學件組合成一個智能的運維流程，如智能化的監控預測及告警，免干預的自動化擴縮容，免干預的性能調優、免干預的成本組成調優等。
- 開始嘗試應用AI能力，還無較成熟單點應用
- 具備單場景的AI運維能力，可以初步形成供內部使用的學件
- 有由多個單場景AI運維模塊串聯起來的流程化AI運維能力，可以對外提供可靠的運維AI學件
- 主要運維場景均已實現流程化免干預AI運維能力，可以對外提供可靠的AIOps服務。
- 有核心中樞AI，可以在成本、質量、效率間從容調整，達到業務不同生命周期對三個方面不同的指標要求，可實現多目標下的最優或按需最優。
2.3、AIOps 能力框架
學件：亦稱AI運維組件類似程序中的API或公共庫但API及公共庫不含具體業務數據只是某種算法，而AI運維組件或稱學件則是在類似API的基礎上兼具對某個運維場景智能化解決的“記憶”能力，將處理這個場景的智能規則保存在了這個組件中。
- “可重用”的特性使得能夠獲取大量不同的樣本；
- “可演進”的特性使得可以適應環境的變化；
- “可了解”的特性使得能有效地了解模型的能力。
三、AIOps 平台能力體系
AIOps 工作平台的能力體系主要功能是為 AIOps 的實際場景建設落地而提供功能的工具或者產品平台，其主要目的是降低 AIOps 的開發人員成本，提升開發效率，規范工作交付質量。AIOps平台功能與一般的機器學習(或者數據挖掘)平台極為類似此類產品國外的比如Google的AutoML(https://cloud.google.com/automl/)，AIOps平台功能模塊圖如下：
AI建模服務能力示意圖如下:
- 交互式建模功能：該功能支持用戶在平台上交互式的進行模型的開發調試，通過簡單的方法配置完成模型的構建。
- 算法庫：用戶可以在算法庫中找到常見常用的算法直接使用，算法按照用途分類，以供用戶方便的使用。
- 樣本庫：樣本庫用於管理用戶的樣本數據，供用戶建模時使用，支持樣本的增刪改查等基本操作。
- 數據准備：該功能支持用戶對數據進行相關的預處理操作，包括關聯、合並、分支路由、過濾等。
- 靈活的計算邏輯表達：在基本常用的節點功能之外，用戶還需要自由的表達一些計算邏輯，該需求主要是通過讓用戶寫代碼或表達式來支持。
- 可擴展的底層框架支持：平台本身要能夠靈活的支持和兼容多種算法框架引擎，如Spark、TensorFlow等，以滿足不同的場景以及用戶的需求。
- 數據分析探索：該功能是讓用戶能夠方便快捷的了解認識自己的數據，用戶只有基於對數據充分的認識與理解，才能很好的完成模型的構建。
- 模型評估：對模型的效果進行評估的功能，用戶需要依據評估的結論對模型進行調整。
- 參數以及算法搜索：該功能能夠自動快速的幫助用戶搜索算法的參數，對比不同的算法，幫助用戶選擇合適的算法以及參數，輔助用戶建模。
- 場景模型：平台針對特定場景沉淀的解決方案，這些場景都是通用常見的，用戶可以借鑒參考相關的解決方案以快速的解決實際問題
- 實驗報告：模型除了部署運行，相關挖掘出來的結論也要能夠形成報告，以供用戶導出或動態發布使用。
- 模型的版本管理：模型可能有多個不同的版本，線上運行的模型實例可能分屬各個不同的版本，版本管理支持模型不同版本構建發布以及模型實例版本切換升級等。
- 模型部署應用：模型構建完成后需要發布應用，模型部署應用功能支持模型的實例化，以及相關計算任務的運行調度管理。
四、AIOps 團隊角色
AIOps作為一個團隊，由不同角色組成，一般有三種不同角色，他們是運維專家、數據科學家、智能運維研發工程師，以下介紹三種角色分工：
- 特征：具有豐富的運維領域知識、熟悉較為復雜的運維問題、具備解決運維難題能力。
- 職責：運用機器幫助運維人員完成基礎性和重復性的基層運維工作；人工處理機器還不能處理好的運維難題；基於經驗對於較為復雜的運維問題給出最終決策—不斷訓練機器。
- 特征：具備編程、數學、統計學、數據可視化、機器學習等能力。
- 職責： 致力於智能運維平台架構、模型標准、數據分析方法；不斷應用最新的機器學習技術設計優化智能運維算法；監督智能運維系統性能並實施優化和改進。
- 特征：良好的開發語言基礎、大數據處理技術能力。
- 職責：數據采集、自動化處理、實現和運用算法等。
角色協同關系如下圖：
五、AIOps 常見應用場景
AIOps 圍繞質量保障、成本管理和效率提升的基本運維場景，逐步構建智能化運維場景。
- 在質量保障方面，細分為異常檢測、故障診斷、故障預測、故障自愈等基本場景；
- 在成本管理方面，細分為指標監控，異常檢測，資源優化，容量規划，性能優化等基本場景；
- 在效率方面，分為智能變更、聊天機器人等基本場景。
（注：三者之間不是完全獨立的，是相互影響的，場景的划分側重於主影響維度。）
無論是效率提升，質量監控，還是成本優化，都離不開最基礎的數據采集，它是整個AIOp的基石。 AIOps提高運維生產力的一種方式就是把質量處理流程中的人力部分盡可能的都替換成機器來做。在機器的分析過程中系統運行過程中的每一個部件都需要數據支持。無論是海量數據采集、還是數據提取方面都離不開大數據技術。
從數據采集的層面來看，運維數據的采集往往是實時的，數據采集端需要具備一定分析能力，綜合考慮用戶流量、隱私服務器壓力等多個因素，盡可能的降低無效數據的采集，增加有價值信息的上報。
從數據提取的層面來看，運維的數據是多樣化的，歷史數據、流數據、日志數據、網絡數據、算法數據、文本和NLP文檔數據，以及APP數據、瀏覽器數據、業務系統運營指標數據等，從這些海量的數據中提取出正真有價值的指標化數據並可視化是進一步分析決策的前提條件。
而成本優化和效率的提升同樣離不開數據的支撐。例如，開始實施成本優化的AIOPS前，需要盡可能多的收集目前的服務器、網絡設備、應用服務、數據庫等的性能信息，應用日志信息，tracing信息，以便對成本優化的效果進行評估。例如在搭建智能客服機器人的時候，就需要提供充足的問題庫和相應的答案才能夠建立好一個較優的模型。
三大方向的各階段能力描述如下所示。
5.1、質量保障方向
異常檢測：
- 運維系統中常見的兩大類監控數據源是：指標和文本。前者通常是時序數據，即包含指標采集時間和對應指標的值；后者通常是半結構化文本格式，如程序日志、Tracing等。隨着系統規模的變大、復雜度的提高、監控覆蓋的完善、監控數據量越來越大、運維人員無法從海量監控數據中發現質量問題。智能化的異常檢測就是要通過AI算法，自動、實時、准確地從監控數據中發現異常，為后續的診斷、自愈提供基礎。異常檢測的常見任務包括對數據源的異常檢測，保證數據質量，以及對指標和文本的異常檢測。
- 數據源異常檢測：數據源會因為一些不可避免的原因存在一些異常數據，這些異常數據占比雖然很低，但是往往會引起整個指標統計值的波動，使得統計結果偏離真實的用戶體驗。AIOps需要自動、實時的動態設置閾值，去除數據源中的異常數據干擾，並能夠區分系統真正發生異常時候的故障數據和數據源本身的異常數據，這種判斷依賴於一些外部信息。
- 指標異常檢測：包括單指標異常檢測及多指標異常檢測。
- 單指標異常檢測：時間序列指標的異常檢測是發現問題的核心環節，傳統的靜態閾值檢測為主的方式，閾值太高，漏告警多，質量隱患難以發現；閾值太低，告警太多引發告警風暴，干擾業務運維人員的判斷。AIOps通過機器學習算法結合人工標注結果，實現自動學習閾值、自動調參，提高告警的精度和召回率，大幅度降低人工配置成本。
- 多指標異常檢測：運維過程中有些指標孤立來看可能並沒有異常，但是綜合多個指標來看，可能就是異常的。有些單指標表現是異常的，但是綜合多個指標來看可能又是正常的。AIOps需要能夠綜合多個指標綜合評判系統指標異常，提高告警的准確性。
3. 文本異常檢測：文本日志常是在特點條件下觸發生成的，並遵循一定的模板，即半結構化文本。傳統的日志檢測有兩種方式：
- 根據日志級別：如Info、Warning、Critical進行報警，但由於其設定不准確或不滿足實際需要，導致准確性差
- 通過設置規則：匹配日志中特定字符串進行報警，但該方法依賴依賴人工經驗，且只能檢測已知和確定模式的異常。
- AIOps需要通過自然語言處理、聚類、頻繁模式挖掘等手段，自動識別日志出現的反常模式，結合人工反饋和標注，不斷進行優化、完善。
故障診斷：
- 異常檢測實現了運維人員對數據的感知，有了數據之后，智能分析可以進一步解放運維人力，提高運維效率，故障診斷是智能分析的核心部分，主要包括基於人工故障庫的故障診斷和基於數據挖掘的故障診斷。
- 基於人工故障庫的故障診斷：日常運維過程中，運維人員積累了大量的人工經驗，運維過程中的大部分故障都是重復的、人工能夠識別的異常。重復問題的定位浪費了大量的人力而且人工確認過程往往是比較滯后的。AIOps把人工專家經驗固化下來，對常見問題實現分鍾級內自動診斷，運維人員收到的告警信息中就需要包括故障定位的結果信息。
- 基於數據挖掘的故障診斷：人工經驗可能存在偏差，人工認為的原因可能並不是問題的根因，當有些故障首次發生沒有人工經驗可以借鑒的時候故障根因也難以定位。尤其隨着微服務的發展，業務的組網變得更加復雜，模塊多帶來的消息路由多、依賴多，問題的定界定位分析更為困難；人工故障決策效率挑戰巨大。 對於已知故障，AIOps能夠綜合故障數據和人工經驗自動提取故障特征，生成故障特征庫，自動匹配、自動定位故障、對於未知故障AIOps需要根據故障特征推演出可能的故障原因，並在人工確認后加入的故障特征庫。
故障預測：
- 故障的出現一般不是突然的，就比如網絡故障來說，往往從丟包開始到網絡不可用是有一個演變的過程，依據海恩法則，每一起嚴重事故的背后，必然有29次輕微事故和300起未遂先兆以及1000起事故隱患，開展主動健康度檢查，針對重要特性數據進行預測算法學習，提前診斷故障，避免服務受損；常見場景：磁盤故障預測、網絡故障預測（根據交換機日志的交換機故障預測）、內存泄露預測等等。
故障自愈：
- 智能分析實現了故障的診斷和預測，智能執行根據智能分析的結果實現故障自愈。傳統的故障自愈的決策主要靠人的經驗，人的經驗能夠覆蓋的故障范圍是有限的，而且人工無法保證7*24隨時可以立即決策與處理。AIOps能夠提供完善的自動化平台在故障智能分析之后自動決策，實現自愈；常見場景：版本升級回退、DNS自動切換、CDN智能調度、智能流量調度等。
- 故障自愈是根據故障診斷的結果的輸出（問題定位和根因分析），進而進行影響評估決定“解決故障”或“恢復系統”的過程。影響評估是對故障之后所產生的影響范圍（系統應用層面、業務執行層面、成本損失層面等等）輸出評估結果，並根據這個評估來決定要采用什么解決手段，甚至生成解決手段的執行計划。
5.2、效率提升方向
效率提升是運維的基本場景之一，隨着業務的發展，運維系統的整體效率的提升就成為了運維系非常重要的一環。在這樣的背景下，除了增加人力是遠遠不夠的，還需要AIOps提供高質量，可維護的效率提升工具。
智能問答：
- 運維的目標是為了支持穩定，可靠的業務運行，而業務與業務之間既可能有相似性，又可能有差異性。但由於知識背景和對業務的認知差異往往出現以下情況
- 不同的業務人員或開發人員往往會詢問運維人員一些相似的問題，運維人員的答案也是非常類似的，但人力被重復消耗。
- 面對同一個問題，運維人員的回答可能會出現差異，例如表達方式、措辭等，缺乏標准化可能造成誤解。
- AIOps智能問答系統通過機器學習、自然語言處理等技術來學習運維人員的回復文本，構建標准問答知識庫從而在遇到類似問題的時候給出標准的統一的回復。這樣不僅可以有效地節省運維人員的人力成本還能夠使得提問得到更加及時的回復。
智能決策：
- 許多運維管理工作都需要各種各樣的決策，包括擴容、縮容、制定權重、調度、重啟等內容。那么可能面臨如下問題
- 運維人員可以根據自己的業務經驗制定相應的決策。但是不同的業務有着各自的特點，不同的運維人員也有着自己的業務經驗。如何將運維人員的這些經驗有效地傳承是個問題。
- 人的認知局限性，運維場景的復雜性可能導致最有經驗的運維人員遺漏掉某些“不起眼”的“重要細節”，顯然准確的決策還依賴足夠充足的細節。
- AIOps智能決策一方面可以將運維人員的決策過程數據化，構建決策支持知識庫，從而實現經驗積累。另一方面由於系統掌握了從全局到細節的數據，再結合決策支持知識庫，可以為更加准確的決策提供最有力的支撐。
容量預測：
- 運維工作不僅僅包含對當下的決策和處理，往往還需要根據業務的訴求對未來做出合理的規划，包括擴容的預測，縮容的預測等。由於對未來的規划時常存在不確定性那么規划過程往往需要大量的數據來支持，還需要大量的推演來確定。而人工預測的方式，一方面需要投入大量人力；另一方面運維人員的能力可能存在差異，使得推演的結果品質不盡一致。
- AIOps智能預測借助大數據和機器學習能力，結合運維人員的有效評估經驗，甚至業務發展模式以及政策等，對目標場景實現高效的推演過程，最終使預測結果趨近合理范圍。這樣一來，不但是人力得以節省，關鍵在於由於預測效率的提升，使得過去難以重復耗時耗力的人工預測過程變得可以應需而變，不斷修正預測結果，最終使業務訴求獲得最佳預測收益。
5.3、成本管理方向
成本優化：
- 在成本優化方向，需要采取高可用的設計，提供更加合理的服務，包括接入層、業務層、存儲層等。
- 在接入層需要提供合理的健康檢查機制，更加智能的負載均衡算法，限定流量等工作。
- 在業務層不僅需要去除DB的強依賴，使用合理的降級，還要進行合理的壓測、監控以及動態的負載均衡。
- 在存儲層需要做的事情是容災等關鍵工作。這樣的話，可以使得內部數據的質量得到大量提升，外部數據的優先接入和動態選擇。
- 對於設備采集的周期控制這個問題來說，過晚的設備采購可能會影響到業務的正常上線或擴展，而過早的采購也可能造成成本的浪費。於是AIOps 需要建立合理的模型並建立更好的規划，並據此計算更准確的設備采購計划，也能對成本進行更好的控制。
資源優化：
- 公司的運營成本優化項目一直是公司成本預算的關鍵一步。優化問題包括設備的優化、帶寬、碼率的優化等等。只有進行了合理的資源優化，才能夠使得公司的成本得到有效的控制。不同的服務的資源消耗類型是不一樣的，包括計算密集型，包括存儲密集型等等；而對於同一個服務在不同的時間點資源消耗也是不一樣的。
- 對於一個企業來說，識別不同服務的資源消耗類型，識別每個服務的資源瓶頸，實現不同服務間的資源復用是降低成本的重要環節。根據資源應用的性能指標可以大致分類成以下類別：
- 計算密集型：CPU使用率較高，常見於需要大量計算資源的搜索、推薦、數學計算等場景中
- 內存密集型：占用的內存使用率較高，如緩存服務
- IO密集型：網絡IO繁忙或者磁盤IO操作繁忙，常見於爬蟲、消息管道、分布式存儲等服務中。
- 大型互聯網公司里動輒上千上萬的應用數，很容易有應用因為業務變化已經訪問量不斷縮減甚至已經下線，但是線上還占用着大量的資源，通過對應用的性能指標分析，篩選出各項性能指標都很低的應用，就可以識別出這些“被遺忘” 的應用，就可以跟業務負責人進行核對進行縮容或者下線。
- 目前大部分公司都已經使用了虛擬化或者docker技術，同一個物理機上的不同虛擬機或容器已經進行了很好的細粒度資源分配和隔離，所以對於同一台物理機可以進行混合部署不同類型的應用，如計算密集型應用、存儲密集型應用、IO密集型應用混部在同一台物理機上，以提高更大的資源利用率，甚至一定量的“超賣”（通過共享部分資源，實現分配的總的資源數超過物理機的資源數）。對於一些靈活的計算任務：如Spark、Storm等計算類任務，還可以使用按時分配的策略，如白天運行在部分服務器上，而且夜間需要運行大批量計算的報表等任務時，利用業務應用夜間資源使用率低的特點把部分任務分配到業務應用所在的服務器上運行，充分利用這些業務應用的服務器的計算資源，提高整體利用率。
- AIOps通過密度管理、特性管理、碎片管理、木桶管理等方法，優化企業不同服務器的配比，發現並優化資源中的短板，提供不同服務的混合部署建議，最終實現智能化降成本方案分析服務。
性能優化：
- 性能的調優一直是運維的重要一環。如果性能優化得當則會減少實際的運算量，減少內存方面的濫用，提升服務器的性能。運維人員在其中並不能保證及時發現所有潛在的性能問題，很多時候也不知道什么的系統配置才是最優的系統配置，什么時候的權重配比才能夠達到最佳的效果。AIOps 能夠根據現網的實際情況，進行智能地調整配置，智能發現性能優化策略，提供智能化的優化服務。
六、AIOps 實踐路徑建議
6.1、未實現自動化運維時
AIOps的開展，受限於自動化數據采集，網絡、磁盤、成本方面的工作難以深入發展。建議聚焦質量保障的原子場景。
6.2、已經實現自動化運維時
6.2.2、效率提升方向
6.2.3、成本管理方向
七、AIOps 實施及關鍵技術
為了實現成本管理、效率提升、質量保障的場景，根據Gartner的定義，AIOps產品或平台應包含下圖所示的要素：
- 數據源：大量並且種類繁多的IT基礎設施
- 大數據平台：用於處理歷史和實時的數據
- 計算與分析：通過已有的IT數據產生新的數據例如數據清洗、去除噪聲等
- 算法：用於計算和分析以產生IT運維場景所需要的結果
- 機器學習：這里一般指無監督學習，可根據基於算法的分析結果來產生新的算法
7.1、數據采集
- 數據采集：負責將智能運維所需要的數據接入至AIOps平台，所接入的運維數據類型一般包括(但不限於)日志數據、性能指標數據、網絡抓包數據、用戶行為數據、告警數據、配置管理數據、運維流程類數據等。
- 數據采集方式可分為無代理采集以及有代理采集兩種：
- 無代理采集為服務端采集：支持SNMP、 數據庫JDBC、 TCP/UDP監聽、 SYSLOG、 Web Service、消息隊列采集等主流采集方式。
- 有代理采集：用於本地文件或目錄采集、容器編排環境采集、以及腳本采集等。
7.2、數據處理
- 針對采集數據進行入庫前的預處理，數據從非結構化到結構化的解析、數據清洗、格式轉換以及數據（如性能指標）的聚合計算，處理工作主要體現在幾個方面：
- 數據字段提取：通過正則解析、KV解析、分隔符解析等解析方式提取字段
- 規范化數據格式：對字段值類型重定義和格式轉換
- 數據字段內容替換：基於業務規則替換數據字段內容，比如必要的數據脫敏過程，同時可實現無效數據、缺失數據的替換處理
- 時間規范化：對各類運維數據中的時間字段進行格式統一轉換
- 預聚合計算：對數值型字段或指標類數據基於滑動時間窗口進行聚合統計計算，如取1分鍾CPU平均值
7.3、數據存儲
- 數據存儲是AIOps平台的數據落地的地方，可以根據不同的數據類型以及數據的消費和使用場景，可選擇不同的數據存儲方式。數據主要可分為如下幾類：
- 數據需要進行實時全文檢索、分詞搜索：可選用主流的ElasticSearch引擎
- 時間序列數據：性能指標，主要以時間維度進行查詢分析的數據, 可選用主流的rrdtool、graphite、influxdb等時序數據庫
- 關系類數據以及會聚集在基於關系進行遞歸查詢的數據可選擇圖數據庫
- 數據的長期存儲和離線挖掘以及數據倉庫構建，可選用主流的Hadoop、Spark等大數據平台
7.4、離線和在線計算
- 離線計算：針對存儲的歷史數據進行挖掘和批量計算的分析場景，用於大數據量的離線模型訓練和計算，如挖掘告警關聯關系，趨勢預測/容量預測模型計算，錯誤詞頻分析等場景。
- 在線計算：對流處理中的實時數據進行在線計算，包括但不限於數據的查詢、預處理和統計分析，數據的實時異常檢測以及部分支持實時更新模型的機器學習算法運用等。主流的流處理框架包括Spark Streaming, Kafka Streaming, Flink, Storm等。
7.5、面向 AIOps 的算法技術
- 運維場景通常無法直接基於通用的機器學習算法以黑盒的方式解決，因此需要一些面向AIOps的算法技術，作為解決具體運維場景的基礎。有時一個算法技術還可用於支撐另外一個算法技術。 常見的面向AIOps的算法技術包括：
- 指標趨勢預測：通過分析指標歷史數據，判斷未來一段時間指標趨勢及預測值，常見有Holt-Winters、時序數據分解、ARIMA等算法。該算法技術可用於異常檢測、容量預測、容量規划等場景。
- 指標聚類: 根據曲線的相似度把多個KPI聚成多個類別。該算法技術可以應用於大規模的指標異常檢測，在同一指標類別里采用同樣的異常檢測算法及參數，大幅降低訓練和檢測開銷。常見的算法有DBSCAN, K-medoids, CLARANS等應用的挑戰是數據量大曲線模式復雜。
- 多指標聯動關聯挖掘：多指標聯動分析判斷多個指標是否經常一起波動或增長。該算法技術可用於構建故障傳播關系，從而應用於故障診斷。常見的算法有Pearson correlation, Spearman correlation, Kendall correlation等應用的挑戰為KPI種類繁多關聯關系復雜。
- 指標與事件關聯挖掘: 自動挖掘文本數據中的事件與指標之間的關聯關系， 比如在程序A每次啟動的時候CPU利用率就上一個台階。該算法技術可用於構建故障傳播關系，從而應用於故障診斷。常見的算法有Pearson correlation, J-measure, Two-sample test等。應用的挑戰為事件和KPI種類繁多，KPI測量時間粒度過粗會導致判斷相關、先后、單調關系困難。
- 事件與事件關聯挖掘：分析異常事件之間的關聯關系把歷史上經常一起發生的事件關聯在一起。該算法技術可用於構建故障傳播關系，從而應用於故障診斷。常見的算法有FP-Growth、 Apriori、隨機森林等，但前提是異常檢測需要准確可靠。
- 故障傳播關系挖掘：融合文本數據與指標數據，基於上述多指標聯動關聯挖掘、指標與事件關聯挖掘、事件與事件關聯挖掘等技術、由tracing推導出的模塊調用關系圖、輔以服務器與網絡拓撲，構建組件之間的故障傳播關系。該算法技術可以應用於故障診斷，其有效性主要取決於其基於的其它技術。
參考資料