面向業(yè)務(wù)的智能運維：中國移動智能運維系統(tǒng)探索與實踐

作者：胡建華

中國移動蘇州研發(fā)中心，IT支撐產(chǎn)品部，技術(shù)研究員

主要從事集中化系統(tǒng)架構(gòu)設(shè)計，以及數(shù)據(jù)保護(hù)（存儲、備份、云盤）、智能運維相關(guān)領(lǐng)域的技術(shù)研究和開發(fā)工作。

1、BAIOPS-業(yè)務(wù)智能運維

智能運維（AIOps-Algorithmic IT Operations基于算法的IT運維）是人工智能技術(shù)在IT運維領(lǐng)域的運用，引用Gartner 的報告的一段話“到2020年，將近50%的企業(yè)將會在他們的業(yè)務(wù)和IT運維方面采用AIOps，遠(yuǎn)遠(yuǎn)高于今天的10%”，最近2-3年智能運維的概念隨處可見，各大互聯(lián)網(wǎng)公司、傳統(tǒng)IT公司、金融業(yè)等都在談他們的智能運維設(shè)想，同時也有人談AI色變，覺得人工智能只是一個愿景，要落地很難。其實AI已經(jīng)不是一個新的概念了，百度、微軟、谷歌等公司早就在10幾年前開始自己的人工智能布局了，到現(xiàn)在均已成為人工智能行業(yè)的領(lǐng)跑者了。

話不多說，人工智能那么強大，應(yīng)用場景十分的廣泛，當(dāng)然也包括運維領(lǐng)域，而且面向業(yè)務(wù)的運維更是運維發(fā)展的熱點趨勢，下面我就和大家就“面向業(yè)務(wù)的智能運維體系建設(shè)的探索與實踐”這個話題發(fā)表下我的個人見解。

2、傳統(tǒng)運維-痛之又痛

傳統(tǒng)的運維中，存在著諸多痛點：

（1）被動低效的運維難以保證業(yè)務(wù)連續(xù)性

運維人員往往扮演著事后“救火”的角色，待事故發(fā)生后才去處理；

數(shù)據(jù)分散在多處，出了故障無法快速修復(fù)，業(yè)務(wù)連續(xù)性難以有效保障；

隨著業(yè)務(wù)復(fù)雜性不斷提高，人工運維的成本呈指數(shù)級增長。

（2）缺乏統(tǒng)一的運維監(jiān)控體系和技術(shù)工具

針對不同運維實體的煙囪式的運維工具，功能重疊、難以整合；

運維的自動化程度偏低，運維腳本泛濫，層次化、模塊化程度不足；

監(jiān)控、運維、告警平臺林立，各成體系，缺乏統(tǒng)一化體系。

（3）海量的運維數(shù)據(jù)的價值無法充分挖掘

傳統(tǒng)運維系統(tǒng)收集了大量的運維數(shù)據(jù)，但是卻缺乏有效的手段加以分析和利用；

運維數(shù)據(jù)的利用僅限于簡單的可視化和淺度的分析上，缺乏縱向數(shù)據(jù)的關(guān)聯(lián)挖掘，無法快速定位故障根因；

固定式的閾值告警造成了大量的誤判和漏判，而且人工調(diào)整閾值的方式也比較費時費力。

（4）缺乏全方位端到端的運維監(jiān)控手段

大部分的運維監(jiān)控僅停留在針對主機(jī)、網(wǎng)絡(luò)的層面，忽略了業(yè)務(wù)層面的識別手段，故障的發(fā)生無法從最直接的業(yè)務(wù)層面得以發(fā)現(xiàn)，產(chǎn)生預(yù)警；

性能管理大多停留在服務(wù)單應(yīng)用性能的管理和分析上，無法提供端到端的掌控。

3、業(yè)務(wù)智能運維的切入點

針對上述這些傳統(tǒng)運維中存在的痛點，智能化的運維出現(xiàn)必定具有劃時代的意義，智能運維系統(tǒng)的設(shè)計可以從如下幾方面進(jìn)行展開思考：

（1）面向業(yè)務(wù)維度實現(xiàn)異常檢測

業(yè)務(wù)運維是運維的大趨勢，需從最復(fù)雜的業(yè)務(wù)維度入手，根據(jù)業(yè)務(wù)維度的指標(biāo)（如PV、響應(yīng)時間、錯誤率、GC等）上的異動進(jìn)行異常檢測，提前預(yù)警；

（2）提供業(yè)務(wù)全局關(guān)系視圖

業(yè)務(wù)應(yīng)用維度的復(fù)雜性是運維過程中最高的，往往是二線和三線運維之間界限最模糊的區(qū)域，所以智能運維可以先解決的就是向用戶提供全面、清晰的業(yè)務(wù)關(guān)系視圖，讓運維人員對業(yè)務(wù)應(yīng)用的掌控得心應(yīng)手；

（3）KPI可視化與下鉆定位

KPI指標(biāo)可以通過豐富的可視化手段展示給運維人員，業(yè)務(wù)系統(tǒng)的故障可以清晰的體現(xiàn)在可視化終端，同時支持詳細(xì)的下鉆手段，直至定位到發(fā)生故障的環(huán)節(jié)，甚至代碼段；

（4）采用動態(tài)閾值思想的異常檢測

避免傳統(tǒng)固定閾值告警的弊端，引入機(jī)器學(xué)習(xí)算法來進(jìn)行閾值動態(tài)化的異常檢測效果；

