騰訊社交業(yè)務(wù)規(guī)模龐大，歷史悠久矩乐，架構(gòu)復(fù)雜龄句。從運(yùn)維的全局角度來看，無論從運(yùn)維技術(shù)還是監(jiān)控難度都很大散罕。傳統(tǒng)的監(jiān)控手段和思想已經(jīng)無法應(yīng)對如此海量的場景分歇，騰訊社交網(wǎng)絡(luò)運(yùn)營部歷經(jīng)十年的建設(shè)，在運(yùn)維監(jiān)控領(lǐng)域經(jīng)過了多個(gè)建設(shè)階段欧漱。近幾年通過創(chuàng)新的方法引入了多種技術(shù)手段并實(shí)踐落地职抡，將監(jiān)控技術(shù)帶入一個(gè)新的運(yùn)維高度，本次將主要分享四個(gè)創(chuàng)新技術(shù)點(diǎn)误甚。本文整理自聶鑫在 ArchSummit 2017 深圳站上的演講缚甩，原題為《騰訊海量監(jiān)控包袱與創(chuàng)新》。

寫在前面

十年前我到騰訊的時(shí)候靶草，運(yùn)營部剛成立蹄胰，正好開始做 DO 分離這件事情，研發(fā)和運(yùn)維開始分離了奕翔，由專門的團(tuán)隊(duì)來做運(yùn)維這件事情裕寨，但當(dāng)時(shí)沒有太好的運(yùn)維解決方案和思路，所有的東西都需要靠自己摸索派继，監(jiān)控就是其中最大的一個(gè)困難點(diǎn)宾袜。當(dāng)時(shí)我們主要還在做“補(bǔ)功課”，補(bǔ)齊各種基礎(chǔ)的監(jiān)控指標(biāo)和能力驾窟。直到 12 年之后業(yè)務(wù)開始面臨到了很多新的挑戰(zhàn)庆猫，高速發(fā)展的業(yè)務(wù)和移動(dòng)化的進(jìn)展加快，讓我們面臨的監(jiān)控難度也越來越大绅络，所以開始有了很多監(jiān)控相關(guān)的新的嘗試月培。

我們的運(yùn)維說簡單一點(diǎn)嘁字，主要在做三件事情。第一個(gè)就是控制業(yè)務(wù)架構(gòu)：空間杉畜、QQ纪蜒、QQ 音樂這些服務(wù)架構(gòu)是怎么部署的。第二個(gè)此叠，自動(dòng)化能力：各個(gè)團(tuán)隊(duì)纯续，各個(gè)公司在自動(dòng)化運(yùn)維，智能化運(yùn)營灭袁，精細(xì)化運(yùn)營猬错，包括現(xiàn)在很火的 DevOps，都算是自動(dòng)化能力的體現(xiàn)茸歧。第三部分就是監(jiān)控能力倦炒。這也是運(yùn)維三個(gè)不變的主題之一，也是今天主要講的举娩，聚焦在這里和大家一起來探討一下析校。

先拋幾個(gè)數(shù)據(jù)构罗。我們現(xiàn)在有將近 20 套監(jiān)控系統(tǒng)铜涉，指標(biāo)有將近 300 多個(gè)，監(jiān)控的實(shí)例超過 900 萬遂唧，最可怕的是我們每天有近 5 萬條短信告警芙代，人均 500 條。去年收告警最多的運(yùn)維盖彭，一天能收 1500 條短信纹烹，收告警比較多的研發(fā)同學(xué)，每天也有 1200 條短信召边。不知道大家有沒有體驗(yàn)過這種感受铺呵，手機(jī)里面一天有 1000 條短信過來，這是很讓人崩潰的一件事情隧熙。

首先要先簡單介紹一下我們正在做的監(jiān)控片挂，從 06 年開始到 14 年，我們的監(jiān)控圍繞著三個(gè)目標(biāo)：“快”贞盯，“準(zhǔn)”音念，“全”。大部分建設(shè)基本都是圍繞這三個(gè)目標(biāo)去做事情的躏敢。首先要求我們的告警能夠覆蓋很全闷愤，能主動(dòng)發(fā)現(xiàn)用戶的各種犄角旮旯的異常，為此衍生了各種各樣的監(jiān)控手段件余，這就是為什么目前我們會(huì)有 20 套監(jiān)控體系讥脐。其次我們希望告警非吃饩樱快，一出問題馬上發(fā)出來旬渠，同時(shí)希望告警準(zhǔn)魏滚，誤告警少。目前每天有將近 5 萬條告警坟漱，人均幾百條鼠次，說明當(dāng)前告警是不準(zhǔn)的。能不能解決好這件事情芋齿？可能就成為了在監(jiān)控領(lǐng)域運(yùn)維的一種技術(shù)和一種藝術(shù)腥寇。后面分享的幾個(gè)比較有意思的小創(chuàng)新，就是它融入了很多老運(yùn)維同學(xué)的運(yùn)營藝術(shù)在里面觅捆。

