企業(yè)AIOps智能運維方案白皮書

1、 企業(yè)AIOps智能運維方案白皮書目錄背景介紹4組織單位4編寫成員5發(fā)起人5顧問5編審成員5本版本核心編寫成員61、整體介紹82、AIOps 目標103、AIOps 能力框架114、AIOps 平臺能力體系145、 AIOps 團隊角色175.1 運維工程師175.2 運維開發(fā)工程師175.3 運維 AI 工程師176、AIOps 常見應(yīng)用場景196.1效率提升方向216.1.1 智能變更226.1.2 智能問答226.1.3 智能決策236.1.4 容量預(yù)測236.2質(zhì)量保障方向246.2.1 異常檢測246.2.2 故障診斷256.2.3 故障預(yù)測256.2.4 故障自愈266.3 成本管

2、理方向266.3.1 成本優(yōu)化26資源優(yōu)化27容量規(guī)劃28性能優(yōu)化28 HYPERLINK l _TOC_250022 7、AIOps 實施及關(guān)鍵技術(shù)29 HYPERLINK l _TOC_250021 數(shù)據(jù)采集29 HYPERLINK l _TOC_250020 數(shù)據(jù)處理30 HYPERLINK l _TOC_250019 數(shù)據(jù)存儲30 HYPERLINK l _TOC_250018 離線和在線計算30 HYPERLINK l _TOC_250017 面向 AIOps 的算法技術(shù)30 HYPERLINK l _TOC_250016 說明：31 HYPERLINK l _TOC_250015

3、附錄：案例33 HYPERLINK l _TOC_250014 案例 1：海量時間序列異常檢測的技術(shù)方案33 HYPERLINK l _TOC_250013 1、案例陳述33 HYPERLINK l _TOC_250012 2、海量時間序列異常檢測的常見問題與解決方案33 HYPERLINK l _TOC_250011 3、總結(jié)34 HYPERLINK l _TOC_250010 案例 2：金融場景下的根源告警分析35 HYPERLINK l _TOC_250009 1、案例概述35 HYPERLINK l _TOC_250008 2、根源告警分析處理流程35 HYPERLINK l _TOC

4、_250007 3、根源告警分析處理方法37 HYPERLINK l _TOC_250006 4、總結(jié)39 HYPERLINK l _TOC_250005 案例 3：單機房故障自愈壓縮40 HYPERLINK l _TOC_250004 1、案例概述40 HYPERLINK l _TOC_250003 2、單機房故障止損流程40 HYPERLINK l _TOC_250002 3、單機房故障自愈的常見問題和解決方案41 HYPERLINK l _TOC_250001 4、單機房故障自愈的架構(gòu)43 HYPERLINK l _TOC_250000 5、總結(jié)44背景介紹AIOps 即智能運維，其目標

5、是，基于已有的運維數(shù)據(jù)（日志、監(jiān)控信息、應(yīng)用信息等），通過機器學(xué)習的方式來進一步解決自動化運維所未能解決的問題，提高系統(tǒng)的預(yù)判能力、穩(wěn)定性、降低 IT 成本，并提高企業(yè)的產(chǎn)品競爭力。Gartner 在 2016 年時便提出了 AIOps 的概念，并預(yù)測到 2020 年，AIOps 的采用率將會達到 50%。AIOps 目前在國內(nèi)外領(lǐng)先的互聯(lián)網(wǎng)企業(yè)開始被逐漸應(yīng)用，也是近年來國內(nèi)外被普遍看好的新技術(shù)。為了讓國內(nèi)眾多互聯(lián)網(wǎng)中小企業(yè)、特別是傳統(tǒng)企業(yè)可以共享、復(fù)用國內(nèi)外頂尖互聯(lián)網(wǎng)的AIOps 技術(shù)和能力，并能夠更快捷的進行 AIOps 相關(guān)產(chǎn)品選型，因此開展國內(nèi)外第一個 AIOps 白皮書及相關(guān)標準制定

6、工作。AIOps 標準將分成兩大類，分別適用于企業(yè)內(nèi)部的AIOps 能力建設(shè)與評估、及企業(yè)購置相關(guān) AIOps 產(chǎn)品的認證評估，使得 AI 真正落地應(yīng)用于運維，造福于企業(yè)。1、整體介紹AIOps，即 Artificial Intelligence for IT Operations，智能運維，將人工智能應(yīng)用于運維領(lǐng)域，基于已有的運維數(shù)據(jù)（日志、監(jiān)控信息、應(yīng)用信息等），通過機器學(xué)習的方式來進一步解決自動化運維沒辦法解決的問題。早期的運維工作大部分是由運維人員手工完成的，這被稱為手工運維或人肉運維。這種落后的生產(chǎn)方式，在互聯(lián)網(wǎng)業(yè)務(wù)快速擴張、人力成本高企的時代，難以維系。自動化運維因此應(yīng)運而生。其基

7、于用可被自動觸發(fā)的、預(yù)定義規(guī)則的腳本，來執(zhí)行常見的、重復(fù)性的運維工作，從而減少人力成本，提高運維效率。總的來說，自動化運維可以認為是一種基于行業(yè)領(lǐng)域知識和運維場景領(lǐng)域知識的專家系統(tǒng)。隨著整個互聯(lián)網(wǎng)業(yè)務(wù)急劇膨脹，以及服務(wù)類型的復(fù)雜多樣，“基于人為指定規(guī)則”的專家系統(tǒng)逐漸變得力不從心。自動化運維的不足，日益凸顯。DevOps 的出現(xiàn)，部分解決了上述問題。其強調(diào)從價值交付的全局視角，端到端打通軟件生命周期，建立基于微服務(wù)的單件流式的流水線。但 DevOps 更強調(diào)橫向融合及打通，較低階段的 DevOps 無力改變“基于認為指定規(guī)則”的既定事實。AIOps 是 DevOps 在運維（技術(shù)運營）側(cè)的高階

8、實現(xiàn)，兩者并不沖突。此部分可具體參考研發(fā)運營一體化能力成熟度模型。AIOps 不依賴于人為指定規(guī)則，主張由機器學(xué)習算法自動地從海量運維數(shù)據(jù)（包括事件本身以及運維人員的人工處理日志）中不斷地學(xué)習，不斷地提煉并總結(jié)規(guī)則。AIOps 在自動化運維的基礎(chǔ)上，增加了一個基于機器學(xué)習的大腦，指揮監(jiān)測系統(tǒng)采集大腦決策所需的數(shù)據(jù)，做出分析、決策，并指揮自動化腳本去執(zhí)行大腦的決策，從而達到運維系統(tǒng)的整體目標。AIOps 基于自動化運維，將 AI 和運維很好的結(jié)合起來，其需要三方面的知識：行業(yè)領(lǐng)域知識：應(yīng)用的行業(yè)，如互聯(lián)網(wǎng)、金融、電信、物流、能源電力、工業(yè)制造和智慧城市等，并熟悉生產(chǎn)實踐中的難題；運維場景領(lǐng)域知識

9、：如指標監(jiān)控、異常檢測、故障發(fā)現(xiàn)、故障止損、成本優(yōu)化、容量規(guī)劃和性能優(yōu)化等；機器學(xué)習：把實際問題轉(zhuǎn)化為算法問題，常用算法包括如聚類、決策樹、卷積神經(jīng)網(wǎng)絡(luò)等。AIOps 和 DevOps 兩者并不沖突，企業(yè)級 DevOps 涵括包括運維在內(nèi)的整個軟件生命周期，AIOps 是 企業(yè)級 DevOps 在運維（技術(shù)運營）側(cè)的高階實現(xiàn)。AIOps 是運維的發(fā)展必然，是自動化運維的下一個發(fā)展階段。Gartner 相關(guān)報告預(yù)測AIOps 的全球部署率將從 2017 年的 10%增加到 2020 年的 50%。其應(yīng)用行業(yè)，除了互聯(lián)網(wǎng)以外， 還包括高性能計算、電信、金融、電力網(wǎng)絡(luò)、物聯(lián)網(wǎng)、 醫(yī)療網(wǎng)絡(luò)和設(shè)備、航空

