企業(yè)數(shù)字化使得運(yùn)維智能化轉(zhuǎn)型成為必然，宜信積極推動(dòng) AIOps 在科技金融企業(yè)的落地實(shí)踐。本文探索 AIOps 落地的一種形式：通過行為采集、仿真模擬、主動(dòng)感知等手段，從用戶側(cè)真實(shí)系統(tǒng)使用體驗(yàn)出發(fā)，結(jié)合全維監(jiān)控?cái)?shù)據(jù)，更加有效的實(shí)現(xiàn)智能異常檢測(cè)和根因分析。

一、運(yùn)維的發(fā)展

1.1 運(yùn)維的價(jià)值

早期的運(yùn)維工作比較簡(jiǎn)單，一般是先由系統(tǒng)集成工程師及研發(fā)工程師研發(fā)完項(xiàng)目后交付出來，再由負(fù)責(zé)運(yùn)維工作的人員從后臺(tái)做一些操作，保證系統(tǒng)正常運(yùn)行。

隨著軟件研發(fā)行業(yè)和技術(shù)的發(fā)展，運(yùn)維的工作也變得越來越豐富。現(xiàn)階段運(yùn)維的工作與價(jià)值主要集中在三個(gè)方面：

1）效率

大量業(yè)務(wù)上線，運(yùn)維人員需要保障快速高效地為系統(tǒng)提供資源、應(yīng)對(duì)業(yè)務(wù)變更、響應(yīng)操作請(qǐng)求。

2）質(zhì)量

運(yùn)維的目標(biāo)是保障質(zhì)量及系統(tǒng)的穩(wěn)定性。也就是說，要保障業(yè)務(wù)和系統(tǒng)7*24小時(shí)在線上穩(wěn)定運(yùn)行，為用戶提供流暢舒適的體驗(yàn)。為實(shí)現(xiàn)這個(gè)目標(biāo)，運(yùn)維的相關(guān)工作包括：

• 故障預(yù)測(cè)：沒出現(xiàn)問題之前預(yù)測(cè)到故障發(fā)生的可能。 

• 異常檢測(cè)：出現(xiàn)問題時(shí)很快檢測(cè)并定位到異常點(diǎn)。 

• 根因分析：分析問題的誘因，找出真正導(dǎo)致問題的根本原因。 

• 動(dòng)態(tài)擴(kuò)容：?jiǎn)栴}處理的過程中可能受到復(fù)雜因素的影響，需要對(duì)系統(tǒng)進(jìn)行動(dòng)態(tài)擴(kuò)容。 

• 服務(wù)降級(jí)：不影響核心業(yè)務(wù)的邊緣業(yè)務(wù)可能需要做服務(wù)降級(jí)處理。

3）成本

隨著公司規(guī)模的不斷壯大，投入產(chǎn)出比也越來越被重視。運(yùn)維的另外一個(gè)價(jià)值在于降低成本。主要體現(xiàn)為：

• 容量規(guī)劃：規(guī)劃每年在IT運(yùn)維層面投入多少人員和資源。 

• 彈性調(diào)度：如何調(diào)度和分配資源，實(shí)現(xiàn)資源的充分利用。 

• 利用率分析：利用率分析包括動(dòng)態(tài)和靜態(tài)兩個(gè)方面。 

• 趨勢(shì)分析：比如今年花了多少錢在IT運(yùn)維層面，明年要花多少錢在這個(gè)方面，這是一個(gè)趨勢(shì)分析。 

• 成本分析：成本分析包括今年有多少業(yè)務(wù)、每個(gè)業(yè)務(wù)用了多少錢、多少IT技術(shù)設(shè)施、多少人員。

1.2 運(yùn)維的困境

如圖所示，橫坐標(biāo)代表服務(wù)規(guī)模。公司業(yè)務(wù)不斷增長(zhǎng)，服務(wù)規(guī)模也相應(yīng)增長(zhǎng)，此處我們簡(jiǎn)單理解為這是一個(gè)線性的變化，不考慮業(yè)務(wù)的暴增。

然而，業(yè)務(wù)規(guī)模增長(zhǎng)反映到運(yùn)維的復(fù)雜度增長(zhǎng)上最少體現(xiàn)在三個(gè)層面：

• 服務(wù)規(guī)模的增長(zhǎng)直接導(dǎo)致服務(wù)器量及網(wǎng)絡(luò)量的增長(zhǎng)，隨之而來的是網(wǎng)絡(luò)拓?fù)涞脑鲩L(zhǎng)。 

• 業(yè)務(wù)增長(zhǎng)，服務(wù)的技術(shù)棧也是增長(zhǎng)的。以前可能前邊跑一個(gè)服務(wù)，后邊跑一個(gè)數(shù)據(jù)庫(kù)就可以了，現(xiàn)在隨著服務(wù)規(guī)模的不斷增長(zhǎng)，引入不同服務(wù)形式，可能就有了隊(duì)列、緩存等，相應(yīng)的，技術(shù)棧也不斷增加。 

