摘要：隨著人工智能時(shí)代的到來，攜程生產(chǎn)環(huán)境運(yùn)維進(jìn)入了新的運(yùn)維時(shí)代。本文選取了幾種典型的運(yùn)維場景對(duì)在攜程的踐行展開了介紹，首先讓我們從概念認(rèn)識(shí)下。針對(duì)應(yīng)用異常指標(biāo)檢測這種場景，抽取一定的樣本統(tǒng)計(jì)，在基于專家經(jīng)驗(yàn)標(biāo)注下的準(zhǔn)確率可達(dá)到以上，召回率接近。

作者簡介

徐新龍，攜程技術(shù)保障中心應(yīng)用管理團(tuán)隊(duì)高級(jí)工程師，負(fù)責(zé)多個(gè)AIOps項(xiàng)目的設(shè)計(jì)與研發(fā)。信號(hào)處理專業(yè)碩士畢業(yè)，對(duì)人工智能、機(jī)器學(xué)習(xí)、神經(jīng)網(wǎng)絡(luò)及數(shù)學(xué)有濃厚的興趣，對(duì)人工智能技術(shù)結(jié)合運(yùn)維場景的實(shí)踐有深入研究。

隨著人工智能時(shí)代的到來，攜程生產(chǎn)環(huán)境運(yùn)維進(jìn)入了新的運(yùn)維時(shí)代——AIOps。通過兩年多時(shí)間的技術(shù)投入與實(shí)踐，AIOps在效率提升、可用性保障、成本優(yōu)化等運(yùn)維場景取得了顯著的成果。

本文選取了幾種典型的運(yùn)維場景對(duì)AIOps在攜程的踐行展開了介紹，首先讓我們從概念認(rèn)識(shí)下AIOps。

一、AIOps的概念

2016年3月，AlphaGo與圍棋世界冠軍、職業(yè)九段棋手李世石進(jìn)行圍棋人機(jī)大戰(zhàn)，以4比1的總比分獲勝，人工智能技術(shù)又重新進(jìn)入大眾視野，備受關(guān)注。

通常人工智能技術(shù)分為“弱人工智能”和“強(qiáng)人工智能”，其中弱人工智能是能夠和人一樣，甚至比人更好地執(zhí)行特定任務(wù)的技術(shù)；強(qiáng)人工智除了更好的執(zhí)行特定任務(wù)之外，有著人類所有的感知和理性思考(甚至比人類更多)。目前我們提到的人工智能技術(shù)都是弱人工智能。

人工智能技術(shù)從概念落地到實(shí)踐需要具備三個(gè)必要條件，即算法、算力和數(shù)據(jù)。

其中算法和算力，隨著機(jī)器學(xué)習(xí)算法理論和工程技術(shù)體系的成熟，已經(jīng)得到很好的攻克，關(guān)鍵點(diǎn)在于數(shù)據(jù)和應(yīng)用場景。有過算法經(jīng)驗(yàn)的人應(yīng)該都知道，算法效果的上限取決于數(shù)據(jù)質(zhì)量。

運(yùn)維行業(yè)因?yàn)榉e累了大量生產(chǎn)環(huán)境數(shù)據(jù)，其中包括各種指標(biāo)的監(jiān)控?cái)?shù)據(jù)、告警數(shù)據(jù)等，特別是對(duì)于攜程這樣體量龐大的網(wǎng)站，這些數(shù)據(jù)每分鐘正以驚人的速度在不斷增長，具備了AI技術(shù)落地得天獨(dú)厚的條件。

2016年Gartner報(bào)告中提出了AIOps概念，也就是Algorithmic IT Operations—基于算法的IT運(yùn)維，主要指用大數(shù)據(jù)、機(jī)器學(xué)習(xí)驅(qū)動(dòng)自動(dòng)化、服務(wù)臺(tái)、監(jiān)控場景下的能力提升。

從某種意義上講，AIOps也可以稱之為數(shù)據(jù)運(yùn)維。

AIOps人員組成上由三大主體構(gòu)成，即運(yùn)維工程師、運(yùn)維開發(fā)工程師和運(yùn)維AI工程師。

?

