企業AIOps智能運維方案白皮書目錄背景介紹4組織單位4編寫成員5發起人5顧問5編審成員5本版本核心編寫成員61、整體介紹82、AIOps目標103、AIOps能力框架114、AIOps平臺能力體系145、AIOps團隊角色175.1運維工程師175.2運維開發工程師175.3運維AI工程師176、AIOps常見應用場景196.1 效率提升方向216.1.1智能變更226.1.2智能問答226.1.3智能決策236.1.4容量預測236.2 質量保障方向246.2.1異常檢測246.2.2故障診斷256.2.3故障預測256.2.4故障自愈266.3成本管理方向266.3.1成本優化26資源優化 27容量規劃 28性能優化 287、AIOps實施及關鍵技術 29數據采集 29數據處理 30數據存儲 30離線和在線計算 30面向AIOps的算法技術 30說明： 31附錄：案例 33案例1：海量時間序列異常檢測的技術方案 331、案例陳述 332、海量時間序列異常檢測的常見問題與解決方案 333、總結 34案例2：金融場景下的根源告警分析 351、案例概述 352、根源告警分析處理流程 353、根源告警分析處理方法 374、總結 39案例3：單機房故障自愈壓縮 401、案例概述 402、單機房故障止損流程 403、單機房故障自愈的常見問題和解決方案 414、單機房故障自愈的架構 435、總結 44背景介紹AIOps即智能運維，其目標是，基于已有的運維數據（日志、監控信息、應用信息等），通過機器學習的方式來進一步解決自動化運維所未能解決的問題，提高系統的預判能力、穩定性、降低IT成本，并提高企業的產品競爭力。Gartner在2016年時便提出了AIOps的概念，并預測到2020年，AIOps的采用率將會50%。AIOps為了讓國內眾多互聯網中小企業、特別是傳統企業可以共享、復用國內外頂尖互聯網的AIOps技術和能力，并能夠更快捷的進行AIOps相關產品選型，因此開展國內外第一個AIOps白皮書及相關標準制定工作。AIOpsAIOpsAIOpsAI1、整體介紹AIOps，即ArtificialIntelligenceforITOperations，智能運維，將人工智能應用于運維領域，基于已有的運維數據（日志、監控信息、應用信息等），通過機器學習的方式來進一步解決自動化運維沒辦法解決的問題。早期的運維工作大部分是由運維人員手工完成的，這被稱為手工運維或人肉運維。這種落后的生產方式，在互聯網業務快速擴張、人力成本高企的時代，難以維系。自動化運維因此應運而生。其基于用可被自動觸發的、預定義規則的腳本，來執行常見的、重復性的運維工作，從而減少人力成本，提高運維效率?？偟膩碚f，自動化運維可以認為是一種基于行業領域知識和運維場景領域知識的專家系統。隨著整個互聯網業務急劇膨脹，以及服務類型的復雜多樣，“基于人為指定規則”的專家系統逐漸變得力不從心。自動化運維的不足，日益凸顯。DevOps的出現，部分解決了上述問題。其強調從價值交付的全局視角，端到端打通軟件生命周期，建立基于微服務的單件流式的流水線。但DevOps更強調橫向融合及打通，較低階段的DevOps無力改變“基于認為指定規則”的既定事實。AIOps是DevOps在運維（技術運營）側的高階實現，兩者并不沖突。此部分可具體參考《研發運營一體化能力成熟度模型》。AIOps不依賴于人為指定規則，主張由機器學習算法自動地從海量運維數據（包括事件本身以及運維人員的人工處理日志）中不斷地學習，不斷地提煉并總結規則。AIOps在自動化運維的基礎上，增加了一個基于機器學習的大腦，指揮監測系統采集大腦決策所需的數據，做出分析、決策，并指揮自動化腳本去執行大腦的決策，從而達到運維系統的整體目標。AIOps基于自動化運維，將AI和運維很好的結合起來，其需要三方面的知識：行業領域知識：應用的行業，如互聯網、金融、電信、物流、能源電力、工業制造和智慧城市等，并熟悉生產實踐中的難題；運維場景領域知識：如指標監控、異常檢測、故障發現、故障止損、成本優化、容量規劃和性能優化等；機器學習：把實際問題轉化為算法問題，常用算法包括如聚類、決策樹、卷積神經網絡等。AIOps和DevOps兩者并不沖突，企業級DevOps涵括包括運維在內的整個軟件生命周期，AIOps是企業級DevOps在運維（技術運營）側的高階實現。AIOps是運維的發展必然，是自動化運維的下一個發展階段。Gartner相關報告預測AIOps201710%202050%。其應用行業，除了互聯網以外，還包括高性能計算、電信、金融、電力網絡、物聯網、醫療網絡和設備、航空航天、軍用設備及網絡等領域。本白皮書綜合國內領先的互聯網公司、金融企業及AIOps解決方案提供方的相關經驗，給出了一種企業級AIOps的AIOps理論方法和生產實踐，希望能幫助貴司快速、成功實施AIOps。本白皮書聚焦AI應用到Ops領域，不涉及自動化運維相關內容。2、AIOps目標AIOps，通俗的講，是對規則的AI化，即將人工總結運維規則的過程變為自動學習的過程。具體而言，是對我們平時運維工作中長時間積累形成的自動化運維和監控等能力，將其規AIAIOps的目標是，利用大數據、機器學習和其他分析技術，通過預防預測、個性化和動IT3、AIOps能力框架AIOpsAI“AIAIOps能力框架基于如下AIOps能力分級。AIOps能力分級可具體可描述為5級（圖-2）：AIAIAIAIAI主要運維場景均已實現流程化免干預AIAIOps有核心中樞AI，可以在成本、質量、效率間從容調整，達到業務不同生命周期對三個方面不同的指標要求，可實現多目標下的最優或按需最優。圖3-1AIOps能力分級AIAPIAPIAI（或稱學件），API這個智能規則是在一定量的數據下學習而來的，且具有“可重用”，“可演進”，“可了解”的特性，既可共享由專家利用數據訓練的算法，又可保護數據和隱私?！皩W件”（Learnware）一詞由南京大學周志華老師原創，學件（Learnware）=模型（model）+規約（specification），具有可重用、可演進、可了解的特性。很多人可能在自己的應用中已經建立了類似的模型，他們也很愿意找到一個地方把這些模型分享出去。這樣一來，一個新用戶想要應用，也許不用自己去建立一個，而是先到“學件”市場上找一找有沒有合適的，拿來直接或修改后使用。學件基于專家基礎上建立，所以比較容易得到專家級的結果，又因為共享出來的是模型，所以避免了數據泄露和隱私泄露的問題。基于上述AIOps能力分級，對應的AIOps能力框架如下。圖3-2AIOps能力框架相關關鍵運維場景的AIOps演進如下。2圖3-3關鍵運維場景的AIOps演講“可重用”的特性使得能夠獲取大量不同的樣本；“可演進”的特性使得可以適應環境的變化；“可了解”的特性使得能有效地了解模型的能力。4、AIOps平臺能力體系AIOpsAIOpsAIOpsAIOps平臺功能與一般的機器學習(或者數據挖掘)平臺極為類似，此類產品國外的比如Google的AutoML(/automl/)。圖4-1AIOps平臺功能模塊圖4-2AI建模服務能力如上圖4-1、圖4-2，具體的工具或者產品應具備以下功能或模塊：交互式建模功能：該功能支持用戶在平臺上交互式的進行模型的開發調試，通過簡單的方法配置完成模型的構建。算法庫：用戶可以在算法庫中找到常見常用的算法直接使用，算法按照用途分類，以供用戶方便的使用。樣本庫：樣本庫用于管理用戶的樣本數據，供用戶建模時使用，支持樣本的增刪改查等基本操作。數據準備：該功能支持用戶對數據進行相關的預處理操作，包括關聯、合并、分支路由、過濾等。靈活的計算邏輯表達：在基本常用的節點功能之外，用戶還需要自由的表達一些計算邏輯，該需求主要是通過讓用戶寫代碼或表達式來支持。可擴展的底層框架支持：平臺本身要能夠靈活的支持和兼容多種算法框架引擎，如Spark、TensorFlow等，以滿足不同的場景以及用戶的需求。數據分析探索：該功能是讓用戶能夠方便快捷地了解認識自己的數據，用戶只有基于對數據充分的認識與理解，才能很好的完成模型的構建。模型評估：對模型的效果進行評估的功能，用戶需要依據評估的結論對模型進行調整。參數以及算法搜索：該功能能夠自動快速的幫助用戶搜索算法的參數，對比不同的算法，幫助用戶選擇合適的算法以及參數，輔助用戶建模。場景模型：平臺針對特定場景沉淀的解決方案，這些場景都是通用常見的，用戶可以借鑒參考相關的解決方案以快速的解決實際問題實驗報告：模型除了部署運行，相關挖掘出來的結論也要能夠形成報告，以供用戶導出或動態發布使用。模型的版本管理：模型可能有對個不同的版本，線上運行的模型實例可能分屬各個不同的版本，版本管理支持模型不同版本構建發布以及模型實例版本切換升級等。模型部署應用：模型構建完成后需要發布應用，模型部署應用功能支持模型的實例化，以及相關計算任務的運行調度管理。數據質量保障：全鏈路的數據監控，能夠完整的掌控數據的整個生命周期，具備對丟失的數據執行回傳補錄的能力，保障數據的可用性。5、AIOps團隊角色圖5-1AIOps團隊角色及和外部的協同關系AIOpsAIAIOps運維工程師能從業務的技術運營中，提煉出智能化的需求點。在開發實施前能夠考慮好需求方案，規范數據格式。前期可以通過仿真手法探索和驗證方案可行性，起草合適的算法方案。運維開發工程師負責進行平臺相關功能和模塊的開發，以降低用戶使用門檻，提升用戶使用效率，并且將運維數據工程師交付的數據通過友好的方式展現給用戶。根據企業AIOps程度和能力的不同，運維開發工程師中的運維自動化平臺開發和運維數據平臺開發的權重不同。AI針對來自于運維工程師和算法方案進行理解和梳理，完成最終落地方案的輸出工作；在工程落地上能夠考慮好健壯性、魯棒性、敏捷性等，合理拆分任務，保障成果落地，以提升最終業務運營質量。6、AIOps常見應用場景AIOps圍繞質量保障、成本管理和效率提升的基本運維場景，逐步構建智能化運維場景。在質量保障方面，保障現網穩定運行細分為異常檢測、故障診斷、故障預測、故障自愈等基本場景；在成本管理方面，細分為指標監控，異常檢測，資源優化，容量規劃，性能優化等基本場景；在效率方面，分為智能預測，智能變更、智能問答，智能決策等基本場景（注：三者之間不是完全獨立的，是相互影響的，場景的劃分側重于主影響維度）。無論是效率提升，質量監控，還是成本優化，都離不開最基礎的數據采集，它是整個AIOpAIOps從數據采集的層面來看，運維數據的采集往往是實時的，數據采集端需要具備一定分析能力，綜合考慮用戶流量、隱私，服務器壓力等多個因素，盡可能的降低無效數據的采集，增加有價值信息的上報。從數據提取的層面來看，運維的數據是多樣化的，歷史數據，流數據，日志數據、網絡NLPAPP而成本優化和效率的提升同樣離不開數據的支撐。例如，開始實施成本優化的AIOPS前，需要盡可能多的收集目前的服務器，網絡設備，應用服務，數據庫等的性能信息，應用日志信息，tracing圖6-1AIOps常見應用場景枚舉以下為各個方向應用場景的能力描述。效率提升方向質量保障方向成本管理方向在這個階段，嘗試在變在這個階段，沒有成熟在這個階段，運維的成更，問答，決策，預測的單點應用，主要是手本管理方向還在嘗試引第一階段領域使用人工智能的能動運維、自動化運維和入人工智能，但是并沒（嘗試應用）力，但是并沒有形成有智能運維的嘗試階段，有成熟的單點應用，這效的單點應用，這個階這個階段可以聚焦于數個階段可以聚焦于數據段可以聚焦于數據采集據采集和可視化采集和可視化和可視化第二階段在這個階段，在一些小在這個階段，在一些單在這個階段，在一些?。▎吸c應用）的場景下，人工智能已點應用的場景下，人工的場景下，人工智能已經可以逐步發揮自己的智能已經開始逐步發揮經開始逐步發揮自己的能力，包括智能變更，自己的能力，包括指標能力，包括成本報表方智能問答，智能決策，監控，磁盤，網絡異常向，資源優化，容量規智能預測檢測等劃，性能優化等方向第三階段在這個階段，人工智能在這個階段，人工智能在這個階段，人工智能（串聯應用）已經將單點應用中的一已經將第二階段（單點已經將單點應用中的一些模塊串聯起來，可以應用）中的一些模塊串些模塊串聯在一起，可結合多個情況進行下一聯在一起，可以綜合多以根據成本、資源、容步的分析和操作個情況進行下一步的分量、性能的實際狀況進析和操作，包括多維下行下一步的分析和操作鉆分析尋找故障根因等方向第四階段在這個階段，人工智能在這個階段，人工智能在這個階段，人工智能（能力完備）能力完備，已經可以基已經基于故障的實際場的能力已經完備，能夠于實際場景實現性能優景實現故障定位，然后實現基于成本和資源的化，然后進行預測，變進行故障自愈等操作。實際場景實現成本的自更，問答，決策等操作比如根據版本質量分析主優化，然后進行智能改進的操作推斷是否需要版本回退，CDN自動調度等第五階段在這個階段，人工參與在這個階段，人工參與在這個階段，人工參與（終極AIOps）的成分已經很少，性能的部分已經很少，從故的成分已經很少，從成優化等整個流程由智能障發現到診斷到自愈整本報表方向，資源優大腦統一控制，并由自個流程由智能大腦統一化，容量規劃，性能優動化和智能化自主實施控制，并由自動化和智化性等整個流程由智能能化自主實施大腦統一控制，由自動化自主實施表6-1常見應用場景的分類分級能力概述效率提升方向運維效率的提升是運維系統的主要目標之一，自動化運維帶來的核心價值之一就是效率AIOps圖6-2舉例（大規模、高復雜性的系統運維，超越人+工具模式的承載力）圖6-3效率提升方向的常見應用場景質量保障是運維的基本場景之一，隨著業務的發展，運維系統也在不斷的演進，其規模復雜度、變更頻率非常大，技術更新也非常的快，與此同時，軟件的規模、調用關系、變更頻率也在逐漸增大。在這樣背景下，需要AIOps提供精準的業務質量感知、支撐用戶體驗優化、全面提升質量保障效率。智能變更變更是運維中的一種常見場景，DevOps通過串聯變更的各個環節形成流水線提升了效率，而AIOps不僅為變更流水線的各個環節引入了“系統決策”，也能更加持續地，精確地提供高效的變更質量管理。智能變更的系統決策來源于運維人員的運維經驗，這些經驗通過機器學習，知識圖譜等手段轉化成系統可學習和實施的數據模型。AIOps的智能變更可以應對以下場景：頻繁變更，高速發布的場景：運維人員會由于生理極限以及認知的局限難以應付這11010100AIOps根據每次變更的目標，狀態，上下文在變更過程中及時做出系統決策，幫助加速變更過程以及規避變更可能帶來的問題。大規模并行變更：隨著微服務架構的普及，實際上服務節點會成倍增長，原有幾個或幾十個節點，可能變成幾千甚至上萬的規模。人工驅動工具的模式不但受制于人的精力而被迫“串行化”，也制約了變更過程的監察以及變更結果驗證的準確性。AIOps智能問答運維的目標是為了支持穩定，可靠的業務運行，而業務與業務之間既可能有相似性，又可能有差異性。但由于知識背景和對業務的認知差異，往往出現以下情況：不同的業務人員或開發人員往往會詢問運維人員一些相似的問題，運維人員的答案也是非常類似的，但人力被重復消耗。面對同一個問題，運維人員的回答可能會出現差異（例如表達方式，措辭等），缺乏標準化，可能造成誤解。AIOps智能決策許多運維管理工作都需要各種各樣的決策，包括擴容，縮容，制定權重，調度，重啟等內容。那么可能面臨如下問題：運維人員可以根據自己的業務經驗制定相應的決策。但是，不同的業務有著各自的特點，不同的運維人員也有著自己的業務經驗。如何將運維人員的這些經驗有效地傳承是個問題。人的認知局限性，運維場景的復雜性可能導致最有經驗的運維人員遺漏掉某些“不起眼”的“重要細節”，顯然，準確的決策還依賴足夠充足的細節。AIOps容量預測運維工作不僅僅包含對當下的決策和處理，往往還需要根據業務的訴求對未來做出合理的規劃，包括擴容的預測，縮容的預測等。由于對未來的規劃時常存在不確定性，那么規劃過程往往需要大量的數據來支持，還需要大量的推演來確定。而人工預測的方式，一方面需要投入大量人力，另一方面運維人員的能力可能存在差異，使得推演的結果品質不盡一致。AIOps來，不但是人力得以節省，關鍵在于由于預測效率的提升，使得過去難以重復，耗時耗力的人工預測過程，變得可以應需而變，不斷修正預測結果，最終使業務訴求獲得最佳預測收益。質量保障方向質量保障是運維的基本場景之一，隨著業務的發展，運維系統也在不斷的演進，其規模復雜度、變更頻率非常大，技術更新也非常的快，與此同時，軟件的規模、調用關系、變更頻率也在逐漸增大。在這樣背景下，需要AIOps提供精準的業務質量感知、支撐用戶體驗優化、全面提升質量保障效率。圖6-4質量保障方向常見應用場景異常檢測運維系統中常見的兩大類監控數據源是：指標和文本。前者通常是時序數據，即包含指標采集時間和對應指標的值；后者通常是半結構化文本格式，如程序日志、TracingAI數據源異常檢測：數據源會因為一些不可避免的原因存在一些異常數據，這些異常數據占比雖然很低，但是往往會引起整個指標統計值的波動，使得統計結果偏離真實的用戶體驗。AIOps指標異常檢測：包括單指標異常檢測及多指標異常檢測。其中，單指標異常檢測：時間序列指標的異常檢測是發現問題的核心環節，傳統的靜態閾值檢測為主的方式，閾值太高，漏告警多，質量隱患難以發現，閾值太低，告警太多引發告警風暴，干擾業務運維人員的判斷。AIOps通過機器學習算法結合人工標注結果，實現自動學習閾值、自動調參，提高告警的精度和召回率，大幅度降低人工配置成本。其中，多指標異常檢測：運維過程中有些指標孤立來看可能并沒有異常，但是綜合多個指標來看，可能就是異常的。有些單指標表現是異常的，但是綜合多個指標來看可能又是正常的。AIOps文本異常檢測：文本日志常是在特點條件下觸發生成的，并遵循一定的模板，即半結構化文本。傳統的日志檢測有兩種方式：1、根據日志級別（如Info、Warning、Critical）進行報警，但由于其設定不準確，或不滿足實際需要，導致準確性差；2、通過設置規則，匹配日志中特定字符串進行報警，但該方法依賴依賴人工經驗，且只能檢測已知和確定模式的異常。AIOps故障診斷異常檢測實現了運維人員對數據的感知，有了數據之后，智能分析可以進一步解放運維人力，提高運維效率，故障診斷是智能分析的核心部分，主要包括基于人工故障庫的故障診斷和基于數據挖掘的故障診斷?；谌斯す收蠋斓墓收显\斷：日常運維過程中，運維人員積累了大量的人工經驗，運維過程中的大部分故障都是重復的、人工能夠識別的異常。重復問題的定位浪費了大量的人力，而且人工確認過程往往是比較滯后的。AIOps基于數據挖掘的故障診斷：人工經驗可能存在偏差，人工認為的原因可能并不是問題的根因，當有些故障首次發生沒有人工經驗可以借鑒的時候，故障根因也難以定位。尤其隨著微服務的發展，業務的組網變得更加復雜，模塊多帶來的消息路由多、依賴多，問題的定界定位分析更為困難，人工故障決策效率挑戰巨大。對于已知故障，AIOps故障預測故障的出現一般不是突然的，就比如網絡故障來說，往往從丟包開始到網絡不可用是有29300先兆以及1000起事故隱患，開展主動健康度檢查，針對重要特性數據進行預測算法學習，提前診斷故障，避免服務受損；常見場景：磁盤故障預測、網絡故障預測（根據交換機日志的交換機故障預測），內存泄露預測等等。故障自愈智能分析實現了故障的診斷和預測，智能執行根據智能分析的結果實現故障自愈。傳統的故障自愈的決策主要靠人的經驗，人的經驗能夠覆蓋的故障范圍是有限的，而且人工無法保7*24AIOps，CDN故障自愈是根據故障診斷的結果的輸出（問題定位和根因分析），進而進行影響評估，決定“解決故障”或“恢復系統”的過程。影響評估是對故障之后所產生的影響范圍（系統應用層面，業務執行層面，成本損失層面等等）輸出評估結果，并根據這個評估來決定要采用什么解決手段，甚至生成解決手段的執行計劃。成本管理方向每個公司的經營都離不開成本管理，成本管理包括成本核算，成本分析，成本決策，成本控制。本文不對財務上的成本管理做過多的闡述，主要從AIOps方向上在成本分析和決策中能發揮的作用來舉例說明。AIOpsIT成本優化

