騰訊大梁：DevOps最後一棒，有效構建海量運營的持續反饋能力

5月6日，數人云與優維科技主辦了【DevOps&SRE超越傳統運維之道 · 深圳站】，6月北京站敬請關注~本文是騰訊SNG運維負責人——大梁分享的DevOps最後一棒，如何有效構建海量運營的持續反饋能力。同期嘉賓數人云王璞實錄：活動實錄丨SRE在傳統企業中的落地實踐。

梁定安，騰訊織雲負責人，目前就任於騰訊社交網絡運營部，開放運維聯盟委員，騰訊雲佈道師，騰訊課堂運維講師，EXIN DevOps Master講師，鳳凰項目沙盤教練，復旦大學客座講師。

DevOps最後一棒

前言　　　　

此圖歸納了整個DevOps體系，它最後的環節，是作運營和終結的環節。對於運營和終結的理解，我認爲應該包含兩個維度：第一個是此次運維活動質量的運營與終結；第二個是產品的技術運營與生命週期的終結。
今天聊下產品生命週期結束前的技術運營階段，如何構建質量體系，實現持續反饋和優化的目標。

監控、告警與運維

持續反饋於運維的理解

◆ 監控——覆蓋率、狀態反饋、指標度量

監控要作到360度無死角，業務出現什麼問題都能發現，有了監控的反饋，能夠看到實時監控的狀態，同時，當指標發生變化的時候也須要注意反饋信息。

◆ 告警——時效性、準確性、觸及率

業務愈來愈複雜，層次愈來愈多，每個監控點都會產生數據指標、狀態異常，會收到愈來愈多的告警。未看到或者看到未處理都須要承擔責任，由於收到的並不是都是錯誤告警。

◆ 運營——RCA、事件管理、報表/考覈

問題再三出現必須從根源優化。經過事件管理機制保證RCA能夠落地，最後經過報表和考覈去給運維賦予權利，推進相關優化活動的開展，包括架構和代碼的優化等。

監控、告警與運維

全面的監控點

騰訊業務按照不一樣的層級進行管理，自下而上，有服務器層、數據庫、邏輯層。中間計算的這一層，有接入層、負載均衡、機房、DNS服務、客戶端、用戶端等，爲了作到無死角，咱們佈局了不少監控點。

實現輿情監控後，監控點作到了100%的覆蓋，但並不能高枕無憂，由於當監控點作得越多越立體化，360度無死角後，每一個最細節的點都有指標去度量，指標數據爆炸極可能成爲另外一個潛在的監控隱患。

監控、告警與運維

運營階段要解決的問題

〓 繁——簡

在具體生產過程當中會產生運維的事件或者故障，常常會有死機，以及各層監控告警，這些繁瑣的告警、故障，該如何簡單化？

〓 泛——精

舉個例子，在一臺核心的交換機下，假設其下連有1000臺的機器分佈到數據層、邏輯層、接入層等等，當這臺交換機故障不可用時，因爲有立體化監控的存在，每一個監控點都會產生大量的告警信息，要如何發現這些告警是由哪臺核心交換機故障引發的？

〓 亂——序

因爲指標採集方式和計數據量的不一樣，直接致使了監控流處理效率是不同的。告警收到的次序不同，要如何排序並有效識別優先級？

因此在監控匱乏的時代要積極地搞建設，可是告警氾濫的時候要學會過濾。

監控、告警與運維

監控對象與度量指標

騰訊業務要監控的對象如上圖左，按照業務邏輯從下往上，下面是通用的監控層面，網絡、服務器、虛擬化還有應用，應用包括了組件的一些監控。

這裏舉了申請QQ號的業務場景案例，假設用戶在PC端發起申請QQ號的業務請求，請求走到WEB前端，然後是註冊服務，註冊QQ包含了三個信息：我的信息、個性化設置、增值服務。是否是QQ會員，是否要開通會員相似的服務，這是業務邏輯。

