作者介紹：聶鑫，騰訊運(yùn)維總監(jiān)。從開發(fā)到運(yùn)維，伴隨騰訊社交網(wǎng)絡(luò)運(yùn)營(yíng)部成長(zhǎng)的十年，負(fù)責(zé)過騰訊社交產(chǎn)品所有業(yè)務(wù)運(yùn)維工作。目前主要負(fù)責(zé) QQ、空間等產(chǎn)品運(yùn)維團(tuán)隊(duì)管理工作。經(jīng)歷多個(gè)業(yè)務(wù)產(chǎn)品的誕生到蓬勃，伴隨著運(yùn)維團(tuán)隊(duì)的成長(zhǎng)和成熟，見證著騰訊一代代運(yùn)營(yíng)技術(shù)的創(chuàng)新和發(fā)展。作為運(yùn)維界老兵有好多故事想和大家講，也特別愿意聽聽各位經(jīng)歷的酸甜苦辣。

騰訊社交業(yè)務(wù)規(guī)模龐大，歷史悠久，架構(gòu)復(fù)雜。從運(yùn)維的全局角度來看，無論從運(yùn)維技術(shù)還是監(jiān)控難度都很大。傳統(tǒng)的監(jiān)控手段和思想已經(jīng)無法應(yīng)對(duì)如此海量的場(chǎng)景，騰訊織云平臺(tái)經(jīng)歷多年的迭代改進(jìn)，在運(yùn)維監(jiān)控領(lǐng)域經(jīng)過了多個(gè)建設(shè)階段，通過技術(shù)創(chuàng)新，將運(yùn)維監(jiān)控技術(shù)提升到新的高度，解決了很多海量業(yè)務(wù)規(guī)模下的運(yùn)維監(jiān)控難題。

提及騰訊的海量監(jiān)控的挑戰(zhàn)，先拋些數(shù)據(jù)，我們有將近 20 套監(jiān)控系統(tǒng)，指標(biāo)有將近 300 多個(gè)，監(jiān)控的實(shí)例超過 900 萬，最可怕的是每天有近 5 萬條短信告警，人均 500 條。2014年收告警最多的運(yùn)維，一天能收 1500 條短信，收告警比較多的研發(fā)同學(xué)，每天也有 1200 條短信。甚至我們都調(diào)侃自己說，我們要靠手機(jī)震動(dòng)的頻率來判斷事態(tài)的嚴(yán)重。

在騰訊SNG的運(yùn)維平臺(tái)中，承載這些海量監(jiān)控的平臺(tái)是織云。從 06 年開始到 14 年，織云監(jiān)控圍繞著“快”，“準(zhǔn)”，“全”，這三個(gè)目標(biāo)不斷迭代。首先要求監(jiān)控面和告警點(diǎn)能夠覆蓋很全，能主動(dòng)發(fā)現(xiàn)用戶的各種犄角旮旯的異常，為此衍生了各種各樣的監(jiān)控手段，這就是為什么目前我們會(huì)有 20 套監(jiān)控體系。其次我們希望告警非常快，一出問題馬上發(fā)出來，同時(shí)希望告警準(zhǔn)，誤告警少。

以至于最嚴(yán)重的時(shí)候有將近 5 萬條告警，人均幾百條，說明當(dāng)前告警是不準(zhǔn)的。能不能解決好這件事情？可能就成為了在監(jiān)控領(lǐng)域運(yùn)維的一種技術(shù)和一種藝術(shù)。后面分享的幾個(gè)比較有意思的小創(chuàng)新，就是它融入了騰訊運(yùn)維多年的實(shí)踐經(jīng)驗(yàn)和運(yùn)營(yíng)藝術(shù)。

上圖的數(shù)據(jù)可以看得到每天的監(jiān)控實(shí)例非常的龐大。從 09 年開始，當(dāng)時(shí)只有幾套監(jiān)控，隨后每年都在增長(zhǎng)，在 14 年后開始有一些減少，主要是 14 年開始，我們也開始在檢討了，發(fā)現(xiàn)為了完成快、準(zhǔn)、全這三個(gè)目標(biāo)，去建各種各樣的監(jiān)控系統(tǒng)其實(shí)不持久，很多建設(shè)都只是在解決“點(diǎn)”上的問題，并沒有體系化解決“面”上的問題，并沒有深層次挖掘其中的關(guān)系。所以開始有計(jì)劃的去做減法，適當(dāng)裁減了一些系統(tǒng)。

