歡迎大家前往騰訊雲+社區，獲取更多騰訊海量技術實踐干貨哦~
趙建春 騰訊 技術運營通道主席 騰訊 社交網絡運營部助理總經理 AIOps 白皮書核心編寫專家
我今天要講的主題，AIOps，是一個比較新的話題，其實從概念的提出到我們做，只有差不多一年的時間。一個新事物，有其發展的周期，在騰訊里面我們做了比較多的探索，但是肯定還是有不足的地方，就像咱們看到的 AI 的發展也還有很多不足的地方。今天帶來一些案例跟大家分享，希望對大家有一些借鑒和參考的意義。
1 從一個 NLP 故事說起
首先我想從一個 NLP 小的故事來說起。
在二十世紀三四十年代，人們大量嘗試用機器的方式去理解自然語言，開始是用類似於左圖一樣的語法樹的基於規則的方式處理的，但后來逐漸地變化為以統計的方式去做。
到了二十世紀七十年代之后，基於規則的句法分析逐漸地走到了盡頭。
1972年的時候，自然語言處理領域大師賈里尼克加入了IBM。1974年左右，他在 IBM 提出了基於統計概念的語音識別概念，之后自然語音識別的效果就不斷被突破。
2005年谷歌基於統計方面的翻譯系統全面超過基於規則的翻譯系統，規則方法固守的最后一個語音識別的堡壘被拔掉了。
可以看到二十世紀七十年代前，基於規則的自然語言處理的學者和專家們，注定是失落的。
為什么用這個故事來做引子，是因為我覺得咱們的運維環境，每年會有大量的開發人員加入，寫了大量的代碼交給我們。
隨着業務量的增長，設備會不斷增加，系統會越來越龐大，復雜度成指數級增長，而這些壓力全給了我們，還有如我們的監控 log 等數據也是非常的海量。
所以我覺得運維系統和自然語言處理是有相似之處的，語言是非常復雜的，量級也是非常大的。
第二個，運維的經驗，本質上就是一組組的規則。在我們的運維環境里，很多自動化的運維系統，就是一組組規則的實現。規則有一個好處，就是易理解，但往往有場景遺漏。
規則肯定是一個人寫的，一個人面對海量的數據時，處理這些問題會顯得力不從心。AIOps 不是替代 DevOps 的，而是對 DevOps 的一個輔助和補充，是對里面規則化部分進行 AI 化的改造的過程。
規則是我們的經驗，也是我們的負擔，就好比20世紀70年代前的那些專家，我們也需要進行一個轉型。
那什么是AI呢?
AI就是從大量輸入中總結出准確預測的規律（模型）。我們通過x1 x2 x3這樣的大量的輸入，通過統計一些參數，abcdwb這樣的一些參數，讓我們在新的環境中來擬合的預測做一些數值、01、概率型的預測。包括強化的學習，也是通過另外一種形式獲取數據進行統計，通過每次的探測，你能知道這一次成功和受益是多少，是正收益或者是負收益，還是零收益。
其實我們只要有足夠的數據的量級，可以重復地去探測，並且獲得反饋。
易於接入 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 運維變的更簡單從容，真正地成為運維同學，運維線的一個助手工具和智能化的大腦。謝謝大家。
此文已由作者授權騰訊雲+社區發布，更多原文請點擊
搜索關注公眾號「雲加社區」，第一時間獲取技術干貨，關注后回復1024 送你一份技術課程大禮包！
海量技術實踐經驗，盡在雲加社區！