• 服務(wù)拓?fù)洳粩嘣鲩L(zhǎng)。以前可能一個(gè)煙囪型的服務(wù)就可以了，而現(xiàn)在隨著微服務(wù)的應(yīng)用，服務(wù)之間的調(diào)度非常多，需要增長(zhǎng)服務(wù)拓?fù)鋪頋M足需求。

隨著服務(wù)規(guī)模的增長(zhǎng)，運(yùn)維復(fù)雜度呈現(xiàn)指數(shù)級(jí)增長(zhǎng)，那運(yùn)維人員是否也隨著增長(zhǎng)了呢？縱觀各司，答案是否定的。出于節(jié)約成本的考慮，各司各崗位人員并不會(huì)隨著服務(wù)復(fù)雜度增加而擴(kuò)張，反而是越來越趨于平穩(wěn)?；谶@個(gè)比例，相當(dāng)于運(yùn)維復(fù)雜度越來越高的情況下，運(yùn)維人員越來越少了。

中間的差距如何來彌補(bǔ)呢？這就需要運(yùn)用到運(yùn)維手段了。即上圖所示的：運(yùn)維質(zhì)量=運(yùn)維人員 X 運(yùn)維手段。運(yùn)維人員要通過各種運(yùn)維手段來解決運(yùn)維困境，進(jìn)而推動(dòng)運(yùn)維的發(fā)展。

1.3 運(yùn)維的發(fā)展

如圖所示，運(yùn)維的發(fā)展大致分為四個(gè)階段：

1）手工階段

手工階段比較好理解，研發(fā)人員交付一個(gè)系統(tǒng)，運(yùn)維人員通過手工執(zhí)行操作保障這個(gè)系統(tǒng)正常運(yùn)行。此階段的運(yùn)維工作沒有什么標(biāo)準(zhǔn)可言。

2）標(biāo)準(zhǔn)化階段

隨著企業(yè)IT系統(tǒng)越來越多地引入運(yùn)維，且所有業(yè)務(wù)都變成系統(tǒng)形式在線上運(yùn)行，運(yùn)維工作的重要性越來越高，但同時(shí)帶來的是運(yùn)維和研發(fā)、業(yè)務(wù)人員工作中的溝通壁壘。這時(shí)就衍生出了一些標(biāo)準(zhǔn)，其中最主要的是ITSM（IT Service Management，IT服務(wù)管理）。ITSM的目標(biāo)是把日常所有的運(yùn)維工作，包括流程、信息管理、風(fēng)險(xiǎn)控制等，通過系統(tǒng)建設(shè)和標(biāo)準(zhǔn)化固定下來，像流水線一樣，人員只需要按照標(biāo)準(zhǔn)參與即可。

3）自動(dòng)化階段

隨著互聯(lián)網(wǎng)大爆發(fā)，服務(wù)交付模型越來越多，用戶對(duì)互聯(lián)網(wǎng)和IT的要求越來越高，ITSM的缺點(diǎn)也越來越明顯，主要表現(xiàn)為時(shí)間過長(zhǎng)、成本過高，不能適應(yīng)快速多變的需求。于是從工程或運(yùn)維的角度自發(fā)出現(xiàn)了一種文化：DevOps，DevOps強(qiáng)調(diào)運(yùn)維、研發(fā)及QA工程師工作的高度融合，要求運(yùn)維從工程交付的角度不斷迭代。

同時(shí)從企業(yè)IT管理或運(yùn)營(yíng)訴求出發(fā)也要解決快速演進(jìn)的問題，于是演化出了標(biāo)準(zhǔn)ITOM。ITOM和ITSM很像，區(qū)別是把“S”改成“O”，即把Operation本身及其帶來的各種自動(dòng)化工具納入模型中，包括主機(jī)、運(yùn)營(yíng)、發(fā)布系統(tǒng)等等。

• DevOps不斷發(fā)展演變成現(xiàn)在的ChatOps，ChatOps的目標(biāo)是將研發(fā)、運(yùn)維、QA融合起來，以說話（Chat）的方式進(jìn)行交流，但 ChatOps 只考慮了交流的形式，并沒有就如何實(shí)現(xiàn)基于 Chat 方式的整體解決方案，ChatOps 并沒有很好的解決 DevOps 的困境。 