快速進(jìn)入到今天的重點(diǎn)，最近我們又做了哪些不一樣的“新”事情。就是對(duì)織云監(jiān)控的技術(shù)創(chuàng)新，這么多的監(jiān)控系統(tǒng)，存在必有它的合理性，我們認(rèn)為所謂的創(chuàng)新并不是要否定過去監(jiān)控系統(tǒng)存在的意義，更多是希望通過解決歷史中一些不合理的架構(gòu)演進(jìn)，用新時(shí)代的技術(shù)創(chuàng)新和對(duì)監(jiān)控的新理解，讓織云監(jiān)控能夠朝真正的快、準(zhǔn)、全這個(gè)方向去發(fā)展，而不是局部?jī)?yōu)化或者推翻重做的思路。

?ROOT?

第一個(gè)監(jiān)控技術(shù)創(chuàng)新名為 Root 的項(xiàng)目，意在找到造成告警的故障根源。這個(gè)項(xiàng)目從 12 年開始，在 14 年的時(shí)候在業(yè)界分享過。這個(gè)是基于業(yè)務(wù)架構(gòu)，結(jié)合數(shù)據(jù)流，通過算法，能夠?qū)⒏婢M(jìn)行分析、篩選，從中發(fā)現(xiàn)出有價(jià)值的告警，推斷出造成告警的故障根源。

我們?cè)谒伎家粋€(gè)問題，為什么會(huì)出現(xiàn)一方面有 5 萬條告警，另一方面好像服務(wù)質(zhì)量還行？可以肯定的有大量的告警是重復(fù)和無效的。我們啟動(dòng)建設(shè) Root 智能分析的目的是希望能夠解決這個(gè)問題。

第一，運(yùn)維需要能夠了解業(yè)務(wù)架構(gòu)，這也是運(yùn)營(yíng)上的一種思路，“基于業(yè)務(wù)架構(gòu)去運(yùn)營(yíng)”。在騰訊運(yùn)維日常的工作中，是會(huì)對(duì)一些核心服務(wù)架構(gòu)進(jìn)行梳理，比如繪制出架構(gòu)圖來，維護(hù)并運(yùn)營(yíng)起來。

第二，有了架構(gòu)圖，運(yùn)維就可以比較方便地去獲取架構(gòu)之間的訪問關(guān)系，有很多手段。同時(shí) 20 套監(jiān)控系統(tǒng)中有大量的數(shù)據(jù)是帶有一定的邏輯訪問關(guān)系的，從中做一些簡(jiǎn)單的篩選，就能夠獲取架構(gòu)中的訪問關(guān)系。這個(gè)圖是實(shí)際的系統(tǒng)截圖，紅線就代表里面有大流量，灰線代表里面流量比較低，是非常容易做得到的。但是這里也有個(gè)問題，架構(gòu)是網(wǎng)狀的，人肉眼來看是很難去區(qū)分這里面到底和誰有真正直接的關(guān)系，或者說告警發(fā)生的服務(wù)，和告警的故障根源服務(wù)到底是怎么樣的關(guān)系。

通過使用一些簡(jiǎn)單的算法進(jìn)行“降維”，比如上面的網(wǎng)狀業(yè)務(wù)訪問關(guān)系，可以通過有向的窮舉的方式抽取成鏈條狀，形成服務(wù)訪問關(guān)系鏈。然后將各種告警往上疊加。我們將各種各樣的告警疊加在這個(gè)業(yè)務(wù)架構(gòu)的鏈路上面去，比如說當(dāng)某一種告警產(chǎn)生的時(shí)候，就往鏈路上去疊加，其他的告警類似處理，循環(huán)著繼續(xù)這樣去處理，最后你會(huì)發(fā)現(xiàn)訪問關(guān)系鏈路上面已經(jīng)疊滿了各種告警。在同一個(gè)時(shí)間片范圍內(nèi)就可以開始去分析，根據(jù)運(yùn)維的檢驗(yàn)，可以推測(cè)出架構(gòu)中哪一條鏈路或者多條鏈路的故障現(xiàn)象和故障根源最有可能發(fā)生。

我們假設(shè)告警和故障根源的關(guān)聯(lián)在數(shù)據(jù)上是有一定的關(guān)系，這個(gè)關(guān)系可能是一種相近性，我們認(rèn)為兩個(gè)服務(wù)之間的告警隔的非常近，那么互相產(chǎn)生影響可能性會(huì)非常的大，把全部業(yè)務(wù)進(jìn)行這種降維處理后，大概有四百多萬條鏈路進(jìn)行計(jì)算，當(dāng)告警發(fā)生的時(shí)候，就很容易通過一些算法浮現(xiàn)出最有可能的告警根源是哪里？

過去我們很苦惱，每個(gè)新的告警對(duì)運(yùn)維的工作都會(huì)造成騷擾，但基于 ROOT 這樣的方法論上，我們發(fā)現(xiàn)告警越多越好，告警越多越能夠幫我們?nèi)グ堰@個(gè)關(guān)聯(lián)做得更精確。