基於立體化地監控，假設用組件監控，不管是QQ仍是QQ空間、QQ音樂，都有一些通用的指標能夠衡量。如，打開的內存是多少？長鏈接數是多少？用戶進程、吞吐量、流量、CPU，業務層面返回碼分別是什麼？省市鏈接的成功率、請求量的分佈是什麼？這都與具體的業務邏輯無關。

在作監控時，把指標劃分紅兩大類：

☆ 低層次指標

把公共的、基礎設施等在業務邏輯之下的指標稱之爲低層次指標，如網絡、硬件、虛擬化等。

越低層次的指標讓監控系統或是告警帶來的噪音越大。在規劃監控處理或者優化監控策略時，要儘可能把低層次的指標自動化處理和收斂掉，儘可能以高緯度指標來告警，由於這纔是最核心最須要關注，最能反饋業務可用性的告警。若是一個公司用低層次指標來代替高層次的指標做用，那質量是很難管理的。

☆ 高層次指標

高層次指標要能更直接地反饋業務可用性的狀況，如成功率、延時、請求率等。

高層次的指標，要可以實時反饋業務真實情況的，在海量規模的業務運維場景下，人沒辦法看到單機的層面，必需要看到集羣的層面。

以模塊爲統一的運維對象，模塊是提供單一業務功能的集羣。爲何要管理到集羣？簡單理解就是把運維對象給抽象，作減法。拿騰訊的SNG來講，10萬+服務器，抽象成模塊後只有一萬多個模塊，較以前面對10萬個運維對象N個指標的告警量，如今面對一萬個模塊告警量要輕鬆很多，若是再把低層次的告警優化掉，可能只面對5000臺的告警。

在高層次指標中，還要有效的區分開單服務的高層次指標，和業務功能的高層次指標。要理清兩個概念，可靠性和可用性。

可靠性是指單個服務失敗的次數，因爲單個服務的失敗並不必定會影響整個QQ號申請業務功能可用性的降低，由於微服務自身有失敗重試的邏輯，在騰訊的運維經驗中，咱們會在可靠性和可用性之間作出必定取捨。

低層次指標雖然比較基礎或者能夠自動化解決，但每每是一些高層次指標的根源問題，善用低層次指標可以幫助運維快速定位高層次指標故障。

監控、告警與運維

監控的本質

監控無非是監控不少的值和率。把值和率分開是有考慮的，由於值報上來就是一個值，率是通過必定的計算才變成率的，其實都是把扁平化的信息包裝成高層次的指標。

監控最終的目標都是要分析狀態和發現異常，要從圖、表或數據中，分析如今業務的真實狀況，分析如今服務是否有異常。

監控、告警與運維

誤告警解決辦法

立體化監控，會帶來監控指標的爆炸，更有可能帶來告警數據失控，若是不能妥善處理，就會把告警通知演變成「狼來了」，失去了原來警報的效用。想有效解決告警多、誤告警多要面對幾點：

◇ 關聯分析

把一些真正重要的，須要經過事件、活動、指標提取出來。不要把什麼事情都告警出來，從而過多消耗告警的誠信。

◇ 無誤告警

怎麼樣把收斂策略、屏蔽策略用到極致，必要時能夠將二者組合，以達到更強化的效果。

◇ 持續運營

作好持續運營就是作好跟進，確保重要事情有人跟、有人度量，防止問題再三出現，要在流程上有保障的機制。

這樣就要求有一個質量體系來閉環管理，當監控發現業務架構不合理、代碼不合理等問題，可以經過該質量體系，推進業務、開發、運維去將優化措施落地，這也是爲了最終的商業價值，這是DevOps的觀點。

監控、告警與運維

案例：海量數據分析思路

這是手機Qzone的一個多維監控案例。當客戶端第一次鏈接服務端，會有一個心跳包，它是一個命令字，咱們以成功率來度量其質量，其實就是考量它維持長鏈接的可靠性。（若是長鏈接斷開移動客戶端連服務端的話要跟基站創建長鏈接，起碼三、4秒耗掉了，好友消息沒有辦法接收。）如圖，通常的功能，咱們要求三個9的質量。可是千萬別被平均數所矇騙了，一塊兒展開看看真實的狀況。

