講師簡介

樑定安

10年運營開發、海量運維和架構規劃經驗，任騰訊社交平臺運維團隊負責人

主要負責Qzone、相簿、音樂等社交平臺類業務的運營開發和運維規劃工作

精通海量服務的架構設計和自動化運維建設

目前專注於devops、APM、大資料的運維實踐探索

自我介紹

我是來自於騰訊社交網路事業群的樑定安，今天我給大家帶來的分享是關於我們做了幾年的智慧監控實踐的分享。

我們事業群是負責社交網路的，就是傳統的QQ、QQ空間、QQ音樂業務，跟遊戲場景有些不同。

所以，我們在做社交應用監控的過程中，遇到了一些什麼樣的問題，我們做出了什麼樣的思考，最終落地的實踐是什麼樣的，我今天希望重點跟大家探討這些實踐經驗，以及在這個過程中的思考。

監控的意義

我們今天的主題運維自動化是效率提升的一個話題，今天早上也有嘉賓分享過，效率對產品、開發、業務價值來說其實沒有特別地顯性，運維自動化更多受惠的是運維自己，真正給運維帶來價值的是我們對質量的保障。

通過我們做的一系列的監控、自愈等等運維功能，其實都是為了體現我們運維崗位能給業務帶來的一個價值。所以，我認為質量是運維最重要最優先去關注的。

運維在關注質量方面主要是三個方面：可靠性、可用性、使用者體驗。

你的程式是不是可靠的，通過對可靠性的管理、監控來實現對可用性的評估，提出優化建議。通過不同功能、微服務的可靠性可以計算出業務可用性。

最終，所有對可靠性和可用性的度量，都是為了提升使用者使用我們的產品的體驗，讓使用者體驗變得更快、要爽、更好，這是我們做監控的意義。

監控的手段

怎麼樣能夠保證我們產品的服務質量和使用者體驗呢？

通過三種手段可以做到，也是我們談監控經常談到的手段，

主要分為三種：

1. 主動
2. 被動
3. 旁路

主動，所有的業務開發出來的應用程式，在上線之前能夠按照運維的要求，或者自身對程式碼質量的監控，提前做好了很多埋點。

這是最好的開發和運維的合作模式，但卻是可遇不可求的。

因為很多業務在專業運維團隊接管之前就已經存在，運維面臨的最大困難就是歷史包袱，一個業務可以沒有產品，可以沒有開發，但是一定不能沒有運維。

在騰訊社交網路的業務發展的十幾年時間裡，很多長尾業務真的是連研發團隊、產品團隊都已經沒有了，但是服務仍然在對外提供正常的服務。

面對種種歷史包袱或者規劃不周全的問題，監控除了主動手段外，還需要第二種方案，就是被動監控

比如，判斷一臺裝置是不是宕機了，我們可以部署幾臺探測機，持續的ping它，這就是被動的監控手段。

被動有一個先天性的好處，不是強依賴研發團隊配合，我們無痛式的去監控，但是這種能監控的粒度往往卻是有限的。

旁路監控，主動和被動監控做好了，不代表使用者對我們的產品體驗是滿意的。

舉一個例子，有可能我們的服務都是四個九，甚至是五個九，但是由於使用者本身網路的問題，壓根就訪問不了我們的伺服器。

這個時候就需要輿情監控等跟第三方的對比資料，來間接的反應我們外網服務的真實情況，作為對主動和被動監控手段的一個重要的補充。

監控的本質

掌握了監控的主要手段後，我們該怎樣衡量各類不同的監控點呢？請求量、成功率、延時。

所有監控點的度量，都能收攏到這3類指標中。如CPU百分之百了，反饋在我們的服務上就是成功率的下降或者延時的上升。

這三個指標點怎麼樣產生資料的價值和反饋出問題呢？

通過趨勢對比，同比、環比、波動分析、聚類等資料加工分析的策略，來更直觀的突出資料中需要技術人員關注的焦點。

如，通過使用者的來源IP聚類分析來判斷是否有地域的匯聚，從而發現一些和地域相關的問題，類似的做法可以把種種隱藏在監控數值下的一些非顯性問題暴露出來。

並且，我們所有的監控資料最終都是會以圖、表、告警的形式，通知關注這些監控點的人。

監控系統的目標——全、快、準

我們做任何一個監控系統都希望做到全、快、準，就是無盲點，360度無死角，並且又快又準，沒有誤告警。

