分佈式主動感知在智能運維中的實踐 | 分享實錄

時間 2019-11-24

原文原文鏈接

導讀：企業數字化使得運維智能化轉型成爲必然，宜信積極推進 AIOps 在科技金融企業的落地實踐。本次主題是探索 AIOps 落地的一種形式：經過行爲採集、仿真模擬、主動感知等手段，從用戶側真實系統使用體驗出發，結合全維監控數據，更加有效的實現智能異常檢測和根因分析。前端

1、運維的發展

1.1 運維的價值

早期的運維工做比較簡單，通常是先由系統集成工程師及研發工程師研發完項目後交付出來，再由負責運維工做的人員從後臺作一些操做，保證系統正常運行。react

圖1算法

隨着軟件研發行業和技術的發展，運維的工做也變得愈來愈豐富。現階段運維的工做與價值主要集中在三個方面：數據庫

1）效率

大量業務上線，運維人員須要保障快速高效地爲系統提供資源、應對業務變動、響應操做請求。後端

2）質量

運維的目標是保障質量及系統的穩定性。也就是說，要保障業務和系統7*24小時在線上穩定運行，爲用戶提供流暢溫馨的體驗。爲實現這個目標，運維的相關工做包括：緩存

故障預測：沒出現問題以前預測到故障發生的可能。
異常檢測：出現問題時很快檢測並定位到異常點。
根因分析：分析問題的誘因，找出真正致使問題的根本緣由。
動態擴容：問題處理的過程當中可能受到複雜因素的影響，須要對系統進行動態擴容。
服務降級：不影響核心業務的邊緣業務可能須要作服務降級處理。

3）成本

隨着公司規模的不斷壯大，投入產出比也愈來愈被重視。運維的另一個價值在於下降成本。主要體現爲：安全

容量規劃：規劃每一年在IT運維層面投入多少人員和資源。
彈性調度：如何調度和分配資源，實現資源的充分利用。
利用率分析：利用率分析包括動態和靜態兩個方面。
趨勢分析：好比今年花了多少錢在IT運維層面，明年要花多少錢在這個方面，這是一個趨勢分析。
成本分析：成本分析包括今年有多少業務、每一個業務用了多少錢、多少IT技術設施、多少人員。

1.2 運維的困境

圖2服務器

如圖所示，橫座標表明服務規模。公司業務不斷增加，服務規模也相應增加，此處咱們簡單理解爲這是一個線性的變化，不考慮業務的暴增。網絡

然而，業務規模增加反映到運維的複雜度增加上最少體如今三個層面：架構

服務規模的增加直接致使服務器量及網絡量的增加，隨之而來的是網絡拓撲的增加。
業務增加，服務的技術棧也是增加的。之前可能前邊跑一個服務，後邊跑一個數據庫就能夠了，如今隨着服務規模的不斷增加，引入不一樣服務形式，可能就有了隊列、緩存等，相應的，技術棧也不斷增長。
服務拓撲不斷增加。之前可能一個煙囪型的服務就能夠了，而如今隨着微服務的應用，服務之間的調度很是多，須要增加服務拓撲來知足需求。

隨着服務規模的增加，運維複雜度呈現指數級增加，那運維人員是否也隨着增加了呢？縱觀各司，答案是否認的。出於節約成本的考慮，各司各崗位人員並不會隨着服務複雜度增長而擴張，反而是愈來愈趨於平穩。基於這個比例，至關於運維複雜度愈來愈高的狀況下，運維人員愈來愈少了。

中間的差距如何來彌補呢？這就須要運用到運維手段了。即上圖所示的：運維質量=運維人員 X 運維手段。運維人員要經過各類運維手段來解決運維困境，進而推進運維的發展。

1.3 運維的發展

圖3

如圖所示，運維的發展大體分爲四個階段：

1）手工階段

手工階段比較好理解，研發人員交付一個系統，運維人員經過手工執行操做保障這個系統正常運行。此階段的運維工做沒有什麼標準可言。

2）標準化階段