（5）重視故障的全流程管理

故障發(fā)生時，可以提供一定的手段將業(yè)務(wù)層面的KPI異常與引起故障的原因聯(lián)系起來，支持手動下鉆之余還可以自動定位和關(guān)聯(lián)；

（6）立體化監(jiān)控體系的建設(shè)

覆蓋從資源、平臺層、應(yīng)用監(jiān)控和微服務(wù)調(diào)用鏈的立體化的運維分析能力。

4、業(yè)務(wù)智能運維體系架構(gòu)

4.1智能運維核心要素

智能運維體系架構(gòu)的建設(shè)應(yīng)該考慮如下因素：

數(shù)據(jù)

我們要搭建智能運維平臺，首先要數(shù)據(jù)驅(qū)動，數(shù)據(jù)驅(qū)動下要做好以下幾件事：

海量數(shù)據(jù)存儲：運維數(shù)據(jù)的量級是億級、TB甚至PB級別的，所以存儲系統(tǒng)一定要具備高容量和擴(kuò)展性；

數(shù)據(jù)多樣化：運維過程產(chǎn)生的數(shù)據(jù)多種多樣，如應(yīng)用產(chǎn)生的性能數(shù)據(jù)，服務(wù)器基礎(chǔ)監(jiān)控產(chǎn)生的CPU/IO/Net數(shù)據(jù)，服務(wù)間調(diào)用鏈數(shù)據(jù)、日志數(shù)據(jù)等，那么需要針對不同類型數(shù)據(jù)進(jìn)行區(qū)別化的存儲結(jié)構(gòu)的設(shè)計，保證數(shù)據(jù)存儲的擴(kuò)展性，同時建立數(shù)據(jù)之間的關(guān)聯(lián)支點；

分析能力

分析能力是智能運維平臺的核心，可以應(yīng)用大數(shù)據(jù)+機(jī)器學(xué)習(xí)的分析能力，結(jié)合成熟的開源分析算法實現(xiàn)基本的數(shù)據(jù)分析，再結(jié)合具體的應(yīng)用場景，做出一些適應(yīng)性改造或匹配來實現(xiàn)相對較好的分析效果，千萬不要只想著做出來一個分析平臺來，這個平臺做出來不是難事，關(guān)鍵在于這個平臺在運維領(lǐng)域沒有實際意義。

運用起歷史數(shù)據(jù)的價值，且可以有效識別出數(shù)據(jù)的各維度的規(guī)律，如周期性、趨勢等，而且分析能力必須結(jié)合應(yīng)用場景，判別相對適合的算法模型來訓(xùn)練數(shù)據(jù)，方能保證預(yù)期的設(shè)想。

分析能力可以隨著時間的推移不斷的演進(jìn)，可以將新數(shù)據(jù)的特性帶入到模型中來，以不斷提高算法的準(zhǔn)確度。

4.2智能運維體系架構(gòu)

一個通用化的業(yè)務(wù)智能運維的體系架構(gòu)一般如下設(shè)計：

在上述的架構(gòu)設(shè)計中：

（1）用戶層：

面向業(yè)務(wù)的智能運維面向的用戶，不光光是面向于傳統(tǒng)的運維人員，此外，業(yè)務(wù)監(jiān)控人員、業(yè)務(wù)部門主管、客服人員都可以在系統(tǒng)上找到自己所需要的數(shù)據(jù)、看到自己所想看到的東西；

（2）視圖層：

提供WEB端豐富的可視化視圖、大屏方式的業(yè)務(wù)狀態(tài)視圖、以及滿足移動辦公需求的手機(jī)端APP；

（3）服務(wù)層：

業(yè)務(wù)智能運維將提供給用戶業(yè)務(wù)視圖服務(wù)、拓?fù)浞��?wù)、性能KPI服務(wù)、運維分析服務(wù)、告警服務(wù)、報表服務(wù)以及系統(tǒng)服務(wù)等，為用戶提供豐富的監(jiān)控、分析和告警視圖功能。

（4）核心能力層：

智能運維系統(tǒng)的最關(guān)鍵部分，可以分為三個較大的模塊“智能監(jiān)控”、“智能分析”和“智能告警”。

智能監(jiān)控：

實現(xiàn)針對各個層面的監(jiān)控覆蓋，包括用戶體驗的監(jiān)控、應(yīng)用性能的監(jiān)控、中間件監(jiān)控、基礎(chǔ)設(shè)施的監(jiān)控，只有收集了全面的數(shù)據(jù)，才有可能從數(shù)據(jù)中尋找關(guān)聯(lián)，從關(guān)聯(lián)中發(fā)現(xiàn)規(guī)律，豐富運維知識庫。

智能分析：

智能分析為整個核心能力層中最核心的部分，該部分應(yīng)該涵蓋離線算法的訓(xùn)練模塊和在線實時分析模塊

離線算法訓(xùn)練模塊要根據(jù)歷史數(shù)據(jù)來以離線的方式訓(xùn)練和修正算法模型，然后生成的算法模型就類似于一個個的[if else]判斷形成的規(guī)則組合，當(dāng)最新的數(shù)據(jù)輸入到算法模型，就可以實時的給出推測，用于預(yù)測、異常檢測、故障定位等場景，這里面當(dāng)然就需要機(jī)器學(xué)習(xí)和深度學(xué)習(xí)的算法來撐場面了。

