趙建春
騰訊 技術運營通道主席
騰訊 社交網路運營部助理總經理
AIOps 白皮書核心編寫專家
我今天要講的主題，AIOps，是一個比較新的話題，其實從概念的提出到我們做，只有差不多一年的時間。一個新事物，有其發展的週期，在騰訊裡面我們做了比較多的探索，但是肯定還是有不足的地方，就像我們們看到的AI的發展也還有很多不足的地方。今天帶來一些案例跟大家分享，希望對大家有一些借鑑和參考的意義。
一、從一個 NLP 故事說起
首先我想從一個 NLP 小的故事來說起。
在二十世紀三四十年代，人們大量嘗試用機器的方式去理解自然語言，開始是用類似於左圖一樣的語法樹的基於規則的方式處理的，但後來逐漸地變化為以統計的方式去做。
到了二十世紀七十年代之後，基於規則的句法分析逐漸地走到了盡頭。
1972年的時候，自然語言處理領域大師賈里尼克加入了IBM。1974年左右，他在 IBM 提出了基於統計概念的語音識別概念，之後自然語音識別的效果就不斷被突破。
2005年穀歌基於統計方面的翻譯系統全面超過基於規則的翻譯系統，規則方法固守的最後一個語音識別的堡壘被拔掉了。
可以看到二十世紀七十年代前，基於規則的自然語言處理的學者和專家們，註定是失落的。
為什麼用這個故事來做引子，是因為我覺得我們們的運維環境，每年會有大量的開發人員加入，寫了大量的程式碼交給我們。
隨著業務量的增長，裝置會不斷增加，系統會越來越龐大，複雜度成指數級增長，而這些壓力全給了我們，還有如我們的監控 log 等資料也是非常的海量。
所以我覺得運維繫統和自然語言處理是有相似之處的，語言是非常複雜的，量級也是非常大的。
第二個，運維的經驗，本質上就是一組組的規則。在我們的運維環境裡，很多自動化的運維繫統，就是一組組規則的實現。規則有一個好處，就是易理解，但往往有場景遺漏。
規則肯定是一個人寫的，一個人面對海量的資料時，處理這些問題會顯得力不從心。AIOps 不是替代DevOps的，而是對DevOps的一個輔助和補充，是對裡面規則化部分進行AI化的改造的過程。
規則是我們的經驗，也是我們的負擔，就好比20世紀70年代前的那些專家，我們也需要進行一個轉型。
那什麼是AI呢?
AI就是從大量輸入中總結出準確預測的規律（模型）。我們通過x1x2x3這樣的大量的輸入，通過統計一些引數，abcdwb這樣的一些引數，讓我們在新的環境中來擬合的預測做一些數值、01、概率型的預測。包括強化的學習，也是通過另外一種形式獲取資料進行統計，通過每次的探測，你能知道這一次成功和受益是多少，是正收益或者是負收益，還是零收益。
其實我們只要有足夠的資料的量級，可以重複地去探測，並且獲得反饋。
易於接入 AI 的場景是特徵清晰、正負特徵易抽取，就是什麼是對的，什麼是錯的，我們可以比較好分類，有持續地反饋。
資料+演算法+訓練，可以訓練出一個模型，這和之前的規則是有差異的，可以認為是一種有記憶功能的模型。
但是如果要接觸AIOps會發現一個問題，就是我可能是一個小團隊，或者說我缺乏演算法專家，還有即使用了別人的演算法模型，我還希望瞭解這個演算法的原理。
最後一個是，提供演算法的一方和使用演算法的一方，都不願意提供資料，擔心資料洩露給對方，那雙方都有這樣一個擔憂，這是面臨的困難。
那對於以前的運維的環境裡面規則來講，其實你可以認為他是API，或者是一些編寫的邏輯處理，特點就是很少會變，因為是人編寫的，所以容易理解，專家總結了，和資料無關，他寫好就放在那裡，類似 if-else，case swich 等。
但是在AI，前面講了，其實是一組帶有記憶能力的API，這個記憶能力是從哪裡來的，就是對資料有依賴的，從資料裡面統計學習而來的，同時環境裡面不斷地在積累這個資料，可能不斷有新的案例進來。
所以這個模型時刻地在變，非常複雜，它可能是決策樹的決策路徑、迴歸引數或神經網路的網路結構及路徑權重。
因為它的各種的演算法，決策樹的神經網路的結構，以及他的權重，或者是迴歸引數相當複雜，這個不是人編寫出來的，所以就難理解。
二、從API到學件
所以 AIOps 我們可以來一個從API到學件的轉變，“學件”概念是南京大學的周志華老師提出來的，他是國內 AI 領域的泰斗級的人物，非常厲害，他提出學件是通過資料可以不斷地學習，隨著資料的不斷地加入會更好，另外它的演算法是公開的，你也可以瞭解它是怎麼實現的。
你也可以拿過來用，通過我的資料訓練好模型後給你，但沒有把資料交給你，把引數、網路結構這些東西交給你，並沒有把資料交給你，來解決資料安全問題。
你也可以用自己的資料重新去訓練改進適應自己環境的模型，所以是可演進的。演算法也是公開可瞭解的，拿來可以重用，來解決裡面的一些問題。
這是我們前一段時間和業界同仁一起編寫的AIOps白皮書的一個能力框架，我不展開來細講。
我們大體的想法就是說最底層就是各種機器的學習演算法，這個演算法和我們的實際環境場景結合起來，通過訓練一些單個的AIOps學件，單點場景也可以解決問題，之後把單點學件串聯起來組成 AIOps 的串聯應用場景，最終就可以形成一個智慧排程的模型，去解決我們的運維環節的成本、質量、效率等運維關心的問題。
AIOps 五級分類：
-
一級，嘗試應用
-
二級，單點應用
-
三級，串聯引用
-
第四是智慧解決大多數比較重要場景的串聯問題
-
第五級，既然都提到AI，我們還是希望可以有更大的夢想。我們是否可以有一個就是像黑客帝國裡的天網一樣的智慧運維大腦，能做到質量、成本、效率多目標優化。
比如在推薦場景裡，我即希望使用者規模越來越大，也希望活躍越來越高，同時希望他的消費水平越來越高，但是這三個目標是有衝突的，就像我們的成本和質量是有衝突的，但是我們希望它在多目標裡有一個比較好的均衡，最高階別的時候，連多目標都可以進行同步的優化去平衡。
總體來講，希望 AIOps 是DevOps的一個補充，然後從單點到串聯到智慧排程這樣一個過程，去解決運維裡成本、質量和效率的問題。
然後我們團隊跟高效運維社群做了一些實踐和理論方面的探索和嘗試，今天也希望通過這幾個單點的串聯質量效率這些緯度跟大家分享一下。
三、我們的實踐案例分享
1. 單點案例：成本 – 記憶體儲存智慧降冷
單點第一個是成本，就是記憶體儲存智慧降冷，因為我們是社交網路業務，使用者規模大，又有大量的訪問，這樣就導致團隊喜歡用記憶體型的KV儲存。
上線的時候，請求量可能很高，但是隨著時間的推移，他的資料量不斷地增長，訪問密度反而在下降，對我們的成本造成很大的壓力。
那大家會想到降冷，但是降冷之前大家都熟悉就是利用資料的最晚使用時間按規則處理，但是這個你想想其實只有一個指標，這個資料的最後使用時間，作為特徵去分析，其實遠遠不夠的。
我們對每一類資料做了非常多的特徵的抽樣提取，有幾十個特徵，如週期的熱度變化這些，就是如圖上這些，還有一些沒有寫出來的。
然後我們同學根據的經驗，因為他們之前手工處理過很多，就會有一些經驗，哪些資料條目是可以降冷的，把他標註之後，用邏輯迴歸和隨機森林，去學習和訓練，其實就是做分類，機器學習絕大部分都是做分類。
做一個分類之後，上面是 LR 和 邏輯的迴歸，下面是隨機森林。那在隨機森林，在 30 棵樹的時候效果最好，因為隨機森林本來就是一個bagging的方法，對穩定性效果有提高。
最終的效果就是說，我們把資料進行了一個下沉，把接近90%的資料，下沉到硬碟上，我們的訪問量並沒有下降，SSD資料沒有造成訪問壓力，可以看到下沉和下降是非常精準的。
而且這裡面的資料延遲和成功率幾乎沒有變化，其實之前的同事通過人工的設定做下沉的設定，其實效率是非常的低，這個模組提升了8到10倍的下沉的效率，這是第一個案例是成本的。
2. 單點案例：質量 — 統一監控去閾值
質量，大家可以看到統一監控去閾值是很有意義的一件事情。監控有兩種情況，一種是成功率的監控，它應該是一個直線，正常應該在 100% 左右，但它會往下掉。
第二個就是類似於一個累計性的曲線，或者 CPU 的曲線，這個曲線監控其實是非常的千變萬化的。
之前我們可能是通過設定閾值的方法，最大值最小值，閾值設定這樣的方式，去設定告警。
這個曲線一直在變化，最大值和最小值也一直在變化，然後他的形式也非常的多變，也很難去設定這樣的東西。
那我們做了兩種的方式第一個是成功率的方式，我們使用了3sigma方式，來自於工業界，是來控制產品的次品率的，如果是3sigma是99.7%是正品，其實用這個方式我們統計出來的告警裡面，超過正常值範圍裡面的多少多我們認為是多少個次品，把它找出來。
第二步用孤立森林，就是長的相似的一類的東西，是比較難分類的，要通過很多步才可以去到葉子節點上，所以看到這個Gap，這一塊就是說在比較淺的葉子的節點，就是異常的節點。
我們通過第一步統計的方式，第二步的無監督方式找到一場。目前最後一步我們還是加了一些規則，讓告警更可靠。這個規則其實就是看到我在什麼時候告警和恢復，這樣一個邏輯既然是一個規則，在未來我們會進一步做一個 AI 化的改造。
那對於這個曲線型的監控，目前我們就是因為曲線不是屬於正態分佈的，一個曲線是一個曲線，所以極差很大。我們把它做了一個分段的3sigma，就是一個小時一個段，過去7天進行一個取樣。
還有曲線我們可以用多項式去擬合這個曲線，我們用3sigma、統計方法、多項式擬合幾種方法作為第一步，就是相當於推薦系統裡的多路召回。
第二步依然就是孤立森林，和前面講的原理一致。
第三步就是有監督的人工標註，就是圖上畫圈的有些告警有一些不應該告警的標註，標註訓練集後去訓練自動地分類。
為了獲得更多的樣本庫，同事們用這個叫相關係數的協方差演算法，尋找更多的樣本庫。大家可以關注一下，就是說去找一些相似的曲線，對訓練不好的模型，就再進行打包去訓練。
總的方式，通過三級的過濾找到異常的告警。
我們有十萬多臺裝置，超過120萬個監控檢視，其實之前我們70%以上都沒有設告警，因為很難每個都設一個最高值最低值，所以說目前就把這些模組都納入到這個監控裡面去，百分之百覆蓋，這是一個監控區域值，去設定的一個案例。
3. 串聯應用案例：質量 — ROOT智慧根源異常分析
第三個案例，就是質量的串聯案例，異常根因分析，其實我們的同學其實在很多的場合分享過。
我們對我們的系統做了很多這樣的訪問關係統計，生成一個業務訪問關係檢視，就是業務的訪問關係是什麼樣子的，最後就會畫出這樣一個圖來，就像蜘蛛網一樣，這只是其中的一個部分，但是故障發生之後，到底哪一個是根源的問題。
根因分析最開始的做法，是通過先降維關係的方式，右圖左邊這一列全是同一個模組，由這個模組產生的每一條路徑，我們都列出來，就是右邊多條路徑，這個路徑模組裡面，把告警出現疊加在模組上，然後設定一個人為定義的面積演算法，從面積的大小，就判定哪個模組是異常的根源，雖然是基於規則的，但之前效果還不錯，可以幫助我們找到可能是根源的 TOPN 告警，但現在我們又把它做了一些基於AI演算法的更新。
中間這一排，就是前面介紹的根因分析的主邏輯。在告警疊加前面，訪問相關的模組才是導致根源告警的模組，所以我們先通過訪問關係緊密度進行社團Group劃分，把一些互相訪問緊密的模組，做了一個聚類。
然後告警嚴重程度接近的，互相導致告警的可能性也更高一些，再用DBSCAN類的密度聚類演算法，進行聚類。最後再用頻繁項集和相關係數等去找一些重複出現的，就是相關性的，貢獻度和支援度這樣的一些方式去找這個原因。
另外我們在做交流的時候，也有人給我們提出一個建議，就是用貝葉斯演算法來找TOP根因的概率，因為這個是一個概率性的統計，我們目前也在進行實驗和測試。
4. 智慧排程案例：效率 — 織雲全自動擴容
再來看一個智慧的排程的案例，我之前想智慧排程是一個很巨集大的目標，並不是只是有點像這樣的東西是一個小的改進，那我們智慧的全自控的擴容流程。
之前我們在很多的場合講過智慧的工作的流程，他實際上把一個業務模組上需要的資源全部登記進去，之後通過申請裝置、獲取的資源，釋出部署、釋出自檢、業務測試、灰度上線這樣的 6 大步，實際上有二十多小步，我們會組合，組合成不同的流程，那我們看一下這個流程。
（視訊播放時對視訊內容的簡要解釋）一個模組的自動擴容，先是新增一些資源，其實就是上線一個新的業務，但是正常情況下他是自動執行的。會有一些業務包，會有一些基礎包，還有一些許可權，這個許可權也是基礎化的東西。
我們監控看到壓力不斷地增長，CPU增長到75%以上，隨著增長，我們發現這個系統壓力超標了，系統自動啟動了擴容，這個是加快的了好幾倍的樣子。
這樣一個過程，就是剛才列了20多步的擴容的步驟，就自動地在執行，執行之後企業微信提示對這個模組進行快速上線，然後監控到他有問題，就是快速地上線。
上了兩臺新的裝置，然後這兩臺新的裝置，負載在增加，老的流量在逐漸地下降，最後達到一個平衡。
這就是我們騰訊織雲的全自動擴容，目前其中的容量預測及很多監控都已經經過了一定程度的AI化的改造。
我還想重點講下其中有一個叫平衡木的模組。為什麼要平衡木，因為監控這一塊也講過了，平衡木對於一個模組來講，一個模組幾百臺上千臺的裝置都有，雖然對它設的同樣的壓力權重，這是真實環境裡的資料，就是上下差異非常大。
然後我們通過平衡木這樣的一個調整，就可以把上面這樣的負載曲線，基本上可以縮成一條線，第二個的曲線容量就變成的40%，也就是說你通過這樣的一個調整，讓你的支撐能力，增長了 22%，那它是怎麼做的？
實際上我們有一個機器學習，就是希望我們的模組裡面，每臺單機的負載，儘可能的一致，設定一個loss function，我們用梯度下降的方式，找到這個lossfunction裡引數w1～wn的設定。之後通過幾輪調整，使得所有裝置的負載趨於一致。
5. 更多單點或串聯應用
還有更多的單點和串聯應用，其中一些由於之前在GOPS上海分享過，這裡只是簡述一下，做為一些案例參考。
第一就是多維下鑽智慧分析，因為一個APP上線之後，你可能會有播放平臺，運營商有域名，每個裡面有幾百個裝置，運營商裡面有多個運營商，一旦出現一個問題，有可能是魔方里面的塊出現問題，很難定位。
比如我們找到前後資料差異化很大，但訪問量很小，那它就不是核心的，核心的就是差異性越大，貢獻度越大的那些異常，就可能是出問題的那個。
大家都知道啤酒尿布的案例，那頻繁項集演算法，就是A告警出現之後，B告警肯定會出現，同時 AB 出現的概率還會超過一定的比例，我們就可以找到這樣的一些東西，對他進行合併的告警。
第三個就是我們一直有一個智慧體檢變更報告的東西，就像之前谷歌的講師也講到，谷歌通過各種的監控方式發現這次變更之後，是否出現故障。比如可能流量增高，或者有異常告警。
我們的變更檢測報告，會自動監測變更後模組的各項指標變化，來輔助工程師判斷，這次變更是否正常，輸出分 2 類，正常情況不輸出可以忽略:
一類是變更後導致了資料的大幅波動，但可能不是異常，如流量大幅增長；
一類是變更後可能出現了異常，如產生了大量coredump，需要去處理。如何處理也是一個二分類的問題，我們也會在未來改造。
上一次也講到我們智慧客服的問題，利用NLP技術，可以做資訊檢索類、操作執行類的智慧客服工具機器人。
四、思考和展望
做一點簡單的思考和展望，AIOps才剛剛起步，但是做的時候，可以考慮把它做成類似公共的元件這樣的形式，就是學件，不同的是它們帶了一種學習的結果在裡面。
有些場景是公司的內部的場景，可以在內部變成一個學件來用。但是對於一些共性的東西，比如說監控，各個公司的監控場景是一樣的，如果我們把它定義成標準的上報的格式，標準的時間區間，訓練好了 AIOps 的模型，大家認可了效果，就可以一起來使用。
“學件”這個詞，周志華老師也在多個場合去講過。通過編寫類似這些共識的上報格式，命名規範等，會讓公共的AIOps元件變得更加的共享、共識，這個也是我們未來希望更多放到標準裡面東西。
這個也是AIOps的標準委員會存在的一個意義。
下面這個圖是我們織雲的Metis平臺，我們希望先在內部形成更多的學件庫，再去解決一些串聯的問題，剛才也舉了一些例子，也希望在未來的幾個月，或者一段時間裡，開放出來跟大家一起學習，共同地探討和改進，可能我的演講就到這裡了。
最後用一句很有名的話做個總結：一般情況下，人們常常會高估一個新技術在一兩年內的影響而低估其在未來五到十年的影響。
而 AIOps 就是這麼一個技術，作為DevOps的輔助和改進，相信它一定會讓IT運維變的更簡單從容，真正地成為運維同學，運維線的一個助手工具和智慧化的大腦。謝謝大家。
注：本文根據趙建春在 DOIS 2018 · 北京站 主會場分享整理而成。轉載自：高效運維。