AIOps 在騰訊的探索和實踐

歡迎你們前往騰訊雲+社區，獲取更多騰訊海量技術實踐乾貨哦~

本文由LemonLu發表於雲+社區專欄

趙建春 騰訊 技術運營通道主席 騰訊 社交網絡運營部助理總經理 AIOps 白皮書核心編寫專家

我今天要講的主題，AIOps，是一個比較新的話題，其實從概念的提出到咱們作，只有差很少一年的時間。一個新事物，有其發展的週期，在騰訊裏面咱們作了比較多的探索，可是確定仍是有不足的地方，就像我們看到的 AI 的發展也還有不少不足的地方。今天帶來一些案例跟你們分享，但願對你們有一些借鑑和參考的意義。

1 從一個 NLP 故事提及

首先我想從一個 NLP 小的故事來講起。

在二十世紀三四十年代，人們大量嘗試用機器的方式去理解天然語言，開始是用相似於左圖同樣的語法樹的基於規則的方式處理的，但後來逐漸地變化爲以統計的方式去作。

到了二十世紀七十年代以後，基於規則的句法分析逐漸地走到了盡頭。

1972年的時候，天然語言處理領域大師賈里尼克加入了IBM。1974年左右，他在 IBM 提出了基於統計概念的語音識別概念，以後天然語音識別的效果就不斷被突破。

2005年穀歌基於統計方面的翻譯系統全面超過基於規則的翻譯系統，規則方法固守的最後一個語音識別的堡壘被拔掉了。

能夠看到二十世紀七十年代前，基於規則的天然語言處理的學者和專家們，註定是失落的。

爲何用這個故事來作引子，是由於我以爲我們的運維環境，每一年會有大量的開發人員加入，寫了大量的代碼交給咱們。

隨着業務量的增加，設備會不斷增長，系統會愈來愈龐大，複雜度成指數級增加，而這些壓力全給了咱們，還有如咱們的監控 log 等數據也是很是的海量。

因此我以爲運維繫統和天然語言處理是有類似之處的，語言是很是複雜的，量級也是很是大的。

第二個，運維的經驗，本質上就是一組組的規則。在咱們的運維環境裏，不少自動化的運維繫統，就是一組組規則的實現。規則有一個好處，就是易理解，但每每有場景遺漏。

規則確定是一我的寫的，一我的面對海量的數據時，處理這些問題會顯得力不從心。AIOps 不是替代 DevOps 的，而是對 DevOps 的一個輔助和補充，是對裏面規則化部分進行 AI 化的改造的過程。

規則是咱們的經驗，也是咱們的負擔，就比如20世紀70年代前的那些專家，咱們也須要進行一個轉型。

那什麼是AI呢?

AI就是從大量輸入中總結出準確預測的規律（模型）。咱們經過x1 x2 x3這樣的大量的輸入，經過統計一些參數，abcdwb這樣的一些參數，讓咱們在新的環境中來擬合的預測作一些數值、0一、機率型的預測。包括強化的學習，也是經過另一種形式獲取數據進行統計，經過每次的探測，你能知道這一次成功和受益是多少，是正收益或者是負收益，仍是零收益。

其實咱們只要有足夠的數據的量級，能夠重複地去探測，而且得到反饋。

易於接入 AI 的場景是特徵清晰、正負特徵易抽取，就是什麼是對的，什麼是錯的，咱們能夠比較好分類，有持續地反饋。

數據+算法+訓練，能夠訓練出一個模型，這和以前的規則是有差別的，能夠認爲是一種有記憶功能的模型。

可是若是要接觸AIOps會發現一個問題，就是我多是一個小團隊，或者說我缺少算法專家，還有即便用了別人的算法模型，我還但願瞭解這個算法的原理。

最後一個是，提供算法的一方和使用算法的一方，都不肯意提供數據，擔憂數據泄露給對方，那雙方都有這樣一個擔心，這是面臨的困難。

那對於之前的運維的環境裏面規則來說，其實你能夠認爲他是API，或者是一些編寫的邏輯處理，特色就是不多會變，由於是人編寫的，因此容易理解，專家總結了，和數據無關，他寫好就放在那裏，相似 if-else，case swich 等。