• ITOM把所有的Operation線上化、自動(dòng)化后，發(fā)現(xiàn)IT運(yùn)維所產(chǎn)生的大量數(shù)據(jù)是非常有意義的，特別是對(duì)于企業(yè)數(shù)字化而言，這些數(shù)據(jù)經(jīng)過加工分析，可以對(duì)日常業(yè)務(wù)產(chǎn)生價(jià)值。于是Gartner提出了一個(gè)新的標(biāo)準(zhǔn)“ITOA”。ITOA強(qiáng)調(diào)IT數(shù)據(jù)的價(jià)值，提出對(duì)IT運(yùn)維分析的訴求，但沒說明這個(gè)數(shù)據(jù)能干什么。很快Gartner就將ITOA演化成“AIOps”。這時(shí)AIOps中的“AI”是指“Algorithm（算法）”，強(qiáng)調(diào)的是數(shù)據(jù)分析本身產(chǎn)生的價(jià)值，包括通過算法來解決線上故障發(fā)現(xiàn)、日常交互等運(yùn)維問題。

4）智能化階段

隨著行業(yè)對(duì)IT運(yùn)維要求的不斷提高，無論是AIOps還是ChatOps，都面臨一個(gè)嚴(yán)重的問題：人處理不過來了。從工程角度來看，運(yùn)維面臨的現(xiàn)狀是異構(gòu)性非常強(qiáng)，需要引入三方應(yīng)用和各種各樣的設(shè)備，交付模式也越來越多，運(yùn)維復(fù)雜度出現(xiàn)指數(shù)級(jí)增長(zhǎng)。

為解決上述問題，Gartner適時(shí)提出了“AIOps”的概念，這里的“AI”代表的是人工智能，通過機(jī)器人的參與將人工智能技術(shù)體系帶入到運(yùn)維的各個(gè)環(huán)節(jié)，幫助解決運(yùn)維問題，運(yùn)維發(fā)展也由此進(jìn)入智能化階段。

二、什么是智能運(yùn)維

2.1 什么是智能運(yùn)維（AIOps）？

BMC給了AIOps定義是：

AIOps refers to multi-layered technology platforms that automate and enhance IT operations by 1) using analytics and machine learning to analyze big data collected from various IT operations tools and devices, in order to 2) automatically spot and react to issues in real time.

簡(jiǎn)單來說，就是引入多層平臺(tái)，使用大數(shù)據(jù)分析和機(jī)器學(xué)習(xí)等方法，加強(qiáng)IT運(yùn)維自動(dòng)化的能力。

上圖底部三張小圖分別表示2016、2017、2018年的AIOps架構(gòu)演進(jìn)，都是圍繞Machine Learning和Big Data來建設(shè)的。

2.2 技術(shù)、場(chǎng)景與算法

AIOps涉及的技術(shù)、場(chǎng)景和算法如圖所示。

1）技術(shù)層面

• 大數(shù)據(jù)分析：主要關(guān)注點(diǎn)在分析的部分，包括基于海量數(shù)據(jù)的分析。 

• 機(jī)器學(xué)習(xí)：數(shù)據(jù)量太大，人工的簡(jiǎn)單分析遠(yuǎn)遠(yuǎn)不夠，需要它自己產(chǎn)生智能，這是機(jī)器學(xué)習(xí)的價(jià)值。 

• 知識(shí)圖譜：日常運(yùn)維會(huì)產(chǎn)生各種經(jīng)驗(yàn)數(shù)據(jù)，這些數(shù)據(jù)如何反過來對(duì)運(yùn)維工作產(chǎn)生真正的價(jià)值，這就涉及到知識(shí)圖譜。 

• 自然語言處理：自然語言處理是ChatOps能引入到AIOps這個(gè)領(lǐng)域的原因，我們希望能夠找到一個(gè)相對(duì)簡(jiǎn)單且容易接受的交互界面，最好的就是聊天平臺(tái)Chat，這就需要使用自然語言處理的方式，理解人的語言并反饋給人，并理解相關(guān)的執(zhí)行動(dòng)作。

2）涉及場(chǎng)景

• 單指標(biāo)異常檢測(cè)：比如想要知道一個(gè)實(shí)時(shí)數(shù)據(jù)的指標(biāo)是否出現(xiàn)異常，我們可以對(duì)它進(jìn)行檢測(cè)，如有異常就反饋出來。 

• 多維指標(biāo)異常檢測(cè)：指標(biāo)和指標(biāo)之前是有關(guān)系的，通過比如聚類的一些操作能夠檢查出更多異常。 

• 趨勢(shì)預(yù)測(cè)：主要體現(xiàn)在成本部分，能夠通過人工智能的方式預(yù)測(cè)出未來的增長(zhǎng)和變化，更好地指導(dǎo)決策。 

• 日志異常檢測(cè)：檢測(cè)日志是否出現(xiàn)異常。 

• 根因分析：出現(xiàn)故障時(shí)，能夠從時(shí)間維度和空間維度找到導(dǎo)致故障出現(xiàn)的原因。 

• 智能問答：以前每次變更操作都需要向運(yùn)維提出要求，現(xiàn)在這些職能全部被承接下來變成一個(gè)智能平臺(tái)，日常運(yùn)維的工作可以通過智能平臺(tái)或機(jī)器人直接完成。 