這張圖是我們的系統(tǒng)展現(xiàn)，比如說從這里把告警進(jìn)行一些疊加，中間可能隔開了，也許它自己沒有接入告警，或者自己的告警并沒有和這個(gè)問題現(xiàn)象相關(guān)，這是很常見的一種形態(tài)。那我們開始算，首先這個(gè)算法就會(huì)在一定的時(shí)間片范圍內(nèi)，它有一定的范圍，大概前 15 分鐘，后 5 分鐘，因?yàn)楦婢旧碜约壕蜁?huì)有發(fā)送和接收的延時(shí)，我們?cè)谶@里會(huì)取前 15 分鐘，后 5 分鐘的時(shí)間片，認(rèn)為這個(gè)時(shí)間片范圍內(nèi)的告警才有關(guān)聯(lián)度。第二個(gè)部分就是時(shí)間相關(guān)性，底下這個(gè)服務(wù)它每天都在告警，那么其實(shí)它的時(shí)間相關(guān)度是非常低的，它和這條告警產(chǎn)生根源故障的關(guān)聯(lián)也非常的低，屬于臟數(shù)據(jù)應(yīng)該剔除掉。這個(gè)算法里面會(huì)把這部分的數(shù)據(jù)作為一個(gè)垃圾剔除掉，這個(gè)垃圾就是我們剛說的 5 萬條告警。

也有人挑戰(zhàn)過這個(gè)問題，你們?yōu)槭裁床蝗グ阉崂硪幌?#xff1f;把這個(gè)梳理干凈了不就很準(zhǔn)了嗎？我們也想做這個(gè)事情，但是那個(gè)包袱實(shí)在是太重了。當(dāng)前我們已經(jīng)沒有辦法去把所有的臟數(shù)據(jù)通過人工梳理的方式去掉了，只能夠通過一些額外的算法分析出這些臟數(shù)據(jù)存在的干擾，能夠把它過濾掉。這個(gè)里面就是通過一些時(shí)間相關(guān)性和時(shí)間片的范圍，然后通過鏈路關(guān)系和時(shí)間關(guān)系，一起來決定準(zhǔn)確性，這也是我們?cè)趯で蟾婢P(guān)聯(lián)分析準(zhǔn)確度上的一個(gè)探索。

我們將告警分成了原因告警和現(xiàn)象告警，原因告警才是造成那個(gè)故障的根源，現(xiàn)象告警可能只是故障的結(jié)果，其實(shí)看不出來故障根源在哪里。

舉例說，用戶 QQ 里面不能發(fā)消息了，往往不一定是 QQ 有問題，很有可能后面數(shù)據(jù)庫(kù)宕掉了。在一個(gè)多運(yùn)維團(tuán)隊(duì)協(xié)同分工運(yùn)營(yíng)體系下，前端負(fù)責(zé)人很多時(shí)候不知道后面那臺(tái)數(shù)據(jù)庫(kù)宕掉了，所以現(xiàn)象和結(jié)果往往是關(guān)聯(lián)不起來的，我們這個(gè)方法是希望能夠做到這一點(diǎn)。

第二個(gè)部分，我們將告警分成持續(xù)性告警，波動(dòng)性告警，關(guān)聯(lián)性告警。“持續(xù)性告警”屬于臟數(shù)據(jù)，往往是不重要也不緊急的，我們認(rèn)為不需要立刻去處理。“波動(dòng)性告警”也是處理起來比較糾結(jié)的一點(diǎn)，很多告警會(huì)被監(jiān)控發(fā)現(xiàn)，但故障一下子恢復(fù)，指標(biāo)很快恢復(fù)，這種告警應(yīng)該去區(qū)別對(duì)待，可以根據(jù)業(yè)務(wù)的重要性去做處理，服務(wù)如果重要那么可能就要處理分析一下；如果不重要，站在我的立場(chǎng)，我覺得可以不處理。

我們會(huì)更加去關(guān)注“關(guān)聯(lián)性告警”，它是有因有果，就應(yīng)該立刻去處理。有一個(gè)簡(jiǎn)單的數(shù)據(jù)，這是最后的結(jié)果，我們發(fā)現(xiàn)那 5 萬條告警里面，有 65% 屬于持續(xù)性告警，不是那么重要，可能不一定真的要把它清理掉，但是對(duì)于告警分析來說沒有那么重要。波動(dòng)告警又占到了 24%，也就說我們有將近 1/4 的告警，只是發(fā)生了一下故障很快就恢復(fù)了，無論是作為運(yùn)維，還是作為研發(fā)，還是作為技術(shù)化團(tuán)隊(duì)里邊的 QA，都沒有必要在這里面去投入過多的人力或者精力，這種波動(dòng)告警是我們這個(gè)體系里面應(yīng)該過濾掉的。最后一部分，只有不到 10% 的告警才是真正能夠去關(guān)聯(lián)出原因的，有現(xiàn)象有原因的，這部分告警才是最重要的，我們需要重點(diǎn)去關(guān)注的一部分告警。

