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

作者簡介

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

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

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

一、AIOps的概念

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

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

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

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

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

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

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

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

?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

AB之間存在異常的某段時間序列

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

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

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

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

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

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

某段包含異常的時間序列檢測，紅色豎直虛線位置為檢測到的異常點?

周期性檢測：

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

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

2、故障智能診斷?

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

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

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

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

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

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

所有潛在故障因子展示

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

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

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

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

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

3、資源利用率提升

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

應(yīng)用畫像

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

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

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

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

Online/Offline混部

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

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

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

智能彈性擴(kuò)縮容

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

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

三、結(jié)束語

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

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

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

QQ群：26931708

Hadoop源代碼研究群

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

QQ群：288410967?