AIOps指導

   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 自從 Gartner 於2016年提出至今已有一段時間，雖然在頂級互聯網及電信企業，已有較多落地，但至今仍無基於生產實踐的理論體系及實施指南。高效運維社區和雲計算開源產業聯盟（OSCAR聯盟）牽頭，和互聯網大廠如 BATJ、360、華爲、平安科技等的 AIOps 負責人聯合編寫了國內外首個《企業級 AIOps 實施建議》白皮書，如下爲摘抄內容，供我的學習參考。

 

 1、總體介紹

---

    早期的運維工做大部分是由運維人員手工完成的，這被稱爲手工運維或人肉運維。這種落後的生產方式，在互聯網業務快速擴張、人力成本高企的時代，難以維繫。    

    這時，出現了自動化運維，用可被自動觸發的、預約義規則的腳本，來執行常見的、重複性的運維工做，從而減小人力成本，提升運維效率。自動化運維能夠認爲是一種基於行業領域知識和運維場景領域知識的專家系統。可是，隨着整個互聯網業務急劇膨脹，以及服務類型的複雜多樣，「基於人爲指定規則」的專家系統逐漸變得力不從心。自動化運維的不足，日益凸顯，這也爲 AIOps 帶來發展機遇。

   AIOps 不依賴於人爲指定規則，主張由機器學習算法自動地從海量運維數據（包括事件自己以及運維人員的人工處理日誌）中不斷地學習，不斷地提煉並總結規則。

   AIOps 在自動化運維的基礎上，增長了一個基於機器學習的大腦，指揮監測系統採集大腦決策所需的數據，作出分析、決策，並指揮自動化腳本去執行大腦的決策，從而達到運維繫統的總體目標。

   AIOps 基於自動化運維，將 AI 和運維很好的結合起來，其須要三方面的知識：

1. 行業領域知識：應用的行業，如互聯網、金融、電信、物流、能源電力等，並熟悉生產實踐中的難題；
2. 運維場景領域知識：包括異常檢測、故障預測、瓶頸分析、容量預測等；
3. 機器學習：把實際問題轉化爲算法問題，經常使用算法包括如聚類、決策樹、卷積神經網絡等。   

   AIOps 是 企業級 DevOps 在運維（技術運營）側的高階實現。

   AIOps 和 DevOps 二者並不衝突，企業級 DevOps 涵括包括運維在內的整個軟件生命週期，。此部分可具體參考《研發運營一體化能力成熟度模型》。

   AIOps 是運維的發展必然，是自動化運維的下一個發展階段。

   Gartner 相關報告預測 AIOps 的全球部署率將從2017年的10%增長到2020年的50%。其應用行業，除了互聯網之外，還包括高性能計算、電信、金融、電力網絡、物聯網、 醫療網絡和設備、航空航天、軍用設備及網絡等領域。

2、AIOps 目標、原則及能力框架

---

   AIOps，通俗的講，是對規則的AI化，即將人工總結運維規則的過程變爲自動學習的過程。

   具體而言，是對咱們平時運維工做中長時間積累造成的自動化運維和監控等能力，將其規則配置部分，進行自學習的「去規則化」改造，最終達到終極目標：「有AI調度中樞管理的，質量、成本、效率三者兼顧的無人值守運維，力爭所運營系統的綜合收益最大化」。

 2.一、AIOps 目標

   利用大數據、機器學習和其餘分析技術，經過預防預測、個性化和動態分析，直接和間接加強IT業務的相關技術能力，實現所維護產品或服務的更高質量、合理成本及高效支撐。

 2.二、AIOps 能力分級
   AIOps的建設能夠先由無到局部單點探索、再到單點能力完善，造成解決某個局部問題的運維AI「學件」，再有多個具備AI能力的單運維能力點或學件組合成一個智能的運維流程，如智能化的監控預測及告警，免干預的自動化擴縮容，免干預的性能調優、免干預的成本組成調優等。 

   具體可描述爲5級、以下圖：

