節省3500萬的背後，運維如何兼顧成本與效率？
講師介紹
今天我們要分享的是近幾年我們在AIOps（智慧運維）領域的探索和實踐經驗。
下面是本次分享的摘要：
-
背景介紹
-
360對 AIOps 的思考
-
AIOps 的實踐方案
-
經驗和總結
一、背景介紹
隨著網際網路的軟硬體呈現爆發性的增長，新的架構層出不窮，運維人員需要做到7*24小時的職守來保證系統的可靠性和穩定性。但這明顯是不可能的。
那麼面對這種空前的壓力，有沒有一種“機器大腦”能夠減少甚至代替運維人員去做一些事情，極大地減少他們的工作量，提高運維的效率？又該如何得到這種“機器大腦”呢？
很多運維場景都可以總結成一些規則化的東西，可以經過提煉總結生成人工經驗庫。除了人工經驗以外，是否可以通過AI演算法對歷史資料進行分析，得到一些由機器生成的規則？
答案當然是可以的。如果能將AI演算法+人工經驗應用到Ops中，代替一部分的人工決策，這樣將推動運維從普通的自動化階段到智慧化階段邁進。
從今年開始，很多公司在AIOps領域進行了一些嘗試。我們公司的AIOps也經歷了從最開始的標準化到後來的精細化、資料化運維的前期鋪墊，在2018年，AIOps專案組正式組建，經過近一年的發展，已經在很多單點應用方面取得比較好的效果，並爭取在今年年底，能夠實現一些場景的閉環。
二、360對AIOps的思考
大家熟悉的AIOps場景有很多，諸如異常檢測、根因分析、故障自愈、容量預測等方面。根據平臺的實際場景和業界AIOps的實踐經驗，我們將AIOps劃分為三個場景：成本、效率和穩定性。
針對成本來說，利用AI演算法節省資源、智慧排程、提高資源利用率的手段來節省資源；針對效率方面來說，利用AI演算法主動發現問題、分析問題和解決問題，真正節省人力，提高效率。
那如何開展AIOps呢？我們認為AIOps需要開展需要下面三種人員：運維人員、運維開發、機器學習工程師。三者缺一不可，否則專案就會半途而廢。
上面介紹了我們對AIOps的理解，下面就是純乾貨出場了，我們將分兩個大方向五個具體專案來介紹AIOps最佳實踐經驗。
三、AIOps實踐方案
1、基礎
資料積累
所謂“巧婦難為無米之炊”，在啟動AIOps之前，需要準備很多資料，包括機器維度的基礎資料、網路資料、日誌資料、甚至程序資料等。我們有專門的大資料工程師歷時兩年多對資料進行收集，為後面的資料分析、機器學習模型打下堅實的基礎。
下面是我們前後收集的資料總結：
容量預估
有了歷史資料，我們就可以對資料進行一些分析。
首先介紹一種場景——容量預估。對重要監控項的預測，能夠使我們及時瞭解指標的走勢，為後面的決策提供了科學的依據。
監控項的樣本就是時間序列，通過分析監控項的序列，得到未來一段時間的預測值。根據波動劇烈程度，監控項可以分為波動不太劇烈和劇烈的；根據週期性，可以分為具有周期性和不具有周期性等等，當然還有很多劃分的標準。可見，不同時間的序列，我們需要使用不同的模型去預測。
在對時間序列進行預測的過程中，我們先後使用了下面幾種模型，從中總結出了一些經驗：
很多時間序列具有周期性，我們還自研了一個週期性檢測的模型，能夠比較好的判斷一個序列是否具有周期性。在週期性檢測的基礎上，進一步跟進序列的週期性特徵，來預測不同的時間序列。
對於預測模型，前人已經總結了很多種，我們在專案中使用了下面一些模型，你可以根據時間開銷和準確度來選擇自己的模型。以上所有的預測方法將在近期進行開源，還希望大家持續關注：
主機分類
在實際的專案中，我們經常會遇到分類任務，比如根據主機監控項的特徵，需要用模型判斷出該機器是否為空閒機器；再比如，我們會根據監控項的特徵，來判斷該機器屬於的型別（CPU、磁碟、記憶體密集型）。
機器學習中有很多分類演算法，比如SVM、決策樹、分類樹等都可以完成分類任務。我們只需要做一些預處理以及特徵工程等方面的工作後，就可以使用Python中現成的分類模型，在此就不詳細介紹。
2、專案
有了容量預估和主機分類的基礎模組後，我們在成本方面先後做了資源回收、智慧排程系統兩個專案，並取得了比較好的效果。
資源回收
資源回收，就是及時發現比較空閒的機器，通知業務進行回收，以達到提高資源利用率的目的。
我們的資源回收系統分為三塊：容量預估、主機分類以及通知模組。容量預估模型是對五個比較重要的指標（CPU使用率、記憶體使用率、網絡卡流量、磁碟使用率以及狀態連線數）進行預測以及定量分析後，生成了五個特徵。接下來使用分類器來對五個特徵進行分類後，得到空閒的機器列表，最後將空閒機器通知給相應的業務負責人。
在AIOps中，經常用遇到負樣本不足的問題，一個原因是異常的場景比較少，另一個原因是使用者標註的成本比較高。
在主機分類的過程中，我們使用了兩種手段來生成樣本，一種是人工標註，一種是使用者標註，解決了負樣本不足的問題。下面這幅圖是我們在Q2季度時候資源回收取得的效果，目前看還不錯：
SQL/">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