隨着企業IT系統愈來愈多地引入運維，且全部業務都變成系統形式在線上運行，運維工做的重要性愈來愈高，但同時帶來的是運維和研發、業務人員工做中的溝通壁壘。這時就衍生出了一些標準，其中最主要的是ITSM（IT Service Management，IT服務管理）。ITSM的目標是把平常全部的運維工做，包括流程、信息管理、風險控制等，經過系統建設和標準化固定下來，像流水線同樣，人員只須要按照標準參與便可。

3）自動化階段

隨着互聯網大爆發，服務交付模型愈來愈多，用戶對互聯網和IT的要求愈來愈高，ITSM的缺點也愈來愈明顯，主要表現爲時間過長、成本太高，不能適應快速多變的需求。因而從工程或運維的角度自發出現了一種文化：DevOps，DevOps強調運維、研發及QA工程師工做的高度融合，要求運維從工程交付的角度不斷迭代。

同時從企業IT管理或運營訴求出發也要解決快速演進的問題，因而演化出了標準ITOM。ITOM和ITSM很像，區別是把「S」改爲「O」，即把Operation自己及其帶來的各類自動化工具歸入模型中，包括主機、運營、發佈系統等等。

DevOps不斷髮展演變成如今的ChatOps，ChatOps的目標是將研發、運維、QA融合起來，以說話（Chat）的方式進行交流，但 ChatOps 只考慮了交流的形式，並無就如何實現基於 Chat 方式的總體解決方案，ChatOps 並無很好的解決 DevOps 的困境。
ITOM把全部的Operation線上化、自動化後，發現IT運維所產生的大量數據是很是有意義的，特別是對於企業數字化而言，這些數據通過加工分析，能夠對平常業務產生價值。因而Gartner提出了一個新的標準「ITOA」。ITOA強調IT數據的價值，提出對IT運維分析的訴求，但沒說明這個數據能幹什麼。很快Gartner就將ITOA演化成「AIOps」。這時AIOps中的「AI」是指「Algorithm（算法）」，強調的是數據分析自己產生的價值，包括經過算法來解決線上故障發現、平常交互等運維問題。

4）智能化階段

隨着行業對IT運維要求的不斷提升，不管是AIOps仍是ChatOps，都面臨一個嚴重的問題：人處理不過來了。從工程角度來看，運維面臨的現狀是異構性很是強，須要引入三方應用和各類各樣的設備，交付模式也愈來愈多，運維複雜度出現指數級增加。爲解決上述問題，Gartner適時提出了「AIOps」的概念，這裏的「AI」表明的是人工智能，經過機器人的參與將人工智能技術體系帶入到運維的各個環節，幫助解決運維問題，運維發展也由此進入智能化階段。

2、什麼是智能運維

2.1 什麼是智能運維（AIOps）？

圖4

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.

簡單來講，就是引入多層平臺，使用大數據分析和機器學習等方法，增強IT運維自動化的能力。

上圖底部三張小圖分別表示201六、201七、2018年的AIOps架構演進，都是圍繞Machine Learning和Big Data來建設的。

2.2 技術、場景與算法

圖5

AIOps涉及的技術、場景和算法如圖所示。

1）技術層面

大數據分析：主要關注點在分析的部分，包括基於海量數據的分析。
機器學習：數據量太大，人工的簡單分析遠遠不夠，須要它本身產生智能，這是機器學習的價值。
知識圖譜：平常運維會產生各類經驗數據，這些數據如何反過來對運維工做產生真正的價值，這就涉及到知識圖譜。
天然語言處理：天然語言處理是ChatOps能引入到AIOps這個領域的緣由，咱們但願可以找到一個相對簡單且容易接受的交互界面，最好的就是聊天平臺Chat，這就須要使用天然語言處理的方式，理解人的語言並反饋給人，並理解相關的執行動做。

2）涉及場景

單指標異常檢測：好比想要知道一個實時數據的指標是否出現異常，咱們能夠對它進行檢測，若有異常就反饋出來。
多維指標異常檢測：指標和指標以前是有關係的，經過好比聚類的一些操做可以檢查出更多異常。
趨勢預測：主要體如今成本部分，可以經過人工智能的方式預測出將來的增加和變化，更好地指導決策。
日誌異常檢測：檢測日誌是否出現異常。
根因分析：出現故障時，可以從時間維度和空間維度找到致使故障出現的緣由。
智能問答：之前每次變動操做都須要向運維提出要求，如今這些職能所有被承接下來變成一個智能平臺，平常運維的工做能夠經過智能平臺或機器人直接完成。
智能執行：這是咱們期待的最好的方式，經過聊天窗口可以實時感知線上業務發生的變化，需求提交給平臺後平臺會自動執行。

