AIOps 平臺的誤解挑戰及建議
| 編輯推薦: |
| 本文來源sohu，本文是根據作者的理解，嘗試從現實的角度，去談AIOps 在落地過程中容易產生的誤解，挑戰以及一些建議。 |
背景概念的進化：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》 bigbully.github.io/Dapp/
Opentracing 的技術規範文件 github.com/opentracing/如果我們將以上資料型別做成一個矩陣看看，我們可以得到這樣一個表格，比較好的說清楚了相關關係。
舉例就是，我們的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年的黃金時代。