但是實現起來很困難，從某種意義上來講，監控速度要快又要準是有點相矛盾的。

舉一個例子，監控突然產生一個毛刺，因為一個網路丟包，它的成功率馬上就掉了，這個時候產生告警，可能下個時間片就馬上恢復了。

如果這樣產生的告警是不是運維人員會覺得不準呢？因為等我上機去看的時候已經恢復了。

我們怎麼樣能夠權衡，能夠做到又快、又準、覆蓋全呢？一旦全了，資料量就很多，資料多產生的告警點就很多，怎麼做到呢？我們帶著這個疑點，看看我們在實踐中是怎麼做到的。

全鏈路監控

隨著移動網際網路的興起，使用者在訪問到我們社交服務的時候，全景的鏈路大概是這樣的（圖），首先使用者在自己終端裝置上發起的訪問，會經過很多不同的網路到達我們的後臺服務中。

移動網際網路讓這個網路變得更復雜化，我們有不同的接入方式，有不同的運營商。

同時，移動網際網路又把我們暴露在使用者側的客戶端的版本碎片化，有很多版本，有很多不同廠家不同型號的智慧手機，有安卓，有IOS等等不同的系統。

因此，我們要做到全面的監測，就必須在整個全景鏈路中設定很多功能不同的監控點。

騰訊在我們的社交業務場景下設定了很多的監控點，這是一張全景圖，圖上有很多小字母，每個小字母代表了不同的監控型別，我們分為網路類、服務端類、基礎類。

又專門針對移動網際網路的特殊性做了很多，比如卡慢分析、多維度分析、輿情監測，這些都是具體的監控點。

監控的速度

有了這麼多監控點，怎麼樣保證所有監控點的監控資料能夠快速地被加工、處理，最終傳遞到最需要關注的人手中呢？

我把監控資料從採集到最終終端使用者收到產生的異常資訊及單個監控點的資料從採集到最終產生告警的耗時做成瀑布流。

大家可以很直觀的看到一個監控點的資料怎麼樣加工計算才能保證最優最快或者最價效比最高，怎麼樣讓我們的告警又快又準？

可以優化的點需要我們深入探討和挖掘，由於時間關係，只能簡單列舉一二。

統一上報協議

為了降低計算的複雜度。我們把所有的資料歸為三維資料和多維資料。

三維的資料就是一個ID，你上報的監控是什麼型別的，你的ID、你的時間、你的值，我們就可以做針對性的告警或者圖形展示的一些優化，讓我們的處理速度會變得更快。

多維，因為社交網路提供的業務型別、對使用者的服務也是多種多樣的，有QQ，有音樂，有圖片、檔案、微雲，針對這些不同的服務場景，它其實都是多維的場景，我們就把它們按場景區分，分別統一幾類通用的多維協議，然後我們的後臺流處理叢集可以針對每類多維監控的場景，定製流計算邏輯，按照使用者使用資料的形式將多維資料做加工處理。

如果我們後臺用了一個關係型資料庫儲存，過多的資料維度，會讓在做監控視覺化時，無法獲得高效的查詢效能。

我們怎麼樣解決其中的矛盾呢？如果資料的緯度特別大，隨便列舉一個維度大於30的案例，騰訊億萬級量所產生的監控資料絕對是“億億”級的。

為了解決這個問題，我們把每一塊都設計成微服務化，我們用了開源的svr、kafka、Storm，再落地儲存。

運營開發和運維人員其實關係一般不是特別好，如果按照以前我們的分工規則，一方提需求一方做需求。

運營開發按自己的思路做一套監控系統給運維來用，大部分運維是用得不爽，這是一個客觀存在的事實，這是人性使然。

為了優化這個問題，我們微服務化的分工也是基於這種理念，運營開發更專注於對Storm邏輯的一些封裝，專注於原始資料的高效加工處理，然後，告訴資料消費者（運維）有什麼樣的資料，在資料銀行中提供了哪些資料的型別，提供了哪些豐富的介面，所有產品化的工作都是由運維來實現的。

整個架構圖其實都是運營部來做的，但運營部內部又可以按照不同的功能模組孵化出各自負責工作的職責範圍，基於這些職責範圍我們就可以更好地相互協作，相互地分享各自的工作成果，這是為了達到快的目標，統一協議，優化我們的分工的一個架構。

準：智慧監控