10、航天、軍用設(shè)備及網(wǎng)絡(luò)等領(lǐng)域。本白皮書綜合國內(nèi)領(lǐng)先的互聯(lián)網(wǎng)公司、金融企業(yè)及 AIOps 解決方案提供方的相關(guān)經(jīng)驗， 給出了一種企業(yè)級 AIOps 的 AIOps 理論方法和生產(chǎn)實踐，希望能幫助貴司快速、成功實施AIOps。本白皮書聚焦 AI 應(yīng)用到 Ops 領(lǐng)域，不涉及自動化運維相關(guān)內(nèi)容。2、AIOps 目標AIOps，通俗的講，是對規(guī)則的 AI 化，即將人工總結(jié)運維規(guī)則的過程變?yōu)樽詣訉W(xué)習的過程。具體而言，是對我們平時運維工作中長時間積累形成的自動化運維和監(jiān)控等能力，將其規(guī)則配置部分，進行自學(xué)習的“去規(guī)則化”改造，最終達到終極目標：“有 AI 調(diào)度中樞管理的， 質(zhì)量、成本、效率三者兼顧的無人值守

11、運維，力爭所運營系統(tǒng)的綜合收益最大化”。AIOps 的目標是，利用大數(shù)據(jù)、機器學(xué)習和其他分析技術(shù)，通過預(yù)防預(yù)測、個性化和動態(tài)分析，直接和間接增強 IT 業(yè)務(wù)的相關(guān)技術(shù)能力，實現(xiàn)所維護產(chǎn)品或服務(wù)的更高質(zhì)量、合理成本及高效支撐。3、AIOps 能力框架AIOps 的建設(shè)可以先由無到局部單點探索、再到單點能力完善，形成解決某個局部問題的運維 AI“學(xué)件”，再由多個具有 AI 能力的單運維能力點組合成一個智能運維流程。AIOps 能力框架基于如下 AIOps 能力分級。AIOps 能力分級可具體可描述為 5 級（圖-2）：開始嘗試應(yīng)用 AI 能力，還無較成熟單點應(yīng)用具備單場景的 AI 運維能力，可以初

12、步形成供內(nèi)部使用的學(xué)件有由多個單場景 AI 運維模塊串聯(lián)起來的流程化 AI 運維能力，可以對外提供可靠的運維 AI 學(xué)件主要運維場景均已實現(xiàn)流程化免干預(yù)AI 運維能力，可以對外提供可靠的AIOps 服務(wù)。有核心中樞 AI，可以在成本、質(zhì)量、效率間從容調(diào)整，達到業(yè)務(wù)不同生命周期對三個方面不同的指標要求，可實現(xiàn)多目標下的最優(yōu)或按需最優(yōu)。圖 3-1 AIOps 能力分級學(xué)件，亦稱 AI 運維組件，類似程序中的 API 或公共庫，但 API 及公共庫不含具體業(yè)務(wù)數(shù)據(jù)，只是某種算法，而 AI 運維組件（或稱學(xué)件），則是在類似 API 的基礎(chǔ)上，兼具對某個運維場景智能化解決的“記憶”能力，將處理這個場景的

13、智能規(guī)則保存在了這個組件中。這個智能規(guī)則是在一定量的數(shù)據(jù)下學(xué)習而來的，且具有“可重用”，“可演進”，“可了解”的特性，既可共享由專家利用數(shù)據(jù)訓(xùn)練的算法，又可保護數(shù)據(jù)和隱私?！皩W(xué)件”（Learnware）一詞由南京大學(xué)周志華老師原創(chuàng)，學(xué)件（Learnware）= 模型（ model ） + 規(guī)約（ specification ），具有可重用、可演進、可了解的特性。很多人可能在自己的應(yīng)用中已經(jīng)建立了類似的模型，他們也很愿意找到一個地方把這些模型分享出去。這樣一來，一個新用戶想要應(yīng)用，也許不用自己去建立一個，而是先到“學(xué)件” 市場上找一找有沒有合適的，拿來直接或修改后使用。學(xué)件基于專家基礎(chǔ)上建立，所

14、以比較容 易得到專家級的結(jié)果，又因為共享出來的是模型，所以避免了數(shù)據(jù)泄露和隱私泄露的問題?；谏鲜?AIOps 能力分級，對應(yīng)的 AIOps 能力框架如下。圖 3-2 AIOps 能力框架相關(guān)關(guān)鍵運維場景的 AIOps 演進如下。2圖 3-3 關(guān)鍵運維場景的 AIOps 演講2“可重用”的特性使得能夠獲取大量不同的樣本；“可演進”的特性使得可以適應(yīng)環(huán)境的變化；“可了解”的特性使得能有效地了解模型的能力。4、AIOps 平臺能力體系A(chǔ)IOps 工作平臺能力體系主要功能是為AIOps 的實際場景建設(shè)落地而提供功能的工具或者產(chǎn)品平臺，其主要目的是降低 AIOps 的開發(fā)人員成本，提升開發(fā)效率，規(guī)范工

15、作交付質(zhì)量。AIOps 平臺功能與一般的機器學(xué)習( 或者數(shù)據(jù)挖掘) 平臺極為類似，此類產(chǎn)品國外的比如 Google 的 AutoML(/automl/)。圖 4-1 AIOps 平臺功能模塊圖 4-2 AI 建模服務(wù)能力如上圖 4-1、圖 4-2，具體的工具或者產(chǎn)品應(yīng)具備以下功能或模塊：交互式建模功能：該功能支持用戶在平臺上交互式的進行模型的開發(fā)調(diào)試，通過簡單的方法配置完成模型的構(gòu)建。算法庫：用戶可以在算法庫中找到常見常用的算法直接使用，算法按照用途分類， 以供用戶方便的使用。樣本庫：樣本庫用于管理用戶的樣本數(shù)據(jù)，供用戶建模時使用，支持樣本的增刪改查等基本操作。數(shù)據(jù)準備：該功能支持用戶對數(shù)據(jù)進

16、行相關(guān)的預(yù)處理操作，包括關(guān)聯(lián)、合并、分支路由、過濾等。靈活的計算邏輯表達：在基本常用的節(jié)點功能之外，用戶還需要自由的表達一些計算邏輯，該需求主要是通過讓用戶寫代碼或表達式來支持?？蓴U展的底層框架支持：平臺本身要能夠靈活的支持和兼容多種算法框架引擎，如Spark、TensorFlow 等，以滿足不同的場景以及用戶的需求。數(shù)據(jù)分析探索：該功能是讓用戶能夠方便快捷地了解認識自己的數(shù)據(jù)，用戶只有基于對數(shù)據(jù)充分的認識與理解，才能很好的完成模型的構(gòu)建。模型評估：對模型的效果進行評估的功能，用戶需要依據(jù)評估的結(jié)論對模型進行調(diào)整。參數(shù)以及算法搜索：該功能能夠自動快速的幫助用戶搜索算法的參數(shù)，對比不同的算法，幫

17、助用戶選擇合適的算法以及參數(shù)，輔助用戶建模。場景模型：平臺針對特定場景沉淀的解決方案，這些場景都是通用常見的，用戶可以借鑒參考相關(guān)的解決方案以快速的解決實際問題實驗報告：模型除了部署運行，相關(guān)挖掘出來的結(jié)論也要能夠形成報告，以供用戶導(dǎo)出或動態(tài)發(fā)布使用。模型的版本管理：模型可能有對個不同的版本，線上運行的模型實例可能分屬各個不同的版本，版本管理支持模型不同版本構(gòu)建發(fā)布以及模型實例版本切換升級等。模型部署應(yīng)用：模型構(gòu)建完成后需要發(fā)布應(yīng)用，模型部署應(yīng)用功能支持模型的實例化，以及相關(guān)計算任務(wù)的運行調(diào)度管理。數(shù)據(jù)質(zhì)量保障：全鏈路的數(shù)據(jù)監(jiān)控，能夠完整的掌控數(shù)據(jù)的整個生命周期，具備對丟失的數(shù)據(jù)執(zhí)行回傳補錄的