這是我最近剛剛更新的數(shù)據(jù)赦役，可以看得到我們每天的監(jiān)控實(shí)例非常的龐大。從 09 年開始栅炒，當(dāng)時(shí)只有幾套監(jiān)控掂摔，隨后每年都在增長，在 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)樟澜，最近我們又做了哪些不一樣的“新”事情误窖。說到創(chuàng)新，這么多的監(jiān)控系統(tǒng)往扔，存在必有它的合理性贩猎，我們?nèi)ソㄔO(shè)新的創(chuàng)新并不是要否定過去監(jiān)控系統(tǒng)的存在，主要還是希望通過解決歷史中一些不合理的架構(gòu)演進(jìn)萍膛，用一些創(chuàng)新的方法吭服，讓我們的監(jiān)控能夠朝真正的快、準(zhǔn)蝗罗、全這個(gè)方向去發(fā)展艇棕，而不是局部優(yōu)化或者推翻重做這樣子的一個(gè)思路蝌戒。所以下面的一些創(chuàng)新的方法，可能大家會(huì)發(fā)現(xiàn)運(yùn)用的技術(shù)并不是特別牛逼沼琉，可能不是特別了不起的算法北苟。

ROOT

第一個(gè)就是代號(hào) 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à)值的告警，推斷出造成告警的故障根源胸梆。

因?yàn)槲覀儎偛盘徇^敦捧，我們有 5 萬條告警，其實(shí)騰訊的業(yè)務(wù)總體服務(wù)體驗(yàn)還是很好的碰镜，至少?zèng)]有讓人感覺有特別多故障兢卵，為什么出現(xiàn)一方面有 5 萬條告警，另一方面好像服務(wù)質(zhì)量還行洋措？可以肯定的有大量的告警是重復(fù)和無效的济蝉。我們啟動(dòng)建設(shè) Root 智能分析的目的是希望能夠解決這個(gè)問題杰刽。

第一菠发，我們需要能夠了解業(yè)務(wù)架構(gòu)，這也是運(yùn)營上的一種思路贺嫂，“基于業(yè)務(wù)架構(gòu)去運(yùn)營”滓鸠。在我們的內(nèi)部里面，是會(huì)對一些核心服務(wù)架構(gòu)進(jìn)行梳理第喳，比如繪制出架構(gòu)圖來糜俗，維護(hù)并運(yùn)營起來。

第二曲饱，有了架構(gòu)圖悠抹，我們可以比較方便地去獲取架構(gòu)之間的訪問關(guān)系，有很多手段扩淀。同時(shí) 20 套監(jiān)控系統(tǒng)中有大量的數(shù)據(jù)是帶有一定的邏輯訪問關(guān)系的楔敌，從中做一些簡單的篩選，就能夠獲取架構(gòu)中的訪問關(guān)系驻谆。這個(gè)圖是實(shí)際的系統(tǒng)截圖卵凑，紅線就代表里面有大流量庆聘，灰線代表里面流量比較低，是非常容易做得到的勺卢。但是這里也有個(gè)問題伙判，架構(gòu)是網(wǎng)狀的，人肉眼來看是很難去區(qū)分這里面到底和誰有真正直接的關(guān)系黑忱，或者說告警發(fā)生的服務(wù)宴抚，和告警的故障根源服務(wù)到底是怎么樣的關(guā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)剪勿，可以推測出架構(gòu)中哪一條鏈路或者多條鏈路的故障現(xiàn)象和故障根源最有可能發(fā)生贸诚。

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

過去我們很苦惱班眯，每個(gè)新的告警對我們的工作都會(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í)赛蔫，我們在這里會(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)槭裁床蝗グ阉崂硪幌绿绷堪堰@個(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)確性窿祥，這也是我們在尋求告警關(guān)聯(lián)分析準(zhǔn)確度上的一個(gè)探索。

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