在線實時分析模塊要實現(xiàn)實時的算法分析，并不依賴于歷史數(shù)據(jù)所訓(xùn)練出的離線模型，而是進(jìn)行實時的計算，這里則需要大數(shù)據(jù)的實時計算技術(shù)了。

智能告警：

智能告警需要可以有效的遏制“告警風(fēng)暴”，這個可是告警系統(tǒng)中必須面對的問題，那么需要提供較高效的分析算法，實現(xiàn)告警的自動歸類、自動消除，那么歸類中最合適的方法就是尋找告警之間的關(guān)系關(guān)系，將相近的告警合并為一條發(fā)送，避免告警風(fēng)暴。

智能告警還可以動態(tài)調(diào)整告警短信/郵件發(fā)送的頻率和周期，還有告警通知對象的智能配置，保證運維人員處理告警的專注性，不會被突如其來的海量告警所淹沒。

5、業(yè)務(wù)智能運維典型應(yīng)用場景和關(guān)鍵設(shè)計

5.1數(shù)據(jù)的采集

（1）業(yè)務(wù)層數(shù)據(jù)的采集

包括接口響應(yīng)時間、調(diào)用次數(shù)、服務(wù)間調(diào)用關(guān)系、時延、慢SQL、JVM內(nèi)存消耗、以及線程棧信息，上述數(shù)據(jù)的采集可以參考Google Dappe的思想實現(xiàn)，其中一款較好的開源軟件就是pinpoint。

pinpoint運用JavaAgent字節(jié)碼增強技術(shù)實現(xiàn)應(yīng)用服務(wù)端數(shù)據(jù)的采集，且無侵入式的設(shè)計，使用方便，無需更改業(yè)務(wù)代碼�？梢詢�(nèi)置支持JAVA程序內(nèi)幾十種協(xié)議交互的兼容，如http、okhttp、mysql、oracle、postgresql、dbcp、cubrid、kafka、rabbitmq、springboot、log4j、logback、redis等。

Pinpoint的架構(gòu)原理圖如下：

采用hbase 實現(xiàn)海量數(shù)據(jù)的存儲，通過部署在業(yè)務(wù)遠(yuǎn)端的agent通過UDP+thrift的方式將應(yīng)用采集的數(shù)據(jù)傳輸?shù)絚ollector，經(jīng)過處理后實現(xiàn)hbase的落存。Web UI實現(xiàn)監(jiān)控的可視化。

上圖是通過pinpoint進(jìn)行鏈路追蹤的原理圖，可以簡單的理解為在一次交易過程中，貫穿的整個分布式系統(tǒng)的各個環(huán)節(jié)內(nèi)都維持著一個唯一的transactionid，且允許記錄上下文環(huán)節(jié)的spanid，從而實現(xiàn)鏈路信息的洞悉。

且pinpoint允許開發(fā)者自定義開發(fā)插件，實現(xiàn)更多協(xié)議的監(jiān)控支持，如activemq、zookeeper、consul等。

不過pinpoint的功能如此強大的同時，還需要我們做適當(dāng)?shù)膬?yōu)化，如：

Agent發(fā)送海量的udp數(shù)據(jù)到collector，很有可能遇到網(wǎng)絡(luò)和collector的阻塞，那么，這個時候可以在agent和collector之間加一層kafka實現(xiàn)消息的緩沖，提升系統(tǒng)穩(wěn)定性。

Pinpoint沒有用戶權(quán)限體系，需要我們自己實現(xiàn)。

可以通過參數(shù)自定義的方式來指定實際需要采集的指標(biāo)項，避免agent多余的性能損耗，降低系統(tǒng)負(fù)載。

（2）關(guān)聯(lián)數(shù)據(jù)的采集

關(guān)聯(lián)數(shù)據(jù)包括基設(shè)施數(shù)據(jù)和中間件數(shù)據(jù)。

首先，基礎(chǔ)設(shè)施數(shù)據(jù)如服務(wù)器的性能狀態(tài)的數(shù)據(jù)，包括CPU、磁盤、內(nèi)存、IO、負(fù)載等維度各個參數(shù)的獲取，您可能首先想到的是zabbix，那么zabbix確實功能強大，但是“殺雞焉用牛刀”，上述CPU/磁盤/內(nèi)存等幾個參數(shù)就是我們隨手敲行代碼就可以搞定的事，只不過做成定時任務(wù)即可，所以我們不用zabbix，轉(zhuǎn)向輕量化的開源手段，其實TICK數(shù)據(jù)采集框架您可能都聽過，那么我們模仿TICK，通過TIG（Telegraf+influxdb+grafana）框架也可以輕松搞定了。

Telegraf是一種輕量級的采集框架，支持秒級別間歇的采集粒度，對服務(wù)器的資源占用很�。ú坏�3%）；

Influxdb是一種高性能的時序數(shù)據(jù)存儲引擎，可支持百億級別的時序數(shù)據(jù)的存儲，而且內(nèi)置強大的連續(xù)計算、API功能，你可以輕松的實現(xiàn)數(shù)據(jù)的匯聚和外部調(diào)用；

Grafana是一款基于JS的前端可視化引擎，支持豐富的dashboard組件，如圖表、儀表盤、表格、清單等，你可以利用它輕松實現(xiàn)各種高大上的性能監(jiān)控頁面，另外grafana和influxdb的兼容性也異常的友好。

