AIOps背景/所應具有技術能力分析（上）

本文篇幅較長，分爲上，中，下，三個部分進行連載。內容分別爲：AIOps 背景/所應具有技術能力分析（上），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 的所應該有的能力定義。

 

 

1. ML/SPDR: 機器學習/統計模式發現與識別;

2. UTISI: 非結構化文本索引，搜索以及推斷;

3. Topological Analysis: 拓撲分析;

4. Multi-dimensional Database Search and Analysis:多維數據庫搜索與分析;

5. 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)。

 

 

 

 

回到 Garnert 的 AIOps 能力定義， 竟然沒有把 Tracing Data 歸入到數據整合的範圍之中，我的認爲不太合理，由於要去作根因分析，若是不知道服務和指標之間的關聯關係，實際上是比較難作到故障的根本定位的。

算法部分

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

小結

AIOPS 概念與 ITOA 概念相比，在大數據技術部分進行了更細，更有指導性的闡述，因此我認爲，AIOps 首先是大數據，而後纔是算法。

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

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