[[243467]]

這十多年來，騰訊運維團隊里發生的點點滴滴，在我內心中，每件事情印象都很深刻。

我把一些故事梳理了一下，發現有些事情可以跟大家交流分享，所以借這個機會跟大家談談騰訊最近一兩年做的一些 AI 落地。

我們都做些什么？

在 IT 行業，稍微大一點的企業都會設有運維團隊，我們的運維團隊和大家一樣會做很多基礎工作，比如資產的管理、服務器管理、業務架構規劃等等。

以 2015 年天津大爆炸的事件為例：

在業務架構上，我們之前做過 QQ 全國多地高可用分布，所以在天津大爆炸事件中，是由運維來主導將北方天津接入的用戶從天津 IDC 機房遷到了上海和深圳。

這也是有史以來***規模的用戶遷移，用戶是無感知的，這就是我們運維團隊日常工作的一個縮影。

還有，每年的紅包是大家比較熟悉的，每年都會由運維團隊參與到整個項目當中。

另外，運維團隊也需要關注成本，會花很多力氣去優化設備、帶寬的使用情況。

其他的還包括大家可能都聽說過的一些突發事件，比如 8 億人軍裝照、直播業務井噴、鹿晗事件、紅米首發事件等等，后面都有我們的團隊支撐。

我來自騰訊的 SNG 社交網絡業務，旗下主要有 QQ、QQ 空間、騰訊云、QQ 會員、QQ 音樂等很多產品。

它有一些特點，比如單體業務非常大，有兩萬多臺，也有超過 19 年的老業務，然后每年還會有 20+ 個新業務上線。

有些業務會慢慢地衰退，新老業務變換得非常快，同時我們也在做一些 2B 的事。

我們運維團隊所處的環境和面臨的問題都非常復雜，那么有些什么樣的問題呢？今天的分享是關于我們在 AI 領域監控方面的事件，我先把這個問題拋出來。

SNG 每天有 5 萬條短信告警，每個人一天***能收到 1500 條。大家想象一下，一個手機每天收 1500 條短信是多么讓人崩潰的事情。

講個笑話，我們的一些 Leader 說，他們不看具體告警的內容，而是看告警的發送頻率，頻率快了就有問題，如果每天按照固定的頻率發就沒什么問題。

這是個玩笑，但很深刻的折射出我們運維所面臨的告警量巨大的挑戰是非常嚴峻的。

每天發出 5 萬條告警，它背后有將近 900 萬的監控指標，這是巨大的問題，同時也是非常寶貴的數據。但是我們過去沒怎么用好，今天分享的也是我們在這點做的實踐。

我們的愿望：咖啡運維

以上是我們大致的背景情況，而早先我們的愿望是能做到“咖啡運維”。什么是咖啡運維？

剛入職的時候老板跟我們說，做運維的個人目標就是喝著咖啡做運維，翹著二郎腿就把運維工作做好。

然而十多年過去了還是沒有達到，非常艱難，業務增長非常快，運維的人數和規模增長卻遠遠沒有業務和研發團隊增長快，我們要解決的問題反而越來越多。

正在做哪些監控？

在監控上很難做到平衡，因為要快、準、全，其實本身就是矛盾的。這是我們的業務架構，先看一下左邊的時間軸：

從 2006 年我入職騰訊開始，我們的運維和研發開始 DO 分離，運維開始主導去做各種監控系統，陸陸續續十多年來，建立了 20 多個監控系統，非常可怕。

很少有企業做這么多，多數企業一套監控系統做好就可以了。而我們這么多監控系統，并非重復建設，到目前看每套系統也都有存在價值的。

在 2009 年的時候，我們的監控指標非常少，監控系統不到 10 個，每天的短信告警數量也不多。差不多到了 2014 年的時候，監控系統數超過了 20 個，算是***狀態了。

而現在我們的監控實例已經超過 2000 萬個，隨著監控實例的增加，告警也增加了非常多，告警泛濫的問題沒有得到解決。

有哪些一樣的地方？

先來看看我們和大家有哪些做得一樣：

• 在運維團隊上和大家一樣，會被需求驅動，來自研發團隊、老板、產品的各種驅動。
• 業務受架構的能力制約，為了解決一個問題就建立一種方式方法監控，這樣慢慢地建成。
• 過去的視野放在監控點上，一個點一個點地解決問題，不斷地給它們優化。
• 可以把一件事情做得非常深入，在一個點上不斷優化，對于監控這么復雜的事情，這個效果并不是特別的好。