運(yùn)維工程師作為最前線的人員，對(duì)生產(chǎn)運(yùn)維場景了如指掌，提煉出相應(yīng)的需求點(diǎn)；運(yùn)維開發(fā)工程師則是協(xié)助運(yùn)維工程師，將其提出的需求加以自動(dòng)化實(shí)現(xiàn)，從而避免重復(fù)性手動(dòng)勞動(dòng)，解放雙手；隨著運(yùn)維規(guī)模和場景變的越來越復(fù)雜，僅僅靠以往的經(jīng)驗(yàn)知識(shí)已經(jīng)難以應(yīng)對(duì)，于是AIOps應(yīng)運(yùn)而生，用基于統(tǒng)計(jì)、學(xué)習(xí)替代傳統(tǒng)的基于規(guī)則，而代表這種生產(chǎn)力的就是運(yùn)維AI工程師。

二、攜程AIOps幾種典型應(yīng)用場景介紹

目前AIOps在業(yè)界還屬于應(yīng)用探索階段，其比較成熟的場景主要包括以下兩個(gè)領(lǐng)域：

可用性保障：異常指標(biāo)檢測、故障智能診斷、故障預(yù)測、故障自動(dòng)修復(fù)等；

成本優(yōu)化：容量規(guī)劃、資源利用率提升、性能優(yōu)化等。

接下來介紹下攜程在這兩個(gè)領(lǐng)域下的部分典型場景，以及相關(guān)算法簡介； ?

1、應(yīng)用異常指標(biāo)檢測?

應(yīng)用的埋點(diǎn)信息是能反映應(yīng)用健康狀況的指標(biāo)，這些埋點(diǎn)指標(biāo)被監(jiān)控系統(tǒng)采集并設(shè)置一定的告警規(guī)則(一般為固定的閾值)，一旦某個(gè)指標(biāo)連續(xù)達(dá)到設(shè)定的閾值時(shí)，就會(huì)通知相應(yīng)的負(fù)責(zé)人處理。傳統(tǒng)基于固定閾值的告警技術(shù)存在以下的問題：

1）固定閾值的設(shè)定依賴人為經(jīng)驗(yàn)，和實(shí)際情況可能存在較大的偏差；

2）一旦設(shè)置不合理，即存在大量的漏報(bào)誤報(bào)；

3）無法檢測異常序列的冒煙特征，例如緩慢爬升等；

4）攜程應(yīng)用成千上萬，數(shù)量眾多，為每個(gè)應(yīng)用維護(hù)固定閾值，成本極高；

5）犧牲告警及時(shí)性換取有效性，出現(xiàn)應(yīng)用告警滯后于訂單告警。

下圖給出某個(gè)應(yīng)用的一段監(jiān)控指標(biāo)(已經(jīng)脫敏)，其中A、B兩條換黃線之間存在異常，如采用固定閾值就可能造成：使用紅線2作為閾值可以發(fā)現(xiàn)異常點(diǎn)，但造成了大量的誤報(bào)(黃線B的有部分)；使用紅線1作為閾值雖然減少了誤告，但無法檢測出異常時(shí)序。

AB之間存在異常的某段時(shí)間序列

為了解決以上存在的問題，通過對(duì)時(shí)間序列建立ARMA模型，利用時(shí)序的統(tǒng)計(jì)特性、時(shí)頻分析，再結(jié)合工業(yè)常用的3sigma準(zhǔn)則確定動(dòng)態(tài)閾值，自動(dòng)識(shí)別時(shí)序中的異常點(diǎn)。同時(shí)根據(jù)告警時(shí)序之間的相關(guān)性、專家知識(shí)庫等區(qū)分告警類型。相比傳統(tǒng)告警規(guī)則，智能告警系統(tǒng)在準(zhǔn)確率和召回率都有巨大的提升。針對(duì)應(yīng)用異常指標(biāo)檢測這種場景，抽取一定的樣本統(tǒng)計(jì)，在基于專家經(jīng)驗(yàn)標(biāo)注下的準(zhǔn)確率可達(dá)到90%以上，召回率接近100%。

對(duì)正態(tài)分布而言，樣本99.74%都分布在中心位置之處

針對(duì)應(yīng)用異常指標(biāo)檢測這個(gè)場景，為了更具體說明算法步驟，我們使用動(dòng)態(tài)閾值告警和周期性檢測來進(jìn)一步闡述。

動(dòng)態(tài)閾值告警：