同樣，常見的Paas和Daas層中間件，如nginx、apache、zookeeper、docker、mesos、ZFS、Elasticsearch、mysql、mongodb、postgresql、sql server、rethinkDB、influxdb、couchDB、redis、memcache、rabbitmq等的組件的監(jiān)控也都可以通過TIG框架實現(xiàn)監(jiān)控。

至此，我們已經(jīng)可以實現(xiàn)應(yīng)用層數(shù)據(jù)和其關(guān)聯(lián)數(shù)據(jù)（Iaas層、Paas層）的集中采集和匯聚，那么有了數(shù)據(jù)，能做的事情簡直太多了。

5.2業(yè)務(wù)層面的精細(xì)劃分

欲建立面向業(yè)務(wù)服務(wù)維度的監(jiān)控體系，首先需要針對業(yè)務(wù)服務(wù)做出分層次的劃分，即對業(yè)務(wù)監(jiān)控對象的管理需要建立體系，智能運維產(chǎn)品的業(yè)務(wù)服務(wù)管理體系結(jié)構(gòu)如下：

如上圖中的②③④層，專注面向業(yè)務(wù)維度的監(jiān)控的同時，更要對業(yè)務(wù)層面進(jìn)行精細(xì)化分層，比較容易想到的辦法就是建立系統(tǒng)、服務(wù)、實例三層的業(yè)務(wù)監(jiān)控體系。

針對系統(tǒng)、服務(wù)、實例做一個概念的普及：

系統(tǒng)：完成某一類完整需求的系統(tǒng)體系，如OA系統(tǒng)，系統(tǒng)是一個比較抽象的概念，一般由一個或多個運維人員來管理

服務(wù)：系統(tǒng)的下一層模塊，即完成系統(tǒng)內(nèi)某一個完整的相對獨立功能的模塊，如個人信息管理服務(wù)、薪資管理服務(wù)、流程引擎服務(wù)等；一個服務(wù)一般部署為一個集群，包含多個應(yīng)用實例（如tomcat）

實例：屬于一個服務(wù)集群中的一個具體的應(yīng)用實例，一般一個服務(wù)集群會部署多個實例到不同主機(jī)上，如薪資管理服務(wù)實例一、薪資管理服務(wù)實例二，實現(xiàn)負(fù)載均衡。

在這三個層次上進(jìn)行性能的監(jiān)控，實現(xiàn)了業(yè)務(wù)應(yīng)用從上到下三層的數(shù)據(jù)關(guān)聯(lián)，服務(wù)運維人員可以更深入的掌控系統(tǒng)業(yè)務(wù)的關(guān)聯(lián)狀況。

那么我們是否可以針對系統(tǒng)、服務(wù)、實例分別進(jìn)行性能監(jiān)控呢？如果發(fā)生故障，就可以尋根溯源，舉例：如果一個服務(wù)層的指標(biāo)（如服務(wù)整體平均響應(yīng)時間發(fā)生偏高的異常），那么必定是由其下的一個或多個實例導(dǎo)致，現(xiàn)在我們?nèi)ゲ榭疵總�實例的性能信息，通過皮爾曼相關(guān)系數(shù)，發(fā)現(xiàn)性能曲線和服務(wù)性能曲線最近的實例，就是異常實例，進(jìn)而可以針對該實例的Top N請求進(jìn)行下鉆分析就可以得到故障所對應(yīng)的代碼行，問題就可以解決了。

上面所建立的系統(tǒng)服務(wù)實例的關(guān)系，本身就是利用了業(yè)務(wù)應(yīng)用運行時本身就存在的關(guān)系，那么為何不利用起來呢，到這里還沒用到高大上的AI、機(jī)器學(xué)習(xí)呢。

5.3故障可視化與故障重現(xiàn)

故障可視化

當(dāng)發(fā)生故障時，可以在指標(biāo)的運行圖譜高亮顯示該異常點，也是可視化工作中必須的，正如如下圖：

上圖內(nèi)，系統(tǒng)識別到了“響應(yīng)時間”的異常，當(dāng)前時間點的異常指標(biāo)為11ms，同時一個友好的智能運維系統(tǒng)會把該時刻系統(tǒng)其他方面的指標(biāo)也展示出來，運維人員可以直觀的看到不同曲線之間的關(guān)系，并且圖中每一個坐標(biāo)圖的右上角都展示了該指標(biāo)與異常指標(biāo)之間的“相關(guān)系數(shù)”，并且按相關(guān)系數(shù)絕對值倒序排列，相關(guān)系數(shù)絕對值越接近于1，那么就越有可能是問題的直接或間接原因。

故障重現(xiàn)

另外當(dāng)業(yè)務(wù)系統(tǒng)的一次請求發(fā)生了錯誤，如果我們可以提供手段將該次請求的過程進(jìn)行一次重現(xiàn)，對于運維人員的排錯支持也“將是極好的”。

如上圖所示，可以對一次應(yīng)用的請求進(jìn)行回放，每一個環(huán)境執(zhí)行了多長時間都可以一目了然。

5.4異常檢測

說到異常檢測，應(yīng)該是業(yè)務(wù)智能運維領(lǐng)域中的一個最常見的場景了，異常檢測的方法很多，本篇中會重點的介紹一下我的見解：

（1）傳統(tǒng)的異常檢測方法

