AIOps 平臺的誤解，挑戰及建議（下）— AIOps 挑戰及建議

本文篇幅較長，分爲上，中，下，三個部分進行連載。內容分別爲：AIOps 背景/所應具有技術能力分析（上），AIOps 常見的誤解（中），挑戰及建議（下）。

前言

我大概是 5，6 年前開始接觸 ITOA 這個領域的，首次接觸後，發現領域有着巨大的潛力，一直尋找在這個領域作點事情的機會。大約三年前在這個領域創業，積極尋求 Product Market Fit。這幾年下來，通過與行業內的專家交流，研讀報告，閱讀論文，客戶訪談，親自動手對相應的運維場景解析，行業產品的試用調研，以及結合着中國運維市場現狀，撰寫了此文。本人才疏學淺，不學無術，歡迎拍磚。

挑戰

挑戰1：超越當前技術水平的指望

如下是其中一例，當用戶指望超越當前技術水平的一個典型的例子，車毀人亡。

 

 

美國加州灣區高速上的一塊兒致命車禍，。一輛價值$79,500的 Tesla Model X，在行駛至山景城段101和85高速交界時，忽然撞上隔離帶，隨後爆炸起火。

對此，遇難華裔司機的遺孀 Sevonne Huang(下文簡稱Sevonne)首次公開發聲透露，丈夫生前曾抱怨過，特斯拉的自動導航儀，好幾回讓車子開向衝上防撞欄。Sevonne 說，將起訴特斯拉。

自動駕駛的安全性問題，再次把特斯拉推到風口浪尖上。然而過後，雖然特斯拉發聲明稱，抱歉發生這樣的悲劇，但同時也將責任指向了死者，「車輛再三發出警告，提醒司機操控車子，但事發前，司機並無把手放在方向盤上。自動駕駛儀並不能避免任何事故。」

司機對於特斯拉的 AutoPilot 過分相信，最終致使了悲劇了發生。

雖然目前的智能運維，所形成的結果可能不會那麼嚴重，可是按照Gartner 技術成熟度曲線來看，AIOps 還處於很是初期的階段(左下角)，超越現階段的指望，是 AIOps 最大的風險。

 

 

中國的企業用戶每每有大而全的建設方案，如何從企業的實際狀況出發，制定節奏合適的規劃，我認爲是一個很大的挑戰。

挑戰2：算法應用場景分散，成熟度不一致，通用性差，產品化，工程化困難，大部分場景距離實際應用有必定的距離

從目前來看，你們指望利用算法解決的場景包括：

• 單指標異常檢測;

• 多指標異常檢測;

• 日誌模式異常檢測，根據日誌的類型的變化態勢，發現正常和異常狀況下各種型日誌出現的模式；

• 故障根因分析，方法多種多樣，有基於傳播網絡，有基於依賴，有基於機率數學統計等方法;

• 容量預估，對現有業務狀況進行分析，預測將來所須要資源使用狀況;

• 告警智能壓縮，基於根因，減小告警數量;

• 故障預測，目前較爲經常使用的場景爲大批量，同批次硬盤的故障預測;

• 基於知識圖譜(運維經驗)故障定位;

以上的每一個智能場景，每一個場景所須要用到的算法都不同，並且成熟度差別較大。

以最爲簡單，但應用最爲普遍，成熟度最高的單指標異常檢測來舉例，從學術的角度來看，若是你到 Google 裏去搜索，你會發現有大約 60000 多條的記錄，時間跨度從上世紀 90 年代到幾天前的都會有。

從商業化的角度來看，目前從我看到的，比較成熟的也只有 Elastic 公司所收購的 Prelert 的異常檢測技術，是產品化的比較好的，普通的用戶是容易理解，容易使用的。

 

 

這已是 30 年來，集合了那麼多頂尖的智慧，所能達到的產品化程度最高，通用性最強的場景了。其餘的場景，成熟度，或者通用性確定是不如本場景。

例如故障預測，目前比較好的案例是預測硬盤故障，前提是你擁有大量一樣型號，相同批次的硬盤，其中某一些硬盤出故障了，從 S.M.A.R.T 信息中，你纔可以得到訓練集，而後利用模型去預測同一個批次的故障。這種前置條件，一般只會在特定的用戶，例如騰訊，百度的數據中心，一次性購置上千塊的，才能出現1到15塊的故障硬盤 (據統計，硬盤的故障率在0.1%~1.5% 左右)，並且就算有用戶根據硬盤的狀況，訓練好的模型由於每一個用戶的機房，電壓，溫度都不同，極可能沒有辦法進行復現，所以，此場景通用性極差。

若是要將用於預測硬盤故障的算法，用到某一個 IT 業務系統之上故障上，基本上也是不可能的，由於一個系統，相應的參數，變量，可能影響系統平穩運行因子太多，已是沒有辦法套用到預測硬盤故障的算法裏頭來了。

還有，部分的算法，在實驗室中的效果很是好，準確率和召回率都很高，可是，消耗資源巨大，實時性差，沒有辦法投入真正的生產使用的可能性。

所以，在算法上，咱們應該先去落地成熟，ROI 顯著的場景。

挑戰3：現有運維監控體系沒有完善

在無人駕駛技術領域，最核心的一個組件是 LiDar(激光雷達)，一種運用雷達原理，採用光和激光做爲主要傳感器的汽車視覺系統，LiDAR 傳感器賦予了自動駕駛汽車可以看到周邊環境的「雙眼」。