18、能力，保障數(shù)據(jù)的可用性。5、 AIOps 團隊角色圖 5-1 AIOps 團隊角色及和外部的協(xié)同關(guān)系A(chǔ)IOps 團隊內(nèi)部人員根據(jù)職能可分為三類團隊，分別為運維工程師團隊、運維開發(fā)工程師團隊和運維 AI 工程師團隊，他們在 AIOps 相關(guān)工作中分別扮演不同的角色，三者缺一不可。運維工程師能從業(yè)務(wù)的技術(shù)運營中，提煉出智能化的需求點。在開發(fā)實施前能夠考慮好需求方案， 規(guī)范數(shù)據(jù)格式。前期可以通過仿真手法探索和驗證方案可行性，起草合適的算法方案。運維開發(fā)工程師負責進行平臺相關(guān)功能和模塊的開發(fā)，以降低用戶使用門檻，提升用戶使用效率，并且將運維數(shù)據(jù)工程師交付的數(shù)據(jù)通過友好的方式展現(xiàn)給用戶。根據(jù)企業(yè) AIO

19、ps 程度和能力的不同，運維開發(fā)工程師中的運維自動化平臺開發(fā)和運維數(shù)據(jù)平臺開發(fā)的權(quán)重不同。運維 AI 工程師針對來自于運維工程師和算法方案進行理解和梳理，完成最終落地方案的輸出工作；在工程落地上能夠考慮好健壯性、魯棒性、敏捷性等，合理拆分任務(wù)，保障成果落地，以提升最終業(yè)務(wù)運營質(zhì)量。6、AIOps 常見應(yīng)用場景AIOps 圍繞質(zhì)量保障、成本管理和效率提升的基本運維場景，逐步構(gòu)建智能化運維場景。在質(zhì)量保障方面，保障現(xiàn)網(wǎng)穩(wěn)定運行細分為異常檢測、故障診斷、故障預(yù)測、故障自愈等基本場景；在成本管理方面，細分為指標監(jiān)控，異常檢測，資源優(yōu)化，容量規(guī)劃，性能優(yōu)化等基本場景；在效率方面，分為智能預(yù)測，智能變更、

20、智能問答，智能決策等基本場景（注：三者之間不是完全獨立的，是相互影響的，場景的劃分側(cè)重于主影響維度）。無論是效率提升，質(zhì)量監(jiān)控，還是成本優(yōu)化，都離不開最基礎(chǔ)的數(shù)據(jù)采集，它是整個AIOp 的基石。 AIOps 提高運維生產(chǎn)力的一種方式就是把質(zhì)量處理流程中的人力部分盡可能的都替換成機器來做。在機器的分析過程中，系統(tǒng)運行過程中的每一個部件都需要數(shù)據(jù)支持。無論是海量數(shù)據(jù)采集、還是數(shù)據(jù)提取方面都離不開大數(shù)據(jù)技術(shù)。從數(shù)據(jù)采集的層面來看，運維數(shù)據(jù)的采集往往是實時的，數(shù)據(jù)采集端需要具備一定分析能力，綜合考慮用戶流量、隱私，服務(wù)器壓力等多個因素，盡可能的降低無效數(shù)據(jù)的采集，增加有價值信息的上報。從數(shù)據(jù)提取的層面

21、來看，運維的數(shù)據(jù)是多樣化的，歷史數(shù)據(jù)，流數(shù)據(jù)，日志數(shù)據(jù)、網(wǎng)絡(luò)數(shù)據(jù)、算法數(shù)據(jù)、文本和 NLP 文檔數(shù)據(jù)，以及 APP 數(shù)據(jù)、瀏覽器數(shù)據(jù)、業(yè)務(wù)系統(tǒng)運營指標數(shù)據(jù)等，從這些海量的數(shù)據(jù)中提取出正真有價值的指標化數(shù)據(jù)并可視化是進一步分析決策的前提條件。而成本優(yōu)化和效率的提升同樣離不開數(shù)據(jù)的支撐。例如，開始實施成本優(yōu)化的 AIOPS 前，需要盡可能多的收集目前的服務(wù)器，網(wǎng)絡(luò)設(shè)備，應(yīng)用服務(wù)，數(shù)據(jù)庫等的性能信息，應(yīng)用日志信息，tracing 信息，以便對成本優(yōu)化的效果進行評估。例如，在搭建智能客服機器人的時候，就需要提供充足的問題庫和相應(yīng)的答案才能夠建立好一個較優(yōu)的模型。圖 6-1 AIOps 常見應(yīng)用場景枚舉

22、以下為各個方向應(yīng)用場景的能力描述。效率提升方向質(zhì)量保障方向成本管理方向在這個階段，嘗試在變在這個階段，沒有成熟在這個階段，運維的成更，問答，決策，預(yù)測的單點應(yīng)用，主要是手本管理方向還在嘗試引第一階段領(lǐng)域使用人工智能的能動運維、自動化運維和入人工智能，但是并沒（嘗試應(yīng)用）力，但是并沒有形成有智能運維的嘗試階段，有成熟的單點應(yīng)用，這效的單點應(yīng)用，這個階這個階段可以聚焦于數(shù)個階段可以聚焦于數(shù)據(jù)段可以聚焦于數(shù)據(jù)采集據(jù)采集和可視化采集和可視化和可視化第二階段在這個階段，在一些小在這個階段，在一些單在這個階段，在一些?。▎吸c應(yīng)用）的場景下，人工智能已點應(yīng)用的場景下，人工的場景下，人工智能已經(jīng)可以逐步發(fā)揮自

23、己的智能已經(jīng)開始逐步發(fā)揮經(jīng)開始逐步發(fā)揮自己的能力，包括智能變更，自己的能力，包括指標能力，包括成本報表方智能問答，智能決策，監(jiān)控，磁盤，網(wǎng)絡(luò)異常向，資源優(yōu)化，容量規(guī)智能預(yù)測檢測等劃，性能優(yōu)化等方向第三階段在這個階段，人工智能在這個階段，人工智能在這個階段，人工智能（串聯(lián)應(yīng)用）已經(jīng)將單點應(yīng)用中的一已經(jīng)將第二階段（單點已經(jīng)將單點應(yīng)用中的一些模塊串聯(lián)起來，可以應(yīng)用）中的一些模塊串些模塊串聯(lián)在一起，可結(jié)合多個情況進行下一聯(lián)在一起，可以綜合多以根據(jù)成本、資源、容步的分析和操作個情況進行下一步的分量、性能的實際狀況進析和操作，包括多維下行下一步的分析和操作鉆分析尋找故障根因等方向第四階段在這個階段，人工智

24、能在這個階段，人工智能在這個階段，人工智能（能力完備）能力完備，已經(jīng)可以基已經(jīng)基于故障的實際場的能力已經(jīng)完備，能夠于實際場景實現(xiàn)性能優(yōu)景實現(xiàn)故障定位，然后實現(xiàn)基于成本和資源的化，然后進行預(yù)測，變進行故障自愈等操作。實際場景實現(xiàn)成本的自更，問答，決策等操作比如根據(jù)版本質(zhì)量分析主優(yōu)化，然后進行智能改進的操作推斷是否需要版本回退，CDN 自動調(diào)度等第五階段在這個階段，人工參與在這個階段，人工參與在這個階段，人工參與（終極 AIOps）的成分已經(jīng)很少，性能的部分已經(jīng)很少，從故的成分已經(jīng)很少，從成優(yōu)化等整個流程由智能障發(fā)現(xiàn)到診斷到自愈整本報表方向，資源優(yōu) 大腦統(tǒng)一控制，并由自個流程由智能大腦統(tǒng)一化，容量