傳統(tǒng)模式下完全基于人的主觀經(jīng)驗，也即基于固定閾值的異常判斷，如 CPU usage高于80%就告警，這種方式適配性是很差的，需要針對不同的場景設(shè)定不同的閾值，甚至同一個業(yè)務(wù)不同時間段的閾值都是不一樣的，大量個性化的配置要求，對于運維人員來說是十分崩潰的。

后來就出現(xiàn)了一定的改進(jìn)，如3-sigma算法，是根據(jù)正態(tài)分布的概率，自動的調(diào)整告警閾值，是的，告警閾值的配置不用人工進(jìn)行，一定程度上提高了運維效率。但是，該類的算法機(jī)器容易忽略指標(biāo)的周期性和趨勢性，造成誤判的問題也很常見了。

（2）基于統(tǒng)計學(xué)和機(jī)器學(xué)習(xí)的異常檢測方法

總結(jié)前面的異常檢測方法，可以概括為兩點：人工運維工作量大、算法適配性低下。其實歸結(jié)為一句話，就是動態(tài)閾值怎么評定的問題。

這個時候就比較適合引入機(jī)器學(xué)習(xí)了，比如基于指數(shù)的三次平滑算法、基于分解的傅里葉/小波分解算法等，可以有效的識別出指標(biāo)的周期性、趨勢性，可以快速識別出一些尖峰（spike）異常。

另外自回歸移動平均模型（ARIMA算法），對于穩(wěn)定的時序數(shù)據(jù)的異常檢測是非常有效的，該算法也非常適合用作時序數(shù)據(jù)的預(yù)測場景。

還有基于深度學(xué)習(xí)的循環(huán)神經(jīng)網(wǎng)絡(luò) RNN算法和長短期記憶網(wǎng)絡(luò)LSTM算法，比較適合處理和預(yù)測時間序列中間隔和延遲相對較長的重要事件。

基于機(jī)器學(xué)習(xí)的眾多算法，都可以大大的提高運維的效率，發(fā)現(xiàn)人工難以發(fā)現(xiàn)的問題，提高預(yù)警的及時性。

（3）異常檢測模型優(yōu)化

上一小節(jié)提到的各類機(jī)器學(xué)習(xí)算法，雖然都功能強大，但是往往都有一定的局限性，那么我們在對具體的一個場景指標(biāo)（如響應(yīng)時間）做異常檢測的時候，我們到底選哪個算法呢？

方法一：這個問題可以通過“自動模型選取”方式來解決，即采用多個算法同時運行，然后通過投票的方式抉擇產(chǎn)生最終的結(jié)果。

舉個例子，針對“響應(yīng)時間”指標(biāo)進(jìn)行異常檢測，采用同比、環(huán)比、ARIMA、LSTM、KNN、高斯共5個算法同時進(jìn)行異常檢測，當(dāng)其中的一半（即>=3）的算法判定為異常時，方認(rèn)為該時刻的指標(biāo)是異常的。

方法二：在方法一的基礎(chǔ)上為每個算法加入權(quán)重值，5種算法初始值均為20（總合為100），當(dāng)一次異常的判斷后，比如算法1/2/3都判定是異常，算法4/5都判定為非異常，那么最終結(jié)果為判定為異常，系統(tǒng)向運維人員發(fā)出告警，當(dāng)運維人員在平臺上通過指標(biāo)橫向?qū)Ρ�、請求下鉆、事件挖掘之后發(fā)現(xiàn)該時刻的指標(biāo)確實為異常，那么運維人員會將這個告警處理掉，那么此時后臺就會默認(rèn)向投票正確的算法的權(quán)重傾斜，為其權(quán)重加1，同時為投票錯誤的算法權(quán)重扣分（但總分仍保持100分）；而如果運維人員發(fā)現(xiàn)該告警是誤報，則會在平臺上反饋“誤報”，則后臺會向投票為非異常的算法權(quán)重傾斜，為每個算法權(quán)重加1，同時為投票為異常的算法權(quán)重扣分（但總分仍保持100分）。如此經(jīng)過長時間的不斷調(diào)整，算法組合就越來越接近于準(zhǔn)確。

（4）答疑解惑

不過有朋友可能會遇到如下問題：

Q：如果我要檢測的指標(biāo)剛剛上線，我根本就沒有離線的訓(xùn)練模型怎么辦？

A：那就初始階段不利用離線模型的算法，先使用ARIMA、同比、環(huán)比、KNN這類的算法跑起來，等待歷史數(shù)據(jù)足夠了生成離線模型之后，再以同等權(quán)重（取得和現(xiàn)有算法權(quán)重的平均值，再進(jìn)行100分支均衡）的方式加入到算法集合中。

Q：我使用這么多的算法來進(jìn)行異常檢測，對于前端告警規(guī)則配置的時候來說，我該怎么去選擇我去使用哪種智能的算法呢？

A：異常檢測的目的就是要識別異常并發(fā)出告警，那么在告警規(guī)則出進(jìn)行配置，選擇智能化的方法來檢測異常的思路是正確的，但是沒有必要讓普通的運維人員來看到我們所提供的眾多算法，還有算法邏輯，對于他們來說我們只需要讓他們選擇諸如“智能告警”這樣的選項就好了，后面的算法選擇交給專業(yè)的“運維算法工程師”來搞定就好。

Q：有了“智能告警”之后，是不是固定閾值告警就不需要了呢？