舉例說，用戶 QQ 里面不能發(fā)消息了贝奇，往往不一定是 QQ 有問題虹菲，很有可能后面數(shù)據(jù)庫宕掉了。在一個(gè)多運(yùn)維團(tuán)隊(duì)協(xié)同分工運(yùn)營體系下掉瞳，前端負(fù)責(zé)人很多時(shí)候不知道后面那臺(tái)數(shù)據(jù)庫宕掉了毕源，所以現(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ū)別對待嬉探，可以根據(jù)業(yè)務(wù)的重要性去做處理，服務(wù)如果重要那么可能就要處理分析一下棉圈；如果不重要涩堤，站在我的立場，我覺得可以不處理分瘾。

我們會(huì)更加去關(guān)注“關(guān)聯(lián)性告警”胎围，它是有因有果，就應(yīng)該立刻去處理德召。有一個(gè)簡單的數(shù)據(jù)白魂，這是最后的結(jié)果，我們發(fā)現(xiàn)那 5 萬條告警里面上岗，有 65% 屬于持續(xù)性告警福荸，不是那么重要，可能不一定真的要把它清理掉肴掷，但是對于告警分析來說沒有那么重要敬锐。波動(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)注的一部分告警韵吨。

后面是簡單的一個(gè)算法，這種鏈路怎么去判斷權(quán)重亏推，哪個(gè)應(yīng)該告警学赛，哪個(gè)應(yīng)該不告警，這里有個(gè)簡單的面積算法吞杭。簡單解釋一下盏浇，根據(jù)告警連續(xù)，如果一連續(xù)它的長度就加芽狗，如果不連續(xù)它的縱向就減绪钥，最后算出一個(gè)簡單的面積來焰枢。

比較典型的例子魔眨，就像這種苏章，同樣是 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)確性双揪。

代碼很簡單，分享給大家包帚。

DLP

16 年初我們開始做 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)在觀測故障吼鱼，大多數(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ù)成功率吮螺，失敗率，各種訪問量帕翻、購買量鸠补、在線數(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ù)跌了一定是有問題，購買量跌了一定是有問題摹蘑，這的確是事實(shí)筹燕，但是作為技術(shù)運(yùn)營線，作為運(yùn)維衅鹿，或者說作為最前沿的技術(shù)研發(fā)撒踪，這些指標(biāo)的一些漲和跌是不是應(yīng)該馬上去處理的？事實(shí)是這個(gè)指標(biāo)的漲跌大渤，可能和很多非技術(shù)因素有關(guān)系制妄，比如說發(fā)布原因造成的，比如活動(dòng)造成的泵三，這些大家都見過耕捞，做一個(gè)活動(dòng)衔掸，購買量一定會(huì)漲，活動(dòng)一結(jié)束一定會(huì)跌砸脊，但這些指標(biāo)是不是我們技術(shù)運(yùn)營線要去第一關(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è)指標(biāo)折算購買成功率，用 DLP 來監(jiān)控這個(gè)購買成功率伏恐。

有了前面的三個(gè)假設(shè)孩哑，就可以采取一些簡單的統(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ì)對告警做各種各樣的數(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)新貌矿，但是對于解決監(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ù)以前對我們運(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è)對比，如果發(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 玩直播虐先，可能在一些特殊的場景下，比如電梯里面派敷。

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

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

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

后面分享的是一些我們也在探索的部分（201712 月最新的進(jìn)展已經(jīng)在織云 AIOps 里面落地员舵，請參考最新分享），所以寫的是踐行遭商，我相信同行們都在做這件事情固灵，跟大家交流一下，包括幾個(gè)部分劫流，主要是機(jī)器學(xué)習(xí)相關(guān)的巫玻。

我們自己總是給自己樹一個(gè)愿景：咖啡運(yùn)維，希望我們做運(yùn)維的坐在那里喝咖啡就行了祠汇，花了十年時(shí)間還沒有到這個(gè)目標(biāo)仍秤。

這是我們以前的做法，對數(shù)據(jù)進(jìn)行各種各樣的分析可很，大家都用過诗力，各種曲線圖對比，這都是老套路我抠，匯聚苇本、對比袜茧、閥值、分布瓣窄、聚類笛厦，這個(gè)我們都用過，但是幫助有限俺夕。

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

這個(gè)項(xiàng)目還要從一個(gè)有趣的例子說起，早年我接觸過一個(gè)老板映九，他抱怨說我們的服務(wù)質(zhì)量不好梦湘。他的理由很簡單，他每天上百度上去搜氯迂，有負(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) 方法，通過對各種渠道收集到的用戶的反饋內(nèi)容進(jìn)行文本分析荞雏，找出異常虐秦。

語義分析首先要分詞，然后做情感分析凤优，發(fā)現(xiàn)到底是表揚(yáng)我們的還是批評(píng)我們的悦陋，如果是批評(píng)我們的，它的量會(huì)不會(huì)有波動(dòng)筑辨，正常每天 20 幾 30 幾俺驶，如果突然短暫時(shí)間內(nèi)各種渠道有很多人反饋有問題了，基本上就會(huì)有故障棍辕，這個(gè)語義分析就是我們對機(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)系晌块，也不判斷閥值爱沟，就看你曲線長的像不像，我們?nèi)撕苋菀着袛啻冶常瑱C(jī)器也能判斷出來呼伸，這也是個(gè)挺好的思路，這對完全告警收斂有一定的幫助钝尸。

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

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

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

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