后面是簡(jiǎn)單的一個(gè)算法，這種鏈路怎么去判斷權(quán)重，哪個(gè)應(yīng)該告警，哪個(gè)應(yīng)該不告警，這里有個(gè)簡(jiǎn)單的面積算法。簡(jiǎn)單解釋一下，根據(jù)告警連續(xù)，如果一連續(xù)它的長(zhǎng)度就加，如果不連續(xù)它的縱向就減，最后算出一個(gè)簡(jiǎn)單的面積來。

比較典型的例子，就像這種，同樣是 7 個(gè)節(jié)點(diǎn)的一條鏈路，同樣是有四個(gè)告警疊加的，最后算下來面積它們的面積是不一樣的，算出來會(huì)發(fā)現(xiàn)很有意思，非常準(zhǔn)確能夠分析出關(guān)聯(lián)性，關(guān)聯(lián)性越大的，它的面積一定是最大的。最新的基于AI的新算法已經(jīng)落地，具有更高的準(zhǔn)確性。

代碼很簡(jiǎn)單，分享給大家。

? DLP??

16 年初織云監(jiān)控又做了一個(gè)創(chuàng)新項(xiàng)目 DLP，它的英文就是 Dead Live Point。有人很難理解，這個(gè)和監(jiān)控有什么關(guān)系？當(dāng)然前面提到，我們有 5 萬條告警，每個(gè)運(yùn)維都要收好幾百條，到底運(yùn)維應(yīng)該收哪些，到底研發(fā)應(yīng)該收哪些？怎么分工才合理？

我作為運(yùn)維團(tuán)隊(duì)的負(fù)責(zé)人經(jīng)常會(huì)參加一些故障的復(fù)盤會(huì)，故障復(fù)盤里面會(huì)要求寫改進(jìn)措施，基本上第一條就是告警太多，告警被忽略掉了。大家常常會(huì)問：這個(gè)故障有沒有告警？一般來說，我們 20 多套監(jiān)控系統(tǒng)在觀測(cè)故障，大多數(shù)情況下告警都可以發(fā)現(xiàn)，但往往告警都被忽略掉了，沒有人看的過來。說明一個(gè)現(xiàn)象，就是我們的告警泛濫已經(jīng)成為我們發(fā)現(xiàn)和解決故障的一種致命的騷擾，所以在這里面，我們很迫切能夠去區(qū)分出到底哪些是最重要的。DLP 是我們能夠去區(qū)分哪些告警應(yīng)該去立刻處理，哪些告警可以緩一緩，或者有分工的處理。

DLP 這衡量業(yè)務(wù)生死的指標(biāo)，它有幾個(gè)要求：

第一，這套告警體系里面是不允許有閥值這個(gè)概念的，比如說你告訴我告警超過三次，你就要告警，No，在我們這里面是不允許，比如說業(yè)務(wù)訪問量正常情況下大概每天 1000 萬量，跌下來了，比如跌到 800 萬，你就得有告警，No，在我們這里也不支持。在我們這里面不允許用閥值，在我們這里面只有一個(gè)指標(biāo)，就是成功率。

第二，一個(gè)服務(wù)只能有一個(gè)生死指標(biāo)，為什么會(huì)有這么樣一個(gè)奇怪的要求？我們服務(wù)只有幾萬個(gè)，為什么會(huì)有 900 萬個(gè)監(jiān)控點(diǎn)？舉個(gè)例子，我們有的服務(wù)會(huì)有超過 400 個(gè)監(jiān)控點(diǎn)來監(jiān)控這個(gè)服務(wù)的各種緯度運(yùn)行狀況，比如說它打開 Linux 文件句柄數(shù)，內(nèi)存使用量要監(jiān)控，磁盤 IO 也要監(jiān)控，還包括很多業(yè)務(wù)緯度監(jiān)控，比如業(yè)務(wù)成功率，失敗率，各種訪問量、購(gòu)買量、在線數(shù)等等這些監(jiān)控造就了一個(gè)服務(wù)可能會(huì)超過 400 的監(jiān)控點(diǎn)，那么當(dāng)這 400 個(gè)監(jiān)控點(diǎn)有 20 個(gè)人關(guān)注這個(gè)服務(wù)，一旦發(fā)生告警，這個(gè)告警量自然就會(huì)很多，這就是為什么會(huì)有 5 萬個(gè)告警出來。所以在這里面，我們“粗暴”的假設(shè)，一個(gè)服務(wù)只能有一個(gè)生死指標(biāo)，就好像一個(gè)人死了還是活著，就只有 0 和 1 的選擇。