騰訊的服務是多地多活的，有一些分佈在規模相對小的AC點，有些分佈在比較大的DC點。根據全國用戶訪問服務端點的不一樣，騰訊內部稱之爲SET。講平均數按SET的維度展開，爲何「無SET」的成功率只有2個9？再展開一下。

按APN（接入方式WIFI、4G、3G等）展開，服務質量愈來愈差，只有兩個綠了，發現4G是100%，WIFI環境爲何只有兩個9了？

按運營商展開，質量數據更紅（差）了，雖然符合預期，但最終的問題尚未找到。

繼續按地區展開，發現全是紅的，但仍是沒有頭緒。

當再次按地域展開時，展開到浙江地區，發現出錯的全是安卓版本。而IOS的版本全是100%的成功率，共性問題呼之欲出。

這時候回過頭來反省一下排障的思路，可能打開的方式不對。在第三步的時候直接展開，好像真相就已經出來了，實際上是安卓的某幾個版本可能有這樣的隱患，致使這個心跳邏輯有問題。

這裏說明一個問題，對待海量多維數據的處理，分析方案很重要，在規劃和建設監控體系時，應該考慮好這點。今天給你們帶來3個小技巧，但願能給你們在作監控數據分析時有幫助。

海量分析三技巧

海量分析三技巧

海量監控數據分析的技巧：溯源、根因和優選。

爲了加快告警信息量的處理每每把監控的協議格式化，格式化處理完了以後再進一步格式化，把不少原始數據的蛛絲馬跡丟掉了，致使沒有辦法查到真正的問題。由於以前作的格式化會讓監控數據失真，影響排障的效率，因此上報協議的時候儘量的保留字段。

海量分析三技巧

溯源分析

〓 高維與降維打擊

高維與降維打擊，把一個指標的結果值或率以不一樣的緯度展開，要把每個維度的指標組合狀態異常都變成告警，這是很不現實的，由於壓根處理不過來。反而多維度的指標異常能經過平常報表彙總分析就能發現異常，而後經過考覈去持續的推進，把異常指標給理順、優化掉，這是就是高維、降維的打擊。

〓 級聯分析

網絡有一個詞叫微突發，網絡忽然擁塞了，致使一大波低層次和高層次的告警產生。好比，一個交換機異常，引起下聯服務器爆炸式的告警。當此類狀況發生，統一告警平臺所有不理，作好全局的收斂，以保證監控告警的有效性不受影響。

〓 逆向思惟

不能只看結果數據，要回到原始數據來看。若是要作到逆向思惟可生效，流處理集羣在真正加工完，存儲的結果數據以前要作最基礎的分析，把那部分日誌備份到大數據平臺作離線的計算，而後結果數據再走正常的流，去作告警也好，異常波動也好，由於不少異常的東西必需要看到原始數據。咱們曾經深刻分析相冊上傳照片的流水日誌，找到了大量異常的用戶照片，從而節省了大量的運營成本，這些都是結果數據沒法作到的效果。

海量分析三技巧

根因分析

用高層次的告警 收斂 低層次的告警
同一個集羣下既產生了低層次告警，又產生了高層次告警，低層次的告警不用發。

用主調的告警 收斂 被調的告警
模塊A調用模塊B，B掛了，A受不受影響？從保障業務可用性的角度，若是A沒有產生告警，證實該場景只是B的可靠性告警，告警通知開發而不是運維。但若是B掛了，A也產生了告警，運維就應該收到A的告警，B仍是告警給開發。推動告警分級（分值、分級、分人、分通道）的機制，實際上是慢慢把一些運維要作的事情分給開發，運維只看核心的，軟件可靠性這些開發來看，可靠性是開發的問題，可用性是運營質量的問題。

用緣由告警 收斂 現象告警：
在業務邏輯的調用聯調中，用緣由告警收斂掉現象告警。