25、規(guī)劃，性能優(yōu)動化和智能化自主實施控制，并由自動化和智化性等整個流程由智能能化自主實施大腦統(tǒng)一控制，由自動化自主實施表 6-1 常見應(yīng)用場景的分類分級能力概述效率提升方向運維效率的提升是運維系統(tǒng)的主要目標之一，自動化運維帶來的核心價值之一就是效率提升，而 AIOps 會推動運維效率提升到一個新的高度。其本質(zhì)的原因是自動化運維依然是人+自動化工具的模式，人工決策與實施依然是主要驅(qū)動力，但人會受到自身生理極限以及認知局限的限制，無法持續(xù)地面向大規(guī)模、高復(fù)雜性的系統(tǒng)提供高質(zhì)量的運維效率。而 AIOps 系統(tǒng)通過深度洞察能力為運維提供持續(xù)的，高質(zhì)量的效率運轉(zhuǎn)。圖 6-2 舉例（大規(guī)模、高復(fù)雜性的系統(tǒng)運維

26、，超越人+工具模式的承載力）圖 6-3 效率提升方向的常見應(yīng)用場景質(zhì)量保障是運維的基本場景之一，隨著業(yè)務(wù)的發(fā)展，運維系統(tǒng)也在不斷的演進，其規(guī)模復(fù)雜度、變更頻率非常大，技術(shù)更新也非常的快，與此同時，軟件的規(guī)模、調(diào)用關(guān)系、變更頻率也在逐漸增大。在這樣背景下，需要 AIOps 提供精準的業(yè)務(wù)質(zhì)量感知、支撐用戶體驗優(yōu)化、全面提升質(zhì)量保障效率。智能變更變更是運維中的一種常見場景，DevOps 通過串聯(lián)變更的各個環(huán)節(jié)形成流水線提升了效率， 而 AIOps 不僅為變更流水線的各個環(huán)節(jié)引入了“系統(tǒng)決策”，也能更加持續(xù)地，精確地提供高效的變更質(zhì)量管理。智能變更的系統(tǒng)決策來源于運維人員的運維經(jīng)驗，這些經(jīng)驗通過機器

27、學(xué)習， 知識圖譜等手段轉(zhuǎn)化成系統(tǒng)可學(xué)習和實施的數(shù)據(jù)模型。AIOps 的智能變更可以應(yīng)對以下場景：頻繁變更，高速發(fā)布的場景：運維人員會由于生理極限以及認知的局限難以應(yīng)付這 樣的場景。例如，每天從 1 到 10 次變更時，運維人員通過自動化運維系統(tǒng)尚可應(yīng)對， 如果由 10 次升級到 100 次，甚至更多，就難以高效的，準確的應(yīng)對了。AIOps 可以根據(jù)每次變更的目標，狀態(tài)，上下文在變更過程中及時做出系統(tǒng)決策，幫助加速變 更過程以及規(guī)避變更可能帶來的問題。大規(guī)模并行變更：隨著微服務(wù)架構(gòu)的普及，實際上服務(wù)節(jié)點會成倍增長，原有幾個或幾十個節(jié)點，可能變成幾千甚至上萬的規(guī)模。人工驅(qū)動工具的模式不但受制于人的

28、精力而被迫“串行化”，也制約了變更過程的監(jiān)察以及變更結(jié)果驗證的準確性。AIOps 則可以并行驅(qū)動更大規(guī)模的變更過程，而且變更監(jiān)察以及結(jié)果驗證都會被更準確的完成。智能問答運維的目標是為了支持穩(wěn)定，可靠的業(yè)務(wù)運行，而業(yè)務(wù)與業(yè)務(wù)之間既可能有相似性，又可能有差異性。但由于知識背景和對業(yè)務(wù)的認知差異，往往出現(xiàn)以下情況：不同的業(yè)務(wù)人員或開發(fā)人員往往會詢問運維人員一些相似的問題，運維人員的答案也是非常類似的，但人力被重復(fù)消耗。面對同一個問題，運維人員的回答可能會出現(xiàn)差異（例如表達方式，措辭等），缺乏標準化，可能造成誤解。AIOps 智能問答系統(tǒng)通過機器學(xué)習，自然語言處理等技術(shù)來學(xué)習運維人員的回復(fù)文本，構(gòu)建標

29、準問答知識庫，從而在遇到類似問題的時候給出標準的，統(tǒng)一的回復(fù)。這樣，不僅可以有效地節(jié)省運維人員的人力成本，還能夠使得提問得到更加及時的回復(fù)。智能決策許多運維管理工作都需要各種各樣的決策，包括擴容，縮容，制定權(quán)重，調(diào)度，重啟等內(nèi)容。那么可能面臨如下問題：運維人員可以根據(jù)自己的業(yè)務(wù)經(jīng)驗制定相應(yīng)的決策。但是，不同的業(yè)務(wù)有著各自的特點，不同的運維人員也有著自己的業(yè)務(wù)經(jīng)驗。如何將運維人員的這些經(jīng)驗有效地傳承是個問題。人的認知局限性，運維場景的復(fù)雜性可能導(dǎo)致最有經(jīng)驗的運維人員遺漏掉某些“不起眼”的“重要細節(jié)”，顯然，準確的決策還依賴足夠充足的細節(jié)。AIOps 智能決策一方面可以將運維人員的決策過程數(shù)據(jù)化，

30、構(gòu)建決策支持知識庫，從而實現(xiàn)經(jīng)驗積累；另一方面，由于系統(tǒng)掌握了從全局到細節(jié)的數(shù)據(jù)，再結(jié)合決策支持知識庫，可以為更加準確的決策提供最有力的支撐。容量預(yù)測運維工作不僅僅包含對當下的決策和處理，往往還需要根據(jù)業(yè)務(wù)的訴求對未來做出合理的規(guī)劃，包括擴容的預(yù)測，縮容的預(yù)測等。由于對未來的規(guī)劃時常存在不確定性，那么規(guī)劃過程往往需要大量的數(shù)據(jù)來支持，還需要大量的推演來確定。而人工預(yù)測的方式，一方面需要投入大量人力，另一方面運維人員的能力可能存在差異，使得推演的結(jié)果品質(zhì)不盡一致。AIOps 智能預(yù)測借助大數(shù)據(jù)和機器學(xué)習能力，結(jié)合運維人員的有效評估經(jīng)驗，甚至業(yè)務(wù)發(fā)展模式以及政策等，對目標場景實現(xiàn)高效的推演過程，最

31、終使預(yù)測結(jié)果趨近合理范圍。這樣一來，不但是人力得以節(jié)省，關(guān)鍵在于由于預(yù)測效率的提升，使得過去難以重復(fù)，耗時耗力的人工預(yù)測過程，變得可以應(yīng)需而變，不斷修正預(yù)測結(jié)果，最終使業(yè)務(wù)訴求獲得最佳預(yù)測收益。質(zhì)量保障方向質(zhì)量保障是運維的基本場景之一，隨著業(yè)務(wù)的發(fā)展，運維系統(tǒng)也在不斷的演進，其規(guī)模復(fù)雜度、變更頻率非常大，技術(shù)更新也非常的快，與此同時，軟件的規(guī)模、調(diào)用關(guān)系、變更頻率也在逐漸增大。在這樣背景下，需要 AIOps 提供精準的業(yè)務(wù)質(zhì)量感知、支撐用戶體驗優(yōu)化、全面提升質(zhì)量保障效率。圖 6-4 質(zhì)量保障方向常見應(yīng)用場景異常檢測運維系統(tǒng)中常見的兩大類監(jiān)控數(shù)據(jù)源是：指標和文本。前者通常是時序數(shù)據(jù)，即包含指標采