• 智能執(zhí)行：這是我們期待的最好的方式，通過聊天窗口能夠?qū)崟r(shí)感知線上業(yè)務(wù)發(fā)生的變化，需求提交給平臺(tái)后平臺(tái)會(huì)自動(dòng)執(zhí)行。

3）算法層面

• 規(guī)則 

• 統(tǒng)計(jì) 

• 機(jī)器學(xué)習(xí) 

1.  變分自編碼器、GBRT、EMA、極限理論 
2.  Pearson 相關(guān)系數(shù)、DBScan 算法 
3.  FP-Tree 
4.  Path Ranking

2.3 AIOps平臺(tái)架構(gòu)

上圖所示是一個(gè)比較典型的AIOps平臺(tái)架構(gòu)。

底層是所有數(shù)據(jù)的來源，我們把大量數(shù)據(jù)收集起來，通過實(shí)時(shí)分析交付到算法平臺(tái)。算法平臺(tái)包括三部分，首先是基于規(guī)則和模式進(jìn)行簡(jiǎn)單的分類，然后通過域算法，最后通過機(jī)器學(xué)習(xí)和AI的方式影響Operation，讓自動(dòng)化運(yùn)行起來。

如果大家了解AI，就會(huì)發(fā)現(xiàn)這其實(shí)就是一個(gè)AI智能體，包括從Sensing到Thinking到Acting，即感知到思考到執(zhí)行的過程。

三、宜信智能運(yùn)維實(shí)踐

3.1 宜信IT運(yùn)營(yíng)架構(gòu)

宜信正在落地“中臺(tái)化戰(zhàn)略”，將可復(fù)用的技術(shù)集中到技術(shù)中臺(tái)、數(shù)據(jù)/智能中臺(tái)、運(yùn)維中臺(tái)，統(tǒng)一提供服務(wù)，節(jié)約了人力和資源，提高需求響應(yīng)速度。

宜信的IT運(yùn)營(yíng)架構(gòu)分為四部分：

• 居于中心的是技術(shù)中臺(tái)，真正承載業(yè)務(wù)。技術(shù)中臺(tái)沿用了云平臺(tái)的概念，從底層的物理環(huán)境開始，包括IaaS、PaaS、saas，這里的saas實(shí)際上是一種中臺(tái)的概念，將通用性的系統(tǒng)軟件沉淀到中臺(tái)上，統(tǒng)一為業(yè)務(wù)系統(tǒng)提供服務(wù)。 

• 數(shù)據(jù)/智能中臺(tái)，為其他業(yè)務(wù)和平臺(tái)提供統(tǒng)一的可復(fù)用的數(shù)據(jù)和智能服務(wù)。 

• 運(yùn)維中臺(tái)，積極響應(yīng)研發(fā)、業(yè)務(wù)發(fā)起的請(qǐng)求，維護(hù)線上業(yè)務(wù)系統(tǒng)。運(yùn)維方面采用傳統(tǒng)運(yùn)營(yíng)的方式和互聯(lián)網(wǎng)快速迭代共同交互的方式，在監(jiān)控、信息、自動(dòng)化等垂直領(lǐng)域建立所有套件。

運(yùn)維如何使用數(shù)據(jù)/智能中臺(tái)的數(shù)據(jù)和應(yīng)用呢？我們建立一個(gè)通用的管道，把運(yùn)維產(chǎn)生的有價(jià)值的數(shù)據(jù)傳輸?shù)綌?shù)據(jù)/智能中臺(tái)，數(shù)據(jù)/智能中臺(tái)通過對(duì)這些數(shù)據(jù)進(jìn)行分析，并基于運(yùn)維需要的場(chǎng)景反饋智能應(yīng)用。

3.2 運(yùn)維管理

上圖所示是運(yùn)維管理架構(gòu)。

從左到右是從運(yùn)營(yíng)到運(yùn)維，也可以說是從運(yùn)營(yíng)到DevOps，左邊更偏向于ITSM的概念，右邊更偏向于DevOps的概念。從上到下是從入口到執(zhí)行。大家可能更熟悉DevOps，以這部分為例介紹上圖所示架構(gòu)。

我們的建設(shè)方式是從自服務(wù)入口，它被對(duì)接到持續(xù)集成和持續(xù)發(fā)布平臺(tái)，持續(xù)集成和持續(xù)發(fā)布平臺(tái)會(huì)利用所有的自動(dòng)化建設(shè)，包括主機(jī)、域名、數(shù)據(jù)庫(kù)、負(fù)載均衡及其他組件，實(shí)現(xiàn)自動(dòng)化，最終我們會(huì)把線上的系統(tǒng)數(shù)據(jù)收集起來，包括指標(biāo)、跟蹤、日志等，這就是監(jiān)控的部分。

