本文篇幅較長(zhǎng)，分為上，中，下，三個(gè)部分進(jìn)行連載。內(nèi)容分別為：AIOps?背景/所應(yīng)具備技術(shù)能力分析（上），AIOps 常見(jiàn)的誤解（中），挑戰(zhàn)及建議（下）。

前言

我大概是 5，6 年前開(kāi)始接觸 ITOA 這個(gè)領(lǐng)域的，首次接觸后，發(fā)現(xiàn)領(lǐng)域有著巨大的潛力，一直尋找在這個(gè)領(lǐng)域做點(diǎn)事情的機(jī)會(huì)。大約三年前在這個(gè)領(lǐng)域創(chuàng)業(yè)，積極尋求 Product Market Fit。這幾年下來(lái)，經(jīng)過(guò)與行業(yè)內(nèi)的專家交流，研讀報(bào)告，閱讀論文，客戶訪談，親自動(dòng)手對(duì)相應(yīng)的運(yùn)維場(chǎng)景解析，行業(yè)產(chǎn)品的試用調(diào)研，以及結(jié)合著中國(guó)運(yùn)維市場(chǎng)現(xiàn)狀，撰寫(xiě)了此文。本人才疏學(xué)淺，不學(xué)無(wú)術(shù)，歡迎拍磚。

背景

概念的進(jìn)化：ITOA -> AIOps -> AIOps

讓我們回到2013年，著名的 Buzz word (時(shí)髦用語(yǔ)) 制造商?Gartner?在一份報(bào)告中提及了 ITOA，當(dāng)時(shí)的定義是，IT 運(yùn)營(yíng)分析(IT Operations Analytics)， 通過(guò)技術(shù)與服務(wù)手段，采集、存儲(chǔ)、展現(xiàn)海量的 IT 運(yùn)維數(shù)據(jù)，并進(jìn)行有效的推理與歸納得出分析結(jié)論。

而隨著時(shí)間推移，在2016年，Gartner 將 ITOA 概念升級(jí)為了 AIOps，原本的含義基于算法的 IT 運(yùn)維(Algorithmic IT Operations)，即，平臺(tái)利用大數(shù)據(jù)，現(xiàn)代的機(jī)器學(xué)習(xí)技術(shù)和其他高級(jí)分析技術(shù)，通過(guò)主動(dòng)，個(gè)性化和動(dòng)態(tài)的洞察力直接或間接地，持續(xù)地增強(qiáng) IT 操作(監(jiān)控，自動(dòng)化和服務(wù)臺(tái))功能。 AIOps 平臺(tái)可以同時(shí)使用多個(gè)數(shù)據(jù)源，多種數(shù)據(jù)收集方法，實(shí)時(shí)分析技術(shù)，深層分析技術(shù)以及展示技術(shù)。

隨著 AI 在多個(gè)領(lǐng)域越來(lái)越火爆，Gartner 終于按捺不住了，在它的2017年年中一份報(bào)告中，順應(yīng)民意將 AIOps 的含義定義為了，Artificial Intelligence for IT Operations， 也就是現(xiàn)在大家都在說(shuō)的智能運(yùn)維。

在短短的不到 1 年時(shí)間中，伴隨著AI的熱炒，以及在各個(gè)領(lǐng)域的落地，運(yùn)維界的同仁基本上把 AIOps 看成是未來(lái)解決運(yùn)維問(wèn)題的必然方向。

個(gè)人認(rèn)為，在企業(yè)內(nèi)部構(gòu)建 AIOps，通過(guò)融合 IT 數(shù)據(jù)，真正打破數(shù)據(jù)煙囪，對(duì)監(jiān)控，自動(dòng)化，服務(wù)臺(tái)進(jìn)行支持，使得 IT 能夠更好的支撐業(yè)務(wù)，利用大數(shù)據(jù)技術(shù)以及機(jī)器學(xué)習(xí)技術(shù)，回答以前很多單從業(yè)務(wù)口徑，或者單從 IT 口徑無(wú)法回答的問(wèn)題。如，聯(lián)通，電信，移動(dòng)，電信的用戶，哪種用戶轉(zhuǎn)化率較高。AIOps 以創(chuàng)造商業(yè)價(jià)值為導(dǎo)向，對(duì) IT 運(yùn)營(yíng)以及業(yè)務(wù)運(yùn)營(yíng)產(chǎn)生持續(xù)洞察，為?DevOps?提供持續(xù)反饋，加快企業(yè)在競(jìng)爭(zhēng)日趨激烈市場(chǎng)環(huán)境中，數(shù)字化轉(zhuǎn)型的步伐。

因此，Gartner 預(yù)測(cè)到2022年，大型企業(yè)中的的40%將會(huì)部署 AIOps 平臺(tái)。

