少年，你的告警量可以更少些！
作者簡介：
梁定安，騰訊織雲負責人，目前就職於騰訊社交網路運營部，開放運維聯盟委員，騰訊雲佈道師，騰訊課堂運維講師，EXIN DevOps Master講師，鳳凰項目沙盤教練，復旦大學客座講師。請原諒我的標題黨，謝謝你點擊進來，本文主要是從DevOps持續反饋的視角出發，圍繞著構建企業質量體系的目標，談談如何做好監控、做好告警、做好運營這3件運維繞不開的大事。
備註：此文是5月6日深圳DevOps與SRE線下技術交流大會，《DevOps最後一棒，有效構建海量運營的持續反饋能力》主題演講的文字稿。
DevOps的最後一棒（圖01）
這張圖概括了整個DevOps的體系，它最後的一個環節，就是做運營和終結的環節。對與運營和終結的理解，我認為應該包含兩個緯度，一是這次運維活動的質量運營與終結；二是產品的技術運營和生命周期的終結。今天我們聊下在產品生命周期結束前，我們在技術運營階段構建的質量體系，以實現持續反饋和優化的目標。
持續反饋於運維的理解（圖02）
監控——覆蓋率、狀態反饋、指標度量。
監控要做到360度無死角，業務出現了什麼問題都能發現，有了監控的反饋，可以看到實時監控的狀態，同時，當指標發生變化的時候也需要看到一些反饋。告警——時效性、準確性、觸及率。
業務越來越複雜，層次越來越多，每一個監控點都會產生數據指標、狀態異常，會收到越來越多的告警。未看到或者看到未處理都需要承擔責任，因為收到的並非都是誤告警。最重要還要有觸及率，告警由誰發布與處理？運營——RCA、事件管理、報表/考核
問題再三出現、必須從根源優化。通過事件管理機制保證RCA可以落地，最後通過報表和考核去給運維賦予權利推動相關優化活動的開展，包括架構和代碼的優化等等。
全面的監控點（圖03）
騰訊織雲監控體系是按照互聯網業務不同的層級進行管理，從下向上，有伺服器層、資料庫、邏輯層、中間計算的這一層，有接入層、負載均衡，有我們的機房，DNS服務、客戶端、用戶端，為了做到無死角，我們布局了很多監控點。
在實現輿情監控後，織雲監控點做到了100%的覆蓋，但並不能高枕無憂，因為當監控點做得越多越立體化的360度無死角後，每個最細節的點都有指標去度量，指標數據爆炸很有可能成為另一個潛在的監控隱患。運營階段要解決的問題（圖04）
繁——簡
在具體生產過程中會產生運維的事件或者是故障，經常會有死機，以及各層監控告警，這些繁瑣的告警、故障，改如何簡單化？泛——精
舉個案例，在一台核心的交換機下，假設其下聯有1000台的機器分布到數據層、邏輯層、接入層等等，當這台交換機故障不可用時，由於有立體化監控的存在，每個監控點都會產生大量的告警信息，我們要如何發現這些告警是由於這台核心交換機故障引起的呢？亂——序
由於指標採集方式和計數據量的不同，直接導致了監控的流處理效率是不一樣的，告警收到的次序不一樣，我們要如何排序，如何有效識別優先順序？所以我們今天重點聊下，在監控匱乏的時代我們在積極的搞建設，但是告警泛濫的時候我們要學會過濾。
監控對象與度量指標（圖05）
騰訊業務要監控的對象如左圖，按照業務邏輯從下往上，下面是通用的監控層面，網路、伺服器、虛擬化還有應用，應用包括了組件的一些監控。
這裡舉了申請QQ號的業務場景案例，假設用戶在PC端發起申請QQ號的業務請求，請求走到WEB前端，而後是註冊服務，註冊QQ包含了三個信息：個人信息、個性化的設置、增值服務。
基於立體化的織雲監控體系，假設用組件的監控，無論是QQ還是QQ空間、QQ音樂，都有一些通用的指標可以衡量。如，打開的內存是多少？長連接數是多少？用戶進程、吞吐量、流量、CPU，業務層面返回碼的分別是什麼？省市連接的成功率、請求量的分布是什麼？這都與具體的業務邏輯無關。
在做監控時，我們把指標劃分成兩大類：
低層次指標把公共的、基礎設施等在業務邏輯之下的指標稱之為低層次的指標，網路、硬體、虛擬化等。
高層次指標
高層次的指標要能更直接的反饋業務可用性的情況，如成功率、延時、請求率等。監控點
越低層次的指標會給讓監控系統或者是告警帶來的噪音越大的，在規劃監控處理或者優化監控策略時，要盡量把低層次的指標自動化處理或收斂掉，盡量以高緯度的指標來告警，因為這才是最核心需要關注的，也是最能反饋業務可用性的。如果一個公司用低層次指標來代替高層次的指標的作用，那質量是很難管理好的。高層次的指標，是要能夠實時反饋業務的真實狀況的，在海量規模的業務運維場景下，靠人沒辦法看到單機的層面，必須要看到集群的層面。
以SNG運維舉例，我們以模塊為統一的運維對象，模塊是提供單一業務功能的集群。為什麼要管理到集群呢？簡單的理解就是把運維對象給抽象，做減法。拿騰訊的SNG來說，有10萬+的伺服器，抽象成模塊後只有一萬多個模塊，相當於以前面對10萬個運維對象的N個指標的告警量，現在面對一萬個模塊告警量要輕鬆不少。再把低層次的告警優化掉，可能只面對5000台的告警了。
在高層次指標中，還要有效的區分開單服務的高層次的指標，和業務功能的高層次的指標。我們要先理清兩個概念，可靠性和可用性。
可靠性是指單個服務失敗的次數，由於單個服務的失敗並不一定會影響整個申請QQ號業務功能的可用性的下降，因為微服務自身有失敗重試的邏輯，在騰訊的運維經驗中，我們會在可靠性和可用性之間做出一定取捨。
低層次的指標雖然比較基礎或者可以自動化的解決，但往往是一些高層次指標的根源的問題，善用這些低層次的指標能夠幫助運維快速的定位高層次指標的故障原因。
監控的本質（圖06）
監控無非就是很多的值、很多的率，把值和率分開是有考慮的，因為值報上來就是一個值了，率是經過一定的計算才變成率的，其實都是把扁平化的信息包裝成高層次的指標。
最終監控的目標都是要分析狀態和發現異常的，要從圖、表或數據中，分析現在業務的真實的情況，分析現在服務是否有異常。為什麼要強調有效（圖07）
立體化的監控，會帶來監控指標的爆炸，更有可能帶來告警數據的失控，如果不能妥善處理，就會把告警通知演變成「狼來了」，失去了原來警報的效用。要有效的解決告警多、誤告警多我們要面對幾點：
1、 關聯分析：把一些真正重要的，需要通過事件、活動、指標提取出來。希望不要把什麼事情都告警出來，而過多的消耗告警的誠信。2、無誤告警：
怎麼樣把收斂策略、屏蔽的策略用到極致，必要時可以將兩者組合，以達到更強化的效果。
3、 持續運營
做好持續運營就是做好跟進，為了保證重要的事情有人跟、有人度量，防止問題再三出現，要在流程上有保障的機制。這樣就要求我們有一個質量體系來閉環管理，當監控發現業務架構不合理、代碼不合理等問題，能夠通過該質量體系，推動業務、開發、運維去將優化措施落地，這也是為了最終的商業價值，這是DevOps的觀點。案例：扼殺真相的「結論」（圖08）
按被調的聚集展開（圖09）
按APN展開（圖10）
按運營商展開（圖11）
按地區展開（圖12）
繼續按地區展開，發現全是紅的，但還是沒有頭緒。
按運營商展開（圖13）
當再次按地域展開時，展開到浙江地區，我們發現出錯的全是安卓的版本。而IOS的版本，全是100%的成功率，共性問題呼之欲出？
一擊命中（圖14）
這裡說明一個問題，我們對待海量的多維數據的處理，分析方案很重要，在我們規劃和建設監控體系時，應該考慮好這點。今天給大家帶來了3個小技巧，希望能給大家在做監控數據分析時有幫助。
海量監控數據分析3個小技巧（圖15）
海量監控數據分析的技巧：溯源、根因和優選。
為了加快告警信息量的處理往往把監控的協議格式化，格式化處理完了之後進一步的格式化，把很多原始數據的蛛絲馬跡丟掉了，導致沒有辦法查到真正的問題。因為之前做的格式化會讓監控數據失真，影響排障的效率，所以上報協議的時候儘可能的保留欄位。溯源分析（圖16）
高緯與降維打擊
高維與降維打擊，把一個指標的結果值或率以不同的緯度展開，要把每一個緯度的指標組合的狀態異常都變成告警，這是很不現實的，因為壓根處理不過來。反而多維度的指標異常能通過日常的報表匯總分析就能發現的異常，然後通過考核去持續的推動，把異常指標給理順、優化掉，這是就是高維、降維的打擊。級聯分析
網路有一個詞叫微突發，網路突然擁塞了，導致一大波低層次和高層次的告警產生。舉個案例，一個交換機異常，引發下聯的伺服器爆炸式的告警，當此類情況發生，我們的統一告警平台全部不理，做好全局的收斂，以保證監控告警的有效性不受影響。逆向思維
意思是不能只看結果數據，要回到原始數據來看。如果要做到逆向思維可生效，那流處理集群在真正加工完，存儲的結果數據之前要做最基礎的清晰，把那部分日誌備份到大數據平台做離線的計算，然後結果數據再走正常的流，去做告警也好，異常波動也好，因為很多異常的東西必須要看到原始數據。我們曾經深入分析相冊的日上傳照片流水日誌，找到了大量異常的用戶照片，從而節省了大量的運營成本，這些都是結果數據無法做到的效果。根因分析（圖17）
用高層次的告警收斂低層次的告警：
同一個集群下既產生了低層次的告警，又產生了高層次的告警，低層次的告警不用發。用主調的告警收斂被調的告警：
模塊A調用模塊B，B掛了，A受不受影響？從保障業務可用性的角度，如果A沒有產生告警，證明該場景只是B的可靠性告警，告警通知開發而不是運維。但如果B掛了，A也產生了告警，運維就應該收到A的告警，B還是告警給開發。推進告警分級（分值、分級、分人、分通道）的機制，其實是慢慢把一些運維要做的事情分給開發，運維只看核心的，軟體可靠性這些開發來看，可靠性是開發的問題，可用性是運營質量的問題。用原因告警收斂現象告警：
在業務邏輯的調用聯調中，用原因告警收斂掉現象告警。（具體可參考2016年3月深圳運維大會上，我關於監控的分享PPT。）用主動觸發的活動去屏蔽一個對象的告警：
有些告警是由於變更的行為引起的，要收斂掉。如正在做升級引發了告警，運維繫統要能關聯這些事件與告警。有高層次的告警、低層次的告警，還有運維的活動事件，都把這些集中在一起，通過權重的演算法，有一個排序決策說告警應該是告這條鏈路，而不是每一個對象都重複的告警。優選指標（圖18）
DLP
核心指標論優選指標應該是第一次對外分享，騰訊內部的系統代號叫DLP，是一種通過人工來篩選核心指標的方法，可以說在大數據時代的今天，這種做法稍稍有些不夠優雅。加入，一個模塊可能有300－400個指標，這300－400個指標中，包含有低層次的指標，高層次的指標，但當這個模塊出問題的時候，這300－400個指標可能都會產生告警，那麼應該怎麼樣收斂呢？倘若我們提前已經對該模塊進行過核心指標的人工篩選，這個指標能代表模塊最真實的指標。監控的相關性
監控是相關的，例如300個指標告警了，最核心的那個也會告警，最核心的告警了這300個指標可以不告警，只看核心的就可以了，為什麼要人手選核心指標，因為暫時沒有辦法人工識別。告警分級管理
可以基於核心的指標對告警做分級，非核心的開發自己收，核心的運維收，高規格保障。降低流試監控的計算量
監控點越多，流的數據越大，整個監控流處理集群規模很大，10萬台機器光是流處理的集群都是接近1500台，當運營成本壓力大時，我們也可以重點的保障DLP的指標的優先計算資源，保證優先給予容量的支持。用戶輿情分析監控（圖19）
有策略更要有自動化（圖20）
精準適用的演算法與策略（圖21）
在定義指標狀態異常時，我們的經驗是盡量不要用固定閥值，要用也是動態閥值，否則在監控對象的閥值管理上就會有大量的人工管理的成本。其他的推薦策略如圖。
常見的業務監控圖形與策略（圖22）
我們在日常運維工作中，面對的監控的圖形就如上圖，趨勢有小波動、毛刺、無規律的，建議大家有針對性的套用監控策略，讓監控告警更精準。
案例：監控自愈（圖23）
常用的收斂演算法（圖24）
同類收斂：
一個模塊有300個監控實力，產生了300條的告警，只要有一條告給運維，對於運維同類收斂掉了。時間收斂：
生產環境中有很多定時的任務，如定時跑批會引起I/O的陡增等異常，這種可以針對性的收斂掉。晝夜收斂：
有一些告警，在分散式服務的高可用架構下，晚上不需要告警出來，可以等白天才告警，更人性化的管理。變更收斂：
如果告警的時間點有運維的活動，就要收斂掉它。怎麼做到的？取決於要把運維的活動都收口在標準化運維的平台，運維平台對生產環節都要講變更日誌寫入在變更記錄中心那裡，然後統一告警系統能夠關聯變更記錄來決策是收斂還是發出告警。織雲監控構建的質量體系（圖25）
織雲監控：質量體系（圖26）
監控能力：
全局的看、需要什麼樣的監控能力和監控點，同時要理清指標是怎麼分層的，哪些指標是重要的？最終把它轉成業務看得懂的高層次指標。業務可用性：
運維要看什麼，要看可靠性還是可用性，如果規模不大看可靠性可以，但是在海量的場景下可靠性要太細，要抽象核心指標來度量，用于衡量可用性。可靠性則可以通過考核體系去度量與管理，結合QA和老闆的力量來推動開發團隊的投入與優化。用戶體驗：
做技術運營會有視角的盲點，會經常迷戀可用性的數據是4個9、5個9，但這並不完全代表了我們服務質量好，當用戶連接不上我們的服務端時，幾個9的意義都不大。這是一個很現實的問題，因此用戶體驗監控一定要做，因為內部的可用性再高都不代表用戶用得好。技術解決：
要有技術解決的方案，要有自動化的工具，有協助用戶排障的工具，有根因分析的演算法平台等等。統計分析：
最終形成可度量的指標、可考核的、可展示的，最好是DIY展示的，監控數據的統計/報表能力服務化，應發揮更多的角色來使用監控數據，而非僅限於運維角色。持續改進：
最終持續的改進無論是架構的問題、代碼的問題，還是因為標準化的問題或非功能落地推進不了的問題，都是需要數字來度量和推動。最好，這個數字要能間接的反饋商業的價值，也就是DevOps提倡的思路。最後，質量體系肯定是反作用於監控能力再去形成這樣的閉環，跟開發怎麼溝通？跟產品怎麼溝通？跟QA、跟客服怎麼溝通？要把他們用起來，要把他們關注的點牽引住，最終落到運維想實現的目標上是最好的，這很DevOps，也撬動老闆的思維，爭取從上而下的支持做好質量體系的建設。
我們經常說DevOps很難落地，為什麼難？因為我們總是想要去影響老闆，先改變文化再改變工作方法，但這談何容易。如果是運維和開發能聯合起來，先從小的重點的業務抓起，用數據說話體現DevOps能給業務帶來的最終的商業價值，說不定會起到事半功倍的效果。
推薦閱讀：
※Python 項目的部署，目前互聯網公司有哪些成熟的方案？
※DevOps 的意義
※在 2016 年做 DevOps 是一種什麼樣的體驗？
※基於Docker持續交付平台建設的實踐