上述DevOps部分的運(yùn)維管理架構(gòu)對(duì)于交付2C產(chǎn)品是非常適合的，但對(duì)于像宜信這樣，有大量系統(tǒng)是面向內(nèi)部人員的，要求能夠快速響應(yīng)用戶的問題，并且能快速沉淀更有價(jià)值的運(yùn)維請(qǐng)求和數(shù)據(jù)，單一的運(yùn)維管理架構(gòu)不足以滿足上述要求。

因此我們也會(huì)建設(shè)ITSM部分，即偏運(yùn)營(yíng)、偏管理、偏審核的部分。ITSM部分以服務(wù)臺(tái)為入口，涉及的內(nèi)部管理包括請(qǐng)求管理、事件管理、問題管理、變更管理、需求管理和編排管理等，涉及的信息管理包括資產(chǎn)管理和CMDB。 

下面我們通過一個(gè)實(shí)例來看ITSM的價(jià)值點(diǎn)。

系統(tǒng)出現(xiàn)一個(gè)故障：業(yè)務(wù)人員在提交一個(gè)用戶的手機(jī)號(hào)時(shí)報(bào)錯(cuò)，提示系統(tǒng)出現(xiàn)故障請(qǐng)聯(lián)系開發(fā)人員。如果是在DevOps領(lǐng)域處理這個(gè)問題就很簡(jiǎn)單，把故障報(bào)給研發(fā)，研發(fā)就給解決了。但這樣處理，下次可能還會(huì)出現(xiàn)同樣的問題。

如果將故障放到ITSM部分進(jìn)行分析，就能讓問題得到更根本的解決。發(fā)現(xiàn)故障后，通過請(qǐng)求管理把這件事告訴后臺(tái)人員，后臺(tái)人員看到請(qǐng)求后將故障升級(jí)為“事件”并提交給研發(fā)人員，研發(fā)人員分析得知引發(fā)故障的原因是手機(jī)號(hào)觸發(fā)了風(fēng)險(xiǎn)控制平臺(tái)，而風(fēng)險(xiǎn)控制平臺(tái)由于剛剛上線所以狀態(tài)碼的解釋并不充分，研發(fā)人員將平臺(tái)關(guān)閉，故障處理完成，同時(shí)將該“事件”升級(jí)成“問題”。研發(fā)和產(chǎn)品人員對(duì)該問題分析后認(rèn)為需要變更相關(guān)服務(wù)，提供更細(xì)的狀態(tài)碼和更清晰的錯(cuò)誤提示，于是將“問題”提交成“需求”。最終“需求”完成，“問題”解決，之后類似的情況也不會(huì)再發(fā)生。

3.3 采集和處理

前文提到運(yùn)維中臺(tái)和數(shù)據(jù)/智能中臺(tái)之間有一個(gè)通用管道，運(yùn)維中臺(tái)負(fù)責(zé)采集所有數(shù)據(jù)，進(jìn)行簡(jiǎn)單加工，并傳輸給數(shù)據(jù)/智能中臺(tái)，智能中臺(tái)分析處理數(shù)據(jù)并反饋數(shù)據(jù)及智能應(yīng)用給運(yùn)維中臺(tái)。

上圖所示為數(shù)據(jù)采集和處理的架構(gòu)。

采集的數(shù)據(jù)形式包括動(dòng)態(tài)和靜態(tài)兩種：動(dòng)態(tài)數(shù)據(jù)包括業(yè)務(wù)、應(yīng)用、鏈路、技術(shù)設(shè)施、全網(wǎng)、日志數(shù)據(jù)等；靜態(tài)數(shù)據(jù)包括配置、拓?fù)?、工單?shù)據(jù)等。

我們通過自有系統(tǒng)將所有數(shù)據(jù)收集起來，通過統(tǒng)一管道（統(tǒng)一管道包括kafka、宜信開源的DBus，DBus會(huì)對(duì)結(jié)構(gòu)化的數(shù)據(jù)進(jìn)行配置或預(yù)處理。）傳送到實(shí)時(shí)分析平臺(tái)，對(duì)數(shù)據(jù)進(jìn)行后期加工，包括相關(guān)運(yùn)算，最終數(shù)據(jù)會(huì)分類存儲(chǔ)到數(shù)據(jù)中臺(tái)的數(shù)據(jù)庫(kù)中，比如關(guān)系、指標(biāo)、文檔/日志型數(shù)據(jù)會(huì)存儲(chǔ)在ElasticSearch中、結(jié)構(gòu)化數(shù)據(jù)會(huì)存儲(chǔ)在Hive中，其他歷史數(shù)據(jù)會(huì)存儲(chǔ)在HDFS中。

3.4 智能場(chǎng)景

運(yùn)維中的智能場(chǎng)景如上圖所示。

智能中臺(tái)根據(jù)運(yùn)維中臺(tái)提供的工單、編排規(guī)則、CMDB、畫像、Tracing、KPIs、Logs等數(shù)據(jù)，通過算法為運(yùn)維中臺(tái)建設(shè)一系列模型和應(yīng)用。