第三，是不建議用業(yè)務(wù)指標(biāo)做生死指標(biāo)，這個(gè)也很難理解。互聯(lián)網(wǎng)產(chǎn)品業(yè)務(wù)第一，什么東西都是以業(yè)務(wù)為主的，業(yè)務(wù)必須第一保障，看指標(biāo)當(dāng)然看業(yè)務(wù)指標(biāo)，在線數(shù)跌了一定是有問題，購(gòu)買量跌了一定是有問題，這的確是事實(shí)，但是作為技術(shù)運(yùn)營(yíng)線，作為運(yùn)維，或者說作為最前沿的技術(shù)研發(fā)，這些指標(biāo)的一些漲和跌是不是應(yīng)該馬上去處理的？事實(shí)是這個(gè)指標(biāo)的漲跌，可能和很多非技術(shù)因素有關(guān)系，比如說發(fā)布原因造成的，比如活動(dòng)造成的，這些大家都見過，做一個(gè)活動(dòng)，購(gòu)買量一定會(huì)漲，活動(dòng)一結(jié)束一定會(huì)跌，但這些指標(biāo)是不是我們技術(shù)運(yùn)營(yíng)線要去第一關(guān)注的？在我們這個(gè)體系里面也是假設(shè)應(yīng)該由產(chǎn)品人員關(guān)注而不是技術(shù)人員，我需要知道的是這個(gè)業(yè)務(wù)是死還是活著。所以這在里面，我們不太建議用業(yè)務(wù)指標(biāo)作為 DLP，業(yè)務(wù)指標(biāo)會(huì)被我們?nèi)藶檗D(zhuǎn)化成為成功率，比如我們會(huì)把購(gòu)買量和購(gòu)買失敗量?jī)蓚€(gè)指標(biāo)折算購(gòu)買成功率，用 DLP 來監(jiān)控這個(gè)購(gòu)買成功率。

有了前面的三個(gè)假設(shè)，就可以采取一些簡(jiǎn)單的統(tǒng)計(jì)學(xué)算法幫助我們發(fā)現(xiàn)異常指標(biāo)，比如我們用的的 3 西格瑪算法，拿到環(huán)比同比，昨天上周的數(shù)據(jù)，用 3 西格瑪一算就能獲得一個(gè)波峰區(qū)間來，你的業(yè)務(wù)指標(biāo)只要在這個(gè)波峰區(qū)間之內(nèi)變動(dòng)的，我們基本上就能夠知道這個(gè)業(yè)務(wù)要不要告警了。

上面截圖中的每一段文字就是一個(gè)監(jiān)控點(diǎn)，而此截圖僅僅來自一個(gè)服務(wù)。僅僅織云 monitor 監(jiān)控就有 125 萬個(gè)指標(biāo)。這就是為什么我們的告警會(huì)有那么多的原因了。所以我們會(huì)從這些監(jiān)控服務(wù)中抽出一些關(guān)鍵的指標(biāo)生成 DLP。

當(dāng)然我們會(huì)對(duì)告警做各種各樣的數(shù)據(jù)分析，比如多維數(shù)據(jù)匯聚。把主調(diào)，被調(diào) IP 的聚集度，主調(diào)、備調(diào)的失敗率，錯(cuò)誤碼、返回碼、訪問碼的聚集度等數(shù)據(jù)，并結(jié)合 ROOT 做的根源故障推薦，給用戶一個(gè)全新的故障定位分析體驗(yàn)。

這個(gè)系統(tǒng)在我們這邊目前使用情況相當(dāng)?shù)牟诲e(cuò)，都有點(diǎn)出乎我的意料，正式推動(dòng)這件事情大半年，準(zhǔn)確率基本上在 95% 以上，一旦這個(gè)告警告出來，基本上就一定有問題，漏告的情況下極少。現(xiàn)在有一些技術(shù)團(tuán)隊(duì)基本上開始以 DLP 告警為主了，其他的告警為輔。團(tuán)隊(duì)開始由尷尬的監(jiān)控陷阱中脫身出來，故障處理更有節(jié)奏了，從突發(fā)故障數(shù)量的下降就可以明顯感覺到。

DLP，Root 雖然不算是個(gè)技術(shù)上很難的創(chuàng)新，但是對(duì)于解決監(jiān)控告警數(shù)量的問題特別有幫助。

全鏈路監(jiān)控

最后一個(gè)也是我們最近在做新的一個(gè)事情，全鏈路監(jiān)控。除前面提到 20 多套運(yùn)維監(jiān)控系統(tǒng)，我們還有很多其他的數(shù)據(jù)源，比如有很多產(chǎn)品指標(biāo)數(shù)據(jù)，服務(wù)器日志數(shù)據(jù)，用戶日志數(shù)據(jù)等等各種各樣的數(shù)據(jù)源。這些數(shù)據(jù)以前對(duì)我們運(yùn)維來說是負(fù)擔(dān)，但是現(xiàn)在隨著大數(shù)據(jù)的興起，我們發(fā)現(xiàn)這個(gè)數(shù)據(jù)也是一個(gè)寶藏，蘊(yùn)藏著大量有價(jià)值的信息。我們現(xiàn)在在做全鏈路監(jiān)控建設(shè)，是希望能夠去幫助我們數(shù)據(jù)的生產(chǎn)者、消費(fèi)者去合理地把數(shù)據(jù)用起來，能夠幫助我們的生產(chǎn)者有辦法去消費(fèi)這些數(shù)據(jù)，過去是做不到的。