用主動觸發的活動 屏蔽 對象的告警：
有些告警是因爲變動行爲引發的，要收斂掉。如正在作升級引起了告警，運維繫統要能關聯這些事件與告警。有高層次告警、低層次告警，還有運維的活動事件，都把這些集中在一塊兒，經過權重的算法，有一個排序決策說告警應該是告這條鏈路，而不是每個對象都重複告警。

海量分析三技巧

優選指標

核心指標論

優選指標應該是第一次對外分享，騰訊內部的系統代號叫DLP，是一種經過人工來篩選核心指標的方法，在大數據時代的今天，這種作法稍稍有些不夠優雅。如一個模塊可能有300－400個指標，這300－400個指標中，包含有低層次的指標，高層次的指標，但當這個模塊出問題的時候，這300－400個指標可能都會產生告警，那麼應該怎麼樣收斂呢？假若咱們提早已經對該模塊進行過核心指標的人工篩選，這個指標能表明模塊最真實的指標。

監控的相關性

監控是相關的，例如300個指標告警了，最核心的那個也會告警，最核心的告警了這300個指標能夠不告警，只看核心的就能夠了，爲何要人首選核心指標，由於暫時沒有辦法人工識別。

告警分級管理

基於核心的指標對告警作分級，非核心的開發本身收，核心的運維收，作到高規格保障。

下降流式監控的計算量

監控點越多，流的數據越大，整個監控流處理集羣規模很大，10萬臺機器光是流處理的集羣都是接近1500臺，當運營成本壓力大時，也能夠重點保障DLP指標的優先計算資源，保證優先給予容量的支持。

SNG織雲監控系統

用戶輿情分析監控

還有一個很核心的指標，就是織雲用戶輿情監控系統。簡單介紹這個系統，用戶輿情監控顧名思義就是監控用戶的聲音和反饋。用戶的意見反饋來源能夠分幾部分，一是AppStore的入口，另外一個是App內嵌的反饋入口，還有的就是騰訊的用戶反饋論壇，全部的數據都會被聚集到織雲輿情監控平臺上，而後經過機器學習實現自動分類。系統會把相似「QQ空間打不開」、「QQ空間用很差」等這些詞彙進行語意分析和歸類，而後統一告警成「QQ空間異常」，時間間隔是15分鐘顆粒度，技術細節不重點介紹。

當實現了用戶輿情監控後，咱們基本有把握說業務監控是360度無死角的（假設用戶都會反饋問題，且不考慮時間因素）。但這套監控先天就有門檻，由於要基於用戶的主動反饋行爲，同時須要較多的用戶反饋數據量，騰訊的用戶量基數很大，用戶主動反饋的量也很大。輿情監控能夠用於監控技術上的質量問題，也能用於監控產品的體驗或交互問題。

SNG織雲監控系統

有策略更要有自動化

告警自動化處理的前提是標準化運維體系，在SNG織雲監控體系下，全部告警處理會先通過預處理策略，而後再通過統一告警平臺的策略和算法，最終才被決策會否發出。

SNG織雲監控系統

精準試用的算法與策略

在定義指標狀態異常時，咱們的經驗是儘可能不要用固定閥值，要用也是動態閥值，不然在監控對象的閥值管理上就會有大量人工管理的成本。其餘的推薦策略如圖。

SNG織雲監控系統

常見業務監控圖形與策略

咱們在平常運維工做中，面對的監控圖形如上圖，趨勢有小波動、毛刺、無規律的，建議有針對性的套用監控策略，讓監控告警更精準。

SNG織雲監控系統

案例：監控自愈

分享一個織雲監控實現進程自愈的案例，流程中的模塊在部署時，運維自動化流程就會把進程和端口的信息註冊到CMDB中，而後監控服務會讀取該模塊須要監控的進程與端口信息，並把監控配置發送每臺機器的監控Agent上，本地的監控Agent經過定時Ps檢測進程和端口的運行狀況，若是發生異常，則自動經過標準化的管理找到命令進行啓動，若是啓動成功便實現了進程自愈。