準，以告警舉例，通常告警的產生基於閥值或演算法的策略，把異常的監控資料點找出，然後系統把過去運維人員處理的異常問題的經驗變成一個個自動化的工具，像自愈、收斂、根源分析這樣的延伸功能特性，來達到我們對準的訴求。

如，大範圍故障的場景，一個核心交換機壞了，會產生多少告警？如果所有監控點都發出告警，那這些告警對運維人員其實是騷擾的，是不準的。

但如果絕大多數的告警都不發了，就告訴運維是核心交換機故障這一條告警，這便是我們追逐的精準告警。

我們今天主要探討一下怎麼樣找到根源的問題，讓我們的告警變得更加智慧，而不是“點”的告警。過去我們做了很多監控點，我們怎麼樣通過點的監控去做好“面”的告警呢？

其實做所有事情都是有一些機緣的，因為在業務上面臨很大的挑戰，過去我們一步一步去構建監控體系的時候，我們埋了很多監控點，當我們的業務體量一上來的時候，這些監控點就變成運維人員的負擔，我們對業務邏輯監控、主機也監控、網路也監控，使用者投訴過來的時候，我去查，很多點都在告警，究竟哪個點的告警最應該關注呢？

運維和研發人員的人數配比是相差巨大的，一個運維可能對應了上百號開發，我不可能要求一個運維關注到方方面面。在我們這麼高可用架構的前提下是不是還應該關注一些“點”的問題呢？帶著這個疑問，我們繼續。

海量監控的困擾

這是一張騰訊廣告其中的一個拓撲圖，這張圖想表達一個問題——像網一樣，很亂。

當一個節點發生異常的時候，會把告警擴散到各個點，因此我們需要一個智慧的監控分析的引擎，去幫我們解決這裡的一些問題。

ROOT智慧監控系統

騰訊的體量在中國網際網路是使用者最多的，QQ同時線上使用者數，在2014年就已經突破2億，創造了世界的吉尼斯記錄。

2015年紅包的時候甚至達到2.15億同時線上，整個社交網路有大於十萬臺的伺服器在支撐著這麼大體量的業務，每天我們會產生4萬條以上的告警，人均的告警量大於500條，有些比較極端的一天收3000條告警簡訊。

當告警量大於500條，你的所有問題都發現不了，上班只有看告警就什麼事情別做了。

因為業務量的龐大複雜，而產生大量的告警，我們過去所有的收斂辦法都是基於一個垂直監控點的收斂，但是監控點一旦多起來，點和點之間怎麼收斂呢？

因此端到端的智慧監控應運而生，基於業務架構，結合資料流的關係，通過時間相關性、面積權重等演算法，將監控告警進行分類篩選，發掘有業務價值的告警，並直接分析出告警根源。

假設我們在這個架構圖上發現了一個問題，我們的DB掛了，會層層往前推，我們的邏輯層、接入層、負載均衡，甚至到我們的使用者端報上的成功率都會受到影響。

但是運維並不希望收到這N個現象告警，我們希望把DB宕機的根源告警發出來，其他告警都收斂掉。

首先，我們基於我們的業務拓撲圖，根據時間的相關性，把告警都疊加在鏈路上，把一些不需要關注的點都過濾掉，最後得到一個經過經驗分析的模型。

很簡單的一個例子，變更容易引起告警，DB更容易是根源告警，越靠後的告警越容易是根源的告警，通過這個模型算出根源的問題。

降維策略

我們採用自動生成拓撲圖的方法，利用社交網路事業群的通用路由元件L5、模組間服務呼叫監控的基礎資料作為我們繪製業務拓撲圖的基礎資料來源。

還有一個靠tcpdump抓包的方式，TCP的請求是有序的，UCP的連線也是可以加工的，雖然它發起的埠是隨機的，但我們通過對資料的積累一段時間，就可以清楚地知道這個UDP服務的主調和被調的關係是什麼樣的。

隨後，把網狀的拓撲變成一條一條的訪問關係鏈，得到這條線之後，我們開始做相對應的關聯分析的邏輯。

我們把相關時間的告警疊加上來，我舉一個例子，10:20到10:30分鐘之間產生了這樣一些業務告警，在這些模組都有發生，B這個模組產生了業務告警，E產生了釋出變更告警，D這個模組產生了基礎告警。

通過權重演算法對這些鏈路進行排序，再套上模型分析，找到我們最需要關注的一條鏈路。

如果這裡按照過去監控點的玩法，我們會產生大於10條的告警，但是我們是希望把這十條告警收斂成這個鏈路的告警。