我們有哪些監控呢？具體如下：

• 基礎指標監控，每家都有，我們也一樣。
• 自動化測試模擬監控，我們通過模擬用戶請求的方式來對我們的服務進行播測發現問題。
• 模塊間調用質量監控，在我們的監控里是非常重要的體系，它是由服務的調用數據上報到后通過各種運算，來反應服務調用成面的監控。
• 測速與返回碼統計，下圖是直接由用戶端報給我們的各種數據，其實這些監控特別多，我前面提到的有一大半都是干這些事的，大家一看也能看懂，都很熟悉。

用的方法和大家也是類似的，畫線、做統計圖、做一些分類，我們也做類似的事情，但就是解決不了根本的問題。

不過并不是說這些系統就不能解決問題。我舉個案例，2012 年 8 月，據報告顯示：QQ 空間首頁比微博首頁慢 35%。

為了解決這個問題，我們聯合了公司十幾個團隊，很多骨干成員一起做系統的各種優化，歷時將近 8 個月，最終取得了較好的效果。

這里面包括：

• 天津聯通 IDC 分布，優化北方 15 省聯通用戶。
• 空間首頁 DOM 節點裁剪，減少首屏渲染時間。
• 動態加速對空間框架進行加速。
• 空間 Set 合并重整，換新機型，減少穿越。
• 根據 GSLB 測速結果，重新調整全國各省就近接入點。
• 空間框架機升級 QZHTTP 版本，支持新特性。
• 中小運營商、移動寬帶 CAP 接入。

非常直觀的案例，說明傳統的手段還是有用的，也有一定的價值。但問題是，為了做這一件事，我們投入了大量的時間、人力、精力。

所以這也促使我們不斷地思考應該如何調整，因此就有了下一部分的內容——有哪些不一樣的地方。

有哪些不一樣的地方？

我自己總結這些不一樣，其實是放下包袱去做創新。并不是要對系統進行所謂的重構，破舊立新。

因為每套系統都有自己存在的價值，現在很多監控系統也還在使用，它們的存在必有其價值，但我們可以優化后臺架構落后的問題。

關于架構落后，我首先想分享的是多維的內容。這也不算創新，因為隨著業界大數據處理技術的強大，海量監控數據開始被按多種緯度進行組合分析，成為發掘數據背后隱藏問題的最主要的監控手段。

數據被處理成多種維度的視角

多維是什么呢？前面提到的監控大家一看就明白了，基本上從我們想采集各種單維度或最多兩個維度的數據報到我們的系統開始，根據時間的序列會進行所謂的曲線會聚，做少量的分類。

現在每一條上報的數據所帶的維度是非常多的，只要研發團隊愿意往我這邊報，沒有任何的限制，報一百個維度都能接受，我們后臺能把這些報上來的成千上萬的維度用各種方式去做一些聚類。

就像截圖上看到的，可以用不同的維度組合去對產品各種方面的數據進行透視，這是我們的織云多維監控系統。

數據可以選擇不同的緯度組合來看，比如說版本、平臺、客戶端、網絡制式還有省份等等，這些數據其實就是在我們同一條數據報上來之后，在織云多維里做的處理。

在下面還可以看到***緩沖率、二次緩沖率、***加載的時長錯誤量等分緯度的數據。

原來的監控數據每次都要單獨上報，現在通過一條就可以在系統里***地落地，這也是我們現在主流的監控手段。

我們監控多維數據所使用的技術，應該和大家比較接近，基本是一致的：

效果如何，同樣舉個案例，大概在 2014 年的時候，我們手機端用戶的訪問開始超過 PC，帶來的問題就是運維壓力山大。

過去我們做的運維監控體系基本都是基于 PC 的，但是手機端用戶一來，千奇百怪的問題都出現了。

運維在幫助研發團隊一起優化產品體驗時，利用多維的技術，把系統中各種數據全部報到織云多維監控中，運維來做分析。

以上表格里是七個優化點，實際上不止，我記得這個項目到后面運維大概有四十多個優化點。

一個手機端的產品，發現了四十多個待優化的點，這些數據原來是分散在各處的，利用多維監控之后，可以更加方便的把各種異常分析出來。

這個例子中，是我們運維團隊的兩位骨干在三個月左右的時間里完成的。對比前面的案例，這次場景更復雜，而且技術的難度也更高了，但在發現問題的過程中，反而效率提升是非常的明顯。

前面幾十個團隊八個月時間做的事，在這里就兩個人、兩三個月也能做到，效果卻能更好。