1. 開始嘗試應用AI能力，還無較成熟單點應用
2. 具有單場景的AI運維能力，能夠初步造成供內部使用的學件
3. 有由多個單場景AI運維模塊串聯起來的流程化AI運維能力，能夠對外提供可靠的運維AI學件
4. 主要運維場景均已實現流程化免干預AI運維能力，能夠對外提供可靠的AIOps服務。
5. 有核心中樞AI，能夠在成本、質量、效率間從容調整，達到業務不一樣生命週期對三個方面不一樣的指標要求，可實現多目標下的最優或按需最優。

•     

  2.三、AIOps 能力框架

    學件：亦稱AI運維組件相似程序中的API或公共庫但API及公共庫不含具體業務數據只是某種算法，而AI運維組件或稱學件則是在相似API的基礎上兼具對某個運維場景智能化解決的「記憶」能力，將處理這個場景的智能規則保存在了這個組件中。

    這個智能規則是在必定量的數據下學習而來的，且具備「可重用」「可演進」「可瞭解」的特性既可共享由專家利用數據訓練的算法又可保護數據和隱私。

    注：「學件」（Learnware）一詞是南京大學周志華老師的原創，學件（Learnware）= 模型（model）+規約（specification），具備可重用、可演進、可瞭解的特性。

• 「可重用」的特性使得可以獲取大量不一樣的樣本；
• 「可演進」的特性使得能夠適應環境的變化；
• 「可瞭解」的特性使得能有效地瞭解模型的能力。

    不少人可能在本身的應用中已經創建了這樣的模型，他們也很願意找到一個地方把這些模型分享出去。那之後一個新用戶想要應用，也許不用本身去創建一個，而是先到「學件」市場上找一找有沒有合適的，能夠拿來使用修改。

    由於學件是在專家基礎上創建的，因此比較容易獲得專家級的結果，又由於共享出來的是模型，因此避免了數據泄露和隱私泄露的問題。

 3、AIOps 平臺能力體系

 