A：并不是，智能告警解決的是無法直觀、簡單判定故障的場景，但是對于錯誤率、CPU利用率、磁盤剩余量這些基本場景時，還是可以使用閾值告警的，甚至做分級閾值告警（如一般告警、重要告警、嚴(yán)重告警等），這些基本的閾值告警發(fā)生后一般都是比較嚴(yán)重的情況，都是需要處理的；而且，這些告警信息匯聚起來，也可以作為業(yè)務(wù)層面異常故障定位的參考依據(jù)，因為很有可能這些固定閾值觸發(fā)的告警就是業(yè)務(wù)層面故障發(fā)生的根因。

（5）算法訓(xùn)練和模型管理平臺

好了，長篇大論了半天，我們似乎還忽視了一個關(guān)鍵的問題，那就是離線訓(xùn)練的模型是怎么來的，怎么用起來，怎么選算法，怎么調(diào)優(yōu)，算法一定好用嗎？

帶著這一系列的問題，我們可以想象的到，一個離線算法訓(xùn)練和模型管理平臺是十分必要的，這就是“運維算法工程師”所需要使用的平臺了，這個平臺至少要實現(xiàn)如下功能：

算法如何選擇

算法的好壞可以評估

算法最好經(jīng)過測試后才可上線

離線算法訓(xùn)練管理平臺的設(shè)計可以參考如下模型：

離線算法訓(xùn)練管理平臺架構(gòu)簡圖

該平臺可以獲取需要檢測的指標(biāo)，展示過去一段（如一周或一天）時間的曲線；

特征分析器會根據(jù)預(yù)設(shè)的特征組合（事先定義好針對曲線可能的各種特征的識別判定方法庫），提示出該指標(biāo)的曲線對于各類特征（如上升趨勢、周期性、隨機(jī)性等）的支持度，支持度越高代表著該指標(biāo)越具有什么特征；

然后算法推薦器會根據(jù)預(yù)設(shè)的特征-算法組合（事先定義好各種特征所適用何種算法的映射庫），推薦出建議的算法集合（可1可多），當(dāng)然也允許“運維算法工程師”在查看了第一步的曲線后，自定義選擇算法庫。

下一步就將通過前面算法推薦器推薦的算法或運維算法工程師自定義的算法組合進(jìn)行模型的訓(xùn)練，將生成的臨時模型保存起來；

然后，采用真實的線上數(shù)據(jù)來跑這個臨時模型，會得到對應(yīng)的告警；

當(dāng)運行一段時間（如一周或一天）后，將臨時模型發(fā)出的告警和線上模型產(chǎn)生的告警進(jìn)行對比，去掉重復(fù)的部分，剩余部分通過運維工程師的標(biāo)注和反饋，得到兩個模型的誤報率（當(dāng)然也可以采用漏報率），若臨時模型的誤報率低于線上模型，則認(rèn)為模型是有效的，可以進(jìn)行發(fā)布環(huán)節(jié)，該臨時模型替換線上模型，進(jìn)入生產(chǎn)。

注：臨時模型和線上模型的對比如果無法通過運維工程師的評估快速得到的情況下，也可以采用比較通用的算法評估方法來計算得出，不過最好的手段就是“利用運維工程師的判斷”。

5.5關(guān)聯(lián)分析

關(guān)聯(lián)分析一般會作用在故障定位和告警歸集兩個差勁

（1）故障定位

基于關(guān)聯(lián)關(guān)系的基礎(chǔ)可視化輔助

在針對系統(tǒng)的異常進(jìn)行有效的檢測后，極大的縮小了故障的范圍，如將故障縮小到了某幾分鐘內(nèi)，然后將相關(guān)的其他指標(biāo)曲線和故障曲線同時可視化展示，則可以輔助我們深入數(shù)據(jù)進(jìn)行問題的定位：

理論依據(jù)：當(dāng)某一個維度的指標(biāo)發(fā)生異常時，那么相關(guān)的其他指標(biāo)也極有可能一定程度上體現(xiàn)出正向或反向的波動，如果可以將多個疑似相關(guān)指標(biāo)的曲線在一個圖上展示，并提供格線比對功能，那么相比于傳統(tǒng)的翻閱日志看log的情況，將會更快的定位到問題的原因。

落地場景：如上圖所示，某服務(wù)器上某服務(wù)實例在10:00左右發(fā)生了響應(yīng)時間嚴(yán)重變慢的情況，經(jīng)過對相同服務(wù)器的各項指標(biāo)分析，可知當(dāng)時系統(tǒng)CPU占用在同一時刻上升，且內(nèi)存的空閑率也大幅下降，但是實際的業(yè)務(wù)訪問量并沒有飆升，說明并非業(yè)務(wù)繁忙導(dǎo)致，疑似服務(wù)器硬件問題所致；同時在針對部署在服務(wù)器B上的相同實例的指標(biāo)進(jìn)行對比，發(fā)現(xiàn)各項指標(biāo)并無明顯波動，且和服務(wù)器B上正常指標(biāo)類似，所以可以確定是因為服務(wù)器A的硬件問題導(dǎo)致，完成故障初步定界，繼而再去排查服務(wù)器的相關(guān)指標(biāo)，便可迅速定位問題。

基于多維度數(shù)據(jù)的異常診斷分析