若是啓動不了發給統一告警平臺，統一告警平臺來決策是否須要告警。當該告警緣由是由於基礎設施正在作變動影響時，也不會發出告警。一系列的監控自愈方案都是構建在織雲的自動化運維體系中。

SNG織雲監控系統

常見的收斂算法

◇ 毛刺收斂

在織雲監控中，告警策略爲了防止毛刺的影響，會將告警策略定義爲10分鐘發生3次相似的模式。

◇ 同類收斂

一個模塊有300個監控實例，產生了300條告警，只要有一條告訴給運維，對於運維同類收斂掉了。

◇ 時間收斂

生產環境中有不少定時的任務，如定時跑量會引發I/O的陡增等異常，這種能夠針對性的收斂掉。

◇ 晝夜收斂

有一些告警，在分佈式服務的高可用架構下，晚上不須要告警出來，能夠等白天才告警，更人性化的管理。

◇ 變動收斂

若是告警時間點有運維的活動，就要收斂掉它。怎麼作到的？取決於要把運維的活動都收口在標準化運維的平臺，運維平臺對生產環節都要將變動日誌寫入在變動記錄中心，而後統一告警系統可以關聯變動記錄來決策是收斂仍是發出告警。

SNG織雲監控系統

織雲監控構建的質量體系

織雲監控構建的質量體系，分紅用戶端、客戶端、服務端、基礎端，定義核心指標DLP，而且善用分級告警、分渠道告警，結合短信、QQ、微信和電話等渠道實現告警通知，整個質量監控體系都是圍繞預警、自愈、分析、排障礙的能力構建。

SNG織雲監控系統

織雲監控：質量體系

織雲監控的質量體系，但願打造一個閉環，可以實現持續反饋、度量、優化，讓團隊間可以有效地協同工做，更高效更有效。

監控能力

全局地看、須要什麼樣的監控能力和監控點，同時要理清指標是怎麼分層的，哪些指標是重要的？最終把它轉成業務看得懂的高層次指標。

業務可用性

運維要看什麼，要看可靠性仍是可用性，若是規模不大看可靠性能夠，可是在海量的場景下可靠性太細，要抽象核心指標來度量，用於衡量可用性。可靠性則能夠經過考覈體系去度量與管理，結合QA和老闆的力量來推進開發團隊的投入與優化。

用戶體驗

作技術運營會有視角的盲點，會常常迷戀可用性的數據是4個九、5個9，但這並不徹底表明服務質量好，當用戶鏈接不上咱們的服務端時，幾個9的意義都不大。這是一個很現實的問題，所以用戶體驗監控必定要作，由於內部的可用性再高都不表明用戶用得好。

技術解決

要有技術解決方案和自動化工具，還要有協助用戶排障的工具，以及根因分析的算法平臺等等。

統計分析

最終造成可度量的指標、可考覈的、可展現的，最好是DIY展現的，監控數據的統計/報表能力服務化，應發揮更多的角色來使用監控數據，而非僅限於運維角色。

持續改進

最終持續的改進不管是架構的問題、代碼的問題，仍是由於標準化的問題或非功能落地推動不了的問題，都是須要數字來度量和推進。最好，這個數字要能間接的反饋商業的價值，也就是DevOps提倡的思路。

最後，質量體系確定是副作用於監控能力再去造成這樣的閉環，跟開發怎麼溝通？跟產品怎麼溝通？跟QA、跟客服怎麼溝通？要把他們用起來，要把他們關注的點牽引住，最終落到運維想實現的目標上是最好的，這很DevOps，也撬動了老闆的思惟，爭取從上而下的支持作好質量體系的建設。

DevOps最後一棒

結語　　　　

咱們常常說DevOps很難落地，爲何難？由於咱們老是想要去影響老闆，先改變文化再改變工做方法，但這談何容易。若是是運維和開發能聯合起來，先從小的重點的業務抓起，用數聽說話體現DevOps能給業務帶來的最終的商業價值，說不定會起到事半功倍的效果。