32、集時間和對應(yīng)指標的值；后者通常是半結(jié)構(gòu)化文本格式，如程序日志、Tracing 等。隨著系統(tǒng)規(guī)模的變大、復(fù)雜度的提高、監(jiān)控覆蓋的完善，監(jiān)控數(shù)據(jù)量越來越大，運維人員無法從海量監(jiān)控數(shù)據(jù)中發(fā)現(xiàn)質(zhì)量問題。智能化的異常檢測就是要通過 AI 算法，自動、實時、準確地從監(jiān)控數(shù)據(jù)中發(fā)現(xiàn)異常，為后續(xù)的診斷、自愈提供基礎(chǔ)。異常檢測的常見任務(wù)包括對數(shù)據(jù)源的異常檢測，保證數(shù)據(jù)質(zhì)量，以及對指標和文本的異常檢測。數(shù)據(jù)源異常檢測：數(shù)據(jù)源會因為一些不可避免的原因存在一些異常數(shù)據(jù)，這些異常數(shù)據(jù)占比雖然很低，但是往往會引起整個指標統(tǒng)計值的波動，使得統(tǒng)計結(jié)果偏離真實的用戶體驗。AIOps 需要自動、實時的動態(tài)設(shè)置閾值，去除數(shù)據(jù)源中的

33、異常數(shù)據(jù)干擾，并能夠區(qū)分系統(tǒng)真正發(fā)生異常時候的故障數(shù)據(jù)和數(shù)據(jù)源本身的異常數(shù)據(jù)，這種判斷依賴于一些外部信息。指標異常檢測：包括單指標異常檢測及多指標異常檢測。其中，單指標異常檢測：時間序列指標的異常檢測是發(fā)現(xiàn)問題的核心環(huán)節(jié)，傳統(tǒng)的靜態(tài)閾值檢測為主的方式，閾值太高，漏告警多，質(zhì)量隱患難以發(fā)現(xiàn)，閾值太低，告警太多引發(fā)告警風暴，干擾業(yè)務(wù)運維人員的判斷。AIOps 通過機器學(xué)習算法結(jié)合人工標注結(jié)果，實現(xiàn)自動學(xué)習閾值、自動調(diào)參，提高告警的精度和召回率，大幅度降低人工配置成本。其中，多指標異常檢測：運維過程中有些指標孤立來看可能并沒有異常，但是綜合多個指標來看，可能就是異常的。有些單指標表現(xiàn)是異常的，但是綜

34、合多個指標來看可能又是正常的。AIOps 需要能夠綜合多個指標綜合評判系統(tǒng)指標異常，提高告警的準確性。文本異常檢測：文本日志常是在特點條件下觸發(fā)生成的，并遵循一定的模板，即半結(jié)構(gòu)化文本。傳統(tǒng)的日志檢測有兩種方式：1、根據(jù)日志級別（如 Info、Warning、Critical）進行報警，但由于其設(shè)定不準確，或不滿足實際需要，導(dǎo)致準確性差；2、通過設(shè)置規(guī)則，匹配日志中特定字符串進行報警，但該方法依賴依賴人工經(jīng)驗，且只能檢測已知和確定模式的異常。AIOps 需要通過自然語言處理、聚類、頻繁模式挖掘等手段，自動識別日志出現(xiàn)的反常模式；結(jié)合人工反饋和標注，不斷進行優(yōu)化、完善。故障診斷異常檢測實現(xiàn)了運維

35、人員對數(shù)據(jù)的感知，有了數(shù)據(jù)之后，智能分析可以進一步解放運維人力，提高運維效率，故障診斷是智能分析的核心部分，主要包括基于人工故障庫的故障診斷和基于數(shù)據(jù)挖掘的故障診斷?；谌斯す收蠋斓墓收显\斷：日常運維過程中，運維人員積累了大量的人工經(jīng)驗，運維過程中的大部分故障都是重復(fù)的、人工能夠識別的異常。重復(fù)問題的定位浪費了大量的人力， 而且人工確認過程往往是比較滯后的。AIOps 把人工專家經(jīng)驗固化下來，對常見問題實現(xiàn)分鐘級內(nèi)自動診斷，運維人員收到的告警信息中，就需要包括故障定位的結(jié)果信息?；跀?shù)據(jù)挖掘的故障診斷：人工經(jīng)驗可能存在偏差，人工認為的原因可能并不是問題的根因，當有些故障首次發(fā)生沒有人工經(jīng)驗可以

36、借鑒的時候，故障根因也難以定位。尤其隨著微服務(wù)的發(fā)展，業(yè)務(wù)的組網(wǎng)變得更加復(fù)雜，模塊多帶來的消息路由多、依賴多，問題的定界定位分析更為困難，人工故障決策效率挑戰(zhàn)巨大。 對于已知故障，AIOps 能夠綜合故障數(shù)據(jù)和人工經(jīng)驗自動提取故障特征，生成故障特征庫，自動匹配，自動定位故障；對于未知故障，AIOps 需要根據(jù)故障特征推演出可能的故障原因，并在人工確認后加入的故障特征庫。故障預(yù)測故障的出現(xiàn)一般不是突然的，就比如網(wǎng)絡(luò)故障來說，往往從丟包開始到網(wǎng)絡(luò)不可用是有一個演變的過程，依據(jù)海恩法則：每一起嚴重事故的背后，必然有 29 次輕微事故和 300 起未遂先兆以及 1000 起事故隱患，開展主動健康度檢查

37、，針對重要特性數(shù)據(jù)進行預(yù)測算法學(xué)習，提前診斷故障，避免服務(wù)受損；常見場景：磁盤故障預(yù)測、網(wǎng)絡(luò)故障預(yù)測（根據(jù)交換機日志的交換機故障預(yù)測），內(nèi)存泄露預(yù)測等等。故障自愈智能分析實現(xiàn)了故障的診斷和預(yù)測，智能執(zhí)行根據(jù)智能分析的結(jié)果實現(xiàn)故障自愈。傳統(tǒng)的故障自愈的決策主要靠人的經(jīng)驗，人的經(jīng)驗?zāi)軌蚋采w的故障范圍是有限的，而且人工無法保證 7*24 隨時可以立即決策與處理。AIOps 能夠提供完善的自動化平臺，在故障智能分析之后， 自動決策，實現(xiàn)自愈，常見場景：版本升級回退，DNS 自動切換，CDN 智能調(diào)度，智能流量調(diào)度等。故障自愈是根據(jù)故障診斷的結(jié)果的輸出（問題定位和根因分析），進而進行影響評估， 決定“解

38、決故障”或“恢復(fù)系統(tǒng)”的過程。影響評估是對故障之后所產(chǎn)生的影響范圍（系統(tǒng)應(yīng)用層面，業(yè)務(wù)執(zhí)行層面，成本損失層面等等）輸出評估結(jié)果，并根據(jù)這個評估來決定要采用什么解決手段，甚至生成解決手段的執(zhí)行計劃。成本管理方向每個公司的經(jīng)營都離不開成本管理，成本管理包括成本核算，成本分析，成本決策，成本控制。本文不對財務(wù)上的成本管理做過多的闡述，主要從 AIOps 方向上在成本分析和決策中能發(fā)揮的作用來舉例說明。AIOps 通過智能化的資源優(yōu)化，容量管理，性能優(yōu)化實現(xiàn) IT 成本的態(tài)勢感知、支撐成本規(guī)劃與優(yōu)化、提升成本管理效率。成本優(yōu)化圖 6-5 成本管理方向的常見應(yīng)用場景在成本優(yōu)化方向，需要采取高可用的設(shè)計，

39、提供更加合理的服務(wù)，包括接入層，業(yè)務(wù) 層，存儲層等。在接入層需要提供合理的健康檢查機制，更加智能的負載均衡算法，限定流量等工作。在業(yè)務(wù)層不僅需要去除 DB 的強依賴，使用合理的降級，還要進行合理的壓測，監(jiān)控以及動態(tài)的負載均衡。在存儲層需要做的事情是容災(zāi)等關(guān)鍵工作。這樣的話，可以使得內(nèi)部數(shù)據(jù)的質(zhì)量得到大量提升，外部數(shù)據(jù)的優(yōu)先接入和動態(tài)選擇。對于設(shè)備采集的周期控制這個問題來說，過晚的設(shè)備采購可能會影響到業(yè)務(wù)的正常上線或擴展，而過早的采購也可能造成成本的浪費。于是，AIOps 需要建立合理的模型并建立更好的規(guī)劃，并據(jù)此計算更準確的設(shè)備采購計劃，也能對成本進行更好的控制。資源優(yōu)化公司的運營成本優(yōu)化項目