其實我們現在在舉例試圖讓大家更好地理解我們設計這個面監控的思路。

時間相關性分析

這張圖是我們的系統截圖，把我們的鏈路從橫向換成縱向，有一些模組在很長一段時間內都會有一些監控的異常。

我舉一個實際存在的例子，我們的伺服器上裝了一些Agent，不去深究這個Agent應不應該存在，它有一些掛了，掛了但是不一定影響我的服務。

在一個大的叢集下每天都會有一些東西掛掉，但是又不影響，它的處理優先順序很低，但它一直產生告警，因為它有監控點。

這些監控點怎麼不跳出來影響系統的分析呢？

通過時間相關性的分析，長期存在的紅點都是監控到異常，究竟有沒有發出來被收斂掉了是監控系統自身的問題，但是全盤分析中這些監控點會被過濾掉，它的權重是很低的，這個告警是可以忽略掉的，因為它一直都存在。

通過時間相關性的分析，系統會把持續性的，跟延時等等相關的問題，都會過濾掉。

權重面積分析

過濾完沒有用的告警，還是有很多告警，怎麼樣能夠在眾多的鏈路中找到我們最應該關注的鏈路呢？

面積權重的演算法有一個口訣，越靠後的模組越有可能是根源的問題，相連產生的告警越可能是根源的問題。

基於這樣的一個原則，我們把它變成了每條鏈路都可以算出一個面積值。

這樣把各個功能模組介紹完之後，我們的架構基本上就可以出來了。

首先，要做這個事情，我們必須要有一些基礎資料，就是我們的業務拓撲、我們的訪問關係連，通過日積月累的資料整理可以得到。

當我們各個告警渠道有異常產生的時候，就開始過濾的動作，最終把我們篩選出的鏈路做排序，再套用我們以前遇到的一些模型、經驗去分析它，最終給出根源問題。

舉例說明，6個時間片內我們收到了4條告警，在關係鏈路中疊加出一個告警的情況，B告警延時高，有可能是網路擁塞的問題，沒有那麼快解決，它是長期存在的，必然不是影響這個時間片的問題，我們把它過濾掉。

還有一個是B毛刺，馬上又恢復了，最後我們關聯到A和D是有關係的，D可能在釋出，A超時了，我們希望得出一個告警的結果是這樣的，直接告訴我一個結論。

質量體系：生態構建

回到我們做監控的本身，是不是光有監控能力就能解決一切的問題呢？

大家可以想一下，運維能做的是最大程度地幫助你降低影響，但是不能保證這個問題如果是程式程式碼的問題也能被根治。

通過報警能力的建設，把質量生態建設起來，光靠運維團隊自己是沒有辦法做好這個事情的，我們為了更好地做好監控，為了能夠讓產品給到使用者最好的體驗，需要有更多的角色與運維配合著一起去做很多事情。

天網體系

我們把不同的監控點，按照一個業務架構層級的不同做了一個分類。這個分類就代表了每一類最應該由誰負責跟進，相當於是給每個人負責一大堆的監控點的現狀做了減法。

以前我們做監控的時候，經常說這個監控點是這個業務邏輯影響的，配上他的開發總監，對口的運維也對上，導致一個告警產生首先輻射了一大堆人，很多人收到這個告警不知道要做什麼，他可能就看手機震動得快不快。

為了優化這樣的問題，我們專門對所有的監控點按照不同的角色要關注的內容不同做了一個分類，就像使用者端輿情的監控，輿情的監控拿手機應用舉例，更多的是產品體驗的一些問題，說不定使用者噴的是按鈕擺在右面不習慣，我要擺在左面，或者說他噴的功能性的問題。

我們希望把系統的告警是分級的，根據不同的告警優先順序走不同的告警渠道，有QQ、簡訊、微信、電話，不同的人不同的告警，不同優先順序的告警渠道來分發。

運維是主要構建一個監控的能力，並不是運維會收所有的告警，運維只收最關鍵的告警。

這裡還有一個DLP（生死點），是下面三層所有監控點，這麼多監控點如果放在一個模組裡，這個模組所有的點可能都告，但是我們希望這個模組只告一個，這就是它的DLP。

你的一個agent告警不是決定服務生死的關鍵，那就是agent的負責人去跟進，選定一個能夠決定這個模組生死的監控點作為模組的唯一運維負責的監控點，質量由運維來負責。

其他的如網路問題，負責基礎網路的運維去看。