在創(chuàng)建ARMA模型之后，利用頻域特性設(shè)計(jì)模型參數(shù)，待模型參數(shù)調(diào)節(jié)得當(dāng)后，對(duì)原始時(shí)間序列進(jìn)行平滑濾波，確定時(shí)序每一時(shí)刻的統(tǒng)計(jì)中心，中心位置確定后，再結(jié)合3sigma準(zhǔn)則給出時(shí)序每一時(shí)刻的上限，以此達(dá)到動(dòng)態(tài)閾值的功能。

以下示例為生產(chǎn)某個(gè)應(yīng)用一段包含異常情況的監(jiān)控時(shí)間序列，黃色曲線代表了原始時(shí)序數(shù)據(jù)，綠色的曲線為ARMA平滑濾波的輸出，紅色曲線是在綠色曲線基礎(chǔ)上疊加3sigma之后的動(dòng)態(tài)閾值(根據(jù)實(shí)際數(shù)據(jù)的統(tǒng)計(jì)特性，如果滿足超高斯分布，則可選擇2sigma或更??；對(duì)于亞高斯分布，可選擇5sigma或更大等)。借助動(dòng)態(tài)閾值，異常點(diǎn)(離群較遠(yuǎn)的監(jiān)控點(diǎn))很容易被識(shí)別出來。

某段包含異常的時(shí)間序列檢測，紅色豎直虛線位置為檢測到的異常點(diǎn)?

周期性檢測：

自動(dòng)周期發(fā)現(xiàn)主要是通過對(duì)監(jiān)控指標(biāo)一段時(shí)間的觀察，找出其中蘊(yùn)含的規(guī)律信息，例如檢查網(wǎng)站是否存在定期的爬蟲抓取房價(jià)、票價(jià)現(xiàn)象，自動(dòng)發(fā)現(xiàn)某些監(jiān)控指標(biāo)的季節(jié)性指數(shù)等場景。通常的辦法是將時(shí)間域的時(shí)序信號(hào)經(jīng)過傅里葉變換映射到頻率域加以分析。以下示例是對(duì)生產(chǎn)某個(gè)應(yīng)用一段監(jiān)控時(shí)間序列先做自相關(guān)降噪，濾波器剔除高頻干擾，然后借助快速傅里葉變換FFT確定時(shí)序周期的場景。

自上而下分為原始時(shí)序、自相關(guān)函數(shù)輸出、濾波器濾波后的時(shí)序及FFT變換之后的幅頻響應(yīng)，從最下面一幅圖可以清楚的看到一條譜線，通過適當(dāng)?shù)淖儞Q即可得出該時(shí)序發(fā)生的周期

2、故障智能診斷?

便隨著攜程業(yè)務(wù)的不斷擴(kuò)大，網(wǎng)站架構(gòu)也在朝著越來越復(fù)雜的結(jié)構(gòu)演化。一旦出現(xiàn)訂單或應(yīng)用異常，靠人力已經(jīng)很難快速定位到故障根源，即便是經(jīng)驗(yàn)豐富的資深運(yùn)維人員很多時(shí)候也需要花費(fèi)很長時(shí)間來定位。對(duì)攜程這樣一個(gè)在OTA行業(yè)的領(lǐng)軍企業(yè)來說，長時(shí)間的網(wǎng)站不可用，損失的不僅僅是收入，更是用戶體驗(yàn)和社會(huì)信任，因而能夠快速定位故障源和止損，至關(guān)重要。

實(shí)際的網(wǎng)站架構(gòu)拓?fù)涓訌?fù)雜?

正因網(wǎng)站架構(gòu)非常復(fù)雜，故障點(diǎn)就可能存在于網(wǎng)絡(luò)線路、路由器、交換機(jī)、機(jī)架、服務(wù)器、負(fù)載均衡設(shè)備、代理、DNS、CDN、數(shù)據(jù)庫、Redis、應(yīng)用程序、外部供應(yīng)商接口等各個(gè)環(huán)節(jié)。

而且對(duì)于大部分的網(wǎng)站故障，往往環(huán)節(jié)相扣。例如，上游的故障源，通過調(diào)用鏈，一層層傳遍所有依賴方，即使每個(gè)環(huán)節(jié)都有著非常完善的監(jiān)控告警系統(tǒng)，但面對(duì)大量的告警風(fēng)暴，定位故障根源絕非易事。另外，定位到故障根源之后，也需要手動(dòng)恢復(fù)，如此一來也是增加了網(wǎng)站恢復(fù)的總時(shí)間。