可是 在AI，前面講了，實際上是一組帶有記憶能力的 API，這個記憶能力是從哪裏來的，就是對數據有依賴的，從數據裏面統計學習而來的，同時環境裏面不斷地在積累這個數據，可能不斷有新的案例進來。

因此這個模型時刻地在變，很是複雜，它多是決策樹的決策路徑、迴歸參數或神經網絡的網絡結構及路徑權重。

由於它的各類的算法，決策樹的神經網絡的結構，以及他的權重，或者是迴歸參數至關複雜，這個不是人編寫出來的，因此就難理解。

2 從API到學件

因此 AIOps 咱們能夠來一個從 API 到學件的轉變，「學件」 概念是南京大學的周志華老師提出來的，他是國內 AI 領域的泰斗級的人物，很是厲害，他提出學件是經過數據能夠不斷地學習，隨着數據的不斷地加入會更好，另外它的算法是公開的，你也能夠了解它是怎麼實現的。

你也能夠拿過來用，經過個人數據訓練好模型後給你，但沒有把數據交給你，把參數、網絡結構這些東西交給你，並無把數據交給你，來解決數據安全問題。

你也能夠用本身的數據從新去訓練改進適應本身環境的模型，因此是可演進的。算法也是公開可瞭解的，拿來能夠重用，來解決裏面的一些問題。

這是咱們前一段時間和業界同仁一塊兒編寫的 AIOps 白皮書的一個能力框架，我不展開來細講。

咱們大致的想法就是說最底層就是各類機器的學習算法，這個算法和咱們的實際環境場景結合起來，經過訓練一些單個的 AIOps 學件，單點場景也能夠解決問題，以後把單點學件串聯起來組成 AIOps 的串聯應用場景，最終就能夠造成一個智能調度的模型，去解決咱們的運維環節的成本、質量、效率等運維關心的問題。

AIOps 五級分類：

• 一級，嘗試應用
• 二級，單點應用
• 三級，串聯引用
• 第四是智能解決大多數比較重要場景的串聯問題
• 第五級，既然都提到AI，咱們仍是但願能夠有更大的夢想。咱們是否能夠有一個就是像黑客帝國裏的天網同樣的智能運維大腦，能作到質量、成本、效率多目標優化。 好比在推薦場景裏，我即但願用戶規模愈來愈大，也但願活躍愈來愈高，同時但願他的消費水平愈來愈高，可是這三個目標是有衝突的，就像咱們的成本和質量是有衝突的，可是咱們但願它在多目標裏有一個比較好的均衡，最高級別的時候，連多目標均可以進行同步的優化去平衡。

整體來說，但願 AIOps 是 DevOps 的一個補充，而後從單點到串聯到智能調度這樣一個過程，去解決運維裏成本、質量和效率的問題。

而後咱們團隊跟高效運維社區作了一些實踐和理論方面的探索和嘗試，今天也但願經過這幾個單點的串聯質量效率這些緯度跟你們分享一下。

3 咱們的實踐案例分享

1. 單點案例：成本 - 內存存儲智能降冷

單點第一個是成本，就是內存存儲智能降冷，由於咱們是社交網絡業務，用戶規模大，又有大量的訪問，這樣就致使團隊喜歡用內存型的KV存儲。

上線的時候，請求量可能很高，可是隨着時間的推移，他的數據量不斷地增加，訪問密度反而在降低，對咱們的成本形成很大的壓力。

那你們會想到降冷，可是降冷以前你們都熟悉就是利用數據的最晚使用時間按規則處理，可是這個你想一想其實只有一個指標，這個數據的最後使用時間，做爲特徵去分析，其實遠遠不夠的。

咱們對每一類數據作了很是多的特徵的抽樣提取，有幾十個特徵，如週期的熱度變化這些，就是如圖上這些，還有一些沒有寫出來的。

而後咱們同窗根據的經驗，由於他們以前手工處理過不少，就會有一些經驗，哪些數據條目是能夠降冷的，把他標註以後，用邏輯迴歸和隨機森林，去學習和訓練，其實就是作分類，機器學習絕大部分都是作分類。

作一個分類以後，上面是 LR 和 邏輯的迴歸，下面是隨機森林。那在隨機森林，在 30 棵樹的時候效果最好，由於隨機森林原本就是一個 bagging 的方法，對穩定性效果有提升。

