本文主要是從 DevOps 持續(xù)反饋的視角出發(fā)，圍繞著構(gòu)建企業(yè)質(zhì)量體系的目標(biāo)，談?wù)勅绾巫龊帽O(jiān)控、做好告警、做好運(yùn)營(yíng)這3件運(yùn)維繞不開的大事。

備注：本文由IT大咖說（id：itdakashuo）轉(zhuǎn)自數(shù)人云公眾號(hào)（id：dmesos），此文是5月6日深圳DevOps與SRE線下技術(shù)交流大會(huì)，《DevOps最后一棒，有效構(gòu)建海量運(yùn)營(yíng)的持續(xù)反饋能力》主題演講的文字稿。

嘉賓演講視頻回顧及PPT：http://suo.im/5bNLnb

1.DevOps持續(xù)反饋關(guān)鍵在于做好運(yùn)營(yíng)

這張圖概括了整個(gè)DevOps的體系，它最后的一個(gè)環(huán)節(jié)，就是做運(yùn)營(yíng)和終結(jié)的環(huán)節(jié)。對(duì)與運(yùn)營(yíng)和終結(jié)的理解，我認(rèn)為應(yīng)該包含兩個(gè)緯度，一是這次運(yùn)維活動(dòng)的質(zhì)量運(yùn)營(yíng)與終結(jié)；二是產(chǎn)品的技術(shù)運(yùn)營(yíng)和生命周期的終結(jié)。今天我們聊下在產(chǎn)品生命周期結(jié)束前，我們?cè)诩夹g(shù)運(yùn)營(yíng)階段構(gòu)建的質(zhì)量體系，以實(shí)現(xiàn)持續(xù)反饋和優(yōu)化的目標(biāo)。

2.產(chǎn)品在運(yùn)營(yíng)階段運(yùn)維發(fā)揮的關(guān)鍵作用

在騰訊運(yùn)維看來，要做好持續(xù)反饋的落地，我們有必要做好3點(diǎn)：

①監(jiān)控——覆蓋率、狀態(tài)反饋、指標(biāo)度量

監(jiān)控要做到360度無死角，業(yè)務(wù)出現(xiàn)了什么問題都能發(fā)現(xiàn)，有了監(jiān)控的反饋，可以看到實(shí)時(shí)監(jiān)控的狀態(tài)，同時(shí)，當(dāng)指標(biāo)發(fā)生變化的時(shí)候也需要看到一些反饋。

②告警——時(shí)效性、準(zhǔn)確性、觸及率