要舉個(gè)例子大家才能理解什么叫全鏈路，這個(gè)圖是 QQ 業(yè)務(wù)的一個(gè)局部服務(wù)的架構(gòu)圖，標(biāo)記 QQ 里面好朋友見發(fā)消息的時(shí)序，消息在整個(gè)騰訊的體系里會(huì)經(jīng)過 51 個(gè)步驟，這里面任何一個(gè)地方出問題了，都可能會(huì)造成丟消息。過去為了監(jiān)控丟消息這個(gè)情況，整個(gè)系統(tǒng)中的這 51 個(gè)狀態(tài)點(diǎn)都會(huì)去埋點(diǎn)，就是做染色，故障發(fā)生時(shí)可以很快知道消息到底在 51 個(gè)系統(tǒng)中的哪個(gè)地方丟掉的，這就是早期的染色監(jiān)控方式。但隨著時(shí)間服務(wù)架構(gòu)越來越復(fù)雜，產(chǎn)品越來越多，這種方式已經(jīng)很難推行，特別是站在運(yùn)維的角度，希望通過這種方式去完成各種業(yè)務(wù)架構(gòu)的監(jiān)控，做不到了，因此“織云全鏈路監(jiān)控方式”就誕生了。

我們會(huì)把基礎(chǔ)監(jiān)控、特性監(jiān)控，現(xiàn)網(wǎng)的各種日志，各大系統(tǒng)中的文本類數(shù)據(jù)等灌到我們的日志中心里去。經(jīng)過一系列的篩選，提取一些特征，計(jì)算一些中間值，形成全連路數(shù)據(jù)。現(xiàn)在我們也用到一些很多的一些開源組件比如 Elasticsearch 再做一些展現(xiàn)，然后全鏈路監(jiān)控平臺(tái)大概的結(jié)構(gòu)就是這個(gè)樣子，最終我們希望能夠幫助用戶去做很多分析。

比如說用戶的數(shù)據(jù)在我們這邊，這里一列代表了各種數(shù)據(jù)源，這個(gè)案例是個(gè)用戶在空間玩直播的案例，它的數(shù)據(jù)在我們這邊由各種不同的數(shù)據(jù)源上報(bào)上來。這里會(huì)把所有的數(shù)據(jù)列出來，把公共特性的值抽象出來做個(gè)對(duì)比，如果發(fā)現(xiàn)用戶的一些值出現(xiàn)了異常，就可以去做告警了，可以產(chǎn)生一些新的運(yùn)維事件，就能驅(qū)動(dòng)產(chǎn)品和研發(fā)去改進(jìn)。

這個(gè)事情一開始做的時(shí)候覺得也挺困難的，各種各樣的日志格式也不一樣，數(shù)據(jù)形式也不同，甚至都有懷疑說這個(gè)方式做不做的下去，但是發(fā)現(xiàn)不斷深入去做，這里面發(fā)掘出來的一些有價(jià)值的數(shù)據(jù)反倒是越來越多，舉個(gè)例子，原來我們都說用戶直播的時(shí)候卡頓，我們也不知道是為什么，但現(xiàn)在好了，只要這個(gè)用戶一上來，通過所有的數(shù)據(jù)匯聚就可以知道他用的什么機(jī)型，我們還會(huì)收集用戶的 CPU，CPU 一直是 100%，很有可能這個(gè)機(jī)器不是特別高效，比如說它的網(wǎng)絡(luò)，有的可能在用 3G 玩直播，可能在一些特殊的場(chǎng)景下，比如電梯里面。

有一次，我們一個(gè)同事在北京機(jī)場(chǎng)玩直播玩不了，終端沒有任何提示的案例。通過全鏈路系統(tǒng)我們技術(shù)人員一看，很快發(fā)現(xiàn)它的 IP 發(fā)生了變化，由 4G 變成了北京機(jī)場(chǎng) wifi，故障發(fā)生在 ip 切換后。原來他過去有去過北京機(jī)場(chǎng)，所以再次進(jìn)北京機(jī)場(chǎng)的時(shí)候他的手機(jī)就自動(dòng)連 WiFi，北京機(jī)場(chǎng) WiFi 是要登陸的，但是他自己沒意識(shí)到，APP 也沒有提示，直播自然會(huì)失敗。