3）算法層面

規則
統計
機器學習
變分自編碼器、GBRT、EMA、極限理論
- Pearson 相關係數、DBScan 算法
- FP-Tree
- Path Ranking

2.3 AIOps平臺架構

圖6

上圖所示是一個比較典型的AIOps平臺架構。

底層是全部數據的來源，咱們把大量數據收集起來，經過實時分析交付到算法平臺。算法平臺包括三部分，首先是基於規則和模式進行簡單的分類，而後經過域算法，最後經過機器學習和AI的方式影響Operation，讓自動化運行起來。

若是你們瞭解AI，就會發現這其實就是一個AI智能體，包括從Sensing到Thinking到Acting，即感知到思考到執行的過程。

3、宜信智能運維實踐

3.1 宜信IT運營架構

宜信正在落地「中臺化戰略」，將可複用的技術集中到技術中臺、數據/智能中臺、運維中臺，統一提供服務，節約了人力和資源，提升需求響應速度。

圖7

宜信的IT運營架構分爲四部分：

居於中心的是技術中臺，真正承載業務。技術中臺沿用了雲平臺的概念，從底層的物理環境開始，包括IaaS、PaaS、SaaS，這裏的SaaS其實是一種中臺的概念，將通用性的系統軟件沉澱到中臺上，統一爲業務系統提供服務。
數據/智能中臺，爲其餘業務和平臺提供統一的可複用的數據和智能服務。
運維中臺，積極響應研發、業務發起的請求，維護線上業務系統。運維方面採用傳統運營的方式和互聯網快速迭代共同交互的方式，在監控、信息、自動化等垂直領域創建全部套件。

運維如何使用數據/智能中臺的數據和應用呢？咱們創建一個通用的管道，把運維產生的有價值的數據傳輸到數據/智能中臺，數據/智能中臺經過對這些數據進行分析，並基於運維須要的場景反饋智能應用。

3.2 運維管理

圖8

上圖所示是運維管理架構。

從左到右是從運營到運維，也能夠說是從運營到DevOps，左邊更偏向於ITSM的概念，右邊更偏向於DevOps的概念。從上到下是從入口到執行。你們可能更熟悉DevOps，以這部分爲例介紹上圖所示架構。

咱們的建設方式是從自服務入口，它被對接到持續集成和持續發佈平臺，持續集成和持續發佈平臺會利用全部的自動化建設，包括主機、域名、數據庫、負載均衡及其餘組件，實現自動化，最終咱們會把線上的系統數據收集起來，包括指標、跟蹤、日誌等，這就是監控的部分。

上述DevOps部分的運維管理架構對於交付2C產品是很是適合的，但對於像宜信這樣，有大量系統是面向內部人員的，要求可以快速響應用戶的問題，而且能快速沉澱更有價值的運維請求和數據，單一的運維管理架構不足以知足上述要求。

所以咱們也會建設ITSM部分，即偏運營、偏管理、偏審覈的部分。ITSM部分以服務檯爲入口，涉及的內部管理包括請求管理、事件管理、問題管理、變動管理、需求管理和編排管理等，涉及的信息管理包括資產管理和CMDB。下面咱們經過一個實例來看ITSM的價值點。

系統出現一個故障：業務人員在提交一個用戶的手機號時報錯，提示系統出現故障請聯繫開發人員。若是是在DevOps領域處理這個問題就很簡單，把故障報給研發，研發就給解決了。但這樣處理，下次可能還會出現一樣的問題。

若是將故障放到ITSM部分進行分析，就能讓問題獲得更根本的解決。發現故障後，經過請求管理把這件事告訴後臺人員，後臺人員看到請求後將故障升級爲「事件」並提交給研發人員，研發人員分析得知引起故障的緣由是手機號觸發了風險控制平臺，而風險控制平臺因爲剛剛上線因此狀態碼的解釋並不充分，研發人員將平臺關閉，故障處理完成，同時將該「事件」升級成「問題」。研發和產品人員對該問題分析後認爲須要變動相關服務，提供更細的狀態碼和更清晰的錯誤提示，因而將「問題」提交成「需求」。最終「需求」完成，「問題」解決，以後相似的狀況也不會再發生。