DLP：業務生死指標

第二個想分享的，是關于 5 萬條短信告警問題。我和很多同行交流過，基本上大家都有同樣的問題，每個大點的運維團隊都面臨著告警泛濫的問題，但到目前沒有哪個是可以***解決的。

所以我們做了一些嘗試，在 2016 年的時候推出 DLP，也就是業務生死指標，它有幾個限定：

***個要求，不能設定閾值。這是運維規定的，完全根據指標值做波動判斷。

第二個要求，一個服務只能有一個生死指標。大家會奇怪為什么有這樣的要求，那么請思考一下，我們為什么有那么多的告警？

為了保證這個服務不出問題或是出了問題能***時間被發現，有的服務有四百多個指標來監控它，這些監控指標有運維配的、有研發配的、也有產品配的。

這樣下來，怎么可能不出現告警泛濫的情況？所以生死指標里一個服務只允許有一個指標，衡量這個服務到底生還是死的指標。

第三個要求，不建議用業務指標做生死指標。什么叫業務指標？比如說在線、收入曲線等這些指標對業務來說非常重要，但對于衡量一個系統是否有“生死”故障來說，這些指標很有可能變成干擾。

舉個例子，比如你的業務正好在做一個推廣活動、那么用戶的在線數、購買量等產品指標都會發生巨大的變化。

如果你對這些指標進行監控，并不能衡量這個業務是生是死，所以我們不推薦用業務指標來做 DLP 監控。

什么叫閾值？過去我們絕大多數的監控系統都是通過閾值來告警的：比如訪問量超過一萬的要告警、量低于幾百的要告警……

以前的監控都是這樣做的，但是在我們這里面不允許，全部是去掉閾值的。我個人認為“去閾值”是未來運維監控的趨勢，而我們只是通過另外一個手段踐行了這個概念。

當然一開始推行，項目難度非常大，基本上所有的產品都不接受，研發也不接受，因為好像太不合情理了，推動起來非常痛苦。

但是后來隨著我們不斷的推動，有的業務逐漸開始試用并感受到了好處，他們收到的 DLP 告警非常的準，告警的數量也很少。

以前一天要收一千條，現在可能一天一條兩條，多了也就十條，這是很明顯的差異。數量少了反而大家愿意去處理告警了，故障反而少了。

怎么去閾值？很簡單，我們在成功率上使用了統計學的方式，設一個成功率的滑動窗口，利用環比同比數據通過 3Sigma 算法計算出一個動態率值區間，只要超出這個區間就認為 DLP 出現了問題。

這不算是一個很難的技術但實踐效果卻非常好，作為最早嘗試將“去閾值”概念用于生產環境，我覺得一定要跟大家分享 DLP 的實踐。

目前正在遇到告警泛濫的企業可以考慮借鑒嘗試一下，至少在我們團隊實實在在落地了，我們二十多萬的服務器都已經上線了，也經過了兩年多的驗證。

舉個例子，這是我們 DLP 告警的效果：

一旦告警出來，它會把這個告警發生的影響時間區間畫出來，并繪制出和過去的同比變化。

同時通過對多種維度進行聚類，會把是否有主調 IP、被調 IP、返回碼匯聚等情況分析出來，也會把是否有版本發布、網絡變更等事件關聯起來。

由于 DLP 告警本身很準，再加上告警出來后用戶可以得到這么多的輔助信息，用戶自然會發現 DLP 非常有幫助。

這個圖的最下方是訪問關系的記錄，也是下面要重點跟大家分享的。

# ROOT：根源智能分析法

ROOT 是今天想重點跟大家分享的內容，這個項目是在 2010 年做的，當時我們也不知道有什么根源分析的概念，只是要做一個嘗試去解決運維分析故障時特別困難的問題。

于是 2010 年啟動代號 ROOT 的項目，大約在 2012 年做出來，2014 年才在行業大會上分享出來。

今天，我再把這個項目拿出來跟大家一起探討，是因為我們用 AI 的方式將這個理念重新地 AI 化了，非常有意思，我個人認為對于 AI 在我們傳統數據上落地非常有借鑒價值。

首先，什么是 ROOT？我們現在把它叫做根源定位（有別于根因分析）。

我總結了一句話來描述它：基于業務架構，結合數據訪問關系流，通過時間相關性、面積權重等算法，將監控告警進行篩選分類，發掘有業務價值的告警，并直接分析給出告警根源。

怎么做的呢？我們在 2010 年的時候，正好在嘗試做“自然運維”（和現在的 DevOps 理念很像）。

