AIOps 平台的誤解，挑戰及建議

07-11

AIOps 平台的誤解，挑戰及建議

來自專欄智能運維雜談

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

才疏學淺，歡迎拍磚。

背景

概念的進化：ITOA -> AIOps -> AIOps

讓我們回到2013年，著名的 Buzz word (時髦用語) 製造商 Gartner 在一份報告中提及了ITOA，當時的定義是，IT運營分析(IT Operations Analytics)，通過技術與服務手段，採集、存儲、展現海量的IT運維數據，並進行有效的推理與歸納得出分析結論。

而隨著時間推移，在2016年，Gartner 將ITOA 概念升級為了 AIOps，原本的含義基於演算法的IT運維(Algorithmic IT Operations)，即，平台利用大數據，現代的機器學習技術和其他高級分析技術，通過主動，個性化和動態的洞察力直接或間接地，持續地增強IT操作（監控，自動化和服務台）功能。 AIOps平台可以同時使用多個數據源，多種數據收集方法，實時分析技術，深層分析技術以及展示技術。

隨著AI在多個領域越來越火爆，Gartner終於按捺不住了，在它的2017年年中一份報告中，順應民意將AIOps的含義定義為了，Artificial Intelligence for IT Operations，也就是現在大家都在說的智能運維。

在短短的不到1年時間中，伴隨著AI的熱炒，以及在各個領域的落地，運維界的同仁基本上把AIOps 看成是未來解決運維問題的必然方向。

個人認為，在企業內部構建AIOps，通過融合IT數據，真正打破數據煙囪，對監控，自動化，服務台進行支持，使得IT能夠更好的支撐業務，利用大數據技術以及機器學習技術，回答以前很多單從業務口徑，或者單從IT口徑無法回答的問題。如，聯通，電信，移動，電信的用戶，哪種用戶轉化率較高。AIOps以創造商業價值為導向，對IT 運營以及業務運營產生持續洞察，為DevOps 提供持續反饋，加快企業在競爭日趨激烈市場環境中，數字化轉型的步伐。

因此，Gartner 預測到2022年，大型企業中的的40%將會部署AIOps平台。

具體關於AIOps的概念，價值，Gartner 很多都已經說的很清楚，不是本文的重點，本文是根據我的理解，嘗試從現實的角度，去談AIOps 在落地過程中容易產生的誤解，挑戰以及一些建議。

AIOps 所應具備技術能力分析

個人認為，AIOps，本質上是ITOA 的升級版，讓我們來看一下 Garnter 在2015年對ITOA 的所應該有的能力定義。

ML/SPDR: 機器學習/統計模式發現與識別
UTISI: 非結構化文本索引，搜索以及推斷
Topological Analysis: 拓撲分析
Multi-dimensional Database Search and Analysis:多維資料庫搜索與分析
Complex Operations Event Processing: 複雜運維事件處理

然後，我們對比一下，Gartner 對AIOps 的能力定義

Historical data management 歷史數據管理
Streaming data management 流數據管理
Log data ingestion 日誌數據整合
Wire data ingestion 網路數據整合
Metric data ingestion 指標數據整合
Document text ingestion 文本數據整合
Automated pattern discovery and prediction 自動化模式發現和預測
Anomaly detection 異常檢測
Root cause determination 根因分析
On-premises delivery 提供私有化部署
Software as a service 提供SaaS服務

除去最後兩個的交付方式，對比下來，我認為AIOps 比起原來的ITOA 有以下的進化：

強調歷史數據的管理：

允許採集，索引和持續存儲日誌數據，網路數據，指標以及文檔數據，數據大部分是非結構化或者半結構化的，而且數據量累積速度很快，格式多樣，非常符合大數據的特徵。總所周知，在新一輪以CNN , RNN 演算法為代表的演算法中，都需要大量有標準的數據來進行訓練，因此，對歷史數據的管理，成了智能運維的第一重點。

強調實時的流數據管理：

