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

一、運維的發展

1.1 運維的價值

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

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

1）效率

大量業務上線，運維人員需要保障快速高效地為系統提供資源、應對業務變更、響應操作請求。

2）質量

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

• 故障預測：沒出現問題之前預測到故障發生的可能。 

• 異常檢測：出現問題時很快檢測并定位到異常點。 

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

• 動態擴容：問題處理的過程中可能受到復雜因素的影響，需要對系統進行動態擴容。 

• 服務降級：不影響核心業務的邊緣業務可能需要做服務降級處理。

3）成本

隨著公司規模的不斷壯大，投入產出比也越來越被重視。運維的另外一個價值在于降低成本。主要體現為：

• 容量規劃：規劃每年在IT運維層面投入多少人員和資源。 

• 彈性調度：如何調度和分配資源，實現資源的充分利用。 

• 利用率分析：利用率分析包括動態和靜態兩個方面。 

• 趨勢分析：比如今年花了多少錢在IT運維層面，明年要花多少錢在這個方面，這是一個趨勢分析。 

• 成本分析：成本分析包括今年有多少業務、每個業務用了多少錢、多少IT技術設施、多少人員。

1.2 運維的困境

如圖所示，橫坐標代表服務規模。公司業務不斷增長，服務規模也相應增長，此處我們簡單理解為這是一個線性的變化，不考慮業務的暴增。

然而，業務規模增長反映到運維的復雜度增長上最少體現在三個層面：

• 服務規模的增長直接導致服務器量及網絡量的增長，隨之而來的是網絡拓撲的增長。 

• 業務增長，服務的技術棧也是增長的。以前可能前邊跑一個服務，后邊跑一個數據庫就可以了，現在隨著服務規模的不斷增長，引入不同服務形式，可能就有了隊列、緩存等，相應的，技術棧也不斷增加。 

• 服務拓撲不斷增長。以前可能一個煙囪型的服務就可以了，而現在隨著微服務的應用，服務之間的調度非常多，需要增長服務拓撲來滿足需求。

隨著服務規模的增長，運維復雜度呈現指數級增長，那運維人員是否也隨著增長了呢？縱觀各司，答案是否定的。出于節約成本的考慮，各司各崗位人員并不會隨著服務復雜度增加而擴張，反而是越來越趨于平穩。基于這個比例，相當于運維復雜度越來越高的情況下，運維人員越來越少了。

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

1.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.1 什么是智能運維（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.

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

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

2.2 技術、場景與算法

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

1）技術層面

• 大數據分析：主要關注點在分析的部分，包括基于海量數據的分析。 

• 機器學習：數據量太大，人工的簡單分析遠遠不夠，需要它自己產生智能，這是機器學習的價值。 

• 知識圖譜：日常運維會產生各種經驗數據，這些數據如何反過來對運維工作產生真正的價值，這就涉及到知識圖譜。 

• 自然語言處理：自然語言處理是ChatOps能引入到AIOps這個領域的原因，我們希望能夠找到一個相對簡單且容易接受的交互界面，最好的就是聊天平臺Chat，這就需要使用自然語言處理的方式，理解人的語言并反饋給人，并理解相關的執行動作。

2）涉及場景

• 單指標異常檢測：比如想要知道一個實時數據的指標是否出現異常，我們可以對它進行檢測，如有異常就反饋出來。 

• 多維指標異常檢測：指標和指標之前是有關系的，通過比如聚類的一些操作能夠檢查出更多異常。 

• 趨勢預測：主要體現在成本部分，能夠通過人工智能的方式預測出未來的增長和變化，更好地指導決策。 

• 日志異常檢測：檢測日志是否出現異常。 

• 根因分析：出現故障時，能夠從時間維度和空間維度找到導致故障出現的原因。 

• 智能問答：以前每次變更操作都需要向運維提出要求，現在這些職能全部被承接下來變成一個智能平臺，日常運維的工作可以通過智能平臺或機器人直接完成。 

• 智能執行：這是我們期待的最好的方式，通過聊天窗口能夠實時感知線上業務發生的變化，需求提交給平臺后平臺會自動執行。

3）算法層面

• 規則 

• 統計 

• 機器學習 

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

2.3 AIOps平臺架構

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

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

如果大家了解AI，就會發現這其實就是一個AI智能體，包括從Sensing到Thinking到Acting，即感知到思考到執行的過程。

三、宜信智能運維實踐

3.1 宜信IT運營架構

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

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

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

• 數據/智能中臺，為其他業務和平臺提供統一的可復用的數據和智能服務。 