世界上，幾乎全部的汽車廠商( Tesla 除外，Tesla 用的是經過攝像頭而實現視覺識別技術，因此我我的高度懷疑特斯拉的事故與此有關)在研發無人駕駛技術的時候，都會給車輛安裝上激光雷達。

而類比到運維的場景，若是眼睛不夠，數據不足，事情看不清楚，實際上是很難作到明確的決策的，具體表現以下：

缺少足夠的數據源： 有的客戶，沒有日誌管理系統，也沒有任何業務監控的手段，只有 CPU 內存，硬盤等基礎監控，這個時候，其實我我的上是不建議在現階段作 AIOps 的;

• 監控指標深度，專業華程度不夠： 這個問題不少時候反應的數據庫監控上，因爲數據庫專業化程度較高，所以對數據庫的不少關鍵的指標未能識別，致使了關鍵信息的遺漏，可能會大大影響 AIOps 的落地效果;

• 配置管理不完善： CMDB 缺少維護， 沒法獲取系統間關係的描述，拓撲依賴，相關運維監控數據元數據缺少管理，都會下降落地效果，特別是在故障根因定位中，缺少關係描述所造成的有向無環圖，就很難利用傳播關係算法去幫助定位根因。固然，這個能夠經過由 APM ，或者 NPM 工具，所生成的應用拓撲去部分彌補;

  挑戰4：大數據基礎複雜，性能及多樣性要求高，元數據管理

  整個 AIOps 平臺最核心數據平臺的部分，是要知足如下的需求：

  • 高吞吐量，能實時處理海量，不一樣類型的數據(Metrics , Logging , Tracing);

  • 具有強大的流式計算能力;

  • 數據在插入後，能被準實時的檢索，聚合;

  • 數據變化多樣，會不停地新增動態列，數據存儲模型隨時會改變;

  • 超高的分析聚合計算性能，須要提供多維列式數據庫的分析能力;

  • 提供強大的實時搜索分析能力，能夠經過關鍵字對事件信息進行檢索;

  • 具有一種或多種的數據查詢 DSL，便於實現不一樣的分析場景;

  • 具有歷史數據和近線數據的分別處理的能力;

  • 數據存儲能對接到多種的 ML 框架中，做爲數據源，訓練模型;

  • 數據要能實現上卷預聚合，在進行長時間範圍聚合的時候，如月報等邏輯時，能夠節約計算時間;

  • 大的查詢進入到平臺，平臺要有自我保護機制，不會形成故障;

  • 良好的元數據管理的能力，包括若是從那麼多數據中，按照模型還原相應的指標，以及指標間的關聯關係;

  • 可以與在線的算法模塊進行集成;

  以上的描述，都是 AIOps 的數據能力要求，每每須要多個大數據處理，存儲組件，才能知足這種苛刻的要求，並且還須要無縫的整合起來，相應的工程技術難度很是大。

  挑戰5：人才匱乏

  目前在國內，不管是算法人才，仍是大數據人才，都是比較匱乏的及昂貴的，在人才招募，項目預算制定的時候，要充分考慮相關因素。

  從人才的意願來看，大部分的算法工程師及大數據工程師，更願意去參與一些離變現比較容易的場景，如推薦系統，視覺識別系統等，如何吸引更多的人才，特別是算法科學家等，讓他們感興趣，加入到 AIOps 的場景中來，也同時得到較好的經濟回報，是整個業界須要考慮的地方。

  建議

  • 企業結合自身的狀況，合理控制指望，分階段進行演進，查漏補缺;

  • 創建一個完整的運維數據大數據體系是項目運維的關鍵，也是爲智能化打下良好的基礎;

  • 以將整合指標數據、日誌數據做爲切入點，落地逐步整合更多的數據源，產生更大的收益;

  • 智能化部分的落地場景優先聚焦在監控的異常檢測，以及日誌的智能聚類;

  • 立足運維，面向業務，將 Operation 的含義演繹爲運營，爲業務提供商業價值;

  總結

  AIOps 的確是一個很是革命性的概念框架，它從大數據和 AI 的能力視角，去顛覆或者完善如今的 ITOM 運維體系，給學術界，工業界，最終用戶，指明瞭一個明確，可持續高速發展5-10年的發展方向。能夠預計，在將來 5-10 年內，大量關於 AIOps 的新思想，新理論，新技術，將會像寒武紀生命大爆炸時，不斷的涌現，創新源源不斷，做爲業界工做者，做爲企業，做爲廠商，如何在此次的週期中抓住屬於本身的機會，這是一個很值得思考的命題。

  AIOps 讓運維部門一下成了公司層面擁有數據最多的部門，運維人如何自身進化，從運維到運營，對大部分運維人來講，都是一個巨大的機會及挑戰。

  雖然 AIOps 的確給咱們帶來不少的想象空間，可是咱們仍是要以實際落地，實際幫助企業產生效率爲導向，要避免跳入 AI 過熱的炒做風，一步一腳印，直面挑戰，持續演進，不斷吸取世界先進的經驗及思想，從而迎接將來這10年的黃金時代。

  OneAPM 全新推出新一代 AIOps 平臺 I2，歡迎您隨時聯繫咱們，即刻開啓貴公司的智能運維之旅。點擊進入 AIOps 官網瞭解更多信息。

• 來源：http://blog.oneapm.com/apm-tech/816.html