40、一直是公司成本預(yù)算的關(guān)鍵一步。優(yōu)化問題包括設(shè)備的優(yōu)化，帶寬，碼率的優(yōu)化等等。只有進行了合理的資源優(yōu)化，才能夠使得公司的成本得到有效的控 制。不同的服務(wù)的資源消耗類型是不一樣的，包括計算密集型，包括存儲密集型等等，而對于同一個服務(wù)在不同的時間點資源消耗也是不一樣的。對于一個企業(yè)來說，識別不同服務(wù)的資源消耗類型，識別每個服務(wù)的資源瓶頸，實現(xiàn)不同服務(wù)間的資源復(fù)用是降低成本的重要環(huán)節(jié)。根據(jù)資源應(yīng)用的性能指標，可以大致分類成以下類別：計算密集型：CPU 使用率較高，常見于需要大量計算資源的搜索，推薦，數(shù)學(xué)計算等場景中；內(nèi)存密集型：占用的內(nèi)存使用率較高，如緩存服務(wù)；IO 密集型：網(wǎng)絡(luò) IO 繁忙或者磁盤

41、IO 操作繁忙，常見于爬蟲，消息管道，分布式存儲等服務(wù)中。大型互聯(lián)網(wǎng)公司里動輒上千上萬的應(yīng)用數(shù)，很容易有應(yīng)用因為業(yè)務(wù)變化已經(jīng)訪問量不斷縮減甚至已經(jīng)下線，但是線上還占用著大量的資源，通過對應(yīng)用的性能指標分析，篩選出各項性能指標都很低的應(yīng)用，就可以識別出這些“被遺忘” 的應(yīng)用，就可以跟業(yè)務(wù)負責人進行核對進行縮容或者下線。目前大部分公司都已經(jīng)使用了虛擬化或者 docker 技術(shù)，同一個物理機上的不同虛擬機或容器已經(jīng)進行了很好的細粒度資源分配和隔離，所以對于同一臺物理機可以進行混合部署不同類型的應(yīng)用，如計算密集型應(yīng)用，存儲密集型應(yīng)用，IO 密集型應(yīng)用混部在同一臺物理機上，以提高更大的資源利用率，甚至一

42、定量的“超賣”（通過共享部分資源，實現(xiàn)分配的總的資源數(shù)超過物理機的資源數(shù)）。對于一些靈活的計算任務(wù)，如 Spark，Storm 等計算類任務(wù)，還可以使用按時分配的策略，如白天運行在部分服務(wù)器上，而且夜間需要運行大批量計算的報表等任務(wù)時，利用業(yè)務(wù)應(yīng)用夜間資源使用率低的特點，把部分任務(wù)分配到業(yè)務(wù)應(yīng)用所在的服務(wù)器上運行，充分利用這些業(yè)務(wù)應(yīng)用的服務(wù)器的計算資源，提高整體利用率。AIOps 通過密度管理、特性管理、碎片管理、木桶管理等方法，優(yōu)化企業(yè)不同服務(wù)器的配比，發(fā)現(xiàn)并優(yōu)化資源中的短板，提供不同服務(wù)的混合部署建議，最終實現(xiàn)智能化降成本方案分析服務(wù)。容量規(guī)劃對于一個企業(yè)來說，容量的需求和業(yè)務(wù)的發(fā)展緊密相

43、關(guān)。為了保障產(chǎn)品的正常運營，就需要對容量進行合理的預(yù)估。如果容量預(yù)留過多，則會造成資源浪費；反之，如果容量預(yù)留過少，則容易引發(fā)現(xiàn)網(wǎng)故障。而傳統(tǒng)的基于業(yè)務(wù)運維人員人工經(jīng)驗容量預(yù)測手段不是十分有效，甚至大多數(shù)是“拍腦袋”的結(jié)果。不準確的容量預(yù)估也使得運維縮容和擴容顯得被動。通常來說，大型的互聯(lián)網(wǎng)公司都會有規(guī)模龐大的服務(wù)器集群，業(yè)務(wù)規(guī)模增加，新業(yè)務(wù)上線，過保機器替換都會導(dǎo)致有大量新采購的機器需要上線并擴容到集群中，對于一些特殊場 景，如電商網(wǎng)站的大促活動，社交類網(wǎng)站的熱點新聞事件等，容量規(guī)劃更是一件必不可少的考驗?；顒又筚Y源往往又需要進行回收縮容操作，以節(jié)省運行的成本。以往的容量規(guī)劃往往是靠人工經(jīng)

44、驗來操作，現(xiàn)今 AIOps 將根據(jù)業(yè)務(wù)目標的需求，結(jié)合服務(wù)數(shù)據(jù)，整合運維人員的業(yè)務(wù)經(jīng)驗，建立精準容量規(guī)劃模型，從而精確預(yù)測各個業(yè)務(wù)的容量， 讓其使用率達到最優(yōu)。性能優(yōu)化性能的調(diào)優(yōu)一直是運維的重要一環(huán)。如果性能優(yōu)化得當，則會減少實際的運算量，減少內(nèi)存方面的濫用，提升服務(wù)器的性能。運維人員在其中并不能保證及時發(fā)現(xiàn)所有潛在的性能問題，很多時候也不知道什么的系統(tǒng)配置才是最優(yōu)的系統(tǒng)配置，什么時候的權(quán)重配比才能夠達到最佳的效果。AIOps 能夠根據(jù)現(xiàn)網(wǎng)的實際情況，進行智能地調(diào)整配置，智能發(fā)現(xiàn)性能優(yōu)化策略，提供智能化的優(yōu)化服務(wù)。7、AIOps 實施及關(guān)鍵技術(shù)為了實現(xiàn)成本管理、效率提升、質(zhì)量保障的場景，根據(jù)

45、Gartner 的定義，AIOps 產(chǎn)品或平臺應(yīng)包含下圖所示的要素：數(shù)據(jù)源：大量并且種類繁多的 IT 基礎(chǔ)設(shè)施大數(shù)據(jù)平臺：用于處理歷史和實時的數(shù)據(jù)計算與分析：通過已有的 IT 數(shù)據(jù)產(chǎn)生新的數(shù)據(jù)，例如數(shù)據(jù)清洗、去除噪聲等算法：用于計算和分析，以產(chǎn)生 IT 運維場景所需要的結(jié)果機器學(xué)習：這里一般指無監(jiān)督學(xué)習，可根據(jù)基于算法的分析結(jié)果來產(chǎn)生新的算法圖 7-1 AIOps 產(chǎn)品或平臺要素圖 說明3數(shù)據(jù)采集數(shù)據(jù)采集負責將智能運維所需要的數(shù)據(jù)接入至 AIOps 平臺，所接入的運維數(shù)據(jù)類型一般包括(但不限于)日志數(shù)據(jù)，性能指標數(shù)據(jù)，網(wǎng)絡(luò)抓包數(shù)據(jù)，用戶行為數(shù)據(jù)，告警數(shù)據(jù)，配置管理數(shù)據(jù)，運維流程類數(shù)據(jù)等。數(shù)據(jù)采

46、集方式可分為無代理采集以及有代理采集兩種。其中無代理采集為服務(wù)端采集，支持 SNMP, 數(shù)據(jù)庫 JDBC, TCP/UDP 監(jiān)聽, SYSLOG, Web Service，消息隊列采集等主流采集方式。有代理采集則用于本地文件或目錄采集，容器編排環(huán)境采集，以及腳本采集等。說明3 本圖來源 https:/ HYPERLINK /blogs/what-is-aiops/ /blogs/what-is-aiops/ 并增加了最上行數(shù)據(jù)處理針對采集數(shù)據(jù)進行入庫前的預(yù)處理，數(shù)據(jù)從非結(jié)構(gòu)化到結(jié)構(gòu)化的解析，數(shù)據(jù)清洗，格式轉(zhuǎn)換，以及數(shù)據(jù)（如性能指標）的聚合計算，處理工作主要體現(xiàn)在幾個方面：數(shù)據(jù)字段提?。和ㄟ^正則

