節省3500萬的背后，運維如何兼顧成本與效率？

一、背景介紹

隨著互聯網的軟硬件呈現爆發性的增長，新的架構層出不窮，運維人員需要做到7*24小時的職守來保證系統的可靠性和穩定性。但這明顯是不可能的。

那么面對這種空前的壓力，有沒有一種“機器大腦”能夠減少甚至代替運維人員去做一些事情，極大地減少他們的工作量，提高運維的效率？又該如何得到這種“機器大腦”呢？

很多運維場景都可以總結成一些規則化的東西，可以經過提煉總結生成人工經驗庫。除了人工經驗以外，是否可以通過AI算法對歷史數據進行分析，得到一些由機器生成的規則？

答案當然是可以的。如果能將AI算法+人工經驗應用到Ops中，代替一部分的人工決策，這樣將推動運維從普通的自動化階段到智能化階段邁進。

從今年開始，很多公司在AIOps領域進行了一些嘗試。我們公司的AIOps也經歷了從最開始的標準化到后來的精細化、數據化運維的前期鋪墊，在2018年，AIOps項目組正式組建，經過近一年的發展，已經在很多單點應用方面取得比較好的效果，并爭取在今年年底，能夠實現一些場景的閉環。

二、360對AIOps的思考

大家熟悉的AIOps場景有很多，諸如異常檢測、根因分析、故障自愈、容量預測等方面。根據平臺的實際場景和業界AIOps的實踐經驗，我們將AIOps劃分為三個場景：成本、效率和穩定性。

針對成本來說，利用AI算法節省資源、智能調度、提高資源利用率的手段來節省資源；針對效率方面來說，利用AI算法主動發現問題、分析問題和解決問題，真正節省人力，提高效率。

那如何開展AIOps呢？我們認為AIOps需要開展需要下面三種人員：運維人員、運維開發、機器學習工程師。三者缺一不可，否則項目就會半途而廢。

上面介紹了我們對AIOps的理解，下面就是純干貨出場了，我們將分兩個大方向五個具體項目來介紹AIOps最佳實踐經驗。

三、AIOps實踐方案

數據積累

所謂“巧婦難為無米之炊”，在啟動AIOps之前，需要準備很多數據，包括機器維度的基礎數據、網絡數據、日志數據、甚至進程數據等。我們有專門的大數據工程師歷時兩年多對數據進行收集，為后面的數據分析、機器學習模型打下堅實的基礎。

下面是我們前后收集的數據總結：

容量預估

有了歷史數據，我們就可以對數據進行一些分析。

首先介紹一種場景——容量預估。對重要監控項的預測，能夠使我們及時了解指標的走勢，為后面的決策提供了科學的依據。

監控項的樣本就是時間序列，通過分析監控項的序列，得到未來一段時間的預測值。根據波動劇烈程度，監控項可以分為波動不太劇烈和劇烈的；根據周期性，可以分為具有周期性和不具有周期性等等，當然還有很多劃分的標準?？梢?，不同時間的序列，我們需要使用不同的模型去預測。

在對時間序列進行預測的過程中，我們先后使用了下面幾種模型，從中總結出了一些經驗：

很多時間序列具有周期性，我們還自研了一個周期性檢測的模型，能夠比較好的判斷一個序列是否具有周期性。在周期性檢測的基礎上，進一步跟進序列的周期性特征，來預測不同的時間序列。

對于預測模型，前人已經總結了很多種，我們在項目中使用了下面一些模型，你可以根據時間開銷和準確度來選擇自己的模型。以上所有的預測方法將在近期進行開源，還希望大家持續關注：

在實際的項目中，我們經常會遇到分類任務，比如根據主機監控項的特征，需要用模型判斷出該機器是否為空閑機器；再比如，我們會根據監控項的特征，來判斷該機器屬于的類型（CPU、磁盤、內存密集型）。

機器學習中有很多分類算法，比如SVM、決策樹、分類樹等都可以完成分類任務。我們只需要做一些預處理以及特征工程等方面的工作后，就可以使用Python中現成的分類模型，在此就不詳細介紹。