重點(diǎn)介紹一下編排規(guī)則。我們用的編排工具是StackStrom，我們把自動(dòng)化的每個(gè)動(dòng)作都抽象成一個(gè)原子（atom），比如重啟服務(wù)、重啟機(jī)器、修改配置，這些atom通過StackStrom建立成一個(gè)個(gè)的工作流，這些工作流是我們有經(jīng)驗(yàn)的運(yùn)維專家建立的一個(gè)更高級(jí)抽象、更語義化的模型。比如我想發(fā)布一個(gè)系統(tǒng)，包括擴(kuò)容機(jī)器、無縫切換、涉及前端負(fù)載均衡的調(diào)整、后端應(yīng)用的調(diào)整，這些都會(huì)是編排規(guī)則。

智能平臺(tái)通過算法，包括NLP分析、根因分析、趨勢(shì)預(yù)測(cè)、異常檢測(cè)等，產(chǎn)生兩個(gè)模型：知識(shí)圖譜和搜索引擎。這兩個(gè)模型應(yīng)用于運(yùn)維中臺(tái)的問答后臺(tái)、編排管理和監(jiān)控系統(tǒng)中。

1）智能問答/執(zhí)行

如圖所示是智能問答/執(zhí)行的案例，用戶通過服務(wù)臺(tái)的會(huì)話窗口提出問題，這些問題以請(qǐng)求的方式發(fā)送到問答后臺(tái)，后臺(tái)利用搜索引擎和知識(shí)圖譜的數(shù)據(jù)自動(dòng)化反饋信息，包括問答、動(dòng)作執(zhí)行等。

2）故障檢測(cè)

目前的AIOps研究最多的是KPIs，將日志等各種數(shù)據(jù)，通過根因分析、趨勢(shì)預(yù)測(cè)、異常檢測(cè)等算法，生成對(duì)應(yīng)的算法/模型，將這些算法/模型應(yīng)用到監(jiān)控系統(tǒng)中，就是監(jiān)控報(bào)警部分。監(jiān)控報(bào)警結(jié)果會(huì)展示到展板上，通知用戶。

四、如何實(shí)現(xiàn)主動(dòng)感知

4.1 痛點(diǎn)

我們的業(yè)務(wù)運(yùn)行在IT環(huán)境中，這個(gè)IT環(huán)境就是承載業(yè)務(wù)的IT，包括數(shù)據(jù)中心、服務(wù)器、各種系統(tǒng)、三方應(yīng)用、網(wǎng)絡(luò)用戶的設(shè)備等。而隨著云平臺(tái)的建設(shè)和微服務(wù)的發(fā)展，很多部分運(yùn)維人員觀察不到，再加上出于投入產(chǎn)出比的考慮，一些部分我們不會(huì)去觀察，因此，實(shí)際上運(yùn)維人員能夠觀察到的IT遠(yuǎn)遠(yuǎn)小于真正承載業(yè)務(wù)的IT。

在運(yùn)維可觀察的IT環(huán)境中，真實(shí)觀察到的IT數(shù)據(jù)往往僅包括交換機(jī)的流量包、進(jìn)程的運(yùn)行狀態(tài)、網(wǎng)卡流量、CPU使用率、請(qǐng)求數(shù)等數(shù)據(jù)。如果要建設(shè)AIOps，數(shù)據(jù)的完整是非常重要的，觀察的IT環(huán)境越多，獲取的數(shù)據(jù)越完整，越有利于AIOps的建設(shè)，這時(shí)就需要用到主動(dòng)感知。

4.2 主動(dòng)感知定義

Wikipedia對(duì)主動(dòng)感知的定義如下：

Active Perception is where an agents' behaviors are selected in order to increase the information content derived from the flow of sensor data obtained by those behaviors in the environment in question. ——Wikipedia

通俗來說，主動(dòng)感知其實(shí)是賦予每個(gè)參與者一個(gè)身份，這個(gè)參與者會(huì)主動(dòng)獲取環(huán)境中的數(shù)據(jù)，同時(shí)會(huì)根據(jù)從環(huán)境中獲取的數(shù)據(jù)主動(dòng)進(jìn)行進(jìn)一步的發(fā)現(xiàn)并獲取新的數(shù)據(jù)，目的是增加獲得數(shù)據(jù)的信息量、信息價(jià)值。

上圖展示了一個(gè)比較典型的主動(dòng)感知流程，重點(diǎn)來看感知部分。感知器從環(huán)境中通過情景感知、情景理解和預(yù)見的方式去感知環(huán)境，產(chǎn)生一個(gè)決策，決策產(chǎn)生一個(gè)動(dòng)作，動(dòng)作反饋到感知。

4.3 主動(dòng)感知領(lǐng)域

• 主動(dòng)感知在人工智能領(lǐng)域并不是一個(gè)陌生的名詞，它已經(jīng)有大量的應(yīng)用，包括：