圖6-5成本管理方向的常見應用場景在成本優化方向，需要采取高可用的設計，提供更加合理的服務，包括接入層，業務層，存儲層等。在接入層需要提供合理的健康檢查機制，更加智能的負載均衡算法，限定流量等工作。在業務層不僅需要去除DB的強依賴，使用合理的降級，還要進行合理的壓測，監控以及動態的負載均衡。在存儲層需要做的事情是容災等關鍵工作。這樣的話，可以使得內部數據的質量得到大量提升，外部數據的優先接入和動態選擇。對于設備采集的周期控制這個問題來說，過晚的設備采購可能會影響到業務的正常上線或擴展，而過早的采購也可能造成成本的浪費。于是，AIOps需要建立合理的模型并建立更好的規劃，并據此計算更準確的設備采購計劃，也能對成本進行更好的控制。資源優化公司的運營成本優化項目一直是公司成本預算的關鍵一步。優化問題包括設備的優化，帶寬，碼率的優化等等。只有進行了合理的資源優化，才能夠使得公司的成本得到有效的控制。不同的服務的資源消耗類型是不一樣的，包括計算密集型，包括存儲密集型等等，而對于同一個服務在不同的時間點資源消耗也是不一樣的。對于一個企業來說，識別不同服務的資源消耗類型，識別每個服務的資源瓶頸，實現不同服務間的資源復用是降低成本的重要環節。根據資源應用的性能指標，可以大致分類成以下類別：計算密集型：CPU內存密集型：占用的內存使用率較高，如緩存服務；IOIOIO大型互聯網公司里動輒上千上萬的應用數，很容易有應用因為業務變化已經訪問量不斷縮減甚至已經下線，但是線上還占用著大量的資源，通過對應用的性能指標分析，篩選出各項性能指標都很低的應用，就可以識別出這些“被遺忘”的應用，就可以跟業務負責人進行核對進行縮容或者下線。dockerSpark，Storm行，充分利用這些業務應用的服務器的計算資源，提高整體利用率。AIOps容量規劃對于一個企業來說，容量的需求和業務的發展緊密相關。為了保障產品的正常運營，就需要對容量進行合理的預估。如果容量預留過多，則會造成資源浪費；反之，如果容量預留過少，則容易引發現網故障。而傳統的基于業務運維人員人工經驗容量預測手段不是十分有效，甚至大多數是“拍腦袋”的結果。不準確的容量預估也使得運維縮容和擴容顯得被動。通常來說，大型的互聯網公司都會有規模龐大的服務器集群，業務規模增加，新業務上線，過保機器替換都會導致有大量新采購的機器需要上線并擴容到集群中，對于一些特殊場景，如電商網站的大促活動，社交類網站的熱點新聞事件等，容量規劃更是一件必不可少的考驗?；顒又筚Y源往往又需要進行回收縮容操作，以節省運行的成本。以往的容量規劃往往是靠人工經驗來操作，現今AIOps性能優化性能的調優一直是運維的重要一環。如果性能優化得當，則會減少實際的運算量，減少內存方面的濫用，提升服務器的性能。運維人員在其中并不能保證及時發現所有潛在的性能問題，很多時候也不知道什么的系統配置才是最優的系統配置，什么時候的權重配比才能夠達到最佳的效果。AIOps能夠根據現網的實際情況，進行智能地調整配置，智能發現性能優化策略，提供智能化的優化服務。7、AIOps實施及關鍵技術Gartner，AIOpsIT大數據平臺：用于處理歷史和實時的數據ITIT機器學習：這里一般指無監督學習，可根據基于算法的分析結果來產生新的算法圖7-1AIOps產品或平臺要素圖說明3數據采集AIOps數據采集方式可分為無代理采集以及有代理采集兩種。其中無代理采集為服務端采集，支SNMP,JDBC,TCP/UDPSYSLOG,WebService，消息隊列采集等主流采集方式。有代理采集則用于本地文件或目錄采集，容器編排環境采集，以及腳本采集等。說明3本圖來源/blogs/what-is-aiops/并增加了最上行數據處理針對采集數據進行入庫前的預處理，數據從非結構化到結構化的解析，數據清洗，格式轉換，以及數據（如性能指標）的聚合計算，處理工作主要體現在幾個方面：數據字段提取：通過正則解析，KV規范化數據格式：對字段值類型重定義和格式轉換數據字段內容替換：基于業務規則替換數據字段內容，比如必要的數據脫敏過程，同時可實現無效數據、缺失數據的替換處理時間規范化：對各類運維數據中的時間字段進行格式統一轉換預聚合計算：對數值型字段或指標類數據基于滑動時間窗口進行聚合統計計算，如1CPU數據存儲AIOpsElasticSearch時間序列數據（性能指標），主要以時間維度進行查詢分析的數據,可選用主流的rrdtool、graphite、influxdb關系類數據，以及會聚集在基于關系進行遞歸查詢的數據可選擇圖數據庫數據的長期存儲和離線挖掘以及數據倉庫構建，可選用主流的Hadoop、Spark等大數據平臺離線和在線計算離線計算：針對存儲的歷史數據進行挖掘和批量計算的分析場景，用于大數據量的離線模型訓練和計算，如挖掘告警關聯關系，趨勢預測/容量預測模型計算，錯誤詞頻分析等場景。在線計算：對流處理中的實時數據進行在線計算，包括但不限于數據的查詢、預處理和統計分析，數據的實時異常檢測，以及部分支持實時更新模型的機器學習算法運用等。主流的流處理框架包括：SparkStreaming,KafkaStreaming,Flink,Storm等。面向AIOps的算法技術運維場景通常無法直接基于通用的機器學習算法以黑盒的方式解決，因此需要一些面向AIOpsAIOps指標趨勢預測：通過分析指標歷史數據，判斷未來一段時間指標趨勢及預測值，常見有Holt-Winters、時序數據分解、ARIMA等算法。該算法技術可用于異常檢測、容量預測、容量規劃等場景。KPI規模的指標異常檢測：在同一指標類別里采用同樣的異常檢測算法及參數，大幅降DBSCAN,K-medoids,CLARANS多指標聯動關聯挖掘:多指標聯動分析判斷多個指標是否經常一起波動或增長。該算法技術可用于構建故障傳播關系，從而應用于故障診斷。常見的算法有Pearsoncorrelation,Spearmancorrelation,KendallcorrelationKPI種類繁多，關聯關系復雜。指標與事件關聯挖掘:自動挖掘文本數據中的事件與指標之間的關聯關系（比如在ACPU）。該算法技術可用于構建故障傳播關系，從而應用于故障診斷。常見的算法有Pearsoncorrelation,J-measure,Two-sampletestKPI，KPI事件與事件關聯挖掘:分析異常事件之間的關聯關系，把歷史上經常一起發生的事件關聯在一起。該算法技術可用于構建故障傳播關系，從而應用于故障診斷。常見FP-Growth,Apriori，隨機森林等，但前提是異常檢測需要準確可靠。故障傳播關系挖掘：融合文本數據與指標數據，基于上述多指標聯動關聯挖掘、指標與事件關聯挖掘、事件與事件關聯挖掘等技術、由tracing推導出的模塊調用關系圖、輔以服務器與網絡拓撲，構建組件之間的故障傳播關系。該算法技術可以應用于故障診斷，其有效性主要取決于其基于的其它技術。說明：本文檔為第一次發布，更多內容如AIOps實踐路徑建議、AIOps效果度量等內容，因時間關系未能呈現，將在后續版本中予以更新。附錄：案例案例1：海量時間序列異常檢測的技術方案1、案例陳述在很多企業內部，工程師都會收集指標類的監控數據，也就是根據時間來采集相應的指標值。例如某款APP的在線用戶數，某個場景下的成功數和失敗數。隨著時間的遷移，整個系統會越來越復雜，監控的數據量會變得越來越大，就會形成海量的時間序列。在這種情況下，運維人員很難通過人工巡查的方式來查看所有的時間序列是否出現了異常，運維人員也無法通過配置規則的方式來解決海量時間序列異常檢測的問題。而且，在公司的人力成本有限的情況下，通過人工巡檢的方式也無法及時和有效地發現時間序列的異常。為了解決這類問題，我們針對騰訊SNG內外部的場景建設了基于機器學習的時間序列異常檢測方案。結合織云Monitor監控的具體場景，我們構建了全方位的時間序列異常檢測方案。同時，基于騰訊SNG豐富的數據集，已經實現了百萬條時間序列用少量時間序列檢測模型就可以實現異常檢測的能力。2、海量時間序列異常檢測的常見問題與解決方案【常見問題】在海量時間序列的異常檢測中，通過人工巡檢的方式明顯不足以及時發現時間序列的異常告警。在海量時間序列的異常檢測中，通過人工配置規則的方式，針對單條時間序列配置不同的參數，也是很難通過少量的人力配置完所有參數的。退一步講，就算通過人力配置好了告警參數，隨著時間的遷移，業務曲線的走勢也會發生變化，以前配置的告警策略有可能無法自動適應現在的環境，又需要投入巨大的人力去重新配置告警參數。【解決方案】圖1 時間序列異常檢測的技術框架上圖為時間序列異常檢測的技術框架，作為時間序列的異常檢測模型，整體框架分成三大板塊，第一個是離線訓練模塊，第二個是在線預測模塊，第三個是ABtest調優模塊。離線模塊，使用統計判別和無監督算法輸出疑似異常，例如使用 3-Sigma 原理，IsolationForest等算法。然后把輸出的疑似異常給人工進行審核，然后加入正負樣本庫。然后通過提取時間序列的特征，加入有監督算法進行離線訓練并且輸出模型；這里的有監督學習算法可以使用線性回歸，邏輯回歸，決策樹，隨機森林等算法。在線模塊，使用加載離線訓練好的模型，并且使用相應的有監督學習算法進行實時預測，也就是判斷正常還是異常。在這里，也需要加入人工校正的過程，把誤告和漏告的樣本加入樣本庫；其中的ABtest模塊是作為調優的工具，一旦有某個流量的模型效果好，就會全網發布，實時預測。3-Sigma，IsolationForest等算法。有監督學習算法可以使用線性回歸，邏輯回歸，決策樹，隨機森林等算法。3、總結針對海量時間序列異常檢測的問題，我們構建了基于機器學習的海量時間序列異常檢測方案。該方案把整個過程劃分成了無監督，有監督，人工決策三部分。通過運維人員的業務經驗，使用機器學習來主動學習人工經驗，來實現時間序列異常檢測的智能化。案例2：金融場景下的根源告警分析1、案例概述金融場景下對線上故障排查的時間要求非常嚴苛，核心業務要求在分鐘級能找到問題的原因，而應用數目和服務器數目又非常龐大，以京東金融為例，單個應用的實例數就有上千之多，應用的數量也是有幾千個。如此大的規模下，靠人工經驗去排查問題很難達到時效性要求，所以京東金融智能運維平臺引入了更智能化的方法來進行根源告警分析。2、根源告警分析處理流程根源告警分析是基于網絡拓撲，結合調用鏈，通過時間相關性、權重、機器學習等算法，將告警進行分類篩選，快速找到告警根源的一種方式。它能從大量的告警中找到問題的根源，因此大大縮短了故障排查及恢復時間。處理步驟：告警過濾(將告警中不重要的告警以及重復告警過濾掉)生成派生告警(根源關聯關系生成各類派生告警)告警關聯(同一個時間窗內,不同類型派生告警是否存在關聯)權重計算(根據預先設置的各類告警的權重，計算成為根源告警的可能性)生成根源告警(將權重最大的派生告警標記為根源告警)根源告警合并(若多類告警計算出的根源告警相同，則將其合并)根據歷史告警處理知識庫，找到類似根源告警的處理方案，智能地給出解決方案。圖1京東金融根源告警架構圖舉例來說：假設多個系統通過RPC進行服務調用，調用關系如下：D系統->C系統->B系統->A系統當A系統查詢數據庫出現查詢超時后，告警會層層往前推進，導致B、C、D系統均有N個超時告警產生。此時，ROOT分析可以將告警進行收斂，直接分析出根源告警為A系統訪問數據庫異常，導致A、B、C、D多個系統異常。這樣，就避免了處理人員和每個系統開發人員溝通，輔助處理人員快速定位問題根源、提高了平均解決時間(MTTR)。如下圖所示：圖2京東金融根源告警調用鏈關系圖圖3京東金融根源告警明細圖3、根源告警分析處理方法根源告警分析的方法主要分為強關聯分析與機器學習兩類。1)強關聯數據分析強關聯指的是已知確定的關聯關系。如：應用之間的調用鏈關系數據庫與應用服務器網絡設備與網絡設備、網絡設備與應用服務器宿主機與虛擬機關系等若在同一個時間窗內，有多個強關聯的設備或應用服務器同時告警，則大概率認為告警之間存在關聯關系。在權重算法中，有一個重要的規則，鏈路上存在連續的告警可能存在關聯，越靠后的應用越可能是根源。現在我們根據例子，分別計算各類根源告警。繼續使用上面的例子，D應用->C應用->B應用->A應用->數據庫的異常的情況。首先是計算數據庫根源告警。根據數據庫關聯關系，會派生數據庫類型的數據庫告警、A應用告警。還會派生一條應用類型的A應用數據庫異常告警。根據數據庫派生告警以及數據庫與應用的關聯關系及權重，可以得出數據庫異常導致A應用查詢超時。接下來是計算應用根源告警。根據調用關系，我們先計算出連續多個應用告警的鏈路。當前D->C->B->A四個應用都有派生告警，滿足此規則。然后，找到最靠后的告警應用，也就是A應用。列舉時間窗口內所有A應用的派生告警(可能存在多種派生告警，根據權重計算根源)，將權重最高的派生告警標記為根源告警。比如：A系統內部有2種類型派生告警，分別是數據庫告警、GC告警。根據權重計算規則，數據庫告警為90，GC告警10，也就是說數據庫異常告警權重最高。這時由于數據庫根源告警和調用鏈根源告警一致，會將兩種類型的告警合并。最后得出結論：數據庫異常導致A、B、C、D系統告警。2)機器學習根源分析強關聯數據分析是對已知告警的關聯關系，直接進行根源告警分析。但是有些時候，關聯關系是未知的，這時就需要通過機器學習算法，找到告警事件之間的隱含聯系，再進行根源告警進行故障預測。目前，京東金融智能運維平臺中使用到的主要是以下兩大類機器學習算法。1、關聯規則算法關聯規則算法主要進行了Apriori算法和FPGrowth兩類算法的實踐。這兩類功能相似，都可以發現頻繁項集。經過實測，FPGrowth比Apriori更高效一些。我們按一定的時間間隔劃分時間窗，計算每個時間窗內，各種告警一起出現的頻率，找出各類告警之間的關聯，最終可按分析出的關聯關系，生成根源告警。關聯規則算法的優點在于理解和實現起來比較簡單。缺點是效率比較低，靈活度也不夠高。2、神經網絡算法循環神經網絡(簡稱RNN)是一個和時間序列有關系的神經網絡，對單張圖片而言，像素信息是靜止的，而對于一段話而言，里面的詞的組成是有先后的，而且通常情況下，后續的詞和前面的詞有順序關聯。這時候，卷積神經網絡通常很難處理這種時序關聯信息，而RNN卻能有效地進行處理。隨著時間間隔的增大，RNN這個問題需要用到LongShortTerm網絡(簡稱LSTM)，它通過刻意的設計來避免長期依賴問題。LSTM在實踐中默認可以記住長期的信息，而不需要付出很大代價。對于某類故障引起的大量告警之間，存在著時間相關性。將歷史派生告警作為輸入，將根源告警類型作為輸出。通過LSTM提取派生告警特征，建立告警相關性分析模型。這樣就可以實時將符合特征的派生告警，劃分到同一類根源告警中，幫助用戶快速定位問題。需要說明的是金融本身的業務特點決定了對第三方存在依賴性，因此告警本身的隨機性較大，客觀上導致學習樣本的質量不高，需要長期的積累和修正才能達到比較好的效果，因此對于根源告警，如果有條件取到強關聯關系，建議使用強關聯分析，能達到事半功倍的效果。4、總結針對金融場景下業務規模大，應用關系復雜，依賴層次多，排查問題困難的問題，我們建設了具有智能化的根源告警分析的方案。通過告警過濾，生成派生告警，告警關聯，權重計算，生成根源告警，根源告警合并，關聯歷史告警處理知識庫的方案進行處理，通過強關聯分析和機器學習的分析方法，找到根源告警，并智能地給出解決方案。案例3：單機房故障自愈壓縮1、案例概述在大型互聯網公司中，單機房故障因為其故障時間長、影響范圍大，一直是互聯網公司運維人員的心頭之痛。在傳統的運維方式中，由于故障感知判斷、流量調度決策的復雜性，通常需要人工止損，但人工處理的時效性會影響服務的恢復速度，同時人的不可靠性也可能導致問題擴大。為了解決這類問題，我們針對百度內外部網絡環境建設了基于智能流量調度的單機房故障自愈能力。結合外網運營商鏈路監測、內網鏈路質量監測與業務指標監控構建了全方位故障發現能力，基于百度統一前端(BFE)與百度名字服務(BNS)實現了智能流量調度與自動止損能力。同時，基于實時容量與實時流量調度自動止損策略與管控風險，實現了任意單機房故障時業務均可快速自愈的效果。當前此解決方案已覆蓋百度眾多核心業務的單機房故障自愈場景。2、單機房故障止損流程一個完整的故障處理生命周期包括感知、止損決策、止損、定位和根因分析、解決問題五個階段。單機房故障自愈主要覆蓋從感知到止損階段，其中感知階段依賴監控系統的故障發現能力，止損階段依賴流量調度系統的調度能力。我們來具體看下百度的監控系統與流量調度系統是如何在單機房故障止損場景中起作用。1．故障發現：百度監控平臺百度監控平臺，針對單機房止損過程中的可用性場景，覆蓋故障發現、止損決策、問題定位各階段的監控。針對單機房止損依賴的容量管理場景，提供資源類監控采集，為容量規劃、擴縮容提供數據支持。數據采集覆蓋了從運營商外網鏈路、百度內部網絡設備/鏈路、服務/實例、機器/容器的全方位數據。智能異常檢測、趨勢預測、多維度分析、關聯分析、服務和鏈路拓撲分析，實現故障的精準發現和定位。2.故障止損：百度流量調度平臺針對百度的網絡架構和業務架構（參考圖11-4），我們將流量調度拆分為三層：接入層、服務層、依賴層。接入層：從外網用戶發起請求經過運營商網絡到百度統一前端（BFE）DNSBFEBFEGSLB依賴層：內網上下游業務之間的流量轉發使用百度名字服務（BNS）進行流量調度。對于單機房止損場景來說，DNS