過去為了實(shí)現(xiàn)快冠场、準(zhǔn)、全本砰，我們在監(jiān)控平臺(tái)上做了很多的技術(shù)優(yōu)化碴裙，但真正運(yùn)用的比較好的監(jiān)控還需要持續(xù)的“運(yùn)營”。如何去運(yùn)營監(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ì)量優(yōu)化秤茅，這都是我們運(yùn)維團(tuán)隊(duì)需要思考的。

TIPS

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

比如輿情監(jiān)控相當(dāng)建議有能力的團(tuán)隊(duì)去嘗試一下厦坛，相當(dāng)?shù)臏?zhǔn)五垮，對于產(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ù)增長快速小作，有很多事情一定要盡早開始實(shí)現(xiàn)自動(dòng)化處理，比如有些基礎(chǔ)的告警能夠讓機(jī)器去處理的就應(yīng)該讓機(jī)器盡早處理稼钩，方法也很簡單顾稀。

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

最后想提一下“告警的分級(jí)”侨拦。站在運(yùn)維的角度怎么去做告警分級(jí)殊橙，和站在研發(fā)或產(chǎn)品的角度并不相同，在告警分級(jí)這里面有個(gè)簡單的規(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ì)量問題后颗圣，或者對一些指標(biāo)數(shù)據(jù)產(chǎn)生了影響之后喳钟，應(yīng)該升級(jí)到什么規(guī)模，這些應(yīng)該在運(yùn)維體系里面應(yīng)該去做在岂。

去年 7 月我在 ArchSummit 深圳站上與大家分享了《騰訊海量監(jiān)控包袱與創(chuàng)新》奔则，當(dāng)時(shí)大會(huì)設(shè)置的運(yùn)維專題仍聚焦在?運(yùn)維新挑戰(zhàn)上，去年 12 月北京站則設(shè)置的是?新一代 DevOps蔽午，可以看出大家關(guān)注的運(yùn)維技術(shù)熱點(diǎn)已經(jīng)快速變化易茬。

今年的 ArchSummit 深圳站策劃已經(jīng)出來了，與運(yùn)維架構(gòu)有關(guān)的是：不可阻擋的 AIOps及老。

Gartner 在 2016 年時(shí)便提出了 AIOps 的概念抽莱，簡單來說，AIOps 就是希望基于已有的運(yùn)維數(shù)據(jù)（日志骄恶、監(jiān)控信息食铐、應(yīng)用信息等）并通過機(jī)器學(xué)習(xí)的方式來進(jìn)一步解決自動(dòng)化運(yùn)維沒辦法解決的問題，同時(shí) Gartner 也預(yù)測僧鲁，到 2020 年虐呻，AIOps 的采用率將會(huì)達(dá)到 50%象泵。

到時(shí)候會(huì)有哪些新實(shí)踐？ArchSummit 深圳站的內(nèi)容铃慷，可以點(diǎn)擊?閱讀原文進(jìn)行了解单芜，敬請期待。

作者介紹

聶鑫犁柜，騰訊運(yùn)維總監(jiān)洲鸠。從開發(fā)到運(yùn)維，伴隨騰訊社交網(wǎng)絡(luò)運(yùn)營部成長的十年馋缅，負(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ì)的成長和成熟，見證著騰訊一代代運(yùn)營技術(shù)的創(chuàng)新和發(fā)展覆履。作為運(yùn)維界老兵有好多故事想和大家講蹋盆，也特別愿意聽聽各位經(jīng)歷的酸甜苦辣