最終的效果就是說，咱們把數據進行了一個下沉，把接近 90% 的數據，下沉到硬盤上，咱們的訪問量並無降低，SS D數據沒有形成訪問壓力，能夠看到下沉和降低是很是精準的。

並且這裏面的數據延遲和成功率幾乎沒有變化，其實以前的同事經過人工的設置作下沉的設置，其實效率是很是的低，這個模塊提高了 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，咱們用梯度降低的方式，找到這個 loss function 裏參數w1～wn的設置。以後經過幾輪調整，使得全部設備的負載趨於一致。

5. 更多單點或串聯應用

還有更多的單點和串聯應用，其中一些因爲以前在 GOPS 上海分享過，這裏只是簡述一下，作爲一些案例參考。

第一就是多維下鑽智能分析，由於一個 APP 上線以後，你可能會有播放平臺，運營商有域名，每一個裏面有幾百個設備，運營商裏面有多個運營商，一旦出現一個問題，有多是魔方里面的塊出現問題，很難定位。

好比咱們找到先後數據差別化很大，但訪問量很小，那它就不是核心的，核心的就是差別性越大，貢獻度越大的那些異常，就多是出問題的那個。

你們都知道啤酒尿布的案例，那頻繁項集算法，就是 A 告警出現以後，B 告警確定會出現，同時 AB 出現的機率還會超過必定的比例，咱們就能夠找到這樣的一些東西，對他進行合併的告警。

第三個就是咱們一直有一個智能體檢變動報告的東西，就像以前谷歌的講師也講到，谷歌經過各類的監控方式發現此次變動以後，是否出現故障。好比可能流量增高，或者有異常告警。

咱們的變動檢測報告，會自動監測變動後模塊的各項指標變化，來輔助工程師判斷，此次變動是否正常，輸出分 2 類，正常狀況不輸出能夠忽略:

一類是變動後致使了數據的大幅波動，但可能不是異常，如流量大幅增加；

一類是變動後可能出現了異常，如產生了大量 coredump，須要去處理。如何處理也是一個二分類的問題，咱們也會在將來改造。

上一次也講到咱們智能客服的問題，利用 NLP 技術，能夠作信息檢索類、操做執行類的智能客服工具機器人。

4 思考和展望

作一點簡單的思考和展望， AIOps 纔剛剛起步，可是作的時候，能夠考慮把它作成相似公共的組件這樣的形式，就是學件，不一樣的是它們帶了一種學習的結果在裏面。

有些場景是公司的內部的場景，能夠在內部變成一個學件來用。可是對於一些共性的東西，好比說監控，各個公司的監控場景是同樣的，若是咱們把它定義成標準的上報的格式，標準的時間區間，訓練好了 AIOps 的模型，你們承認了效果，就能夠一塊兒來使用。

「學件」這個詞，周志華老師也在多個場合去講過。經過編寫相似這些共識的上報格式，命名規範等，會讓公共的 AIOps 組件變得更加的共享、共識，這個也是咱們將來但願更多放到標準裏面東西。

這個也是AIOps的標準委員會存在的一個意義。

下面這個圖是咱們織雲的 Metis 平臺，咱們但願先在內部造成更多的學件庫，再去解決一些串聯的問題，剛纔也舉了一些例子，也但願在將來的幾個月，或者一段時間裏，開放出來跟你們一塊兒學習，共同地探討和改進，可能個人演講就到這裏了。

最後用一句頗有名的話作個總結：通常狀況下，人們經常會高估一個新技術在一兩年內的影響而低估其在將來五到十年的影響。

而 AIOps 就是這麼一個技術，做爲 DevOps 的輔助和改進，相信它必定會讓 IT 運維變的更簡單從容，真正地成爲運維同窗，運維線的一個助手工具和智能化的大腦。謝謝你們。

相關閱讀 【每日課程推薦】機器學習實戰！快速入門在線廣告業務及CTR相應知識

此文已由做者受權騰訊雲+社區發佈，更多原文請點擊

搜索關注公衆號「雲加社區」，第一時間獲取技術乾貨，關注後回覆1024 送你一份技術課程大禮包！

海量技術實踐經驗，盡在雲加社區！