理論依據(jù)：通過貢獻(xiàn)度和一致度評判問題根源（如ERROR數(shù)量維度）

貢獻(xiàn)度：即各維度異常數(shù)與總異常數(shù)的比例

一致度：即構(gòu)成該維度的子維度的異常程度的相似度信息。

那么貢獻(xiàn)度越高、子維度的異常相似度越高，則該維度為根因維度的可能性越大。

因此，可以將數(shù)據(jù)的各維度展開，分別計算各維度的貢獻(xiàn)度、一致度兩個特征，構(gòu)建評估參數(shù)P=貢獻(xiàn)度/一致度，該值越高，則該子維度為根因維度的可能性越大。

落地場景：當(dāng)發(fā)現(xiàn)某服務(wù)（如充值服務(wù)）的錯誤率告警突然大幅增加時，傳統(tǒng)運維人員往往無法快速定位，甚至問題的定界都需要大量的時間，如果運用智能運維產(chǎn)品，可以將該服務(wù)的所有6個實例上進(jìn)行3個錯誤共6*3=18中維度上進(jìn)行分析，利用上述理論中的評估參數(shù)列出排名前N的組合，迅速將問題范圍大幅縮小，提高排查的效率。

可以定位到實例4的404錯誤是錯誤數(shù)的主要原因，可針對性進(jìn)行排查

（2）告警歸集

基于關(guān)聯(lián)挖掘的告警分析

采用機(jī)器學(xué)習(xí)算法實現(xiàn)告警的關(guān)聯(lián)挖掘，進(jìn)而實現(xiàn)告警前的合并優(yōu)化，與告警后的數(shù)據(jù)分析，反哺合并策略。

理論依據(jù)：歷史上每次某一個告警總是伴隨著另外一個告警的出現(xiàn)，那么可以懷疑兩類告警之間存在必然聯(lián)系，甚至因果關(guān)系，所以可以考慮合并該兩類告警，并積累在運維知識庫內(nèi)，隨著歷史數(shù)據(jù)的豐富，告警合并的準(zhǔn)確性將不斷提高。

落地場景：在歷史數(shù)據(jù)上，A實例的策略R1和B實例的策略R2經(jīng)常同時報警，那么A實例的策略R1和B實例的策略R2就極有可能存在關(guān)聯(lián)，經(jīng)過一定的置信評級，就可以合并在一起發(fā)送。

注：置信度是針對一條關(guān)聯(lián)規(guī)則A告警->B告警而言定義的，代表了A告警導(dǎo)致B告警發(fā)生的可能的概率

智能告警體系下充分利用從業(yè)務(wù)到主機(jī)的縱向數(shù)據(jù)關(guān)聯(lián)，實現(xiàn)告警的聚合與收斂

理論依據(jù)：將運維對象劃分為不同的層次

業(yè)務(wù)角度：服務(wù)/實例/告警類型

部署角度：機(jī)器/機(jī)房

同一角度同一層次同時刻的告警，很可能存在著一定聯(lián)系，故而可將這些告警合并。

落地場景：話費查詢服務(wù)的信息港機(jī)房內(nèi)服務(wù)1的A實例在發(fā)生進(jìn)程丟失告警，同時該服務(wù)在信息港機(jī)房的服務(wù)1的B實例上也發(fā)生了進(jìn)程丟失告警。這兩個告警屬于同一個機(jī)房的同一個服務(wù)的同一個策略（進(jìn)程監(jiān)控策略）下的告警，且為同一層次，因而可以實現(xiàn)收斂。

小結(jié)

上述基于關(guān)聯(lián)關(guān)系實現(xiàn)了故障輔助定位和告警的智能歸集，其實還有很多落地的場景，如根據(jù)事件依賴關(guān)系構(gòu)造動態(tài)事件概率模型圖，如果有大量的歷史數(shù)據(jù)做分析，就可以充分的識別出各類事件之間的因果關(guān)系，這些因果關(guān)系就是最寶貴的運維知識庫。

5.6負(fù)載均衡優(yōu)化

同時，智能運維系統(tǒng)也將輔助軟件負(fù)載策略的優(yōu)化，通過針對集群的全面監(jiān)控和分析，在負(fù)載層做出更新時，可以及時的發(fā)現(xiàn)集群整體的健康劣化的狀況，及時發(fā)現(xiàn)負(fù)載策略變更導(dǎo)致的問題，并向負(fù)載層軟件上報問題或針對負(fù)載策略優(yōu)化的建議，以更加智能化的手段提高系統(tǒng)的高可用性和效率。

負(fù)載均衡優(yōu)化模型

輔助負(fù)載優(yōu)化常用場景包括：

相同負(fù)載下某主機(jī)的硬件指標(biāo)告警，則可以考慮將其上應(yīng)用轉(zhuǎn)移到其他低負(fù)載主機(jī)上，或降低負(fù)載均衡器的分配權(quán)重，達(dá)到所有主機(jī)整體健康；

當(dāng)發(fā)現(xiàn)某主機(jī)上應(yīng)用響應(yīng)變慢，并且將會發(fā)生故障時，負(fù)載均衡的tcp探查無法發(fā)現(xiàn)，運維系統(tǒng)可以實現(xiàn)事先預(yù)警，并定位事故原因（一般為硬件或負(fù)載均衡器分擔(dān)錯誤問題），同時上報負(fù)載均衡器，事先負(fù)載重分等止損措施；

