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

作者：胡建華

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

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

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

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

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

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

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

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

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

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

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

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

針對(duì)不同運(yùn)維實(shí)體的煙囪式的運(yùn)維工具，功能重疊、難以整合；

運(yùn)維的自動(dòng)化程度偏低，運(yùn)維腳本泛濫，層次化、模塊化程度不足；

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

（3）海量的運(yùn)維數(shù)據(jù)的價(jià)值無(wú)法充分挖掘

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.1智能運(yùn)維核心要素

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

數(shù)據(jù)

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

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

數(shù)據(jù)多樣化：運(yùn)維過(guò)程產(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ù)等，那么需要針對(duì)不同類型數(shù)據(jù)進(jìn)行區(qū)別化的存儲(chǔ)結(jié)構(gòu)的設(shè)計(jì)，保證數(shù)據(jù)存儲(chǔ)的擴(kuò)展性，同時(shí)建立數(shù)據(jù)之間的關(guān)聯(lián)支點(diǎn)；

分析能力

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

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

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

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

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

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

（1）用戶層：

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

（2）視圖層：

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

（3）服務(wù)層：

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

（4）核心能力層：

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

智能監(jiān)控：

實(shí)現(xiàn)針對(duì)各個(gè)層面的監(jiān)控覆蓋，包括用戶體驗(yà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ùn)維知識(shí)庫(kù)。

智能分析：

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

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

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

智能告警：

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

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

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

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

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

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

pinpoint運(yùn)用JavaAgent字節(jié)碼增強(qiáng)技術(shù)實(shí)現(xiàn)應(yīng)用服務(wù)端數(shù)據(jù)的采集，且無(wú)侵入式的設(shè)計(jì)，使用方便，無(wú)需更改業(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 實(shí)現(xiàn)海量數(shù)據(jù)的存儲(chǔ)，通過(guò)部署在業(yè)務(wù)遠(yuǎn)端的agent通過(guò)UDP+thrift的方式將應(yīng)用采集的數(shù)據(jù)傳輸?shù)絚ollector，經(jīng)過(guò)處理后實(shí)現(xiàn)hbase的落存。Web UI實(shí)現(xiàn)監(jiān)控的可視化。

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

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

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

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

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

可以通過(guò)參數(shù)自定義的方式來(lái)指定實(shí)際需要采集的指標(biāo)項(xiàng)，避免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ù)載等維度各個(gè)參數(shù)的獲取，您可能首先想到的是zabbix，那么zabbix確實(shí)功能強(qiáng)大，但是“殺雞焉用牛刀”，上述CPU/磁盤/內(nèi)存等幾個(gè)參數(shù)就是我們隨手敲行代碼就可以搞定的事，只不過(guò)做成定時(shí)任務(wù)即可，所以我們不用zabbix，轉(zhuǎn)向輕量化的開源手段，其實(shí)TICK數(shù)據(jù)采集框架您可能都聽過(guò)，那么我們模仿TICK，通過(guò)TIG（Telegraf+influxdb+grafana）框架也可以輕松搞定了。

Telegraf是一種輕量級(jí)的采集框架，支持秒級(jí)別間歇的采集粒度，對(duì)服務(wù)器的資源占用很小（不到3%）；

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

故障可視化

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

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

故障重現(xiàn)

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

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

5.4異常檢測(cè)

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

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

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

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

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

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

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

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

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

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

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

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

方法一：這個(gè)問(wèn)題可以通過(guò)“自動(dòng)模型選取”方式來(lái)解決，即采用多個(gè)算法同時(shí)運(yùn)行，然后通過(guò)投票的方式抉擇產(chǎn)生最終的結(jié)果。

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

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

（4）答疑解惑

不過(guò)有朋友可能會(huì)遇到如下問(wèn)題：

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

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

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

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

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

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

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

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

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

算法如何選擇

算法的好壞可以評(píng)估

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

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

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

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

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

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

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

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

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

注：臨時(shí)模型和線上模型的對(duì)比如果無(wú)法通過(guò)運(yùn)維工程師的評(píng)估快速得到的情況下，也可以采用比較通用的算法評(píng)估方法來(lái)計(jì)算得出，不過(guò)最好的手段就是“利用運(yùn)維工程師的判斷”。

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

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

（1）故障定位

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

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

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

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

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

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

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

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

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

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

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

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

（2）告警歸集

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

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

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

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

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

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

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

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

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

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

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

小結(jié)

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

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

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

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

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

相同負(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)變慢，并且將會(huì)發(fā)生故障時(shí)，負(fù)載均衡的tcp探查無(wú)法發(fā)現(xiàn)，運(yùn)維系統(tǒng)可以實(shí)現(xiàn)事先預(yù)警，并定位事故原因（一般為硬件或負(fù)載均衡器分擔(dān)錯(cuò)誤問(wèn)題），同時(shí)上報(bào)負(fù)載均衡器，事先負(fù)載重分等止損措施；

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

5.7日志分析

日志分析的作用，往往會(huì)體現(xiàn)在如下幾個(gè)場(chǎng)景：

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

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

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

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

（3）利用諸如ELK這樣的平臺(tái)

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

（4）利用日志做運(yùn)維審計(jì)與合規(guī)

也是一個(gè)智能運(yùn)維的典型場(chǎng)景。

6、智能運(yùn)維的最高境界-故障自愈

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

（1）Saas層：

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

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

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

（2）Paas和Daas層：

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

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

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

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

（3）Iaas層

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

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

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

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

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

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

7 、智能運(yùn)維不是萬(wàn)能的

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

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

有了智能運(yùn)維不代表就不需要運(yùn)維人員了，因?yàn)楫吘顾惴ㄊ侨藢懙�，機(jī)器學(xué)習(xí)還是需要有“運(yùn)維老司機(jī)”進(jìn)行調(diào)教的；

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

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

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

一定要貼合實(shí)際情況，一步一步來(lái)，切勿期盼一口吃個(gè)胖子。

8、感慨下

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

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