以Kafka Streams，Flink，Storm，Spark Streaming 為代表的流計算處理技術，已經成為了各大數據平台的必備組件，而面對IT 數據中海量的實時流式數據，某些場景裡頭，在數據進行持久化前，進行實時分析，查詢，集合，處理，降低資料庫（SQL or Nosql）的負載，成為了非常合理且常規的選擇，因此AIOps平台中，含有數據流，非常合理。

強調多種數據源的整合:

我認為，這個是AIOps平台最大的價值點，因為Gartner第一次將多種數據源整合的能力，帶入了ITOM 管理的領域，我們搞運維監控那麼多年，終於第一次可以以大數據的視角，數據驅動的視角，去思考運維監控這個傳統的行當。

Gartner 這裡提及到了四種數據，Log Data, Wire Data, Metirc data，Document text。這樣的分類，我是個人持有保留意見，感覺很奇怪，特別是 Document text 的那塊，需要用到NLP，主要是用於打通ITSM 產品，分析ITSM 工單。我對這個場景存在必要性，以及實現的ROI 表示懷疑。具體原因我可能稍後會寫一篇文章，進行更詳細的解釋。

我認為，如果從宏觀的類型來劃分，應該這樣劃分（下含部分我司產品介紹）

機器數據（Machine Data）：是IT系統自己產生的數據，包括客戶端、伺服器、網路設備、安全設備、應用程序、感測器產生的日誌，及 SNMP、WMI，監控腳本等時間序列事件數據（含CPU 內存變化的程度），這些數據都帶有時間戳。這裡要強調， Machine Data 不等於Log Data ，因為指標數據包含。在通常的業界實踐中，這些數據通常通過運行在主機上的一個Agent程序，如LogStash， File beat，Zabbix agent 等獲得，如果我們的LogInsight，Server Insight 產品，就是面向此類型數據。

網路數據（Wire Data）： 系統之間2~7層網路通信協議的數據，可通過網路埠鏡像流量，進行深度包檢測 DPI（Deep Packet Inspection）、包頭取樣 Netflow 等技術分析。一個10Gbps埠一天產生的數據可達100TB，包含的信息非常多，但一些性能、安全、業務分析的數據未必通過網路傳輸，一些事件的發生也未被觸發網路通信，從而無法獲得。我司的Network Insight 主要面向的是這些數據，提供關鍵應用的 7 x 24 小時全方位視圖。

代理數據（Agent Data）： 是在 .NET、PHP、Java 位元組碼里插入代理程序，從位元組碼里統計函數調用、堆棧使用等信息，從而進行代碼級別的監控。我司的Application Insight主要是解決這個問題而誕生，能獲得真正用戶體驗數據以及應用性能指標。

探針數據（Probe Data）：也就是所謂的撥測，是模擬用戶請求，對系統進行檢測獲得的數據，如 ICMP ping、HTTP GET等，能夠從不同地點模擬客戶端發起，進行包括網路和伺服器的端到端全路徑檢測，及時發現問題。我司的Cloud Test，Cloud Performance Test 主要是產出這些數據的，CT的產品能從遍布全球的撥測點，對網站的可用性進行全天候的分散式監控。其中我們的CPT 給你帶來從數百到數百萬完全彈性的壓力測試能力，獲得應用在高壓力的情況下的性能表現情況。

因為IT 監控技術發展實在是太龐雜，以上的劃分不一定對，但是應該沒有顯著的遺漏。

但如果從微觀技術的角度來看，不考慮數據的來源，只考慮數據本身的屬性特點，我們可以這樣劃分：

指標數據（ Metrics Data ）

描述具體某個對象某個時間點這個就不用多說了， CPU 百分比等等，指標數據等等