過去這類個(gè)案的投訴只能請(qǐng)研發(fā)撈取用戶的日志來分析定位，而現(xiàn)在運(yùn)維就能快速定位。整個(gè)過程很流暢，比以前快太多了。全鏈路的數(shù)據(jù)對(duì)于我們運(yùn)維和技術(shù)人員去定位故障非常有幫助，這個(gè)項(xiàng)目在我們現(xiàn)在也是主推的一個(gè)項(xiàng)目。

踐行機(jī)器學(xué)習(xí)

后面分享的是織云監(jiān)控目前正在做的一些技術(shù)探索（2017年12 月最新的進(jìn)展已經(jīng)在織云 AIOps 里面落地，請(qǐng)參考最新分享），所以寫的是踐行，我相信同行們都在做這件事情，跟大家交流一下，包括幾個(gè)部分，主要是機(jī)器學(xué)習(xí)相關(guān)的。

織云監(jiān)控給運(yùn)維團(tuán)隊(duì)樹立的愿景是：咖啡運(yùn)維。希望我們做運(yùn)維的坐在那里喝咖啡就行了，花了十年時(shí)間還沒有到這個(gè)目標(biāo)。

這是以前的做法，對(duì)數(shù)據(jù)進(jìn)行各種各樣的分析，大家都用過，各種曲線圖對(duì)比，這都是老套路，匯聚、對(duì)比、閥值、分布、聚類，這個(gè)我們都用過，但是幫助有限。

踐行機(jī)器學(xué)習(xí) AI 運(yùn)維，我們首先試水了文本處理領(lǐng)域，比如說這是“織云輿情監(jiān)控”，就用了機(jī)器學(xué)習(xí) NLP 處理。

這個(gè)項(xiàng)目還要從一個(gè)有趣的例子說起，早年我接觸過一個(gè)老板，他抱怨說我們的服務(wù)質(zhì)量不好。他的理由很簡(jiǎn)單，他每天上百度上去搜，有負(fù)面反饋，“空間打不開”這幾個(gè)字，搜索排名第一。因此得到結(jié)論，我們的服務(wù)質(zhì)量不行。他不管我們自己的監(jiān)控?cái)?shù)據(jù)質(zhì)量多好，認(rèn)定外面的輿情是負(fù)面的，就認(rèn)為我們的服務(wù)質(zhì)量不行，所以當(dāng)時(shí)我也很苦惱，這個(gè)事情我怎么解決？現(xiàn)在我們有了高雅的解決方法，“織云輿情監(jiān)控”。我們用了一些機(jī)器學(xué)習(xí)中的自然語言處理 (NLP) 方法，通過對(duì)各種渠道收集到的用戶的反饋內(nèi)容進(jìn)行文本分析，找出異常。

語義分析首先要分詞，然后做情感分析，發(fā)現(xiàn)到底是表?yè)P(yáng)我們的還是批評(píng)我們的，如果是批評(píng)我們的，它的量會(huì)不會(huì)有波動(dòng)，正常每天 20 幾 30 幾，如果突然短暫時(shí)間內(nèi)各種渠道有很多人反饋有問題了，基本上就會(huì)有故障，這個(gè)語義分析就是我們對(duì)機(jī)器學(xué)習(xí)文本這邊的嘗試，效果還蠻好的，這個(gè)現(xiàn)在我們所有的產(chǎn)品團(tuán)隊(duì)都在用。

第二部分就是機(jī)器圖像學(xué)習(xí)，前面有一個(gè)有滾動(dòng)條的圖，大家會(huì)發(fā)現(xiàn)一個(gè)模塊下將近有 400 屬性，當(dāng)一旦有問題的時(shí)候，它的監(jiān)控曲線有很多圖都是類似的，所以我們也在做圖像之間的相似性學(xué)習(xí)，有 400 個(gè)屬性沒關(guān)系，也不判斷閥值，就看你曲線長(zhǎng)的像不像，我們?nèi)撕苋菀着袛?#xff0c;機(jī)器也能判斷出來，這也是個(gè)挺好的思路，這對(duì)完全告警收斂有一定的幫助。

第三個(gè)部分是告訴 AI 規(guī)則是什么，通過一些有監(jiān)督學(xué)習(xí)的方式，讓機(jī)器首先去做一些粗判，人工去做一些監(jiān)督，訓(xùn)練機(jī)器，對(duì)曲線的形態(tài)有準(zhǔn)確的判斷，對(duì)我們的告警檢測(cè)會(huì)相當(dāng)有幫助。（201712 月最新的進(jìn)展已經(jīng)在織云 AIOps 里面落地，請(qǐng)參考最新分享）