47、解析，KV 解析，分隔符解析等解析方式提取字段規(guī)范化數(shù)據(jù)格式：對字段值類型重定義和格式轉(zhuǎn)換數(shù)據(jù)字段內(nèi)容替換：基于業(yè)務(wù)規(guī)則替換數(shù)據(jù)字段內(nèi)容，比如必要的數(shù)據(jù)脫敏過程， 同時可實現(xiàn)無效數(shù)據(jù)、缺失數(shù)據(jù)的替換處理時間規(guī)范化：對各類運維數(shù)據(jù)中的時間字段進行格式統(tǒng)一轉(zhuǎn)換預(yù)聚合計算：對數(shù)值型字段或指標類數(shù)據(jù)基于滑動時間窗口進行聚合統(tǒng)計計算，如取 1 分鐘 CPU 平均值數(shù)據(jù)存儲數(shù)據(jù)存儲是 AIOps 平臺的數(shù)據(jù)落地的地方，可以根據(jù)不同的數(shù)據(jù)類型以及數(shù)據(jù)的消費和使用場景，可選擇不同的數(shù)據(jù)存儲方式。數(shù)據(jù)主要可分為如下幾類：數(shù)據(jù)需要進行實時全文檢索，分詞搜索?？蛇x用主流的 ElasticSearch 引擎時間序列數(shù)

48、據(jù)（性能指標），主要以時間維度進行查詢分析的數(shù)據(jù), 可選用主流的rrdtool、graphite、influxdb 等時序數(shù)據(jù)庫關(guān)系類數(shù)據(jù)，以及會聚集在基于關(guān)系進行遞歸查詢的數(shù)據(jù)可選擇圖數(shù)據(jù)庫數(shù)據(jù)的長期存儲和離線挖掘以及數(shù)據(jù)倉庫構(gòu)建，可選用主流的 Hadoop、Spark 等大數(shù)據(jù)平臺離線和在線計算離線計算：針對存儲的歷史數(shù)據(jù)進行挖掘和批量計算的分析場景，用于大數(shù)據(jù)量的離線模型訓(xùn)練和計算，如挖掘告警關(guān)聯(lián)關(guān)系，趨勢預(yù)測/容量預(yù)測模型計算，錯誤詞頻分析等場景。在線計算：對流處理中的實時數(shù)據(jù)進行在線計算，包括但不限于數(shù)據(jù)的查詢、預(yù)處理和統(tǒng)計分析，數(shù)據(jù)的實時異常檢測，以及部分支持實時更新模型的機器學(xué)習

49、算法運用等。主流的流處理框架包括：Spark Streaming, Kafka Streaming, Flink, Storm 等。面向 AIOps 的算法技術(shù)運維場景通常無法直接基于通用的機器學(xué)習算法以黑盒的方式解決，因此需要一些面向AIOps 的算法技術(shù)，作為解決具體運維場景的基礎(chǔ)。有時一個算法技術(shù)還可用于支撐另外一個算法技術(shù)。 常見的面向 AIOps 的算法技術(shù)包括：指標趨勢預(yù)測：通過分析指標歷史數(shù)據(jù)，判斷未來一段時間指標趨勢及預(yù)測值，常見有 Holt-Winters、時序數(shù)據(jù)分解、ARIMA 等算法。該算法技術(shù)可用于異常檢測、容量預(yù)測、容量規(guī)劃等場景。指標聚類: 根據(jù)曲線的相似度把多個

50、 KPI 聚成多個類別。該算法技術(shù)可以應(yīng)用于大規(guī)模的指標異常檢測：在同一指標類別里采用同樣的異常檢測算法及參數(shù)，大幅降低訓(xùn)練和檢測開銷。常見的算法有 DBSCAN, K-medoids, CLARANS 等，應(yīng)用的挑戰(zhàn)是數(shù)據(jù)量大，曲線模式復(fù)雜。多指標聯(lián)動關(guān)聯(lián)挖掘: 多指標聯(lián)動分析判斷多個指標是否經(jīng)常一起波動或增長。該算法技術(shù)可用于構(gòu)建故障傳播關(guān)系，從而應(yīng)用于故障診斷。常見的算法有 Pearson correlation, Spearman correlation, Kendall correlation 等，應(yīng)用的挑戰(zhàn)為 KPI 種類繁多，關(guān)聯(lián)關(guān)系復(fù)雜。指標與事件關(guān)聯(lián)挖掘: 自動挖掘文本數(shù)據(jù)中

51、的事件與指標之間的關(guān)聯(lián)關(guān)系（ 比如在程序 A 每次啟動的時候 CPU 利用率就上一個臺階）。該算法技術(shù)可用于構(gòu)建故障傳播關(guān)系，從而應(yīng)用于故障診斷。常見的算法有 Pearson correlation, J-measure, Two-sample test 等，應(yīng)用的挑戰(zhàn)為事件和 KPI 種類繁多，KPI 測量時間粒度過粗會導(dǎo)致判斷相關(guān)、先后、單調(diào)關(guān)系困難。事件與事件關(guān)聯(lián)挖掘: 分析異常事件之間的關(guān)聯(lián)關(guān)系，把歷史上經(jīng)常一起發(fā)生的事件關(guān)聯(lián)在一起。該算法技術(shù)可用于構(gòu)建故障傳播關(guān)系，從而應(yīng)用于故障診斷。常見的算法有 FP-Growth, Apriori，隨機森林等，但前提是異常檢測需要準確可靠。故障傳

52、播關(guān)系挖掘：融合文本數(shù)據(jù)與指標數(shù)據(jù)，基于上述多指標聯(lián)動關(guān)聯(lián)挖掘、指標與事件關(guān)聯(lián)挖掘、事件與事件關(guān)聯(lián)挖掘等技術(shù)、由 tracing 推導(dǎo)出的模塊調(diào)用關(guān)系圖、輔以服務(wù)器與網(wǎng)絡(luò)拓撲，構(gòu)建組件之間的故障傳播關(guān)系。該算法技術(shù)可以應(yīng)用于故障診斷，其有效性主要取決于其基于的其它技術(shù)。說明：本文檔為第一次發(fā)布，更多內(nèi)容如 AIOps 實踐路徑建議、AIOps 效果度量等內(nèi)容，因時間關(guān)系未能呈現(xiàn)，將在后續(xù)版本中予以更新。附錄：案例案例 1：海量時間序列異常檢測的技術(shù)方案1、案例陳述在很多企業(yè)內(nèi)部，工程師都會收集指標類的監(jiān)控數(shù)據(jù)，也就是根據(jù)時間來采集相應(yīng)的指標值。例如某款 APP 的在線用戶數(shù)，某個場景下的成功數(shù)

53、和失敗數(shù)。隨著時間的遷移，整個系統(tǒng)會越來越復(fù)雜，監(jiān)控的數(shù)據(jù)量會變得越來越大，就會形成海量的時間序列。在這種情況下， 運維人員很難通過人工巡查的方式來查看所有的時間序列是否出現(xiàn)了異常，運維人員也無法通過配置規(guī)則的方式來解決海量時間序列異常檢測的問題。而且，在公司的人力成本有限的情況下，通過人工巡檢的方式也無法及時和有效地發(fā)現(xiàn)時間序列的異常。為了解決這類問題，我們針對騰訊 SNG 內(nèi)外部的場景建設(shè)了基于機器學(xué)習的時間序列異常檢測方案。結(jié)合織云 Monitor 監(jiān)控的具體場景，我們構(gòu)建了全方位的時間序列異常檢測方案。同時，基于騰訊 SNG 豐富的數(shù)據(jù)集，已經(jīng)實現(xiàn)了百萬條時間序列用少量時間序列檢測模型