應用運維，負責業務的質量，應該投入100%的精力處理好DLP監控點的所有異常。通過DLP監控點再去與智慧監控分析做整合，再對鏈路中各個模組的DLP進行一次收斂，每條鏈路只看一個點，每條鏈路根據相關性進行收斂之後，得出一條鏈路。

通過這個，我們把監控點做一個減法，很好地把告警收斂掉。

天網：質量體系

我們的監控體系是閉環的：監控能力、業務可用性、使用者體驗、技術解決、統計分析、持續改進。

我們希望構建這樣一個質量體系，把開發、運維、客服、QA、老闆、產品都捲進來，運維在這裡搭這樣一個舞臺，讓大家共同參與演出，貢獻力量。

監控其實就是一座很高的雪山，這裡的坑很深，很難挖。我們正在探索不同的方法去攀登征服這座雪山，今天分享的這個系統未必能夠解決所有的問題。

但在我們實戰一年多的時間裡，確實能夠真正幫助運維解決一些問題，我們的告警沒有以前那麼多了，重新梳理了我們整個體系的生態，讓更多的人進入我們的生態貢獻自己的一份力量。

我今天的分享結束了，謝謝大家！

Q&A

Q1：主動、被動、旁路，這三種在整個告警量的範圍內，比例分別是怎樣的？這三路產生的效果分別怎樣？

A：其實要看不同的場景，具體的佔比沒有計算過，旁路肯定是最少的，但是旁路往往最能說明問題，我們做監控的目標是為了監控使用者體驗有沒有受影響。

我提到的旁路監控就是輿情，監控使用者口碑，在使用者反饋的論壇，你的APP有一些快速反饋通道的時候，使用者反饋的自然語言會被分析，分析完了發現異常

例如QQ發不了訊息，這個關鍵詞被命中很多就會告警，確實是有使用者遇到這種問題。

但是並不是說它就是萬能的，有些情況下使用者不會反饋，直接卸掉了。

這個時候我們需要結合主動和被動，我們技術能做的就是把主動和被動做好，輿情作為我們的一個輔助手段

要說佔比的話，主動當然是做得越多越好，但是這裡往往有一個問題，拿日誌舉例，我們日誌的規範是不是一開始就能夠設計好？

隨著業務的發展，我們未必考慮得那麼清晰

現在在騰訊社交網路事業群，其實我們沒有一套通用的標準化日誌，因為從騰訊剛成立就想規劃清晰標準日誌體系。

公司發展壯大後，QQ打一份自己覺得是規範的，QQ空間又打一份自己覺得是規範的，以誰的為準呢？

如果研發團隊能夠配合運維做好這裡的規範和準則，並且按照運維的要求主動上報，我們的監控點肯定是全的，

但是事實上，我們不得不面對這些客觀的問題，我們只能退而求其次用被動的方法。

Q2：請教一下，報警之後就可以做自愈嗎？

A：當你的報警精準度很高之後，就可以對告警做分類，做自愈了。

Q3：有沒有一個類似的指標來說？我剛才聽說92%，已知告警92%以後，自愈的報警比例是多少？

A：我們所有的基礎告警都是自愈的，機器宕機等這些都是要求自愈的。業務側的一些告警，目前我們還沒有嚴格的要求你自愈率一定要達到多少，因為這真的是跟研發投入相關的，但是我們也正在朝這個方向去做。

我之前還分享過我們自動化的一個平臺，如果是容量導致的業務成功率低的話，我們會有一個自動上線的過程，就跟騰訊的藍鯨平臺的是一樣，這些是歸為自愈的，但是這些比較可控。

Q4：怎麼保證告警收斂不會收掉有用的告警？你們制訂的規則中怎麼讓它制訂得全？

A：這確實是一個很好的問題，告警的收斂，收斂之後的告警是隻給運用運維看的，原生監控點產生的問題應該是開發看的，還是會有人看，只是說相對的優先順序不會那麼高，被我收斂後的告警的優先順序更高。

怎麼樣解決覆蓋全的問題，凡事都有一個過程，在我們完全到達巔峰的情況下，還是要兼顧整體的。

目前這條路是不是百分之百覆蓋了社交業務所有的場景？

我其實是不敢這麼說的，因為隨著業務的邏輯、架構的不斷變化，有可能會產生新的問題，但是目前我們還在不斷地建設，把我們的門檻降低，就能夠持續地優化它。

文章出處：高效運維