---

    AIOps 工做平臺的能力體系主要功能是爲 AIOps 的實際場景建設落地而提供功能的工具或者產品平臺，其主要目的是下降 AIOps 的開發人員成本，提高開發效率，規範工做交付質量。AIOps平臺功能與通常的機器學習(或者數據挖掘)平臺極爲相似此類產品國外的好比Google的AutoML(https://cloud.google.com/automl/)，AIOps平臺功能模塊圖以下：

     AI建模服務能力示意圖以下:

     具體的工具或者產品應具有如下功能或模塊：

1. 交互式建模功能：該功能支持用戶在平臺上交互式的進行模型的開發調試，經過簡單的方法配置完成模型的構建。
2. 算法庫：用戶能夠在算法庫中找到常見經常使用的算法直接使用，算法按照用途分類，以供用戶方便的使用。
3. 樣本庫：樣本庫用於管理用戶的樣本數據，供用戶建模時使用，支持樣本的增刪改查等基本操做。
4. 數據準備：該功能支持用戶對數據進行相關的預處理操做，包括關聯、合併、分支路由、過濾等。
5. 靈活的計算邏輯表達：在基本經常使用的節點功能以外，用戶還須要自由的表達一些計算邏輯，該需求主要是經過讓用戶寫代碼或表達式來支持。
6. 可擴展的底層框架支持：平臺自己要可以靈活的支持和兼容多種算法框架引擎，如Spark、TensorFlow等，以知足不一樣的場景以及用戶的需求。
7. 數據分析探索：該功能是讓用戶可以方便快捷的瞭解認識本身的數據，用戶只有基於對數據充分的認識與理解，才能很好的完成模型的構建。
8. 模型評估：對模型的效果進行評估的功能，用戶須要依據評估的結論對模型進行調整。
9. 參數以及算法搜索：該功能可以自動快速的幫助用戶搜索算法的參數，對比不一樣的算法，幫助用戶選擇合適的算法以及參數，輔助用戶建模。
10. 場景模型：平臺針對特定場景沉澱的解決方案，這些場景都是通用常見的，用戶能夠借鑑參考相關的解決方案以快速的解決實際問題
11. 實驗報告：模型除了部署運行，相關挖掘出來的結論也要可以造成報告，以供用戶導出或動態發佈使用。
12. 模型的版本管理：模型可能有多個不一樣的版本，線上運行的模型實例可能分屬各個不一樣的版本，版本管理支持模型不一樣版本構建發佈以及模型實例版本切換升級等。
13. 模型部署應用：模型構建完成後須要發佈應用，模型部署應用功能支持模型的實例化，以及相關計算任務的運行調度管理。  

4、AIOps 團隊角色 

---

     AIOps做爲一個團隊，由不一樣角色組成，通常有三種不一樣角色，他們是運維專家、數據科學家、智能運維研發工程師，如下介紹三種角色分工：

     1）運維工程師:  能從業務的技術運營中提煉出智能化的需求點。在開發實施前可以考慮好需求方案規範數據格式。前期能夠經過仿真手法探索和驗證方案可行性起草合適的算法方案。

• 特徵：具備豐富的運維領域知識、熟悉較爲複雜的運維問題、具有解決運維難題能力。
• 職責：運用機器幫助運維人員完成基礎性和重複性的基層運維工做；人工處理機器還不能處理好的運維難題；基於經驗對於較爲複雜的運維問題給出最終決策—不斷訓練機器。

    2）運維數據工程師：針對來自於運維工程師和算法方案進行理解和梳理，完成最終落地方案的輸出工做；在工程落地上可以考慮好健壯性、魯棒性、敏捷性等，合理拆分任務，保障成果落地，以提高最終業務運營質量。

• 特徵：具有編程、數學、統計學、數據可視化、機器學習等能力。
• 職責： 致力於智能運維平臺架構、模型標準、數據分析方法；不斷應用最新的機器學習技術設計優化智能運維算法；監督智能運維繫統性能並實施優化和改進。

    3）運維開發工程師: 負責進行平臺相關功能和模塊的開發，以下降用戶使用門檻，提高用戶使用效率。而且將運維數據工程師交付的數據經過友好的方式展示給用戶。

• 特徵：良好的開發語言基礎、大數據處理技術能力。
• 職責：數據採集、自動化處理、實現和運用算法等。

     角色協同關係以下圖：

5、AIOps 常見應用場景 

---

     AIOps 圍繞質量保障、成本管理和效率提高的基本運維場景，逐步構建智能化運維場景。

• 在質量保障方面，細分爲異常檢測、故障診斷、故障預測、故障自愈等基本場景；
• 在成本管理方面，細分爲指標監控，異常檢測，資源優化，容量規劃，性能優化等基本場景；
• 在效率方面，分爲智能變動、聊天機器人等基本場景。

   （注：三者之間不是徹底獨立的，是相互影響的，場景的劃分側重於主影響維度。）

    不管是效率提高，質量監控，仍是成本優化，都離不開最基礎的數據採集，它是整個AIOp的基石。 AIOps提升運維生產力的一種方式就是把質量處理流程中的人力部分儘量的都替換成機器來作。在機器的分析過程當中系統運行過程當中的每個部件都須要數據支持。不管是海量數據採集、仍是數據提取方面都離不開大數據技術。

    從數據採集的層面來看，運維數據的採集每每是實時的，數據採集端須要具有必定分析能力，綜合考慮用戶流量、隱私服務器壓力等多個因素，儘量的下降無效數據的採集，增長有價值信息的上報。
    從數據提取的層面來看，運維的數據是多樣化的，歷史數據、流數據、日誌數據、網絡數據、算法數據、文本和NLP文檔數據，以及APP數據、瀏覽器數據、業務系統運營指標數據等，從這些海量的數據中提取出正真有價值的指標化數據並可視化是進一步分析決策的前提條件。
    而成本優化和效率的提高一樣離不開數據的支撐。例如，開始實施成本優化的AIOPS前，須要儘量多的收集目前的服務器、網絡設備、應用服務、數據庫等的性能信息，應用日誌信息，tracing信息，以便對成本優化的效果進行評估。例如在搭建智能客服機器人的時候，就須要提供充足的問題庫和相應的答案纔可以創建好一個較優的模型。

  三大方向的各階段能力描述以下所示。

5.一、質量保障方向       

      質量保障是運維的基本場景之一，隨着業務的發展，運維繫統也在不斷的演進，其規模複雜度、變動頻率很是大，技術更新也很是的快，與此同時，軟件的規模、調用關係、變動頻率也在逐漸增大。

      在這樣背景下，須要AIOps提供精準的業務質量感知、支撐用戶體驗優化、全面提高質量保障效率。

  異常檢測：

• 運維繫統中常見的兩大類監控數據源是：指標和文本。前者一般是時序數據，即包含指標採集時間和對應指標的值；後者一般是半結構化文本格式，如程序日誌、Tracing等。隨着系統規模的變大、複雜度的提升、監控覆蓋的完善、監控數據量愈來愈大、運維人員沒法從海量監控數據中發現質量問題。智能化的異常檢測就是要通過AI算法，自動、實時、準確地從監控數據中發現異常，爲後續的診斷、自愈提供基礎。異常檢測的常見任務包括對數據源的異常檢測，保證數據質量，以及對指標和文本的異常檢測。

1. 數據源異常檢測：數據源會由於一些不可避免的緣由存在一些異常數據，這些異常數據佔比雖然很低，可是每每會引發整個指標統計值的波動，使得統計結果偏離真實的用戶體驗。AIOps須要自動、實時的動態設置閾值，去除數據源中的異常數據干擾，並可以區分系統真正發生異常時候的故障數據和數據源自己的異常數據，這種判斷依賴於一些外部信息。
2. 指標異常檢測：包括單指標異常檢測及多指標異常檢測。

• 單指標異常檢測：時間序列指標的異常檢測是發現問題的核心環節，傳統的靜態閾值檢測爲主的方式，閾值過高，漏告警多，質量隱患難以發現；閾值過低，告警太多引起告警風暴，干擾業務運維人員的判斷。AIOps經過機器學習算法結合人工標註結果，實現自動學習閾值、自動調參，提升告警的精度和召回率，大幅度下降人工配置成本。
• 多指標異常檢測：運維過程當中有些指標孤立來看可能並無異常，可是綜合多個指標來看，可能就是異常的。有些單指標表現是異常的，可是綜合多個指標來看可能又是正常的。AIOps須要可以綜合多個指標綜合評判系統指標異常，提升告警的準確性。

     3. 文本異常檢測：文本日誌常是在特色條件下觸發生成的，並遵循必定的模板，即半結構化文本。傳統的日誌檢測有兩種方式：

• 根據日誌級別：如Info、Warning、Critical進行報警，但因爲其設定不許確或不知足實際須要，致使準確性差
• 經過設置規則：匹配日誌中特定字符串進行報警，但該方法依賴依賴人工經驗，且只能檢測已知和肯定模式的異常。
• AIOps須要經過天然語言處理、聚類、頻繁模式挖掘等手段，自動識別日誌出現的反常模式，結合人工反饋和標註，不斷進行優化、完善。

 故障診斷：

• 異常檢測實現了運維人員對數據的感知，有了數據以後，智能分析能夠進一步解放運維人力，提升運維效率，故障診斷是智能分析的核心部分，主要包括基於人工故障庫的故障診斷和基於數據挖掘的故障診斷。

1. 基於人工故障庫的故障診斷：平常運維過程當中，運維人員積累了大量的人工經驗，運維過程當中的大部分故障都是重複的、人工可以識別的異常。重複問題的定位浪費了大量的人力並且人工確認過程每每是比較滯後的。AIOps把人工專家經驗固化下來，對常見問題實現分鐘級內自動診斷，運維人員收到的告警信息中就須要包括故障定位的結果信息。
2. 基於數據挖掘的故障診斷：人工經驗可能存在誤差，人工認爲的緣由可能並非問題的根因，當有些故障首次發生沒有人工經驗能夠借鑑的時候故障根因也難以定位。尤爲隨着微服務的發展，業務的組網變得更加複雜，模塊多帶來的消息路由多、依賴多，問題的定界定位分析更爲困難；人工故障決策效率挑戰巨大。 對於已知故障，AIOps可以綜合故障數據和人工經驗自動提取故障特徵，生成故障特徵庫，自動匹配、自動定位故障、對於未知故障AIOps須要根據故障特徵推演出可能的故障緣由，並在人工確認後加入的故障特徵庫。

 故障預測：

• 故障的出現通常不是忽然的，就好比網絡故障來講，每每從丟包開始到網絡不可用是有一個演變的過程，依據海恩法則，每一塊兒嚴重事故的背後，必然有29次輕微事故和300起未遂先兆以及1000起事故隱患，開展主動健康度檢查，針對重要特性數據進行預測算法學習，提早診斷故障，避免服務受損；常見場景：磁盤故障預測、網絡故障預測（根據交換機日誌的交換機故障預測）、內存泄露預測等等。

 故障自愈：

• 智能分析實現了故障的診斷和預測，智能執行根據智能分析的結果實現故障自愈。傳統的故障自愈的決策主要靠人的經驗，人的經驗可以覆蓋的故障範圍是有限的，並且人工沒法保證7*24隨時能夠當即決策與處理。AIOps可以提供完善的自動化平臺在故障智能分析以後自動決策，實現自愈；常見場景：版本升級回退、DNS自動切換、CDN智能調度、智能流量調度等。
• 故障自愈是根據故障診斷的結果的輸出（問題定位和根因分析），進而進行影響評估決定「解決故障」或「恢復系統」的過程。影響評估是對故障以後所產生的影響範圍（系統應用層面、業務執行層面、成本損失層面等等）輸出評估結果，並根據這個評估來決定要採用什麼解決手段，甚至生成解決手段的執行計劃。

5.二、效率提高方向

   效率提高是運維的基本場景之一，隨着業務的發展，運維繫統的總體效率的提高就成爲了運維繫很是重要的一環。在這樣的背景下，除了增長人力是遠遠不夠的，還須要AIOps提供高質量，可維護的效率提高工具。

  智能問答：

• 運維的目標是爲了支持穩定，可靠的業務運行，而業務與業務之間既可能有類似性，又可能有差別性。但因爲知識背景和對業務的認知差別每每出現如下狀況

1. 不一樣的業務人員或開發人員每每會詢問運維人員一些類似的問題，運維人員的答案也是很是相似的，但人力被重複消耗。
2. 面對同一個問題，運維人員的回答可能會出現差別，例如表達方式、措辭等，缺少標準化可能形成誤解。

• AIOps智能問答系統經過機器學習、天然語言處理等技術來學習運維人員的回覆文本，構建標準問答知識庫從而在遇到相似問題的時候給出標準的統一的回覆。這樣不只能夠有效地節省運維人員的人力成本還可以使得提問獲得更加及時的回覆。

 智能決策：

•  許多運維管理工做都須要各類各樣的決策，包括擴容、縮容、制定權重、調度、重啓等內容。那麼可能面臨以下問題

1. 運維人員能夠根據本身的業務經驗制定相應的決策。可是不一樣的業務有着各自的特色，不一樣的運維人員也有着本身的業務經驗。如何將運維人員的這些經驗有效地傳承是個問題。
2. 人的認知侷限性，運維場景的複雜性可能致使最有經驗的運維人員遺漏掉某些「不起眼」的「重要細節」，顯然準確的決策還依賴足夠充足的細節。

• AIOps智能決策一方面能夠將運維人員的決策過程數據化，構建決策支持知識庫，從而實現經驗積累。另外一方面因爲系統掌握了從全局到細節的數據，再結合決策支持知識庫，能夠爲更加準確的決策提供最有力的支撐。

容量預測：

• 運維工做不只僅包含對當下的決策和處理，每每還須要根據業務的訴求對將來作出合理的規劃，包括擴容的預測，縮容的預測等。因爲對將來的規劃時常存在不肯定性那麼規劃過程每每須要大量的數據來支持，還須要大量的推演來肯定。而人工預測的方式，一方面須要投入大量人力；另外一方面運維人員的能力可能存在差別，使得推演的結果品質不盡一致。
• AIOps智能預測藉助大數據和機器學習能力，結合運維人員的有效評估經驗，甚至業務發展模式以及政策等，對目標場景實現高效的推演過程，最終使預測結果趨近合理範圍。這樣一來，不可是人力得以節省，關鍵在於因爲預測效率的提高，使得過去難以重複耗時耗力的人工預測過程變得能夠應需而變，不斷修正預測結果，最終使業務訴求得到最佳預測收益。

5.三、成本管理方向   

      成本管理方向是當公司內部的業務日益增多的時候，如何在保障業務發展的同時，節省沒必要要的開支，有效地控制成本。成本是每一個企業都很關注的問題，如今業界的資源利用率廣泛偏低，平均資源使用率能作到20%以上是不多的。

      AIOps 經過智能化的資源優化，容量管理，性能優化實現IT成本的態勢感知、支撐成本規劃與優化、提高成本管理效率。

  成本優化：

• 在成本優化方向，須要採起高可用的設計，提供更加合理的服務，包括接入層、業務層、存儲層等。

1. 在接入層須要提供合理的健康檢查機制，更加智能的負載均衡算法，限定流量等工做。
2. 在業務層不只須要去除DB的強依賴，使用合理的降級，還要進行合理的壓測、監控以及動態的負載均衡。
3. 在存儲層須要作的事情是容災等關鍵工做。這樣的話，可使得內部數據的質量獲得大量提高，外部數據的優先接入和動態選擇。

• 對於設備採集的週期控制這個問題來講，過晚的設備採購可能會影響到業務的正常上線或擴展，而過早的採購也可能形成成本的浪費。因而AIOps 須要創建合理的模型並創建更好的規劃，並據此計算更準確的設備採購計劃，也能對成本進行更好的控制。

  資源優化：

• 公司的運營成本優化項目一直是公司成本預算的關鍵一步。優化問題包括設備的優化、帶寬、碼率的優化等等。只有進行了合理的資源優化，纔可以使得公司的成本獲得有效的控制。不一樣的服務的資源消耗類型是不同的，包括計算密集型，包括存儲密集型等等；而對於同一個服務在不一樣的時間點資源消耗也是不同的。
• 對於一個企業來講，識別不一樣服務的資源消耗類型，識別每一個服務的資源瓶頸，實現不一樣服務間的資源複用是下降成本的重要環節。根據資源應用的性能指標能夠大體分類成如下類別：

1. 計算密集型：CPU使用率較高，常見於須要大量計算資源的搜索、推薦、數學計算等場景中
2. 內存密集型：佔用的內存使用率較高，如緩存服務
3. IO密集型：網絡IO繁忙或者磁盤IO操做繁忙，常見於爬蟲、消息管道、分佈式存儲等服務中。

• 大型互聯網公司裏動輒上千上萬的應用數，很容易有應用由於業務變化已經訪問量不斷縮減甚至已經下線，可是線上還佔用着大量的資源，經過對應用的性能指標分析，篩選出各項性能指標都很低的應用，就能夠識別出這些「被遺忘」 的應用，就能夠跟業務負責人進行覈對進行縮容或者下線。
• 目前大部分公司都已經使用了虛擬化或者docker技術，同一個物理機上的不一樣虛擬機或容器已經進行了很好的細粒度資源分配和隔離，因此對於同一臺物理機能夠進行混合部署不一樣類型的應用，如計算密集型應用、存儲密集型應用、IO密集型應用混部在同一臺物理機上，以提升更大的資源利用率，甚至必定量的「超賣」（經過共享部分資源，實現分配的總的資源數超過物理機的資源數）。對於一些靈活的計算任務：如Spark、Storm等計算類任務，還可使用按時分配的策略，如白天運行在部分服務器上，並且夜間須要運行大批量計算的報表等任務時，利用業務應用夜間資源使用率低的特色把部分任務分配到業務應用所在的服務器上運行，充分利用這些業務應用的服務器的計算資源，提升總體利用率。 
• AIOps經過密度管理、特性管理、碎片管理、木桶管理等方法，優化企業不一樣服務器的配比，發現並優化資源中的短板，提供不一樣服務的混合部署建議，最終實現智能化降成本方案分析服務。

  性能優化：

• 性能的調優一直是運維的重要一環。若是性能優化得當則會減小實際的運算量，減小內存方面的濫用，提高服務器的性能。運維人員在其中並不能保證及時發現全部潛在的性能問題，不少時候也不知道什麼的系統配置纔是最優的系統配置，何時的權重配比才可以達到最佳的效果。AIOps 可以根據現網的實際狀況，進行智能地調整配置，智能發現性能優化策略，提供智能化的優化服務。

6、AIOps 實踐路徑建議

 

---

 

   6.一、未實現自動化運維時

       AIOps的開展，受限於自動化數據採集，網絡、磁盤、成本方面的工做難以深刻發展。建議聚焦質量保障的原子場景。

   6.二、已經實現自動化運維時    

            詳見下文。

   6.2.一、質量保障方向

   6.2.二、效率提高方向

   6.2.三、成本管理方向

7、AIOps 實施及關鍵技術

 

---

 

      爲了實現成本管理、效率提高、質量保障的場景，根據Gartner的定義，AIOps產品或平臺應包含下圖所示的要素：

1. 數據源：大量而且種類繁多的IT基礎設施
2. 大數據平臺：用於處理歷史和實時的數據
3. 計算與分析：經過已有的IT數據產生新的數據例如數據清洗、去除噪聲等
4. 算法：用於計算和分析以產生IT運維場景所須要的結果
5. 機器學習：這裏通常指無監督學習，可根據基於算法的分析結果來產生新的算法

   7.一、數據採集

• 數據採集：負責將智能運維所須要的數據接入至AIOps平臺，所接入的運維數據類型通常包括(但不限於)日誌數據、性能指標數據、網絡抓包數據、用戶行爲數據、告警數據、配置管理數據、運維流程類數據等。
• 數據採集方式可分爲無代理採集以及有代理採集兩種：

1. 無代理採集爲服務端採集：支持SNMP、 數據庫JDBC、 TCP/UDP監聽、 SYSLOG、 Web Service、消息隊列採集等主流採集方式。
2. 有代理採集：用於本地文件或目錄採集、容器編排環境採集、以及腳本採集等。         

   7.二、數據處理

• 針對採集數據進行入庫前的預處理，數據從非結構化到結構化的解析、數據清洗、格式轉換以及數據（如性能指標）的聚合計算，處理工做主要體如今幾個方面：

1. 數據字段提取：經過正則解析、KV解析、分隔符解析等解析方式提取字段
2. 規範化數據格式：對字段值類型重定義和格式轉換
3. 數據字段內容替換：基於業務規則替換數據字段內容，好比必要的數據脫敏過程，同時可實現無效數據、缺失數據的替換處理
4. 時間規範化：對各種運維數據中的時間字段進行格式統一轉換
5. 預聚合計算：對數值型字段或指標類數據基於滑動時間窗口進行聚合統計計算，如取1分鐘CPU平均值

   7.三、數據存儲

• 數據存儲是AIOps平臺的數據落地的地方，能夠根據不一樣的數據類型以及數據的消費和使用場景，可選擇不一樣的數據存儲方式。數據主要可分爲以下幾類：

1. 數據須要進行實時全文檢索、分詞搜索：可選用主流的ElasticSearch引擎
2. 時間序列數據：性能指標，主要以時間維度進行查詢分析的數據, 可選用主流的rrdtool、graphite、influxdb等時序數據庫
3. 關係類數據以及會彙集在基於關係進行遞歸查詢的數據可選擇圖數據庫
4. 數據的長期存儲和離線挖掘以及數據倉庫構建，可選用主流的Hadoop、Spark等大數據平臺

   7.四、離線和在線計算

• 離線計算：針對存儲的歷史數據進行挖掘和批量計算的分析場景，用於大數據量的離線模型訓練和計算，如挖掘告警關聯關係，趨勢預測/容量預測模型計算，錯誤詞頻分析等場景。 
• 在線計算：對流處理中的實時數據進行在線計算，包括但不限於數據的查詢、預處理和統計分析，數據的實時異常檢測以及部分支持實時更新模型的機器學習算法運用等。主流的流處理框架包括Spark Streaming, Kafka Streaming, Flink, Storm等。

   7.五、面向 AIOps 的算法技術

• 運維場景一般沒法直接基於通用的機器學習算法以黑盒的方式解決，所以須要一些面向AIOps的算法技術，做爲解決具體運維場景的基礎。有時一個算法技術還可用於支撐另一個算法技術。 常見的面向AIOps的算法技術包括：

1. 指標趨勢預測：經過分析指標歷史數據，判斷將來一段時間指標趨勢及預測值，常見有Holt-Winters、時序數據分解、ARIMA等算法。該算法技術可用於異常檢測、容量預測、容量規劃等場景。
2. 指標聚類: 根據曲線的類似度把多個KPI聚成多個類別。該算法技術能夠應用於大規模的指標異常檢測，在同一指標類別裏採用一樣的異常檢測算法及參數，大幅下降訓練和檢測開銷。常見的算法有DBSCAN, K-medoids, CLARANS等應用的挑戰是數據量大曲線模式複雜。
3. 多指標聯動關聯挖掘：多指標聯動分析判斷多個指標是否常常一塊兒波動或增加。該算法技術可用於構建故障傳播關係，從而應用於故障診斷。常見的算法有Pearson correlation, Spearman correlation, Kendall correlation等應用的挑戰爲KPI種類繁多關聯關係複雜。
4. 指標與事件關聯挖掘: 自動挖掘文本數據中的事件與指標之間的關聯關係， 好比在程序A每次啓動的時候CPU利用率就上一個臺階。該算法技術可用於構建故障傳播關係，從而應用於故障診斷。常見的算法有Pearson correlation, J-measure, Two-sample test等。應用的挑戰爲事件和KPI種類繁多，KPI測量時間粒度過粗會致使判斷相關、前後、單調關係困難。
5. 事件與事件關聯挖掘：分析異常事件之間的關聯關係把歷史上常常一塊兒發生的事件關聯在一塊兒。該算法技術可用於構建故障傳播關係，從而應用於故障診斷。常見的算法有FP-Growth、 Apriori、隨機森林等，但前提是異常檢測須要準確可靠。
6. 故障傳播關係挖掘：融合文本數據與指標數據，基於上述多指標聯動關聯挖掘、指標與事件關聯挖掘、事件與事件關聯挖掘等技術、由tracing推導出的模塊調用關係圖、輔以服務器與網絡拓撲，構建組件之間的故障傳播關係。該算法技術能夠應用於故障診斷，其有效性主要取決於其基於的其它技術。

參考資料

---

• http://www.javashuo.com/article/p-gtlhkcnh-md.html
• https://testerhome.com/topics/11649
• 《企業級AIOps 實施建議》白皮書