具體關(guān)于 AIOps 的概念，價(jià)值，Gartner 很多都已經(jīng)說(shuō)的很清楚，不是本文的重點(diǎn)，本文是根據(jù)我的理解，嘗試從現(xiàn)實(shí)的角度，去談 AIOps 在落地過(guò)程中容易產(chǎn)生的誤解，挑戰(zhàn)以及一些建議。

AIOps 所應(yīng)具備技術(shù)能力分析

個(gè)人認(rèn)為，AIOps，本質(zhì)上是 ITOA 的升級(jí)版，讓我們來(lái)看一下 Garnter 在 2015 年對(duì) ITOA 的所應(yīng)該有的能力定義。

ML/SPDR: 機(jī)器學(xué)習(xí)/統(tǒng)計(jì)模式發(fā)現(xiàn)與識(shí)別;

UTISI: 非結(jié)構(gòu)化文本索引，搜索以及推斷;

Topological Analysis: 拓?fù)浞治?

Multi-dimensional Database Search and Analysis:多維數(shù)據(jù)庫(kù)搜索與分析;

Complex Operations Event Processing: 復(fù)雜運(yùn)維事件處理;

然后， 我們對(duì)比一下，Gartner 對(duì) AIOps 的能力定義

Historical data management 歷史數(shù)據(jù)管理;

Streaming data management 流數(shù)據(jù)管理;

Log data ingestion 日志數(shù)據(jù)整合;

Wire data ingestion 網(wǎng)絡(luò)數(shù)據(jù)整合;

Metric data ingestion 指標(biāo)數(shù)據(jù)整合;

Document text ingestion 文本數(shù)據(jù)整合;

Automated pattern discovery and prediction 自動(dòng)化模式發(fā)現(xiàn)和預(yù)測(cè);

Anomaly detection 異常檢測(cè);

Root cause determination 根因分析;

On-premises delivery 提供私有化部署;

Software as a service 提供?SaaS?服務(wù);

除去最后兩個(gè)的交付方式，對(duì)比下來(lái)，我認(rèn)為 AIOps 比起原來(lái)的 ITOA 有以下的進(jìn)化：

強(qiáng)調(diào)歷史數(shù)據(jù)的管理：

允許采集，索引和持續(xù)存儲(chǔ)日志數(shù)據(jù)，網(wǎng)絡(luò)數(shù)據(jù)，指標(biāo)以及文檔數(shù)據(jù)，數(shù)據(jù)大部分是非結(jié)構(gòu)化或者半結(jié)構(gòu)化的，而且數(shù)據(jù)量累積速度很快，格式多樣，非常符合大數(shù)據(jù)的特征。總所周知，在新一輪以 CNN , RNN 算法為代表的算法中，都需要大量有標(biāo)準(zhǔn)的數(shù)據(jù)來(lái)進(jìn)行訓(xùn)練，因此， 對(duì)歷史數(shù)據(jù)的管理，成了智能運(yùn)維的第一重點(diǎn)。

強(qiáng)調(diào)實(shí)時(shí)的流數(shù)據(jù)管理：

以?Kafka?Streams，F(xiàn)link，Storm，Spark Streaming 為代表的流計(jì)算處理技術(shù)，已經(jīng)成為了各大數(shù)據(jù)平臺(tái)的必備組件，而面對(duì) IT 數(shù)據(jù)中海量的實(shí)時(shí)流式數(shù)據(jù)，某些場(chǎng)景里頭，在數(shù)據(jù)進(jìn)行持久化前，進(jìn)行實(shí)時(shí)分析，查詢，集合，處理，降低數(shù)據(jù)庫(kù)(SQL or Nosql)的負(fù)載，成為了非常合理且常規(guī)的選擇，因此 AIOps 平臺(tái)中，含有數(shù)據(jù)流，非常合理。

強(qiáng)調(diào)多種數(shù)據(jù)源的整合:

我認(rèn)為，這個(gè)是 AIOps 平臺(tái)最大的價(jià)值點(diǎn)，因?yàn)?Gartner 第一次將多種數(shù)據(jù)源整合的能力，帶入了?ITOM管理的領(lǐng)域，我們搞運(yùn)維監(jiān)控那么多年，終于第一次可以以大數(shù)據(jù)的視角，數(shù)據(jù)驅(qū)動(dòng)的視角，去思考運(yùn)維監(jiān)控這個(gè)傳統(tǒng)。

Gartner 這里提及到了四種數(shù)據(jù)，Log Data, Wire Data, Metirc data，Document text。 這樣的分類，我是個(gè)人持有保留意見(jiàn)，感覺(jué)很奇怪，特別是 Document text 的那塊，需要用到 NLP，主要是用于打通 ITSM 產(chǎn)品，分析 ITSM 工單。我對(duì)這個(gè)場(chǎng)景存在必要性，以及實(shí)現(xiàn)的 ROI 表示懷疑。具體原因我可能稍后會(huì)寫(xiě)一篇文章，進(jìn)行更詳細(xì)的解釋。