54、就可以實現(xiàn)異常檢測的能力。2、海量時間序列異常檢測的常見問題與解決方案【常見問題】在海量時間序列的異常檢測中，通過人工巡檢的方式明顯不足以及時發(fā)現(xiàn)時間序列的異常告警。在海量時間序列的異常檢測中，通過人工配置規(guī)則的方式，針對單條時間序列配置不同的參數(shù)， 也是很難通過少量的人力配置完所有參數(shù)的。退一步講，就算通過人力配置好了告警參數(shù)，隨 著時間的遷移，業(yè)務(wù)曲線的走勢也會發(fā)生變化，以前配置的告警策略有可能無法自動適應(yīng)現(xiàn)在 的環(huán)境，又需要投入巨大的人力去重新配置告警參數(shù)?！窘鉀Q方案】圖 1時間序列異常檢測的技術(shù)框架上圖為時間序列異常檢測的技術(shù)框架，作為時間序列的異常檢測模型，整體框架分成三大板塊，第一

55、個是離線訓(xùn)練模塊，第二個是在線預(yù)測模塊，第三個是 AB test 調(diào)優(yōu)模塊。離線模塊，使用統(tǒng)計判別和無監(jiān)督算法輸出疑似異常，例如使用3-Sigma原理， Isolation Forest 等算法。然后把輸出的疑似異常給人工進行審核，然后加入正負樣本庫。然后通過提取時間序列的特征，加入有監(jiān)督算法進行離線訓(xùn)練并且輸出模型；這里的有監(jiān) 督學(xué)習算法可以使用線性回歸，邏輯回歸，決策樹，隨機森林等算法。在線模塊，使用加載離線訓(xùn)練好的模型，并且使用相應(yīng)的有監(jiān)督學(xué)習算法進行實時預(yù)測， 也就是判斷正常還是異常。在這里，也需要加入人工校正的過程，把誤告和漏告的樣本加入樣本庫；其中的 AB test 模塊是作為調(diào)優(yōu)

56、的工具，一旦有某個流量的模型效果好，就會全網(wǎng)發(fā)布，實時預(yù)測。注：統(tǒng)計判別和無監(jiān)督算法可以使用 3-Sigma 原理，Isolation Forest 等算法。有監(jiān)督學(xué)習算法可以使用線性回歸，邏輯回歸，決策樹，隨機森林等算法。3、總結(jié)針對海量時間序列異常檢測的問題，我們構(gòu)建了基于機器學(xué)習的海量時間序列異常檢測方案。該方案把整個過程劃分成了無監(jiān)督，有監(jiān)督，人工決策三部分。通過運維人員的業(yè)務(wù)經(jīng)驗，使用機器學(xué)習來主動學(xué)習人工經(jīng)驗，來實現(xiàn)時間序列異常檢測的智能化。案例 2：金融場景下的根源告警分析1、案例概述金融場景下對線上故障排查的時間要求非常嚴苛，核心業(yè)務(wù)要求在分鐘級能找到問題的 原因，而應(yīng)用數(shù)目和

57、服務(wù)器數(shù)目又非常龐大，以京東金融為例，單個應(yīng)用的實例數(shù)就有上千之 多，應(yīng)用的數(shù)量也是有幾千個。如此大的規(guī)模下，靠人工經(jīng)驗去排查問題很難達到時效性要求， 所以京東金融智能運維平臺引入了更智能化的方法來進行根源告警分析。2、根源告警分析處理流程根源告警分析是基于網(wǎng)絡(luò)拓撲，結(jié)合調(diào)用鏈，通過時間相關(guān)性、權(quán)重、機器學(xué)習等算法， 將告警進行分類篩選，快速找到告警根源的一種方式。它能從大量的告警中找到問題的根源， 因此大大縮短了故障排查及恢復(fù)時間。處理步驟：告警過濾(將告警中不重要的告警以及重復(fù)告警過濾掉)生成派生告警(根源關(guān)聯(lián)關(guān)系生成各類派生告警)告警關(guān)聯(lián)(同一個時間窗內(nèi),不同類型派生告警是否存在關(guān)聯(lián))權(quán)

58、重計算(根據(jù)預(yù)先設(shè)置的各類告警的權(quán)重，計算成為根源告警的可能性)生成根源告警(將權(quán)重最大的派生告警標記為根源告警)根源告警合并(若多類告警計算出的根源告警相同，則將其合并)根據(jù)歷史告警處理知識庫，找到類似根源告警的處理方案，智能地給出解決方案。圖 1 京東金融根源告警架構(gòu)圖舉例來說：假設(shè)多個系統(tǒng)通過 RPC 進行服務(wù)調(diào)用，調(diào)用關(guān)系如下：D 系統(tǒng)- C 系統(tǒng)- B 系統(tǒng)- A 系統(tǒng)當 A 系統(tǒng)查詢數(shù)據(jù)庫出現(xiàn)查詢超時后，告警會層層往前推進，導(dǎo)致 B、C、D 系統(tǒng)均有 N 個超時告警產(chǎn)生。此時，ROOT 分析可以將告警進行收斂，直接分析出根源告警為 A 系統(tǒng)訪問數(shù)據(jù)庫異常，導(dǎo)致 A、B、C、D 多個

59、系統(tǒng)異常。這樣，就避免了處理人員和每個系統(tǒng)開發(fā)人員溝通，輔助處理人員快速定位問題根源、提高了平均解決時間(MTTR)。如下圖所示：圖 2 京東金融根源告警調(diào)用鏈關(guān)系圖圖 3 京東金融根源告警明細圖3、根源告警分析處理方法根源告警分析的方法主要分為強關(guān)聯(lián)分析與機器學(xué)習兩類。 1)強關(guān)聯(lián)數(shù)據(jù)分析強關(guān)聯(lián)指的是已知確定的關(guān)聯(lián)關(guān)系。如：應(yīng)用之間的調(diào)用鏈關(guān)系數(shù)據(jù)庫與應(yīng)用服務(wù)器網(wǎng)絡(luò)設(shè)備與網(wǎng)絡(luò)設(shè)備、網(wǎng)絡(luò)設(shè)備與應(yīng)用服務(wù)器宿主機與虛擬機關(guān)系等若在同一個時間窗內(nèi)，有多個強關(guān)聯(lián)的設(shè)備或應(yīng)用服務(wù)器同時告警，則大概率認為告警之間存在關(guān)聯(lián)關(guān)系。在權(quán)重算法中，有一個重要的規(guī)則，鏈路上存在連續(xù)的告警可能存在關(guān)聯(lián)，越靠后的應(yīng)用越

60、可能是根源?，F(xiàn)在我們根據(jù)例子，分別計算各類根源告警。繼續(xù)使用上面的例子，D 應(yīng)用-C 應(yīng)用-B 應(yīng)用-A 應(yīng)用-數(shù)據(jù)庫 的異常的情況。首先是計算數(shù)據(jù)庫根源告警。根據(jù)數(shù)據(jù)庫關(guān)聯(lián)關(guān)系，會派生數(shù)據(jù)庫類型的數(shù)據(jù)庫告警、A 應(yīng)用告警。還會派生一條應(yīng)用類型的 A 應(yīng)用數(shù)據(jù)庫異常告警。根據(jù)數(shù)據(jù)庫派生告警以及數(shù)據(jù)庫與應(yīng)用的關(guān)聯(lián)關(guān)系及權(quán)重，可以得出數(shù)據(jù)庫異常導(dǎo)致 A 應(yīng)用查詢超時。接下來是計算應(yīng)用根源告警。根據(jù)調(diào)用關(guān)系，我們先計算出連續(xù)多個應(yīng)用告警的鏈路。當前 D-C-B-A 四個應(yīng)用都有派生告警，滿足此規(guī)則。然后，找到最靠后的告警應(yīng)用，也就是 A 應(yīng)用。列舉時間窗口內(nèi)所有 A 應(yīng)用的派生告警(可能存在多種派生