有了容量預估和主機分類的基礎模塊后，我們在成本方面先后做了資源回收、智能調度系統兩個項目，并取得了比較好的效果。

資源回收

資源回收，就是及時發現比較空閑的機器，通知業務進行回收，以達到提高資源利用率的目的。

我們的資源回收系統分為三塊：容量預估、主機分類以及通知模塊。容量預估模型是對五個比較重要的指標（CPU使用率、內存使用率、網卡流量、磁盤使用率以及狀態連接數）進行預測以及定量分析后，生成了五個特征。接下來使用分類器來對五個特征進行分類后，得到空閑的機器列表，最后將空閑機器通知給相應的業務負責人。

在AIOps中，經常用遇到負樣本不足的問題，一個原因是異常的場景比較少，另一個原因是用戶標注的成本比較高。

在主機分類的過程中，我們使用了兩種手段來生成樣本，一種是人工標注，一種是用戶標注，解決了負樣本不足的問題。下面這幅圖是我們在Q2季度時候資源回收取得的效果，目前看還不錯：

MySQL智能調度系統

我們線上的MySQL機器存在嚴重的浪費問題，例如下面的場景：可以看到只要有一個指標是高負載的情況，這個機器將不可用。細想一下，如果一臺機器內存比較高，但是并不代表這臺機器不可用，我們可以將CPU使用率較高但內存使用率較低的實例調度到這臺機器上，達到充分利用資源的目的。

為了將不同類型的機器和不同類型的實例進行合理搭配，需要將實例和機器進行分類。在該項目中，實例分類采用了BP神經網絡，其中輸入是7個重要的實例指標，輸出是4個類別（低消耗、計算型、存儲型、綜合型）。

機器分類采用決策樹模型，輸入是5個機器指標，輸出和實例的輸出類型一樣。樣本全部采用人工標注的方式，生成了1000左右的樣本。

有了分類好的機器和實例以后，就需要進行調度。在調度過程中，考慮了多種因素：

• 盡量保證遷移次數少

• 盡量少的避免切主

• 保證主庫和大容量端口的穩定性

• 控制每臺機器上主庫的個數（不超過5個）和實例總個數

• 同一端口的實例不能出現在同一機器上

• 不調度黑名單機器

我們按照上面的原則對一個機房的實例進行測試，端口遷移的次數為45次，可能將30臺高負載機器中的14臺變為可用狀態。

成本一直是我們今年努力的一個大方向。除了上面介紹的兩個項目，我們還使用了分時計算的手段來進一步節省資源。今年的目標是能夠為公司節省五千萬的成本，目前已經節省三千五百萬，還沒有達到目標，需要繼續努力。

上面介紹的是成本方面的工作，下面介紹效率方面的項目。

異常檢測

異常檢測是AIOps最常見的場景，算法也有很多，業界比較流行的比如普通的統計學習方法——3σ原則，它利用檢測點偏移量來檢測出異常。比如普通的回歸方法，用曲線擬合方法來檢測新的節點和擬合曲線的偏離程度，甚至有人將CNN和RNN模型應用到異常點的檢測。

我們公司使用LVS比較多，為了應對流量突增和突減的情況，需要一個異常檢測算法。

通過對LVS流量的時間序列圖的分析，發現有的曲線有周期性，有的沒有；有的毛刺比較多，有的比較平穩，所以需要有一個普適檢測算法，能夠處理各種復雜的場景。

現實場景中，負樣本比較少，我們采用了無監督模型，除此之外，還借鑒投票機制來解決單純的方法有時候具有偏差這樣的問題。

在該項目中，我們采用了五種以上的檢測算法，有統計學中同比環比的情況、曲線擬合算法以及周志華老師的隔離森林模型。通過這些模型來一起對一個時間序列進行檢測。如果這些算法中有超過一半的算法認為該檢測點為異常點，我們就認為這個點為異常點。

跟蹤了將近半年線上LVS流量數據，檢測算法的準確率高于95%，效果還是不錯的。