為了解決這個(gè)難題，我們收集來自各個(gè)告警系統(tǒng)、發(fā)布系統(tǒng)、變更系統(tǒng)、配置中心等多個(gè)數(shù)據(jù)源的消息，包括網(wǎng)絡(luò)告警、基礎(chǔ)系統(tǒng)告警、應(yīng)用告警、DB告警、Redis告警、代理告警、應(yīng)用發(fā)布、變更、配置修改等，通過因子分析、相關(guān)性分析、決策樹分析、馬爾科夫鏈分析、調(diào)用鏈分析(面積算法)、專家知識(shí)庫分析等方法，對(duì)每個(gè)候選的故障、發(fā)布或變更利用相關(guān)系數(shù)或貝葉斯公式給出一定的分?jǐn)?shù)(分?jǐn)?shù)代表了可信度)，分?jǐn)?shù)較高的確定為故障源。

通過不斷地實(shí)踐優(yōu)化，未來花費(fèi)在排障中的時(shí)間將大大減少，由原來數(shù)十分鐘、乃至小時(shí)級(jí)別的排障時(shí)間縮短至分鐘級(jí)，智能故障診斷將成為提升網(wǎng)站可用性最重要的保障之一。

所有潛在故障因子展示

選取其中調(diào)用鏈故障診斷的部分邏輯做算法說明。

故障應(yīng)用相關(guān)性診斷：

所謂牽一發(fā)而動(dòng)全身，某個(gè)應(yīng)用發(fā)生異常時(shí)，往往會(huì)殃及到整個(gè)調(diào)用鏈。故障期間如果可以歸類這些相關(guān)聯(lián)的告警，對(duì)于收斂告警或判斷是否大面積故障，將變得非常有幫助。在眾多判斷相關(guān)性算法中，最簡單的相關(guān)系數(shù)是一個(gè)不錯(cuò)的衡量標(biāo)準(zhǔn)。計(jì)算兩個(gè)告警時(shí)序之間的皮爾遜相關(guān)系數(shù)，再結(jié)合應(yīng)用之間的調(diào)用關(guān)系，即可給出故障應(yīng)用相關(guān)性的診斷報(bào)告。

以下是某個(gè)時(shí)間點(diǎn)的故障應(yīng)用相關(guān)性部分診斷報(bào)告內(nèi)容，通過這個(gè)報(bào)告，可以比較快速的判斷出是局部異常還是全局故障。如果僅為調(diào)用鏈上的相關(guān)告警，則認(rèn)為是局部異常；反之則可能為全局或大面積故障導(dǎo)致。

告警時(shí)序相關(guān)性分析顯示應(yīng)該為工具組件或大面積異常導(dǎo)致?

3、資源利用率提升

如何在滿足業(yè)務(wù)需求、安全的前提下，更加經(jīng)濟(jì)的運(yùn)營網(wǎng)站是每個(gè)互聯(lián)網(wǎng)公司都在不斷探索的課題。降低網(wǎng)站成本一個(gè)很不錯(cuò)的主意就是提升對(duì)資源的利用率。接下來通過應(yīng)用畫像、Online/Offline混部以及智能彈性擴(kuò)縮容來展示攜程在提升資源利用率方面借助機(jī)器學(xué)習(xí)算法的成功實(shí)踐。

應(yīng)用畫像

作為國內(nèi)較大的在線旅游OTA，攜程擁有成千上萬的應(yīng)用，每個(gè)應(yīng)用對(duì)資源的使用情況也各不相同，哪些是CPU計(jì)算型應(yīng)用、哪些是內(nèi)存消耗型應(yīng)用、哪些是高IO應(yīng)用等，為了提高應(yīng)用對(duì)資源的整體利用率，需要我們有能力對(duì)其進(jìn)行區(qū)分。

針對(duì)這個(gè)問題，我們設(shè)計(jì)了應(yīng)用畫像，通過利用K-means、EM等聚類算法對(duì)應(yīng)用基礎(chǔ)監(jiān)控的各項(xiàng)監(jiān)控指標(biāo)、應(yīng)用監(jiān)控指標(biāo)、發(fā)布?xì)v史數(shù)據(jù)做分類，區(qū)分出：CPU密集型、內(nèi)存密集型、網(wǎng)絡(luò)IO密集型、請(qǐng)求耗時(shí)型、頻繁發(fā)布型等應(yīng)用，同時(shí)給出每個(gè)應(yīng)用屬于某個(gè)標(biāo)簽的置信度。