灰度發(fā)布過程中，可以通過智能運維產(chǎn)品監(jiān)控新版本的性能情況，如可及早發(fā)現(xiàn)新版本應(yīng)用性能較差或者存在錯誤警告，則可以及時上報灰度發(fā)布系統(tǒng)，及時止損，或觸發(fā)自部署節(jié)點的回滾自愈操作。

5.7日志分析

日志分析的作用，往往會體現(xiàn)在如下幾個場景：

（1）針對業(yè)務(wù)日志進(jìn)行業(yè)務(wù)的多維分析

如通過CDN的日志，實現(xiàn)用戶的行為畫像，也可以實現(xiàn)故障分布的拓?fù)湟晥D；

（2）針對于日志中出現(xiàn)的各類關(guān)鍵日志

可以提煉出關(guān)鍵的事件來，這些事件如果和前面的業(yè)務(wù)異常所關(guān)聯(lián)起來，就可以實現(xiàn)業(yè)務(wù)異常所對應(yīng)的根因事件溯源；

（3）利用諸如ELK這樣的平臺

針對分布式的日志進(jìn)行匯聚和索引后，就可以發(fā)揮和業(yè)務(wù)層性能采集一樣的作用，將日志進(jìn)行解析后，同樣是是一列一列的性能指標(biāo)，而后再來做異常檢測還是可以的；

（4）利用日志做運維審計與合規(guī)

也是一個智能運維的典型場景。

6、智能運維的最高境界-故障自愈

針對于故障自愈應(yīng)該以故障定位準(zhǔn)確基礎(chǔ)之上開展的，需要逐步推行，在此我就結(jié)合幾個場景來聊一聊故障自愈的設(shè)計方案（按照云計算體系進(jìn)行分層描述吧），以輔助落地：

（1）Saas層：

服務(wù)4**/5**錯誤：直接重啟進(jìn)程后再檢測。

服務(wù)性能緩慢：排查相同集群服務(wù)是否均發(fā)生劣化，如僅此節(jié)點劣化，可采取流量分擔(dān)方案；如全部節(jié)點均劣化，可采取自動擴(kuò)容方案。

頻繁GC：可按需增大JVM內(nèi)存分配后繼續(xù)監(jiān)控。

（2）Paas和Daas層：

Spark executor性能明顯劣化：可在下次任務(wù)開始之前更新–executor-memory

Db阻塞連接數(shù)激增：可斷開超過設(shè)定閾值（如2分鐘）的連接

Docker性能下降：新建docker分配更大內(nèi)存，對現(xiàn)有docker進(jìn)行替代

YARN資源分配失敗：判斷YARN資源情況，如果占用已滿，進(jìn)行動態(tài)擴(kuò)容

（3）Iaas層

磁盤滿：調(diào)用清理文件腳本實現(xiàn)清理，并釋放進(jìn)程資源占用

磁盤不可見：嘗試重新掛載，如無效后直接將告警轉(zhuǎn)發(fā)給硬件維護(hù)人員

內(nèi)存不足：嘗試清理服務(wù)器page cache等

輔助優(yōu)化的方案：當(dāng)發(fā)生故障后，并不一定需要立刻觸發(fā)自愈操作，如突然的網(wǎng)絡(luò)抖動，引起服務(wù)報錯、性能緩慢的故障，很有可能過若干分鐘即可自行恢復(fù)，此類則不需要立刻修復(fù)，那么優(yōu)化后的方案可以參考如下的思路：

首次發(fā)現(xiàn)故障暫不觸發(fā)自愈操作，待連續(xù)5次出現(xiàn)同樣故障，觸發(fā)自愈操作；

采集一定時間段的平均值，如平均值不超過閾值，則不認(rèn)為是故障，不觸發(fā)自愈操作

7 、智能運維不是萬能的

智能運維并不是萬能的，智能運維的落地成功性在于精于業(yè)務(wù)、切合實際，關(guān)鍵點如下：

精于業(yè)務(wù)，了解業(yè)務(wù)的規(guī)律，才好選擇好的算法模型；

有了智能運維不代表就不需要運維人員了，因為畢竟算法是人寫的，機(jī)器學(xué)習(xí)還是需要有“運維老司機(jī)”進(jìn)行調(diào)教的；

若想做好準(zhǔn)確的預(yù)測，需要有足夠、精細(xì)的歷史數(shù)據(jù)為樣本；

需要將算法運用于貼合實際的某一個具體業(yè)務(wù)場景中，避免離譜夸大的設(shè)想，如“預(yù)測小米什么時候上市，沒準(zhǔn)說著說著就上市了”，其實前幾天就已經(jīng)上市了；

智能運維的前提最好是先實現(xiàn)自動化，否則即使檢測出故障和根因也無法自動修復(fù)；

一定要貼合實際情況，一步一步來，切勿期盼一口吃個胖子。

8、感慨下

業(yè)務(wù)智能運維，是運維發(fā)展的大勢所趨，無所畏懼，世間萬物皆連接，有了人工智能這一利器，加之我們對于業(yè)務(wù)的深層理解，以及運維領(lǐng)域的豐富經(jīng)驗，相信中國移動智能運維體系的建成和落地，指日可待��！

注：文中少部分內(nèi)容的思路和靈感參考于百度、清華大學(xué)、Linkedin、Yahoo等公司運維領(lǐng)域?qū)＜业拇笞鳎�謝謝。