報警收斂

為了保證系統的可靠性，運維人員經常設置很多監控項來及時了解系統的狀況。如果某個監控項超過設置的閾值，則系統中某些指標出現問題，需要運維人員進行處理。這樣不經過過濾，直接將所有的報警全部發出來的方式，很容易增加運維人員的壓力，而且隨著報警數的增多，也很容易造成他們的疲勞感，并不能達到好的報警效果。

我們對歷史報警進行分析，發現其中有很多規律。如果我們利用算法分析出這些報警項之間的關系，再加上人工經驗，將很大程度減少報警的數目。

人工經驗就不用說了，下面介紹一下如何通過算法去分析出報警項之間的潛在關系。

我們采用機器學習中關聯分析常用的算法Apriori來分析歷史報警，該模型利用頻繁項集分析出A→B這種關系。將這種規則應用到報警中，如果A報警發出，則B報警就不需要發出，這樣就能夠成倍減少報警次數。下圖是我們對過去30天的報警數據分析，得到20+的關聯規則：

我們線上維護著一個規則庫，這個規則庫來源于兩部分：算法分析規則、人工總結規則。在利用這些規則同時，我們還結合了業務的評級來對業務報警進行一定程度的合并處理。跟蹤了半年的報警，采用這個規則庫能夠減少60%-80%的報警。

報警事件的根因分析

上節介紹了減少報警的方式，但是現實中的報警是不可避免的。在發生報警以后，如何快速定位具體問題就成為關鍵的環節。那如何通過模型去定位問題呢？

通過統計分析，我們線上發生最多的是這六大類的報警，這些報警分別是：

• 主機存活(host.alive)；

• 磁盤空間使用率(df.bytes.used.percent)；

• 磁盤分區只讀(sys.disk.rw)；

• CPU使用率(cpu.idle)；

• 內存使用率(mem.swapused.percent)；

• 磁盤io操作百分比(disk.io.util)。

在發生報警后，運維人員需要登陸到機器或者監控系統去看出現問題的時間段內是哪些監控項或者進程出現問題。這樣繁重且具有很強規則性的場景特別適合模型去搞定。本節將介紹一種模型，能夠幫助運維人員縮小報警排查范圍，快速定位到問題。

該項目中要分析兩個維度數據：

• 一個是事件維度，關注的是六大類報警事件；

• 一個是指標維度，關注機器維度的監控項（大約有200左右個監控項）。

那如何在事件發生后，找到跟它相關的指標呢？實現的方法如下：

1）針對每個事件，使用在2014年SIGKDD會議上發表的論文《Correlating Events with Time Series for Incident Diagnosis》中提到的方法，看哪些指標跟這個事件發生有關系。這樣的做目的是對指標進行初篩，達到降維的目的。

2）針對第一步選出來的指標，求出這些指標的信息增益比，選擇前k個（我們取得值是5）特征作為最后的影響指標；

3）最后使用xgboost對影響指標進行分類，驗證效果。

下圖是我們對這六大類報警的分析結果，取報警事件最相關的Top5指標，取得比較好的準確率：

比如下一次發生“host.alive”報警，就有很大概率是 'cpu.idle' 、 'net.if.total.bits.sum' 、 'mem.memused.percent' 、 'mem.swapused.percent' 和 'ss.closed' 導致的，這樣就能夠減少排查問題的時間。

四、經驗和總結

通過將近一年的努力，我們已經在一些單點的應用方面取得比較好的效果。下面是接下來要做的工作前瞻：

• 報警進程級別的定位；

• 開源組件（容量預估、異常檢測以及報警事件的關聯分析）；

• 運維聊天機器人。

接下來的工作中，我們將結合一些具體的場景將上面介紹的一些單點串聯起來，真正能夠從發現異常問題、分析問題到最后的解決問題，形成真正意義上的閉環。

以上就是我此次分享的全部內容，感謝大家的參與，謝謝！

直播回放

https://m.qlchat.com/topic/details?topicId=2000002350036659&tracePage=liveCenter