• 機(jī)器人，機(jī)器人怎么觀察環(huán)境、怎么查看邊緣信息、怎么識(shí)別物體。 

• 自動(dòng)駕駛，如果將現(xiàn)實(shí)中獲取的所有圖像數(shù)據(jù)都交給一個(gè)中心去處理，這個(gè)信息量和計(jì)算量是非常大的，目前的芯片還不能滿足這樣的體量處理。我們的方式是在探知環(huán)境數(shù)據(jù)的時(shí)候感知變化，獲取變化數(shù)據(jù)。 

• 智能手機(jī)，主要體現(xiàn)在手機(jī)的GPS、攝像頭，可以感知環(huán)境變化。直接作用并影響到人。 

• 路網(wǎng)監(jiān)控，路網(wǎng)識(shí)別，包括主動(dòng)感知車速變化，判斷行駛的車輛是否超速。

4.4 分布式主動(dòng)感知

AIOps引入分布式主動(dòng)感知：

通過對(duì)真實(shí) IT 環(huán)境的參與者建立模型，有目的的獲取相關(guān) IT 數(shù)據(jù)，并基于獲取到的數(shù)據(jù)持續(xù)優(yōu)化獲取的數(shù)據(jù)和方法，以實(shí)現(xiàn)對(duì)真實(shí) IT 實(shí)時(shí)完整的監(jiān)控。

傳統(tǒng)的監(jiān)控方式是被動(dòng)的，通過被動(dòng)采集是不可能采集到所有數(shù)據(jù)的，無法保證數(shù)據(jù)的真實(shí)完整。如果能夠?qū)λ械腎T參與者進(jìn)行建模，通過模型去感知真正參與者的身份什么樣的、有哪些數(shù)據(jù)，就可以采集到更加實(shí)時(shí)和完整的數(shù)據(jù)。

1）主動(dòng)感知建模

主動(dòng)感知的建模涉及到本地建模和全局建模。本地建模只需要關(guān)注IT參與者是什么，比如一個(gè)職場(chǎng)、一個(gè)主機(jī)；全局建模需要考慮全國(guó)有多少個(gè)職場(chǎng)、都分布在哪里、如何將它們聯(lián)動(dòng)起來。

2）主動(dòng)感知的動(dòng)作

主動(dòng)感知的動(dòng)作包括兩個(gè)方面：有主動(dòng)篩選的被動(dòng)感知和有主動(dòng)行為的主動(dòng)感知。

• 有主動(dòng)篩選的被動(dòng)感知，比如網(wǎng)卡流量數(shù)據(jù)都是實(shí)時(shí)監(jiān)控的，但我并不會(huì)把所有數(shù)據(jù)都收集起來，只有在數(shù)據(jù)陡增或出現(xiàn)異常時(shí)才會(huì)收集，這就是主動(dòng)篩選。 

• 有主動(dòng)行為的主動(dòng)感知，在真正獲取環(huán)境數(shù)據(jù)時(shí)，只是粗略獲得一些內(nèi)網(wǎng)中機(jī)器的端口，如果發(fā)現(xiàn)有端口是危險(xiǎn)的，就會(huì)對(duì)這些端口進(jìn)行細(xì)致的探測(cè)，包括發(fā)一些協(xié)議請(qǐng)求去模擬這些行為，這就是有主動(dòng)行為的主動(dòng)感知。

3）主動(dòng)感知的方法

主動(dòng)感知的方法有兩種：基于規(guī)則和基于智能算法（比如貝葉斯決策樹）?；谝?guī)則的方法是目前使用最多的。

4）主動(dòng)感知的數(shù)據(jù)類型

主動(dòng)感知的數(shù)據(jù)類型包括畫像數(shù)據(jù)、參與者與參與者之間的關(guān)聯(lián)關(guān)系、主動(dòng)篩選和主動(dòng)行為的細(xì)節(jié)捕捉、定位跟蹤等。

5）主動(dòng)感知系統(tǒng)

主動(dòng)感知系統(tǒng)包括全網(wǎng)Agent、業(yè)務(wù)Agent、網(wǎng)絡(luò)Agent、應(yīng)用Agent，這些都是我們的感知器。

4.5 全網(wǎng)感知模型

用一個(gè)例子來細(xì)化什么是分布式主動(dòng)感知。

全網(wǎng)感知的背景：宜信在全國(guó)各地有很多職場(chǎng)，這些職場(chǎng)都是重要的參與者，每個(gè)職場(chǎng)里有很多業(yè)務(wù)人員在使用業(yè)務(wù)系統(tǒng)，需要對(duì)這些職場(chǎng)進(jìn)行監(jiān)控。