前面提到“全鏈路數(shù)據(jù)”項(xiàng)目里蘊(yùn)含著大量的數(shù)據(jù)寶藏，但這些寶藏目前想要分析出來還相當(dāng)?shù)睦щy，這里面全是大量的無規(guī)則文本，人肉去做分析難度非常大，機(jī)器可以做的到，我們能夠做輿情分析，那么對(duì)于日志上下文的分析也是有可能實(shí)現(xiàn)的。

值得關(guān)注點(diǎn)

最后對(duì)于監(jiān)控，除了技術(shù)和創(chuàng)新，還有其他值得關(guān)注的地方。

過去為了實(shí)現(xiàn)快、準(zhǔn)、全，我們?cè)诒O(jiān)控平臺(tái)上做了很多的技術(shù)優(yōu)化，但真正運(yùn)用的比較好的監(jiān)控還需要持續(xù)的“運(yùn)營(yíng)”。如何去運(yùn)營(yíng)監(jiān)控有很多的方法論。比如說我們的指標(biāo)怎么建立，我們的閉環(huán)怎么形成，如何建立監(jiān)控生態(tài)，把相關(guān)的團(tuán)隊(duì)，各個(gè)團(tuán)隊(duì)全部能夠卷進(jìn)，比如 QA、研發(fā)、運(yùn)維的角色是什么，怎么去定義，包括這些產(chǎn)品的服務(wù)質(zhì)量考核怎么和監(jiān)控結(jié)合起來，并通過運(yùn)維指標(biāo)的變化來反推產(chǎn)品質(zhì)量?jī)?yōu)化，這都是我們運(yùn)維團(tuán)隊(duì)需要思考的。

? TIPS??

最后是一些小的運(yùn)維經(jīng)驗(yàn)分享，看著小但對(duì)運(yùn)維效率提升很有益處，值得參考。

比如輿情監(jiān)控相當(dāng)建議有能力的團(tuán)隊(duì)去嘗試一下，相當(dāng)?shù)臏?zhǔn)，對(duì)于產(chǎn)品的體驗(yàn)來說，產(chǎn)品體驗(yàn)好不好，看數(shù)據(jù)是一方面，看反饋比看數(shù)據(jù)還要有效，這是我們切身體會(huì)，如果有能力的團(tuán)隊(duì)可以考慮一下輿情的監(jiān)控。

機(jī)器的自動(dòng)處理（服務(wù)自愈），運(yùn)維人力一般不可能有研發(fā)和業(yè)務(wù)增長(zhǎng)快速，有很多事情一定要盡早開始實(shí)現(xiàn)自動(dòng)化處理，比如有些基礎(chǔ)的告警能夠讓機(jī)器去處理的就應(yīng)該讓機(jī)器盡早處理，方法也很簡(jiǎn)單。

移動(dòng)運(yùn)維，還有就是借助方便的手機(jī)端處理運(yùn)維工作，微信還有 QQ 這些工具非常方便，我們現(xiàn)在很多的故障都是在微信里面處理的，在微信可以打開自己的工具，直接就把故障給處理掉了，也很方便。

最后想提一下“告警的分級(jí)”。站在運(yùn)維的角度怎么去做告警分級(jí)，和站在研發(fā)或產(chǎn)品的角度并不相同，在告警分級(jí)這里面有個(gè)簡(jiǎn)單的規(guī)則：合適的人處理合適的告警。

第一個(gè)是告警它本身就要級(jí)別。第二個(gè)，時(shí)間上一定要分級(jí)，比如該什么時(shí)間發(fā)的，該什么時(shí)間不發(fā)的，什么時(shí)間應(yīng)該讓大家去休息和睡覺的，還有范圍也要分級(jí)，升級(jí)機(jī)制也要分級(jí)。前面我們之所以有 5 萬條告警，在于之前沒做好規(guī)劃，比如一個(gè)告警有 20 個(gè)關(guān)注人，一旦發(fā)生問題，這 20 個(gè)人都會(huì)收到告警，這 20 個(gè)人都認(rèn)為別人在處理，自己都不處理，繼續(xù)睡覺，結(jié)果帶來的壞處就是，這個(gè)告警沒有真正指定到人。所以在告警的一個(gè)范圍上應(yīng)該去做些思考的，告警剛剛發(fā)生的時(shí)候應(yīng)該發(fā)給誰，告警如果一直沒有被恢復(fù)應(yīng)該發(fā)給誰，告警產(chǎn)生了嚴(yán)重的質(zhì)量問題后，或者對(duì)一些指標(biāo)數(shù)據(jù)產(chǎn)生了影響之后，應(yīng)該升級(jí)到什么規(guī)模，這些應(yīng)該在運(yùn)維體系里面應(yīng)該去做。

超強(qiáng)干貨來襲 云風(fēng)專訪：近40年碼齡，通宵達(dá)旦的技術(shù)人生

總結(jié)

以上是生活随笔為你收集整理的运维总监聂鑫：腾讯海量监控体系经验分享的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。