3.3 採集和處理

前文提到運維中臺和數據/智能中臺之間有一個通用管道，運維中臺負責採集全部數據，進行簡單加工，並傳輸給數據/智能中臺，智能中臺分析處理數據並反饋數據及智能應用給運維中臺。

圖9

上圖所示爲數據採集和處理的架構。

採集的數據形式包括動態和靜態兩種：動態數據包括業務、應用、鏈路、技術設施、全網、日誌數據等；靜態數據包括配置、拓撲、工單數據等。

咱們經過自有系統將全部數據收集起來，經過統一管道（統一管道包括kafka、宜信開源的DBus，DBus會對結構化的數據進行配置或預處理。）傳送到實時分析平臺，對數據進行後期加工，包括相關運算，最終數據會分類存儲到數據中臺的數據庫中，好比關係、指標、文檔/日誌型數據會存儲在ElasticSearch中、結構化數據會存儲在Hive中，其餘歷史數據會存儲在HDFS中。

3.4 智能場景

圖10

運維中的智能場景如上圖所示。

智能中臺根據運維中臺提供的工單、編排規則、CMDB、畫像、Tracing、KPIs、Logs等數據，經過算法爲運維中臺建設一系列模型和應用。

重點介紹一下編排規則。咱們用的編排工具是StackStrom，咱們把自動化的每一個動做都抽象成一個原子（atom），好比重啓服務、重啓機器、修改配置，這些atom經過StackStrom創建成一個個的工做流，這些工做流是咱們有經驗的運維專家創建的一個更高級抽象、更語義化的模型。好比我想發佈一個系統，包括擴容機器、無縫切換、涉及前端負載均衡的調整、後端應用的調整，這些都會是編排規則。

智能平臺經過算法，包括NLP分析、根因分析、趨勢預測、異常檢測等，產生兩個模型：知識圖譜和搜索引擎。這兩個模型應用於運維中臺的問答後臺、編排管理和監控系統中。

1）智能問答/執行

圖11

如圖所示是智能問答/執行的案例，用戶經過服務檯的會話窗口提出問題，這些問題以請求的方式發送到問答後臺，後臺利用搜索引擎和知識圖譜的數據自動化反饋信息，包括問答、動做執行等。

2）故障檢測

圖12

目前的AIOps研究最多的是KPIs，將日誌等各類數據，經過根因分析、趨勢預測、異常檢測等算法，生成對應的算法/模型，將這些算法/模型應用到監控系統中，就是監控報警部分。監控報警結果會展現到展板上，通知用戶。

4、如何實現主動感知

4.1 痛點

圖13

咱們的業務運行在IT環境中，這個IT環境就是承載業務的IT，包括數據中心、服務器、各類系統、三方應用、網絡用戶的設備等。而隨着雲平臺的建設和微服務的發展，不少部分運維人員觀察不到，再加上出於投入產出比的考慮，一些部分咱們不會去觀察，所以，實際上運維人員可以觀察到的IT遠遠小於真正承載業務的IT。

在運維可觀察的IT環境中，真實觀察到的IT數據每每僅包括交換機的流量包、進程的運行狀態、網卡流量、CPU使用率、請求數等數據。若是要建設AIOps，數據的完整是很是重要的，觀察的IT環境越多，獲取的數據越完整，越有利於AIOps的建設，這時就須要用到主動感知。

4.2 主動感知定義

圖14

Wikipedia對主動感知的定義以下：

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

通俗來講，主動感知實際上是賦予每一個參與者一個身份，這個參與者會主動獲取環境中的數據，同時會根據從環境中獲取的數據主動進行進一步的發現並獲取新的數據，目的是增長得到數據的信息量、信息價值。

上圖展現了一個比較典型的主動感知流程，重點來看感知部分。感知器從環境中經過情景感知、情景理解和預見的方式去感知環境，產生一個決策，決策產生一個動做，動做反饋到感知。