• 運維中臺，積極響應研發、業務發起的請求，維護線上業務系統。運維方面采用傳統運營的方式和互聯網快速迭代共同交互的方式，在監控、信息、自動化等垂直領域建立所有套件。

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

3.2 運維管理

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

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

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

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

因此我們也會建設ITSM部分，即偏運營、偏管理、偏審核的部分。ITSM部分以服務臺為入口，涉及的內部管理包括請求管理、事件管理、問題管理、變更管理、需求管理和編排管理等，涉及的信息管理包括資產管理和CMDB。 

下面我們通過一個實例來看ITSM的價值點。

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

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

3.3 采集和處理

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

上圖所示為數據采集和處理的架構。

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

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

3.4 智能場景

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

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

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

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

1）智能問答/執行

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

2）故障檢測

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

四、如何實現主動感知

4.1 痛點

我們的業務運行在IT環境中，這個IT環境就是承載業務的IT，包括數據中心、服務器、各種系統、三方應用、網絡用戶的設備等。而隨著云平臺的建設和微服務的發展，很多部分運維人員觀察不到，再加上出于投入產出比的考慮，一些部分我們不會去觀察，因此，實際上運維人員能夠觀察到的IT遠遠小于真正承載業務的IT。

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

4.2 主動感知定義

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 主動感知領域

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

• 機器人，機器人怎么觀察環境、怎么查看邊緣信息、怎么識別物體。 

• 自動駕駛，如果將現實中獲取的所有圖像數據都交給一個中心去處理，這個信息量和計算量是非常大的，目前的芯片還不能滿足這樣的體量處理。我們的方式是在探知環境數據的時候感知變化，獲取變化數據。 

• 智能手機，主要體現在手機的GPS、攝像頭，可以感知環境變化。直接作用并影響到人。 

• 路網監控，路網識別，包括主動感知車速變化，判斷行駛的車輛是否超速。

4.4 分布式主動感知

AIOps引入分布式主動感知：

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

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

1）主動感知建模

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

2）主動感知的動作

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

• 有主動篩選的被動感知，比如網卡流量數據都是實時監控的，但我并不會把所有數據都收集起來，只有在數據陡增或出現異常時才會收集，這就是主動篩選。 

• 有主動行為的主動感知，在真正獲取環境數據時，只是粗略獲得一些內網中機器的端口，如果發現有端口是危險的，就會對這些端口進行細致的探測，包括發一些協議請求去模擬這些行為，這就是有主動行為的主動感知。

3）主動感知的方法

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

4）主動感知的數據類型

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

5）主動感知系統

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

4.5 全網感知模型

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

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

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

4.6 全網感知應用

• 全網Agent獲取當地職場信息，包括出口、網段、地理位置和運營商信息，并反饋到拓撲和圖譜中，同時ITSM會管理所有的組織和職場信息，這些職場身份信息和主動感知的Agent反饋的信息結合，繪制出一個準確而詳細的拓撲/圖譜。 

• 全網Agent從網絡中獲取并反饋所有職場設備及其分布情況。 

• 全網Agent會嗅探風險端口、掃描攻擊，并反饋風險的細節掃描數據。 

• 全網Agent會將網絡統計數據反饋到系統中，幫助完善拓撲和監控。 

• 我們可以通過網格數據加上職場身份給不同 Agent加上不同的監測模擬配置，由Agent發起模擬監測的數據。當發現異常時，可以從全網獲取更詳細的拓撲網絡監測和密集系統檢測數據。

上圖展示的是我們全網感知的一些示例，包括職場信息、組織信息、模擬監控數據、動態監測配置，不展開細述。

4.7 網絡感知模型

上圖展示的是網絡感知模型，我們首先進行建模，建模的點，也就是網絡的參與者，即每個交換機，并實時監測和掃描網絡內部所有服務器。通過這個模型可以直觀且實時看到異常細節數據，保證網絡質量。

上圖展示了網絡感知的示例。

4.8 主機/應用/業務感知

除了上述應用以外，還有主機/應用/業務感知等等。

• 主機感知。出現異常時，異常時感知反饋進程、IO、網絡 Dump 細節信息。 

• 應用感知，根據運行狀態動態調整采集密度和方法。 

• 應用感知，包括主動業務異常捕捉和上報。

4.9 收益

分布式主動感知的收益包括：

• 更豐富的畫像和拓撲 

• 更有價值的監控數據 

• 知識圖譜 

• 根因分析 

• 異常檢測

4.10 問題與前景

分布式主動感知在智能運維中的實踐
網站URL：http://m.newbst.com/news34/98984.html

成都網站建設公司_創新互聯，為您提供響應式網站、網站設計、移動網站建設、全網營銷推廣、電子商務、云服務器

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