日誌數據 ( Logging Data ）

描述某個對象的是離散的事情，例如有個應用出錯，拋出了NullPointerExcepction，個人認為Logging Data 大約等同於 Event Data，所以告警信息在我認為，也是一種Logging Data。

調用鏈數據（ Tracing Data ）：

Tracing Data這詞貌似現在還沒有一個權威的翻譯範式，有人翻譯成跟蹤數據，有人翻譯成調用數據，我盡量用Tracing 這個詞。 Tracing的特點就是，它在單次請求的範圍內，處理信息。任何的數據、元數據信息都被綁定到系統中的單個事務上。例如：一次調用遠程服務的RPC執行過程；一次實際的SQL查詢語句；一次HTTP請求的業務性ID。通過對Tracing 信息進行還原，我們可以得到調用鏈 Call Chain 調用鏈，或者是 Call Tree 調用數。

官方OpenTracing 中的Call Tree例子。

在實踐的過程中，很多的日誌，都會有流水號，Trace ID， span ID， ChildOf, FollowsFrom 等相關的信息，如果通過技術手段，將其串聯在一起，也可以將這些日誌視為Tracing 。

Tracing信息越來越被重視，因為在一個分散式環境中，進行故障定位，Tracing Data 是必不可少的。

由於Tracing 相對於Logging 以及 Metircs 相對比較複雜一點，想深入了解的話，可以參考：

《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》 http://bigbully.github.io/Dapper-translation/

Opentracing 的技術規範文檔 https://github.com/opentracing/specification 如果我們將以上數據類型做成一個矩陣看看，我們可以得到這樣一個表格，比較好的說清楚了相關關係。

舉例就是，我們的Server Insight 基礎監控產品，能採集及處理指標數據，及日誌，但是基礎監控產品，不會處理Tracing Data，而我們的Application Insight 產品能從JVM 虛擬機中，通過插碼，獲得應用的響應時間（Metris），Java異常（ Logging ），應用間的調用拓撲關係，以及調用的響應時間（Tracing）。

我司AI 平台應用拓撲截圖

回到Garnert 的AIOps 能力定義，居然沒有把 Tracing Data 納入到數據整合的範圍之中，個人認為不太合理，因為要去做根因分析，如果不知道服務和指標之間的關聯關係，其實是比較難做到故障的根本定位的。

演算法部分

其實可以看到，Gartner 在ITOA 定義的演算法部分，如模式發現，機器學習等技術定義，都被比較順滑的過渡到AIOPS 中來，一個方面可以看出Gartner 在定義ITOA 的時候有足夠的前瞻性，另外一個方面可以看到，相關的演算法問題，解決及演進的速度，是相對於基礎大數據架構相對要慢上不少。

小結

AIOPS 概念與 ITOA 概念相比，在大數據技術部分進行了更細，更有指導性的闡述，所以我認為，AIOps 首先是大數據，然後才是演算法。

誤解：

AIOps 等於可以減少人力資源的投入

AIOps 不等於無人值守
AIOps 不等於 NoOps
AIOps 不等於可以減少人專家的參與
AIOps 可以降低人力成本
AIOps 在現階段不等於可以省錢

AI 的確是一個非常性感的辭彙，大家認為只要實現了智能化，就能夠輕輕鬆鬆，不需要人的干預，這當然是一個非常理想的狀況，但是，在短時間內，這個不能實現。這個的實現難度，個人認為，與自動無人駕駛，能實現第五等級是同樣的難度，也就說，可能起碼需要10年左右的時間，甚至可能更長時間。

AIOps平台本質上還是一個工具，在構建後，仍然需要人的參與，而且在目前的探索發展的投入階段，有大量的工需要去做，需要運維專家，大數據工程師，演算法科學家，業務專家，暫時看不到能削減人力成本的可能性，而且相關的投入可能需要多年的時間。

在平台建立後，在持續改進的情況下，仍然需要專家或者分析師，從不同的維度，從不同的業務口徑，組合合適的可視化技術，機器學習技術，大數據分析技術，制定分析場景，平台才能夠為IT運維，業務分析產生持續的洞察，提供商業價值。

所以，AIOps 不能取代人，在現階段不可能減少人力投入，但在未來可能能促進部分運維人員轉型為通曉業務，掌握運維知識的數據分析師。

演算法和智能化是AIOps最重要的事情

演算法很重要，但是我個人認為，在此階段，大部分企業不應該以演算法為第一著眼點。

這個應該是比較有爭議，或者，或者說大家認知不太一致的部分。以下這張圖是Gartnert 在 AIOps還在叫ITOA 時候，給定義的四個階段：

Data ingestion, indexing, storage and access
Visualization and basic statistical summary
Pattern discovery and anomaly detection
True causal path discovery

Gartner 在報告中強調，掌握後面階段的前提是擁有前一階段的能力，如果不擁有充分的前一階段能力，將會影響ITOA 的落地效果。因此這四個階段必須一個步一腳印，第三以及第四部時，才顯著地引入了機器演算法，或者AI的必要。

大家都知道，所謂的機器學習演算法，統計演算法，深度學習演算法這些AI 的分類，其實是高度依賴於數據的。沒有多種數據源，數據的採集，數據存儲，數據統計，數據可視化，一切都只是空中樓梯。

來源： Gartner Report 「Organizations Must Sequentially Implement the Four Phases of ITOA to Maximize Investment 」 2015.2.18

因此，AIOps的平台的建設首先應該是著眼點應該是大數據，然後才是演算法，從而實現持續洞察和改進的目標。

一定要上深度學習才叫AIOps

我們可以先看看AI , Machine Learning , Deep Learning 的關係，他們的關係大概如下圖。

學術界有不少學者，在探索部分深度學習演算法智能運維中的應用，如猶他州大學的《DeepLog: Anomaly Detection and Diagnosis from System Logs through Deep Learning》中利用 Long Short-Term Memory (LSTM)來實現日誌模式的發現，從而實現異常檢測。但是，其實智能運維所需要的大部分演算法，決策樹學習（decision tree learning）、聚類（clustering）、SVM（Support Vector Machine）和貝葉斯網路（Bayesian networks）等等演算法，均是屬於傳統的機器學習範疇的，因此我們不應該將深度學習與AIOps 掛上必然的聯繫。

甚至於，我們不用拘泥於概念，從解決問題的角度出發，在特定的場景，利用傳統的規則集，設定一些規則，降低了運維人員的工作強度，提高了效率，也能叫智能運維。甚至在Gartner 的報告中，對AIOps 落地的第一步，是統計分析，可視化，而不是任何的機器學習演算法。

它適合現階段所有有規模的用戶

這個比較好理解，就目前來看，AIOps 只適合大型的客戶，原因如下:

中小型的客戶缺乏多種數據源
中小型客戶業務需求沒有那麼複雜
很多演算法，其實是為了大規模運維的時候才用的上的，在規模小的時候，難以產生效果

運維自動化是智能運維的前提

我看到過不少的文章，將運維分成了四個階段，將自動化運維放在智能運維的前一個階段，把智能，又或者在智能運維這個體系裡頭，硬是塞了很多自動化運維，批量操作，批量規劃的功能在裡頭，我覺得都是不對的。自動化運維更像是手，智能運維更像是眼鏡及大腦，有了更全面數據，更充滿的分析後，大腦能更好的指揮手進行操作。

因此，企業應該將自動化運維和智能化運維看成了兩個有關聯的體系，但是不應該混一談，造成更多的誤解。

挑戰

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

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

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

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

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

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

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

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

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

從目前來看，大家期望利用演算法解決的場景包括：

單指標異常檢測
多指標異常檢測
日誌模式異常檢測（參照 Log Compare）
故障根因分析
容量預估
告警智能壓縮（基於根因，基於事件日誌模式）
故障預測（較為常用的場景為硬碟的故障定位）
基於知識圖譜（運維經驗）故障定位

以上的每個智能場景，每個場景所需要用到的演算法都不一樣，而且成熟度也不一樣。

以最為簡單，但應用最為廣泛，成熟度最高的單指標異常檢測來舉例，從學術的角度來看，如果你到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
監控指標深度，專業華程度不夠： 這個問題很多時候反應的資料庫監控上，由於資料庫專業化程度較高，因此對資料庫的很多關鍵的指標未能識別，導致了關鍵信息的遺漏，可能會大大影響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年的黃金時代。