我認(rèn)為，如果從宏觀的類型來(lái)劃分，應(yīng)該這樣劃分 (下含部分我司產(chǎn)品介紹)

機(jī)器數(shù)據(jù)(Machine Data)：是 IT 系統(tǒng)自己產(chǎn)生的數(shù)據(jù)，包括客戶端、服務(wù)器、網(wǎng)絡(luò)設(shè)備、安全設(shè)備、應(yīng)用程序、傳感器產(chǎn)生的日志，及 SNMP、WMI，監(jiān)控腳本等時(shí)間序列事件數(shù)據(jù)(含CPU 內(nèi)存變化的程度)，這些數(shù)據(jù)都帶有時(shí)間戳。這里要強(qiáng)調(diào)， Machine Data 不等于 Log Data ，因?yàn)橹笜?biāo)數(shù)據(jù)包含。在通常的業(yè)界實(shí)踐中，這些數(shù)據(jù)通常通過(guò)運(yùn)行在主機(jī)上的一個(gè) Agent 程序，如 LogStash， File beat，Zabbix?agent 等獲得，如果我們的 LogInsight，Server Insight 產(chǎn)品，就是面向此類型數(shù)據(jù)。

網(wǎng)絡(luò)數(shù)據(jù)(Wire Data)：系統(tǒng)之間2~7層網(wǎng)絡(luò)通信協(xié)議的數(shù)據(jù)，可通過(guò)網(wǎng)絡(luò)端口鏡像流量，進(jìn)行深度包檢測(cè) DPI(Deep Packet Inspection)、包頭取樣 Netflow 等技術(shù)分析。一個(gè)10Gbps端口一天產(chǎn)生的數(shù)據(jù)可達(dá)100TB，包含的信息非常多，但一些性能、安全、業(yè)務(wù)分析的數(shù)據(jù)未必通過(guò)網(wǎng)絡(luò)傳輸，一些事件的發(fā)生也未被觸發(fā)網(wǎng)絡(luò)通信，從而無(wú)法獲得。我司的 Network Insight 主要面向的是這些數(shù)據(jù)，提供關(guān)鍵應(yīng)用的 7 x 24 小時(shí)全方位視圖。

代理數(shù)據(jù)(Agent Data)：是在 .NET、PHP、Java?字節(jié)碼里插入代理程序，從字節(jié)碼里統(tǒng)計(jì)函數(shù)調(diào)用、堆棧使用等信息，從而進(jìn)行代碼級(jí)別的監(jiān)控。我司的 Application Insight 主要是解決這個(gè)問(wèn)題而誕生，能獲得真正用戶體驗(yàn)數(shù)據(jù)以及應(yīng)用性能指標(biāo)。

探針數(shù)據(jù)(Probe Data)：也就是所謂的撥測(cè)，是模擬用戶請(qǐng)求，對(duì)系統(tǒng)進(jìn)行檢測(cè)獲得的數(shù)據(jù)，如 ICMP ping、HTTP GET 等，能夠從不同地點(diǎn)模擬客戶端發(fā)起，進(jìn)行包括網(wǎng)絡(luò)和服務(wù)器的端到端全路徑檢測(cè)，及時(shí)發(fā)現(xiàn)問(wèn)題。 我司的?Cloud Test，Cloud Performance Test 主要是產(chǎn)出這些數(shù)據(jù)的，CT 的產(chǎn)品能從遍布全球的撥測(cè)點(diǎn)，對(duì)網(wǎng)站的可用性進(jìn)行全天候的分布式監(jiān)控。其中我們的 CPT 給你帶來(lái)從數(shù)百到數(shù)百萬(wàn)完全彈性的壓力測(cè)試能力，獲得應(yīng)用在高壓力的情況下的性能表現(xiàn)情況。

因?yàn)?IT 監(jiān)控技術(shù)發(fā)展實(shí)在是太龐雜，以上的劃分不一定對(duì)，但是應(yīng)該沒(méi)有顯著的遺漏。

但如果從微觀技術(shù)的角度來(lái)看，不考慮數(shù)據(jù)的來(lái)源，只考慮數(shù)據(jù)本身的屬性特點(diǎn)，我們可以這樣劃分：

指標(biāo)數(shù)據(jù)( Metrics Data )

描述具體某個(gè)對(duì)象某個(gè)時(shí)間點(diǎn)這個(gè)就不用多說(shuō)了， CPU 百分比等等，指標(biāo)數(shù)據(jù)等等

日志數(shù)據(jù) ( Logging Data )