4.3 主動感知領域

圖15

主動感知在人工智能領域並非一個陌生的名詞，它已經有大量的應用，包括：

機器人，機器人怎麼觀察環境、怎麼查看邊緣信息、怎麼識別物體。
自動駕駛，若是將現實中獲取的全部圖像數據都交給一箇中心去處理，這個信息量和計算量是很是大的，目前的芯片還不能知足這樣的體量處理。咱們的方式是在探知環境數據的時候感知變化，獲取變化數據。
智能手機，主要體如今手機的GPS、攝像頭，能夠感知環境變化。直接做用並影響到人。
路網監控，路網識別，包括主動感知車速變化，判斷行駛的車輛是否超速。

4.4 分佈式主動感知

圖16

AIOps引入分佈式主動感知：

經過對真實 IT 環境的參與者創建模型，有目的的獲取相關 IT 數據，並基於獲取到的數據持續優化獲取的數據和方法，以實現對真實 IT 實時完整的監控。

傳統的監控方式是被動的，經過被動採集是不可能採集到全部數據的，沒法保證數據的真實完整。若是可以對全部的IT參與者進行建模，經過模型去感知真正參與者的身份什麼樣的、有哪些數據，就能夠採集到更加實時和完整的數據。

1）主動感知建模

主動感知的建模涉及到本地建模和全局建模。本地建模只須要關注IT參與者是什麼，好比一個職場、一個主機；全局建模須要考慮全國有多少個職場、都分佈在哪裏、如何將它們聯動起來。

2）主動感知的動做

主動感知的動做包括兩個方面：有主動篩選的被動感知和有主動行爲的主動感知。

有主動篩選的被動感知，好比網卡流量數據都是實時監控的，但我並不會把全部數據都收集起來，只有在數據陡增或出現異常時纔會收集，這就是主動篩選。
有主動行爲的主動感知，在真正獲取環境數據時，只是粗略得到一些內網中機器的端口，若是發現有端口是危險的，就會對這些端口進行細緻的探測，包括髮一些協議請求去模擬這些行爲，這就是有主動行爲的主動感知。

3）主動感知的方法

主動感知的方法有兩種：基於規則和基於智能算法（好比貝葉斯決策樹）。基於規則的方法是目前使用最多的。

4）主動感知的數據類型

主動感知的數據類型包括畫像數據、參與者與參與者之間的關聯關係、主動篩選和主動行爲的細節捕捉、定位跟蹤等。

5）主動感知系統

主動感知系統包括全網Agent、業務Agent、網絡Agent、應用Agent，這些都是咱們的感知器。

4.5 全網感知模型

圖17

用一個例子來細化什麼是分佈式主動感知。

全網感知的背景：宜信在全國各地有不少職場，這些職場都是重要的參與者，每一個職場裏有不少業務人員在使用業務系統，須要對這些職場進行監控。

咱們用分佈式主動感知的方法，首先創建模型，即職場網絡。在職場放一個Agent，由於職場分佈在全國各地，自己是全網的，所以稱之爲全網Agent。感知的內容包括出口有哪些；網絡、身份識別；這個網絡有多大；邊緣探測；還包括內部一系列的統計數據，同時還會作內部內網的風險監測，甚至會經過模擬數據、誘導攻擊來發現內網是否存在安全隱患。

4.6 全網感知應用

圖18

全網Agent獲取當地職場信息，包括出口、網段、地理位置和運營商信息，並反饋到拓撲和圖譜中，同時ITSM會管理全部的組織和職場信息，這些職場身份信息和主動感知的Agent反饋的信息結合，繪製出一個準確而詳細的拓撲/圖譜。
全網Agent從網絡中獲取並反饋全部職場設備及其分佈狀況。
全網Agent會嗅探風險端口、掃描攻擊，並反饋風險的細節掃描數據。
全網Agent會將網絡統計數據反饋到系統中，幫助完善拓撲和監控。
咱們能夠經過網格數據加上職場身份給不一樣 Agent加上不一樣的監測模擬配置，由Agent發起模擬監測的數據。當發現異常時，能夠從全網獲取更詳細的拓撲網絡監測和密集系統檢測數據。