研發和運維要分工、做配合，基于特定的一些流程去完成我們的日常工作和運維管理，包括現在所謂的交互鏈，我們當時沒有把它包裝成 DevOps 這么高大上的名詞。

當時的理念是基于業務架構去運維。騰訊的業務挺復雜的，人員變動也很大，運維不熟悉業務架構往往是做好運維工作的障礙。

于是我們和研發一起制定了關于業務架構的規范，研發團隊會在我們規范出來的業務架構中去完成增加或減少、變更服務等的一系列任務，我們運維也會做一些系統把這個業務架構圖展現出來，并管理起來。

下圖這是我們產品的頁面。在這個頁面上，運維和研發都能看到當前的業務架構是怎樣的，這就是我們的初衷：

也是基于這個背景，大約 2010 年的時候，我們將各個業務的架構管理起來。上圖是一個廣告業務架構的一部分。

有了這個產品后，我們突發奇想：如果其中有一個節點在產生告警的時候，問題是否不一定是它自己的，而是后面某個節點出的問題？

這是非常合理的考慮。舉個例子，如果我的用戶說我的服務訪問很慢，有可能不是接入層的問題，而是后端的邏輯服務比較慢，死機、宕機或者是網絡問題……

我們不能把問題定位只限制在接入層，那怎么把整條的業務撮到一起去呢？能不能有種技術把它降維到網狀呢？

我們通過把高維度的網狀訪問關系數據降維到鏈狀，主要通過窮舉的方式把訪問關系鏈從圖中拎出來，順利完成降維。

降維的方式挺簡單的，從訪問開始，把整個訪問數據列舉出來，就能得到降維之后的二維數據。

剛才大家看到的復雜網絡圖其實是這樣的一條一條的鏈路，沒有任何邏輯的，然后再把我們前面有提到的 20 多套監控系統發出來的告警數據，都在這條鏈路上進行各種疊加。

得到如下的效果：

從運維經驗上看，相隔近的連續告警，后面告警是引起前端告警原因的概率更大。

我們現在要做的是用數學的方式把它描繪出來，這就是我們整個系統的主要思想和實現方式。

產品上我們把它做成如下圖所示，把權重***的告警鏈路按時間維度透視出來。

圖中縱軸是這條訪問鏈路的模塊，橫軸是時間軸，粉紅色的點是我們的告警疊加在時間鏈上后的效果。

我就可以看到在同一個時間片內有告警，這些告警雖然屬于不同的模塊，相關性也不是很大。

但下面兩個模塊每天都在告警，這個情況很正常，是閾值配錯了，這種情況也非常常見，我們沒有辦法一個個去解決。

這一種持續告警在我們的系統中大量存在，對我們的告警分析是很大的一種干擾，我們希望把這個過濾掉，而聚焦在某一個時間片范圍內相關性非常大的告警分析上。

時間片與時間的相關性是很重要的，我們認為告警本身有一個所謂的時效性，所以有時間窗，比如告警有快慢，還有告警延遲的問題。

連續性的告警絕大多數都是干擾因素，基于這樣的想法，我們把告警做了分類，分成了原因告警和現象告警。

現象告警往往只是一個表象，好像服務出了問題、前端服務訪問慢，但可能只是一個現象，原因不在自己身上而是在后端的某一個服務器上。源在別的地方，我們要找到根源，這是根源分析的思路。

我們把告警分為持續告警、波動告警和關聯告警。這是 2014 年的數據，我們驚奇地發現在系統中有 65% 是持續的，代表了 65% 的告警數據極大可能是干擾，因為不明的原因而每天在告警。

有 24% 的告警是波動告警，這種告警指標一會兒上去，沒一會兒又下去了，可能是某個服務中斷后恢復了，或者有某個產品進行版本發布，都有可能，但是最終是恢復了。

運維也不需要去查，不需要關注。真正的我們系統能關聯出來的告警只有 9.2%，也就是不到 10% 的才是真正有問題。

我們應該把運維的精力放到這里，絕大多數的告警運維都不需要花時間去查的，這是我們的數據分析。那么前面的數據算法，怎么做這個分析呢？

2012 年左右，運維根據經驗所設計的“權重與面積算法”，原理就是在同樣長度的鏈路上通過疊加上去的告警的排列不同，可以把它優先的權重算出來。

從運維的經驗上來判斷，告警間隔越緊密，這些告警的相關性就越高；告警的間隔越稀疏，它的關聯性就越低。