描述某個(gè)對(duì)象的是離散的事情，例如有個(gè)應(yīng)用出錯(cuò)，拋出了 NullPointerExcepction，個(gè)人認(rèn)為 Logging Data 大約等同于 Event Data，所以告警信息在我認(rèn)為，也是一種 Logging Data。

調(diào)用鏈數(shù)據(jù)( Tracing Data )

Tracing Data 這詞貌似現(xiàn)在還沒(méi)有一個(gè)權(quán)威的翻譯范式，有人翻譯成跟蹤數(shù)據(jù)，有人翻譯成調(diào)用數(shù)據(jù)，我盡量用 Tracing 這個(gè)詞。 Tracing 的特點(diǎn)就是，它在單次請(qǐng)求的范圍內(nèi)，處理信息。 任何的數(shù)據(jù)、元數(shù)據(jù)信息都被綁定到系統(tǒng)中的單個(gè)事務(wù)上。 例如：一次調(diào)用遠(yuǎn)程服務(wù)的 RPC 執(zhí)行過(guò)程;一次實(shí)際的 SQL 查詢語(yǔ)句;一次 HTTP 請(qǐng)求的業(yè)務(wù)性 ID。 通過(guò)對(duì) Tracing 信息進(jìn)行還原，我們可以得到調(diào)用鏈 Call Chain 調(diào)用鏈，或者是 Call Tree 調(diào)用數(shù)。

官方 OpenTracing 中的 Call Tree 例子。

在實(shí)踐的過(guò)程中，很多的日志，都會(huì)有流水號(hào)，Trace?ID， span ID， ChildOf, FollowsFrom 等相關(guān)的信息，如果通過(guò)技術(shù)手段，將其串聯(lián)在一起，也可以將這些日志視為 Tracing 。

Tracing 信息越來(lái)越被重視，因?yàn)樵谝粋€(gè)分布式環(huán)境中，進(jìn)行故障定位，Tracing Data 是必不可少的。

由于 Tracing 相對(duì)于 Logging 以及 Metircs 相對(duì)比較復(fù)雜一點(diǎn)，想深入了解的話，可以參考 ：

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

Opentracing 的技術(shù)規(guī)范文檔 https://github.com/opentracing/specification 如果我們將以上數(shù)據(jù)類型做成一個(gè)矩陣看看，我們可以得到這樣一個(gè)表格，比較好的說(shuō)清楚了相關(guān)關(guān)系。

舉例就是，我們的 Server Insight 基礎(chǔ)監(jiān)控產(chǎn)品，能采集及處理指標(biāo)數(shù)據(jù)，及日志，但是基礎(chǔ)監(jiān)控產(chǎn)品，不會(huì)處理 Tracing Data，而我們的?Application Insight?產(chǎn)品能從 JVM 虛擬機(jī)中，通過(guò)插碼，獲得應(yīng)用的響應(yīng)時(shí)間(Metris)，Java異常( Logging )，應(yīng)用間的調(diào)用拓?fù)潢P(guān)系，以及調(diào)用的響應(yīng)時(shí)間(Tracing)。

回到 Garnert 的 AIOps 能力定義， 居然沒(méi)有把 Tracing Data 納入到數(shù)據(jù)整合的范圍之中，個(gè)人認(rèn)為不太合理，因?yàn)橐プ龈蚍治觯绻恢婪?wù)和指標(biāo)之間的關(guān)聯(lián)關(guān)系，其實(shí)是比較難做到故障的根本定位的。

算法部分

其實(shí)可以看到，Gartner 在 ITOA 定義的算法部分，如模式發(fā)現(xiàn)，機(jī)器學(xué)習(xí)等技術(shù)定義，都被比較順滑的過(guò)渡到 AIOPS 中來(lái)，一個(gè)方面可以看出 Gartner 在定義 ITOA 的時(shí)候有足夠的前瞻性，另外一個(gè)方面可以看到，相關(guān)的算法問(wèn)題，解決及演進(jìn)的速度，是相對(duì)于基礎(chǔ)大數(shù)據(jù)架構(gòu)相對(duì)要慢上不少。

小結(jié)

AIOPS 概念與 ITOA 概念相比，在大數(shù)據(jù)技術(shù)部分進(jìn)行了更細(xì)，更有指導(dǎo)性的闡述，所以我認(rèn)為，AIOps 首先是大數(shù)據(jù)，然后才是算法。

OneAPM?全新推出新一代 AIOps 平臺(tái) I2，歡迎您隨時(shí)聯(lián)系我們，即刻開(kāi)啟貴公司的智能運(yùn)維之旅。點(diǎn)擊進(jìn)入AIOps 官網(wǎng)了解更多信息。

來(lái)源：http://blog.oneapm.com/apm-tech/815.html