我們用分布式主動(dòng)感知的方法，首先建立模型，即職場(chǎng)網(wǎng)絡(luò)。在職場(chǎng)放一個(gè)Agent，因?yàn)槁殘?chǎng)分布在全國(guó)各地，本身是全網(wǎng)的，因此稱之為全網(wǎng)Agent。感知的內(nèi)容包括出口有哪些；網(wǎng)絡(luò)、身份識(shí)別；這個(gè)網(wǎng)絡(luò)有多大；邊緣探測(cè)；還包括內(nèi)部一系列的統(tǒng)計(jì)數(shù)據(jù)，同時(shí)還會(huì)做內(nèi)部?jī)?nèi)網(wǎng)的風(fēng)險(xiǎn)監(jiān)測(cè)，甚至?xí)ㄟ^模擬數(shù)據(jù)、誘導(dǎo)攻擊來發(fā)現(xiàn)內(nèi)網(wǎng)是否存在安全隱患。

4.6 全網(wǎng)感知應(yīng)用

• 全網(wǎng)Agent獲取當(dāng)?shù)芈殘?chǎng)信息，包括出口、網(wǎng)段、地理位置和運(yùn)營(yíng)商信息，并反饋到拓?fù)浜蛨D譜中，同時(shí)ITSM會(huì)管理所有的組織和職場(chǎng)信息，這些職場(chǎng)身份信息和主動(dòng)感知的Agent反饋的信息結(jié)合，繪制出一個(gè)準(zhǔn)確而詳細(xì)的拓?fù)?圖譜。 

• 全網(wǎng)Agent從網(wǎng)絡(luò)中獲取并反饋所有職場(chǎng)設(shè)備及其分布情況。 

• 全網(wǎng)Agent會(huì)嗅探風(fēng)險(xiǎn)端口、掃描攻擊，并反饋風(fēng)險(xiǎn)的細(xì)節(jié)掃描數(shù)據(jù)。 

• 全網(wǎng)Agent會(huì)將網(wǎng)絡(luò)統(tǒng)計(jì)數(shù)據(jù)反饋到系統(tǒng)中，幫助完善拓?fù)浜捅O(jiān)控。 

• 我們可以通過網(wǎng)格數(shù)據(jù)加上職場(chǎng)身份給不同 Agent加上不同的監(jiān)測(cè)模擬配置，由Agent發(fā)起模擬監(jiān)測(cè)的數(shù)據(jù)。當(dāng)發(fā)現(xiàn)異常時(shí)，可以從全網(wǎng)獲取更詳細(xì)的拓?fù)渚W(wǎng)絡(luò)監(jiān)測(cè)和密集系統(tǒng)檢測(cè)數(shù)據(jù)。

上圖展示的是我們?nèi)W(wǎng)感知的一些示例，包括職場(chǎng)信息、組織信息、模擬監(jiān)控?cái)?shù)據(jù)、動(dòng)態(tài)監(jiān)測(cè)配置，不展開細(xì)述。

4.7 網(wǎng)絡(luò)感知模型

上圖展示的是網(wǎng)絡(luò)感知模型，我們首先進(jìn)行建模，建模的點(diǎn)，也就是網(wǎng)絡(luò)的參與者，即每個(gè)交換機(jī)，并實(shí)時(shí)監(jiān)測(cè)和掃描網(wǎng)絡(luò)內(nèi)部所有服務(wù)器。通過這個(gè)模型可以直觀且實(shí)時(shí)看到異常細(xì)節(jié)數(shù)據(jù)，保證網(wǎng)絡(luò)質(zhì)量。

上圖展示了網(wǎng)絡(luò)感知的示例。

4.8 主機(jī)/應(yīng)用/業(yè)務(wù)感知

除了上述應(yīng)用以外，還有主機(jī)/應(yīng)用/業(yè)務(wù)感知等等。

• 主機(jī)感知。出現(xiàn)異常時(shí)，異常時(shí)感知反饋進(jìn)程、IO、網(wǎng)絡(luò) Dump 細(xì)節(jié)信息。 

• 應(yīng)用感知，根據(jù)運(yùn)行狀態(tài)動(dòng)態(tài)調(diào)整采集密度和方法。 

• 應(yīng)用感知，包括主動(dòng)業(yè)務(wù)異常捕捉和上報(bào)。

4.9 收益

分布式主動(dòng)感知的收益包括：

• 更豐富的畫像和拓?fù)?nbsp;

• 更有價(jià)值的監(jiān)控?cái)?shù)據(jù) 

• 知識(shí)圖譜 

• 根因分析 

• 異常檢測(cè)

4.10 問題與前景

分布式主動(dòng)感知在智能運(yùn)維中的實(shí)踐
網(wǎng)站URL：http://www.rwnh.cn/news34/98984.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供響應(yīng)式網(wǎng)站、網(wǎng)站設(shè)計(jì)、移動(dòng)網(wǎng)站建設(shè)、全網(wǎng)營(yíng)銷推廣、電子商務(wù)、云服務(wù)器

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)