對(duì)比以往宿主機(jī)上隨機(jī)分配應(yīng)用的資源，借助應(yīng)用畫像，將親和性高的應(yīng)用部署在同一宿主機(jī)上可以有效提高整體資源的利用率。

應(yīng)用畫像各個(gè)維度標(biāo)簽展示，除幫助提升資源利用率外，在其他場景也有廣泛使用

Online/Offline混部

攜程的業(yè)務(wù)特點(diǎn)決定了大部分的Online應(yīng)用資源在夜間非常的空閑，而Offline的一些Hadoop、Spark作業(yè)在這段時(shí)間對(duì)資源的利用率又非常高。

借助應(yīng)用畫像篩選合適的Online應(yīng)用資源，在其利用率低峰期間部署實(shí)例調(diào)度Offline作業(yè)使用，即填補(bǔ)了Online資源利用率的低谷，又為Offline作業(yè)減少了離線資源采購(離線資源采購費(fèi)用非常昂貴)。Online/Offline混部在提升數(shù)倍資源利用率、分擔(dān)Offline作業(yè)的同時(shí)，也提供了一種對(duì)資源互補(bǔ)使用的常態(tài)調(diào)度模式。

Offline作業(yè)調(diào)度到Online計(jì)算節(jié)點(diǎn)

智能彈性擴(kuò)縮容

雖然攜程已經(jīng)具備了虛擬機(jī)分鐘級(jí)交付、容器秒級(jí)交付的能力，但在傳統(tǒng)運(yùn)維中，資源的申請(qǐng)與回收均需要有相關(guān)人員手動(dòng)觸發(fā)才可以完成。如遇到突發(fā)流量飆升造成的容量不足，且相關(guān)人員不能及時(shí)就位，就可能引發(fā)生產(chǎn)故障；另外，因業(yè)務(wù)邏輯下線但服務(wù)器并未下線時(shí)，長此以往就會(huì)堆積大量的空閑服務(wù)器，造成了對(duì)資源的浪費(fèi)以及網(wǎng)站成本的增加。

針對(duì)這個(gè)場景，設(shè)計(jì)資源的利用率模型，使用SVM(支撐向量機(jī))等算法對(duì)CPU、內(nèi)存、網(wǎng)絡(luò)IO等多個(gè)維度加以訓(xùn)練，定期掃描生產(chǎn)資源，產(chǎn)出容量富裕和不足的容量報(bào)告。針對(duì)這些容量報(bào)告，通過攜程內(nèi)部的彈簧系統(tǒng)(Spring，彈性擴(kuò)縮容平臺(tái))對(duì)資源補(bǔ)給和裁剪。整個(gè)過程不需要人工干預(yù)，在節(jié)省人力成本的同事，大大提高了資源的利用率，降低了運(yùn)營成本。

三、結(jié)束語

Dev和Ops的碰撞，產(chǎn)生了DevOps，DevOps的出現(xiàn)避免了重復(fù)性的工作，減少了人力成本，顯著地提升了運(yùn)維效率；AI和Ops的邂逅，誕生了AIOps，作為DevOps更高階的實(shí)現(xiàn)，以機(jī)器學(xué)習(xí)、統(tǒng)計(jì)替代基于規(guī)則的傳統(tǒng)運(yùn)維模式，通過對(duì)海量運(yùn)維數(shù)據(jù)的分析，更加智能的做出分析、決策。AIOps目前還屬于不斷完善和探索階段，未來會(huì)有更多的場景被挖掘和應(yīng)用?？梢灶A(yù)見，面對(duì)未來越來越復(fù)雜的運(yùn)維場景和挑戰(zhàn)，非AIOps而不能勝任。

軟件開發(fā)技術(shù)群

興趣范圍包括：Java，C/C++，Python，PHP，Ruby，shell等各種語言開發(fā)經(jīng)驗(yàn)交流，各種框架使用，外包項(xiàng)目機(jī)會(huì)，學(xué)習(xí)、培訓(xùn)、跳槽等交流

QQ群：26931708

Hadoop源代碼研究群

興趣范圍包括：Hadoop源代碼解讀，改進(jìn)，優(yōu)化，分布式系統(tǒng)場景定制，與Hadoop有關(guān)的各種開源項(xiàng)目，總之就是玩轉(zhuǎn)Hadoop

QQ群：288410967?