所以這三條鏈路雖然同樣是七個節點的鏈路，同樣每個鏈路上都疊加了四種不同類型的告警，我們最終還是能算出來，***個權重是***的，這個算法挺簡單的，后面有源代碼的公開。

這個算法也開創了咱們在做根源分析時通過數據做運維分析的方式，用過一段時間，準確率不是很高，大概 60% 左右。

它的想法和技術都是很老的，這是 ROOT 在 2012 到 2014 年的時候我們做的比較有意思的嘗試。

跟進時代，踐行 AIOps

我們這兩年對 AI 的思考，做了很多在運維監控的 AI 嘗試，發現其實根源分析這塊是很重要的一部分。所以，下面也是我今天分享的重點。

我們踐行 AI 的一些嘗試，整個內容有 5 個階段：

文本 + NLP

***個階段是文本 + NLP 的處理問題，比較有特點的產品叫輿情監控，還有智能對話機器人這部分。

預測 / 判問題

第二個階段是預測和預判問題。預測是大家比較喜歡的，很多團隊都通過 AI 的方式做預測。

比如基于在線預算量、預測未來等等相關的比較多，基本上是基于時間序列。

信息收斂問題

第三個階段是信息收斂的階段，前面提到這么多，有很多的方式去收斂。多維的系統就非常的好用，我覺得也是未來的趨勢。雖然不是我們重點分析的，但是可以去借鑒。

根因分析

第四個是根因分析問題，其實并不重要，重要的是下一個階段。

根源分析

***是根源分析的問題，下面詳細介紹一下根源分析方面在 AI 上的嘗試。

我把前面 ROOT 的問題給大家引出來，它的準確率只有 60%，同時還有很多別的問題。

為什么只有 60% 呢？原因在于：

• 有的場景是解決不了的。比如各種 GW 等 IP 接口大量匯聚的場景，這在騰訊是很普遍的。

而這種高匯聚的場景成了 ROOT 系統構建關系鏈路中的關鍵點，很多的流量都會經過它。這個節點結果成了 ROOT 分析的干擾因素，用 AI 的說法是它的熵太大了。

• 關系鏈不是完整的。前面提到業務拓撲圖關系能繪出來的前提，首先是我們基于業務架構去做運維管理，然后通過模塊之間的調用關系來構建鏈路。

這些數據都是基于 CMDB 來匯聚關系，也就是關系是限定在業務邏輯范圍內，空間就是空間，音樂就是音樂，不會超出范圍。

所以我們現在怎么去解決這些問題呢？

***，針對于 IP 匯聚的問題，就是我們把所有匯聚在 DBSCAN 上面進行分類，如下圖：

通過一些特征對數據進行分類，把我們關鍵的數據拆開，拆成多個服務頁，參與數據的重新運算。

原來只是一個點，現在變成了很多很多的服務節點，解決了以前解決不了的一些問題。

第二個，關系劃分。前面有提到我們服務有很強的業務邏輯在里面，但實際的關系不是這樣的，我們嘗試用社交領域的市場，通過實際的訪問關系來劃分。

這里可以看到，左邊的圖是所有的訪問關系，右邊的圖是經過劃分之后形成的訪問關系。

以前我們系統是直接割斷，而現在，我們的系統因為實際上有很強的關系，就像我們的 QQ 關系鏈一樣，會有各種的交互，哪怕可能不屬于同一類人，但是之間的關系是非常強的，解決了鏈路被切斷的問題。

第三個，權重。剛才前面提到的面積權重方案是經驗問題，我們通過把鏈路告警數據，歷史上所有的告警數據拿出來做平面計算，發現 A 和 B、B 和 C 之間的真實告警相關性上的數據概念。

這就是非常符合邏輯了，AB 同時告警的情況下，歷史上出現的概率非常高，當前又出現這種情況，它的相關性很高，這個業務的概念是很合適的，這是相當于把傳統的數據用運維的理念通過 AI 的方式重新定義。

我們新系統中的準確率會高很多，發現通過 AI 的引進之后，方法還是這個方法，原理還是這樣的原理，但是它的價值是大幅度提升的。

[[243471]]

聶鑫，騰訊運維總監。從開發到運維，伴隨騰訊社交網絡運營部成長的十年，負責過騰訊社交產品所有業務運維工作，目前主要負責業務運維、織云產品、AIOps 體系等團隊管理工作。經歷多個業務產品的誕生到蓬勃，伴隨著運維團隊的成長和成熟，見證著騰訊一代代運營技術的創新和發展。