業(yè)務(wù)越來越復(fù)雜，層次越來越多，每一個(gè)監(jiān)控點(diǎn)都會(huì)產(chǎn)生數(shù)據(jù)指標(biāo)、狀態(tài)異常，會(huì)收到越來越多的告警。未看到或者看到未處理都需要承擔(dān)責(zé)任，因?yàn)槭盏降牟⒎嵌际钦`告警。最重要還要有觸及率，告警由誰(shuí)發(fā)現(xiàn)與處理？

③運(yùn)營(yíng)——RCA、事件管理、報(bào)表/考核

問題再三出現(xiàn)、必須從根源優(yōu)化。通過事件管理機(jī)制保證RCA可以落地，最后通過報(bào)表和考核去給運(yùn)維賦予權(quán)利推動(dòng)相關(guān)優(yōu)化活動(dòng)的開展，包括架構(gòu)和代碼的優(yōu)化等等。

3.騰訊業(yè)務(wù)的立體化監(jiān)控

騰訊的業(yè)務(wù)按照不同的層級(jí)進(jìn)行管理，從下向上，有服務(wù)器層、數(shù)據(jù)庫(kù)、邏輯層、中間計(jì)算的這一層，有接入層、負(fù)載均衡，有我們的機(jī)房，DNS服務(wù)、客戶端、用戶端，為了做到無死角，我們規(guī)劃與建設(shè)了很多監(jiān)控點(diǎn)，美其名曰立體化監(jiān)控。

在2014年實(shí)現(xiàn)用戶輿情監(jiān)控能力后，我們的監(jiān)控點(diǎn)做到了100%的覆蓋（不考慮時(shí)間緯度：P），但并不能高枕無憂，因?yàn)楫?dāng)監(jiān)控點(diǎn)做得越多越立體化的360度無死角后，每個(gè)最細(xì)節(jié)的點(diǎn)都會(huì)有指標(biāo)去度量，指標(biāo)數(shù)據(jù)爆炸很有可能成為另一個(gè)潛在的監(jiān)控隱患。

4.監(jiān)控系統(tǒng)大興土木之后的思考

從而引出，我們迫切需要在運(yùn)營(yíng)階段要解決的難題：

繁 -> 簡(jiǎn)

在具體生產(chǎn)過程中會(huì)產(chǎn)生運(yùn)維的事件或者是故障，經(jīng)常會(huì)有死機(jī)，以及各層監(jiān)控告警，這些繁瑣的告警、故障，改如何簡(jiǎn)單化？

泛 -> 精

舉個(gè)案例，在一臺(tái)核心的交換機(jī)下，假設(shè)其下聯(lián)有1000臺(tái)的機(jī)器分布到數(shù)據(jù)層、邏輯層、接入層等等，當(dāng)這臺(tái)交換機(jī)故障不可用時(shí)，由于有立體化監(jiān)控的存在，每個(gè)監(jiān)控點(diǎn)都會(huì)產(chǎn)生大量的告警信息，我們要如何發(fā)現(xiàn)這些告警是由于這臺(tái)核心交換機(jī)故障引起的呢？

亂 -> 序

由于指標(biāo)采集方式和計(jì)數(shù)據(jù)量的不同，直接導(dǎo)致了監(jiān)控的流處理效率是不一樣的，告警收到的次序不一樣，我們要如何排序，如何有效識(shí)別優(yōu)先級(jí)？

所以我們今天重點(diǎn)聊下，在監(jiān)控匱乏的時(shí)代我們?cè)诜e極的搞建設(shè)，但是告警泛濫的時(shí)候我們要學(xué)會(huì)過濾。

5.理清監(jiān)控對(duì)象與指標(biāo)的關(guān)系

騰訊業(yè)務(wù)要監(jiān)控的對(duì)象如左圖，按照業(yè)務(wù)邏輯從下往上，下面是通用的監(jiān)控層面，網(wǎng)絡(luò)、服務(wù)器、虛擬化還有應(yīng)用，應(yīng)用包括了組件的一些監(jiān)控。

這里舉了申請(qǐng)QQ號(hào)的業(yè)務(wù)場(chǎng)景案例，假設(shè)用戶在PC端發(fā)起申請(qǐng)QQ號(hào)的業(yè)務(wù)請(qǐng)求，請(qǐng)求走到WEB前端，而后是注冊(cè)服務(wù)，注冊(cè)QQ包含了三個(gè)信息：個(gè)人信息、個(gè)性化的設(shè)置、增值服務(wù)。

基于立體化的監(jiān)控，假設(shè)用組件的監(jiān)控，無論是QQ還是QQ空間、QQ音樂，都有一些通用的指標(biāo)可以衡量。如，打開的內(nèi)存是多少？長(zhǎng)連接數(shù)是多少？用戶進(jìn)程、吞吐量、流量、CPU，業(yè)務(wù)層面返回碼的分別是什么？省市連接的成功率、請(qǐng)求量的分布是什么？這都與具體的業(yè)務(wù)邏輯無關(guān)。

為了理清海量的監(jiān)控?cái)?shù)據(jù)，我們把指標(biāo)劃分成兩大類：

低層次指標(biāo)。把公共的、基礎(chǔ)設(shè)施等在業(yè)務(wù)邏輯之下的指標(biāo)稱之為低層次的指標(biāo)，網(wǎng)絡(luò)、硬件、虛擬化等。低層次指標(biāo)可以通過自動(dòng)化運(yùn)維體系實(shí)現(xiàn)告警的自動(dòng)處理與恢復(fù)，也是業(yè)內(nèi)常聽到的故障自愈。

高層次指標(biāo)。高層次的指標(biāo)要能更直接的反饋業(yè)務(wù)可用性的情況，如成功率、延時(shí)、請(qǐng)求率等。高層次指標(biāo)在信息爆炸的時(shí)代，能清晰的說明問題點(diǎn)，但倘若要排障還是有可能需要分析低層次的指標(biāo)。

越基礎(chǔ)的低層次的指標(biāo)會(huì)給讓監(jiān)控系統(tǒng)或者是告警帶來的噪音越大的，在規(guī)劃監(jiān)控處理或者優(yōu)化監(jiān)控策略時(shí)，要盡量把低層次的指標(biāo)自動(dòng)化處理或收斂掉，盡量以高緯度的指標(biāo)來告警，因?yàn)檫@才是最核心需要關(guān)注的，也是最能反饋業(yè)務(wù)可用性的。如果某個(gè)運(yùn)維團(tuán)隊(duì)還在因低層次指標(biāo)的故障而疲于救火，是很難全局管控好業(yè)務(wù)質(zhì)量的。

高層次的指標(biāo)，是要能夠?qū)崟r(shí)反饋業(yè)務(wù)的真實(shí)狀況的。以騰訊經(jīng)驗(yàn)為例，在海量規(guī)模的業(yè)務(wù)運(yùn)維場(chǎng)景下，靠人沒辦法看到單機(jī)的層面，必須要看到集群的層面。以織云運(yùn)維理念舉例，CMDB將模塊作為統(tǒng)一的運(yùn)維對(duì)象，模塊是提供單一業(yè)務(wù)功能的集群。為什么要管理到集群呢？簡(jiǎn)單的理解就是把運(yùn)維對(duì)象做抽象，做減法。在SNG業(yè)務(wù)體量下，有10萬(wàn)+的服務(wù)器，抽象成模塊后只有一萬(wàn)多個(gè)模塊，相當(dāng)于以前面對(duì)10萬(wàn)個(gè)運(yùn)維對(duì)象的N個(gè)指標(biāo)的告警量，現(xiàn)在面對(duì)一萬(wàn)個(gè)模塊告警量要輕松不少。再把低層次的告警優(yōu)化掉，可能只面對(duì)5000臺(tái)的告警了。

在高層次指標(biāo)中，還要有效的區(qū)分開單服務(wù)的高層次的指標(biāo)，和業(yè)務(wù)功能的高層次的指標(biāo)。我們要先理清兩個(gè)概念，可靠性和可用性。

可靠性是指單個(gè)服務(wù)失敗的次數(shù)，由于單個(gè)服務(wù)的失敗并不一定會(huì)影響整個(gè)申請(qǐng)QQ號(hào)業(yè)務(wù)功能的可用性的下降，因?yàn)槲⒎?wù)自身有失敗重試的邏輯，在騰訊的運(yùn)維經(jīng)驗(yàn)中，我們會(huì)在可靠性和可用性之間做出一定取舍。

低層次的指標(biāo)雖然比較基礎(chǔ)或者可以自動(dòng)化的解決，但往往是一些高層次指標(biāo)的根源的問題，善用這些低層次的指標(biāo)能夠幫助運(yùn)維快速的定位高層次指標(biāo)的故障原因。

6.看清監(jiān)控的本質(zhì)

那么我們可以看清監(jiān)控的本質(zhì)，無非就是收集和計(jì)算得到一些值和率，通過一定的分析策略或算法，然后把結(jié)論以不同的形式展現(xiàn)，最終達(dá)到分析狀態(tài)和發(fā)現(xiàn)異常的目標(biāo)。（把值和率分開是有考慮的，因?yàn)橹祱?bào)上來就是一個(gè)值了，率是經(jīng)過一定的計(jì)算才變成率的，其實(shí)都是把扁平化的信息包裝成高層次的指標(biāo)。）

7.海量運(yùn)營(yíng)監(jiān)控需要強(qiáng)調(diào)信息的有效性

立體化的監(jiān)控，會(huì)帶來監(jiān)控指標(biāo)的爆炸，更有可能帶來告警數(shù)據(jù)的失控，如果不能妥善處理，就會(huì)把告警通知演變成“狼來了”，失去了原來警報(bào)的效用。要有效的解決告警多、誤告警多我們要面對(duì)幾點(diǎn)：

1.關(guān)聯(lián)分析。把一些真正重要的，需要通過事件、活動(dòng)、指標(biāo)提取出來。希望不要把什么事情都告警出來，而過多的消耗告警的誠(chéng)信。

2.無誤告警。怎么樣把收斂策略、屏蔽的策略用到極致，必要時(shí)可以將兩者組合，以達(dá)到更強(qiáng)化的效果。

3.持續(xù)運(yùn)營(yíng)。做好持續(xù)運(yùn)營(yíng)就是做好跟進(jìn)，為了保證重要的事情有人跟、有人度量，防止問題再三出現(xiàn)，要在流程上有保障的機(jī)制。這樣就要求我們有一個(gè)質(zhì)量體系來閉環(huán)管理，當(dāng)監(jiān)控發(fā)現(xiàn)業(yè)務(wù)架構(gòu)不合理、代碼不合理等問題，能夠通過該質(zhì)量體系，推動(dòng)業(yè)務(wù)、開發(fā)、運(yùn)維去將優(yōu)化措施落地，這也是為了最終的商業(yè)價(jià)值，這是DevOps的觀點(diǎn)。

8.一個(gè)多維分析的監(jiān)控案例

一起看個(gè)小案例：扼殺真相的“結(jié)論”。

這是手機(jī)Qzone的一個(gè)多維監(jiān)控案例。當(dāng)客戶端第一次連接服務(wù)端，會(huì)有一個(gè)心跳包，它是一個(gè)命令字，我們以成功率來度量其質(zhì)量，其實(shí)就是考量它維持長(zhǎng)連接的可靠性。（如果長(zhǎng)連接斷開移動(dòng)客戶端連服務(wù)端的話要跟基站建立長(zhǎng)連接，起碼3、4秒耗掉了，好友消息沒有辦法接收。）如圖，一般的功能，我們要求三個(gè)9的質(zhì)量。但是千萬(wàn)別被平均數(shù)所蒙騙了，我們一起展開看看真實(shí)的情況。

騰訊的服務(wù)是多地多活的，有一些分布在規(guī)模相對(duì)小的AC點(diǎn)，有些分布在比較大的DC點(diǎn)。根據(jù)全國(guó)用戶訪問的服務(wù)端的點(diǎn)的不同，騰訊內(nèi)部稱之為SET。講平均數(shù)按SET的緯度展開，為什么“無SET”的成功率只有2個(gè)9？再展開一下。

按APN（接入方式wifi、4G、3G等）展開，服務(wù)質(zhì)量越來越差，只有兩個(gè)綠了，你會(huì)4G是100%，wifi的環(huán)境為什么只有兩個(gè)9了？

按運(yùn)營(yíng)商展開，質(zhì)量數(shù)據(jù)更紅（差）了，雖然符合預(yù)期，但最終的問題還沒有找到。

繼續(xù)按地區(qū)展開，發(fā)現(xiàn)全是紅的，但還是沒有頭緒。

當(dāng)再次按地域展開時(shí)，展開到浙江地區(qū)，我們發(fā)現(xiàn)出錯(cuò)的全是安卓的版本。而IOS的版本，全是100%的成功率，共性問題呼之欲出？

倘若我們?cè)诘谌降臅r(shí)候直接展開，真相就已經(jīng)出來了，其實(shí)是安卓的某幾個(gè)版本，可能有這樣的隱患，導(dǎo)致我們這個(gè)心跳邏輯有問題。

這里說明一個(gè)問題，我們對(duì)待海量的多維數(shù)據(jù)的處理，分析方案很重要，在我們規(guī)劃和建設(shè)監(jiān)控體系時(shí)，應(yīng)該考慮好這點(diǎn)。今天給大家?guī)砹?個(gè)小技巧，希望能給大家在做監(jiān)控?cái)?shù)據(jù)分析時(shí)有幫助。

9.對(duì)海量數(shù)據(jù)的分析需要有技巧

為此我們得出海量監(jiān)控?cái)?shù)據(jù)分析的3個(gè)小技巧：

- 溯源

- 根因

- 優(yōu)選

為了加快告警信息量的處理往往把監(jiān)控的協(xié)議格式化，格式化處理完了之后進(jìn)一步的格式化，把很多原始數(shù)據(jù)的蛛絲馬跡丟掉了，導(dǎo)致沒有辦法查到真正的問題。因?yàn)橹白龅母袷交瘯?huì)讓監(jiān)控?cái)?shù)據(jù)失真，影響排障的效率，所以上報(bào)協(xié)議的時(shí)候盡可能的保留字段。

10.溯源分析實(shí)踐簡(jiǎn)介

先談?wù)勊菰矗?/p>

高緯與降維打擊。高維與降維打擊，把一個(gè)指標(biāo)的結(jié)果值或率以不同的緯度展開，要把每一個(gè)緯度的指標(biāo)組合的狀態(tài)異常都變成告警，這是很不現(xiàn)實(shí)的，因?yàn)閴焊幚聿贿^來。反而多維度的指標(biāo)異常能通過日常的報(bào)表匯總分析就能發(fā)現(xiàn)的異常，然后通過考核去持續(xù)的推動(dòng)，把異常指標(biāo)給理順、優(yōu)化掉，這是就是高維、降維的打擊。

級(jí)聯(lián)分析。網(wǎng)絡(luò)有一個(gè)詞叫微突發(fā)，網(wǎng)絡(luò)突然擁塞了，導(dǎo)致一大波低層次和高層次的告警產(chǎn)生。舉個(gè)案例，一個(gè)交換機(jī)異常，引發(fā)下聯(lián)的服務(wù)器爆炸式的告警，當(dāng)此類情況發(fā)生，我們的統(tǒng)一告警平臺(tái)全部不理，做好全局的收斂，以保證監(jiān)控告警的有效性不受影響。

逆向思維。意思是不能只看結(jié)果數(shù)據(jù)，要回到原始數(shù)據(jù)來看。如果要做到逆向思維可生效，那流處理集群在真正加工完，存儲(chǔ)的結(jié)果數(shù)據(jù)之前要做最基礎(chǔ)的清晰，把那部分日志備份到大數(shù)據(jù)平臺(tái)做離線的計(jì)算，然后結(jié)果數(shù)據(jù)再走正常的流，去做告警也好，異常波動(dòng)也好，因?yàn)楹芏喈惓５臇|西必須要看到原始數(shù)據(jù)。我們?cè)?jīng)深入分析相冊(cè)的日上傳照片流水日志，找到了大量異常的用戶照片，從而節(jié)省了大量的運(yùn)營(yíng)成本，這些都是結(jié)果數(shù)據(jù)無法做到的效果。

11.根因分析實(shí)踐簡(jiǎn)介

再看根因分析：

用高層次的告警收斂低層次的告警。同一個(gè)集群下既產(chǎn)生了低層次的告警，又產(chǎn)生了高層次的告警，低層次的告警不用發(fā)。

用主調(diào)的告警收斂被調(diào)的告警。模塊A調(diào)用模塊B，B掛了，A受不受影響？從保障業(yè)務(wù)可用性的角度，如果A沒有產(chǎn)生告警，證明該場(chǎng)景只是B的可靠性告警，告警通知開發(fā)而不是運(yùn)維。但如果B掛了，A也產(chǎn)生了告警，運(yùn)維就應(yīng)該收到A的告警，B還是告警給開發(fā)。推進(jìn)告警分級(jí)（分值、分級(jí)、分人、分通道）的機(jī)制，其實(shí)是慢慢把一些運(yùn)維要做的事情分給開發(fā)，運(yùn)維只看核心的，軟件可靠性這些開發(fā)來看，可靠性是開發(fā)的問題，可用性是運(yùn)營(yíng)質(zhì)量的問題。

用原因告警收斂現(xiàn)象告警。在業(yè)務(wù)邏輯的調(diào)用聯(lián)調(diào)中，用原因告警收斂掉現(xiàn)象告警。（具體可參考2016年3月深圳運(yùn)維大會(huì)上，我關(guān)于監(jiān)控的分享PPT）。

用主動(dòng)觸發(fā)的活動(dòng)去屏蔽一個(gè)對(duì)象的告警。有些告警是由于變更的行為引起的，要收斂掉。如正在做升級(jí)引發(fā)了告警，運(yùn)維系統(tǒng)要能關(guān)聯(lián)這些事件與告警。有高層次的告警、低層次的告警，還有運(yùn)維的活動(dòng)事件，都把這些集中在一起，通過權(quán)重的算法，有一個(gè)排序決策說告警應(yīng)該是告這條鏈路，而不是每一個(gè)對(duì)象都重復(fù)的告警。

12.優(yōu)選指標(biāo)實(shí)踐簡(jiǎn)介

最后，是優(yōu)選指標(biāo)DLP：

核心指標(biāo)論。騰訊內(nèi)部的系統(tǒng)代號(hào)叫DLP，是一種通過人工來篩選核心指標(biāo)的方法。舉例，一個(gè)模塊可能有300－400個(gè)指標(biāo)，這300－400個(gè)指標(biāo)中，包含有低層次的指標(biāo)，高層次的指標(biāo)，但當(dāng)這個(gè)模塊出問題的時(shí)候，這300－400個(gè)指標(biāo)可能都會(huì)產(chǎn)生告警，那么應(yīng)該怎么樣收斂呢？倘若我們提前已經(jīng)對(duì)該模塊進(jìn)行過核心指標(biāo)的人工篩選，這個(gè)指標(biāo)能代表模塊最真實(shí)的指標(biāo)。

監(jiān)控的相關(guān)性。監(jiān)控與監(jiān)控之間是相關(guān)的，例如300個(gè)指標(biāo)告警了，最核心的那個(gè)也會(huì)告警，最核心的告警了這300個(gè)指標(biāo)可以不告警，只看核心的就可以了，為什么要人手選核心指標(biāo)，因?yàn)闀簳r(shí)沒有辦法人工識(shí)別。

告警分級(jí)管理。可以基于核心的指標(biāo)對(duì)告警做分級(jí)，非核心的開發(fā)自己收，核心的運(yùn)維收，高規(guī)格保障。

降低流試監(jiān)控的計(jì)算量。監(jiān)控點(diǎn)越多，流的數(shù)據(jù)越大，整個(gè)監(jiān)控流處理集群規(guī)模很大，10萬(wàn)臺(tái)機(jī)器光是流處理的集群都是接近1500臺(tái)，當(dāng)運(yùn)營(yíng)成本壓力大時(shí)，我們也可以重點(diǎn)的保障DLP的指標(biāo)的優(yōu)先計(jì)算資源，保證優(yōu)先給予容量的支持。

13.織云用戶輿情監(jiān)控簡(jiǎn)介

除上述介紹的監(jiān)控指標(biāo)外，還有一個(gè)很核心的指標(biāo)，就是織云用戶輿情監(jiān)控系統(tǒng)。簡(jiǎn)單的介紹這個(gè)系統(tǒng)，用戶輿情監(jiān)控顧名思義就是監(jiān)控用戶的聲音和反饋。用戶的意見反饋來源可以分幾部分，一是appstore的入口，另一個(gè)是app內(nèi)嵌的反饋入口，還有的就是騰訊的用戶反饋論壇，所有的數(shù)據(jù)都會(huì)被匯集到織云輿情監(jiān)控平臺(tái)上，然后通過機(jī)器學(xué)習(xí)實(shí)現(xiàn)自動(dòng)分類。系統(tǒng)會(huì)把類似“QQ空間打不開”、“QQ空間不用好”等這些詞匯進(jìn)行語(yǔ)意分析和歸類，然后統(tǒng)一告警成“QQ空間異?！?，時(shí)間間隔是15分鐘顆粒度。（技術(shù)細(xì)節(jié)可以參考我在2016年在北京TOP100大會(huì)上的分享主題。）

當(dāng)實(shí)現(xiàn)了用戶輿情監(jiān)控后，我們基本有把握說業(yè)務(wù)的監(jiān)控360度無死角的（假設(shè)用戶都會(huì)反饋問題，且不考慮時(shí)間因素:P）。這套監(jiān)控先天就有門檻，因?yàn)橐谟脩舻闹鲃?dòng)反饋行為，同時(shí)需要較多的用戶反饋數(shù)據(jù)量，因?yàn)轵v訊的用戶量基數(shù)很大，用戶主動(dòng)反饋的量也很大。同時(shí)，輿情監(jiān)控可以用于監(jiān)控技術(shù)上的質(zhì)量問題，也能用于監(jiān)控產(chǎn)品的體驗(yàn)或交互問題。

14.監(jiān)控告警的策略與自愈

告警自動(dòng)化處理的前提是標(biāo)準(zhǔn)化運(yùn)維體系，在SNG織云監(jiān)控體系下，所有告警處理會(huì)先經(jīng)過預(yù)處理策略，然后再經(jīng)過統(tǒng)一告警平臺(tái)的策略和算法，最終才被決策會(huì)否發(fā)出。

15.常用算法與策略簡(jiǎn)介

在定義指標(biāo)狀態(tài)異常時(shí)，我們的經(jīng)驗(yàn)是盡量不要用固定閥值，要用也是動(dòng)態(tài)閥值，否則在監(jiān)控對(duì)象的閥值管理上就會(huì)有大量的人工管理的成本。其他的推薦策略如圖。

16.常見監(jiān)控圖形與策略

我們?cè)谌粘＿\(yùn)維工作中，面對(duì)的監(jiān)控的圖形就如上圖，趨勢(shì)有小波動(dòng)、毛刺、無規(guī)律的，建議大家有針對(duì)性的套用監(jiān)控策略，讓監(jiān)控告警更精準(zhǔn)。

17.監(jiān)控資源案例

分享一個(gè)織云監(jiān)控實(shí)現(xiàn)進(jìn)程自愈的案例，流程中的模塊在部署時(shí)，運(yùn)維自動(dòng)化流程就會(huì)把進(jìn)程和端口的信息注冊(cè)到CMDB中，然后監(jiān)控服務(wù)會(huì)讀取該模塊需要監(jiān)控的進(jìn)程與端口信息，并把監(jiān)控配置發(fā)送每臺(tái)機(jī)器的監(jiān)控agent上，本地的監(jiān)控agent通過定時(shí)的ps檢測(cè)進(jìn)程和端口的運(yùn)行情況，如果發(fā)生異常，則自動(dòng)通過標(biāo)準(zhǔn)化的管理找到啟動(dòng)的命令啟動(dòng)，如果啟動(dòng)成功便實(shí)現(xiàn)了進(jìn)程自愈。如果啟動(dòng)不了發(fā)給統(tǒng)一告警平臺(tái)，統(tǒng)一告警平臺(tái)來決策是否需要告警。當(dāng)該告警原因是因?yàn)榛A(chǔ)設(shè)施正在做變更影響時(shí)，也不會(huì)發(fā)出告警。一系列的監(jiān)控自愈的方案都是構(gòu)建在織云的自動(dòng)化運(yùn)維體系中的，詳情可以參考以前織云的相關(guān)技術(shù)分享。

18.常用收斂算法簡(jiǎn)介

毛刺收斂。在織云監(jiān)控中，我們的告警策略為了防止毛刺的影響，會(huì)將告警策略定義為10分鐘發(fā)生3次類似的模式。

同類收斂。一個(gè)模塊有300個(gè)監(jiān)控實(shí)力，產(chǎn)生了300條的告警，只要有一條告給運(yùn)維，對(duì)于運(yùn)維同類收斂掉了。

時(shí)間收斂。生產(chǎn)環(huán)境中有很多定時(shí)的任務(wù)，如定時(shí)跑批會(huì)引起I/O的陡增等異常，這種可以針對(duì)性的收斂掉。

晝夜收斂。有一些告警，在分布式服務(wù)的高可用架構(gòu)下，晚上不需要告警出來，可以等白天才告警，更人性化的管理。

變更收斂。如果告警的時(shí)間點(diǎn)有運(yùn)維的活動(dòng)，就要收斂掉它。怎么做到的？取決于要把運(yùn)維的活動(dòng)都收口在標(biāo)準(zhǔn)化運(yùn)維的平臺(tái)，運(yùn)維平臺(tái)對(duì)生產(chǎn)環(huán)節(jié)都要講變更日志寫入在變更記錄中心那里，然后統(tǒng)一告警系統(tǒng)能夠關(guān)聯(lián)變更記錄來決策是收斂還是發(fā)出告警。

19.織云監(jiān)控的指標(biāo)體系

織云監(jiān)控構(gòu)建的質(zhì)量體系，分成用戶端、客戶端、服務(wù)端、基礎(chǔ)端，定義核心指標(biāo)DLP，并且善用分級(jí)告警、分渠道告警，結(jié)合短信、QQ、微信和電話等渠道實(shí)現(xiàn)告警通知，整個(gè)質(zhì)量監(jiān)控體系都是圍繞預(yù)警、自愈、分析、排障礙的能力構(gòu)建。

20.織云監(jiān)控的質(zhì)量體系

小結(jié)織云監(jiān)控的質(zhì)量體系，我們希望打造一個(gè)閉環(huán)，能夠?qū)崿F(xiàn)持續(xù)反饋、度量、優(yōu)化，讓團(tuán)隊(duì)間能夠有效的協(xié)同工作，更高效更有效。

監(jiān)控能力。全局的看、需要什么樣的監(jiān)控能力和監(jiān)控點(diǎn)，同時(shí)要理清指標(biāo)是怎么分層的，哪些指標(biāo)是重要的？最終把它轉(zhuǎn)成業(yè)務(wù)看得懂的高層次指標(biāo)。

業(yè)務(wù)可用性。運(yùn)維要看什么，要看可靠性還是可用性，如果規(guī)模不大看可靠性可以，但是在海量的場(chǎng)景下可靠性要太細(xì)，要抽象核心指標(biāo)來度量，用于衡量可用性?？煽啃詣t可以通過考核體系去度量與管理，結(jié)合QA和老板的力量來推動(dòng)開發(fā)團(tuán)隊(duì)的投入與優(yōu)化。

用戶體驗(yàn)。做技術(shù)運(yùn)營(yíng)會(huì)有視角的盲點(diǎn)，會(huì)經(jīng)常迷戀可用性的數(shù)據(jù)是4個(gè)9、5個(gè)9，但這并不完全代表了我們服務(wù)質(zhì)量好，當(dāng)用戶連接不上我們的服務(wù)端時(shí)，幾個(gè)9的意義都不大。這是一個(gè)很現(xiàn)實(shí)的問題，因此用戶體驗(yàn)監(jiān)控一定要做，因?yàn)閮?nèi)部的可用性再高都不代表用戶用得好。

技術(shù)解決。要有技術(shù)解決的方案，要有自動(dòng)化的工具，有協(xié)助用戶排障的工具，有根因分析的算法平臺(tái)等等。

統(tǒng)計(jì)分析。最終形成可度量的指標(biāo)、可考核的、可展示的，最好是DIY展示的，監(jiān)控?cái)?shù)據(jù)的統(tǒng)計(jì)/報(bào)表能力服務(wù)化，應(yīng)發(fā)揮更多的角色來使用監(jiān)控?cái)?shù)據(jù)，而非僅限于運(yùn)維角色。

持續(xù)改進(jìn)。最終持續(xù)的改進(jìn)無論是架構(gòu)的問題、代碼的問題，還是因?yàn)闃?biāo)準(zhǔn)化的問題或非功能落地推進(jìn)不了的問題，都是需要數(shù)字來度量和推動(dòng)。最好，這個(gè)數(shù)字要能間接的反饋商業(yè)的價(jià)值，也就是DevOps提倡的思路。

最后，質(zhì)量體系肯定是反作用于監(jiān)控能力再去形成這樣的閉環(huán)，跟開發(fā)怎么溝通？跟產(chǎn)品怎么溝通？跟QA、跟客服怎么溝通？要把他們用起來，要把他們關(guān)注的點(diǎn)牽引住，最終落到運(yùn)維想實(shí)現(xiàn)的目標(biāo)上是最好的，這很DevOps，也撬動(dòng)老板的思維，爭(zhēng)取從上而下的支持做好質(zhì)量體系的建設(shè)。

我們經(jīng)常說DevOps很難落地，為什么難？因?yàn)槲覀兛偸窍胍ビ绊懤习?，先改變文化再改變工作方法，但這談何容易。如果是運(yùn)維和開發(fā)能聯(lián)合起來，先從小的重點(diǎn)的業(yè)務(wù)抓起，用數(shù)據(jù)說話體現(xiàn)DevOps能給業(yè)務(wù)帶來的最終的商業(yè)價(jià)值，說不定會(huì)起到事半功倍的效果。

今天的分享就到這里，謝謝大家！