梁定安
10年運營開發(fā)、海量運維和架構(gòu)規(guī)劃經(jīng)驗，任騰訊社交平臺運維團隊負責(zé)人
主要負責(zé)Qzone、相冊、音樂等社交平臺類業(yè)務(wù)的運營開發(fā)和運維規(guī)劃工作
精通海量服務(wù)的架構(gòu)設(shè)計和自動化運維建設(shè)
目前專注于devops、APM、大數(shù)據(jù)的運維實踐探索
我是來自于騰訊社交網(wǎng)絡(luò)事業(yè)群的梁定安，今天我給大家?guī)淼姆窒硎顷P(guān)于我們做了幾年的智能監(jiān)控實踐的分享。
我們事業(yè)群是負責(zé)社交網(wǎng)絡(luò)的，就是傳統(tǒng)的QQ、QQ空間、QQ音樂業(yè)務(wù)，跟游戲場景有些不同。
所以，我們在做社交應(yīng)用監(jiān)控的過程中，遇到了一些什么樣的問題，我們做出了什么樣的思考，最終落地的實踐是什么樣的，我今天希望重點跟大家探討這些實踐經(jīng)驗，以及在這個過程中的思考。
我們今天的主題運維自動化是效率提升的一個話題，今天早上也有嘉賓分享過，效率對產(chǎn)品、開發(fā)、業(yè)務(wù)價值來說其實沒有特別地顯性，運維自動化更多受惠的是運維自己，真正給運維帶來價值的是我們對質(zhì)量的保障。
通過我們做的一系列的監(jiān)控、自愈等等運維功能，其實都是為了體現(xiàn)我們運維崗位能給業(yè)務(wù)帶來的一個價值。所以，我認為質(zhì)量是運維最重要最優(yōu)先去關(guān)注的。
運維在關(guān)注質(zhì)量方面主要是三個方面：可靠性、可用性、用戶體驗。
你的程序是不是可靠的，通過對可靠性的管理、監(jiān)控來實現(xiàn)對可用性的評估，提出優(yōu)化建議。通過不同功能、微服務(wù)的可靠性可以計算出業(yè)務(wù)可用性。
最終，所有對可靠性和可用性的度量，都是為了提升用戶使用我們的產(chǎn)品的體驗，讓用戶體驗變得更快、要爽、更好，這是我們做監(jiān)控的意義。
怎么樣能夠保證我們產(chǎn)品的服務(wù)質(zhì)量和用戶體驗?zāi)兀?/p>
通過三種手段可以做到，也是我們談監(jiān)控經(jīng)常談到的手段，
主要分為三種：
主動
被動
旁路
主動，所有的業(yè)務(wù)開發(fā)出來的應(yīng)用程序，在上線之前能夠按照運維的要求，或者自身對代碼質(zhì)量的監(jiān)控，提前做好了很多埋點。
這是最好的開發(fā)和運維的合作模式，但卻是可遇不可求的。
因為很多業(yè)務(wù)在專業(yè)運維團隊接管之前就已經(jīng)存在，運維面臨的最大困難就是歷史包袱，一個業(yè)務(wù)可以沒有產(chǎn)品，可以沒有開發(fā)，但是一定不能沒有運維。
在騰訊社交網(wǎng)絡(luò)的業(yè)務(wù)發(fā)展的十幾年時間里，很多長尾業(yè)務(wù)真的是連研發(fā)團隊、產(chǎn)品團隊都已經(jīng)沒有了，但是服務(wù)仍然在對外提供正常的服務(wù)。
面對種種歷史包袱或者規(guī)劃不周全的問題，監(jiān)控除了主動手段外，還需要第二種方案，就是被動監(jiān)控，一種從外部探測而非自主上報的被動行為。
比如，判斷一臺設(shè)備是不是宕機了，我們可以部署幾臺探測機，持續(xù)的ping它，這就是被動的監(jiān)控手段。
被動有一個先天性的好處，不是強依賴研發(fā)團隊配合，我們無痛式的去監(jiān)控，但是這種能監(jiān)控的粒度往往卻是有限的。
旁路監(jiān)控，主動和被動監(jiān)控做好了，不代表用戶對我們的產(chǎn)品體驗是滿意的。
舉一個例子，有可能我們的服務(wù)都是四個九，甚至是五個九，但是由于用戶本身網(wǎng)絡(luò)的問題，壓根就訪問不了我們的服務(wù)器。
這個時候就需要輿情監(jiān)控等跟第三方的對比數(shù)據(jù)，來間接的反應(yīng)我們外網(wǎng)服務(wù)的真實情況，作為對主動和被動監(jiān)控手段的一個重要的補充。
掌握了監(jiān)控的主要手段后，我們該怎樣衡量各類不同的監(jiān)控點呢？請求量、成功率、延時。
所有監(jiān)控點的度量，都能收攏到這3類指標中。如CPU百分之百了，反饋在我們的服務(wù)上就是成功率的下降或者延時的上升。
這三個指標點怎么樣產(chǎn)生數(shù)據(jù)的價值和反饋出問題呢？
通過趨勢對比，同比、環(huán)比、波動分析、聚類等數(shù)據(jù)加工分析的策略，來更直觀的突出數(shù)據(jù)中需要技術(shù)人員關(guān)注的焦點。
如，通過用戶的來源IP聚類分析來判斷是否有地域的匯聚，從而發(fā)現(xiàn)一些和地域相關(guān)的問題，類似的做法可以把種種隱藏在監(jiān)控數(shù)值下的一些非顯性問題暴露出來。
并且，我們所有的監(jiān)控數(shù)據(jù)最終都是會以圖、表、告警的形式，通知關(guān)注這些監(jiān)控點的人。
我們做任何一個監(jiān)控系統(tǒng)都希望做到全、快、準，就是無盲點，360度無死角，并且又快又準，沒有誤告警。
但是實現(xiàn)起來很困難，從某種意義上來講，監(jiān)控速度要快又要準是有點相矛盾的。
舉一個例子，監(jiān)控突然產(chǎn)生一個毛刺，因為一個網(wǎng)絡(luò)丟包，它的成功率馬上就掉了，這個時候產(chǎn)生告警，可能下個時間片就馬上恢復(fù)了。
如果這樣產(chǎn)生的告警是不是運維人員會覺得不準呢？因為等我上機去看的時候已經(jīng)恢復(fù)了。
我們怎么樣能夠權(quán)衡，能夠做到又快、又準、覆蓋全呢？一旦全了，數(shù)據(jù)量就很多，數(shù)據(jù)多產(chǎn)生的告警點就很多，怎么做到呢？我們帶著這個疑點，看看我們在實踐中是怎么做到的。
隨著移動互聯(lián)網(wǎng)的興起，用戶在訪問到我們社交服務(wù)的時候，全景的鏈路大概是這樣的（圖），首先用戶在自己終端設(shè)備上發(fā)起的訪問，會經(jīng)過很多不同的網(wǎng)絡(luò)到達我們的后臺服務(wù)中。
移動互聯(lián)網(wǎng)讓這個網(wǎng)絡(luò)變得更復(fù)雜化，我們有不同的接入方式，有不同的運營商。
同時，移動互聯(lián)網(wǎng)又把我們暴露在用戶側(cè)的客戶端的版本碎片化，有很多版本，有很多不同廠家不同型號的智能手機，有安卓，有IOS等等不同的系統(tǒng)。
因此，我們要做到全面的監(jiān)測，就必須在整個全景鏈路中設(shè)置很多功能不同的監(jiān)控點。
騰訊在我們的社交業(yè)務(wù)場景下設(shè)置了很多的監(jiān)控點，這是一張全景圖，圖上有很多小字母，每個小字母代表了不同的監(jiān)控類型，我們分為網(wǎng)絡(luò)類、服務(wù)端類、基礎(chǔ)類。
又專門針對移動互聯(lián)網(wǎng)的特殊性做了很多，比如卡慢分析、多維度分析、輿情監(jiān)測，這些都是具體的監(jiān)控點。
有了這么多監(jiān)控點，怎么樣保證所有監(jiān)控點的監(jiān)控數(shù)據(jù)能夠快速地被加工、處理，最終傳遞到最需要關(guān)注的人手中呢？
我把監(jiān)控數(shù)據(jù)從采集到最終終端用戶收到產(chǎn)生的異常信息及單個監(jiān)控點的數(shù)據(jù)從采集到最終產(chǎn)生告警的耗時做成瀑布流。
大家可以很直觀的看到一個監(jiān)控點的數(shù)據(jù)怎么樣加工計算才能保證最優(yōu)最快或者最性價比最高，怎么樣讓我們的告警又快又準？
可以優(yōu)化的點需要我們深入探討和挖掘，由于時間關(guān)系，只能簡單列舉一二。
為了降低計算的復(fù)雜度。我們把所有的數(shù)據(jù)歸為三維數(shù)據(jù)和多維數(shù)據(jù)。
三維的數(shù)據(jù)就是一個ID，你上報的監(jiān)控是什么類型的，你的ID、你的時間、你的值，我們就可以做針對性的告警或者圖形展示的一些優(yōu)化，讓我們的處理速度會變得更快。
多維，因為社交網(wǎng)絡(luò)提供的業(yè)務(wù)類型、對用戶的服務(wù)也是多種多樣的，有QQ，有音樂，有圖片、文件、微云，針對這些不同的服務(wù)場景，它其實都是多維的場景，我們就把它們按場景區(qū)分，分別統(tǒng)一幾類通用的多維協(xié)議，然后我們的后臺流處理集群可以針對每類多維監(jiān)控的場景，定制流計算邏輯，按照用戶使用數(shù)據(jù)的形式將多維數(shù)據(jù)做加工處理。
如果我們后臺用了一個關(guān)系型數(shù)據(jù)庫存儲，過多的數(shù)據(jù)維度，會讓在做監(jiān)控可視化時，無法獲得高效的查詢性能。
我們怎么樣解決其中的矛盾呢？如果數(shù)據(jù)的緯度特別大，隨便列舉一個維度大于30的案例，騰訊億萬級量所產(chǎn)生的監(jiān)控數(shù)據(jù)絕對是“億億”級的。
為了解決這個問題，我們把每一塊都設(shè)計成微服務(wù)化，我們用了開源的svr、kafka、Storm，再落地存儲。
運營開發(fā)和運維人員其實關(guān)系一般不是特別好，如果按照以前我們的分工規(guī)則，一方提需求一方做需求。
運營開發(fā)按自己的思路做一套監(jiān)控系統(tǒng)給運維來用，大部分運維是用得不爽，這是一個客觀存在的事實，這是人性使然。
為了優(yōu)化這個問題，我們微服務(wù)化的分工也是基于這種理念，運營開發(fā)更專注于對Storm邏輯的一些封裝，專注于原始數(shù)據(jù)的高效加工處理，然后，告訴數(shù)據(jù)消費者（運維）有什么樣的數(shù)據(jù)，在數(shù)據(jù)銀行中提供了哪些數(shù)據(jù)的類型，提供了哪些豐富的接口，所有產(chǎn)品化的工作都是由運維來實現(xiàn)的。
整個架構(gòu)圖其實都是運營部來做的，但運營部內(nèi)部又可以按照不同的功能模塊孵化出各自負責(zé)工作的職責(zé)范圍，基于這些職責(zé)范圍我們就可以更好地相互協(xié)作，相互地分享各自的工作成果，這是為了達到快的目標，統(tǒng)一協(xié)議，優(yōu)化我們的分工的一個架構(gòu)。
準，以告警舉例，通常告警的產(chǎn)生基于閥值或算法的策略，把異常的監(jiān)控數(shù)據(jù)點找出，然后系統(tǒng)把過去運維人員處理的異常問題的經(jīng)驗變成一個個自動化的工具，像自愈、收斂、根源分析這樣的延伸功能特性，來達到我們對準的訴求。
如，大范圍故障的場景，一個核心交換機壞了，會產(chǎn)生多少告警？如果所有監(jiān)控點都發(fā)出告警，那這些告警對運維人員其實是騷擾的，是不準的。
但如果絕大多數(shù)的告警都不發(fā)了，就告訴運維是核心交換機故障這一條告警，這便是我們追逐的精準告警。
我們今天主要探討一下怎么樣找到根源的問題，讓我們的告警變得更加智能，而不是“點”的告警。過去我們做了很多監(jiān)控點，我們怎么樣通過點的監(jiān)控去做好“面”的告警呢？
其實做所有事情都是有一些機緣的，因為在業(yè)務(wù)上面臨很大的挑戰(zhàn)，過去我們一步一步去構(gòu)建監(jiān)控體系的時候，我們埋了很多監(jiān)控點，當(dāng)我們的業(yè)務(wù)體量一上來的時候，這些監(jiān)控點就變成運維人員的負擔(dān)，我們對業(yè)務(wù)邏輯監(jiān)控、主機也監(jiān)控、網(wǎng)絡(luò)也監(jiān)控，用戶投訴過來的時候，我去查，很多點都在告警，究竟哪個點的告警最應(yīng)該關(guān)注呢？
運維和研發(fā)人員的人數(shù)配比是相差巨大的，一個運維可能對應(yīng)了上百號開發(fā)，我不可能要求一個運維關(guān)注到方方面面。在我們這么高可用架構(gòu)的前提下是不是還應(yīng)該關(guān)注一些“點”的問題呢？帶著這個疑問，我們繼續(xù)。
這是一張騰訊廣告其中的一個拓撲圖，這張圖想表達一個問題——像網(wǎng)一樣，很亂。
當(dāng)一個節(jié)點發(fā)生異常的時候，會把告警擴散到各個點，因此我們需要一個智能的監(jiān)控分析的引擎，去幫我們解決這里的一些問題。
騰訊的體量在中國互聯(lián)網(wǎng)是用戶最多的，QQ同時在線用戶數(shù)，在2014年就已經(jīng)突破2億，創(chuàng)造了世界的吉尼斯記錄。
2015年紅包的時候甚至達到2.15億同時在線，整個社交網(wǎng)絡(luò)有大于十萬臺的服務(wù)器在支撐著這么大體量的業(yè)務(wù)，每天我們會產(chǎn)生4萬條以上的告警，人均的告警量大于500條，有些比較極端的一天收3000條告警短信。
當(dāng)告警量大于500條，你的所有問題都發(fā)現(xiàn)不了，上班只有看告警就什么事情別做了。
因為業(yè)務(wù)量的龐大復(fù)雜，而產(chǎn)生大量的告警，我們過去所有的收斂辦法都是基于一個垂直監(jiān)控點的收斂，但是監(jiān)控點一旦多起來，點和點之間怎么收斂呢？
因此端到端的智能監(jiān)控應(yīng)運而生，基于業(yè)務(wù)架構(gòu)，結(jié)合數(shù)據(jù)流的關(guān)系，通過時間相關(guān)性、面積權(quán)重等算法，將監(jiān)控告警進行分類篩選，發(fā)掘有業(yè)務(wù)價值的告警，并直接分析出告警根源。
假設(shè)我們在這個架構(gòu)圖上發(fā)現(xiàn)了一個問題，我們的DB掛了，會層層往前推，我們的邏輯層、接入層、負載均衡，甚至到我們的用戶端報上的成功率都會受到影響。
但是運維并不希望收到這N個現(xiàn)象告警，我們希望把DB宕機的根源告警發(fā)出來，其他告警都收斂掉。
首先，我們基于我們的業(yè)務(wù)拓撲圖，根據(jù)時間的相關(guān)性，把告警都疊加在鏈路上，把一些不需要關(guān)注的點都過濾掉，最后得到一個經(jīng)過經(jīng)驗分析的模型。
很簡單的一個例子，變更容易引起告警，DB更容易是根源告警，越靠后的告警越容易是根源的告警，通過這個模型算出根源的問題。
我們采用自動生成拓撲圖的方法，利用社交網(wǎng)絡(luò)事業(yè)群的通用路由組件L5、模塊間服務(wù)調(diào)用監(jiān)控的基礎(chǔ)數(shù)據(jù)作為我們繪制業(yè)務(wù)拓撲圖的基礎(chǔ)數(shù)據(jù)源。
還有一個靠tcpdump抓包的方式，TCP的請求是有序的，UCP的連接也是可以加工的，雖然它發(fā)起的端口是隨機的，但我們通過對數(shù)據(jù)的積累一段時間，就可以清楚地知道這個UDP服務(wù)的主調(diào)和被調(diào)的關(guān)系是什么樣的。
隨后，把網(wǎng)狀的拓撲變成一條一條的訪問關(guān)系鏈，得到這條線之后，我們開始做相對應(yīng)的關(guān)聯(lián)分析的邏輯。
我們把相關(guān)時間的告警疊加上來，我舉一個例子，10:20到10:30分鐘之間產(chǎn)生了這樣一些業(yè)務(wù)告警，在這些模塊都有發(fā)生，B這個模塊產(chǎn)生了業(yè)務(wù)告警，E產(chǎn)生了發(fā)布變更告警，D這個模塊產(chǎn)生了基礎(chǔ)告警。
通過權(quán)重算法對這些鏈路進行排序，再套上模型分析，找到我們最需要關(guān)注的一條鏈路。
如果這里按照過去監(jiān)控點的玩法，我們會產(chǎn)生大于10條的告警，但是我們是希望把這十條告警收斂成這個鏈路的告警。
其實我們現(xiàn)在在舉例試圖讓大家更好地理解我們設(shè)計這個面監(jiān)控的思路。
這張圖是我們的系統(tǒng)截圖，把我們的鏈路從橫向換成縱向，有一些模塊在很長一段時間內(nèi)都會有一些監(jiān)控的異常。
我舉一個實際存在的例子，我們的服務(wù)器上裝了一些Agent，不去深究這個Agent應(yīng)不應(yīng)該存在，它有一些掛了，掛了但是不一定影響我的服務(wù)。
在一個大的集群下每天都會有一些東西掛掉，但是又不影響，它的處理優(yōu)先級很低，但它一直產(chǎn)生告警，因為它有監(jiān)控點。
這些監(jiān)控點怎么不跳出來影響系統(tǒng)的分析呢？
通過時間相關(guān)性的分析，長期存在的紅點都是監(jiān)控到異常，究竟有沒有發(fā)出來被收斂掉了是監(jiān)控系統(tǒng)自身的問題，但是全盤分析中這些監(jiān)控點會被過濾掉，它的權(quán)重是很低的，這個告警是可以忽略掉的，因為它一直都存在。
通過時間相關(guān)性的分析，系統(tǒng)會把持續(xù)性的，跟延時等等相關(guān)的問題，都會過濾掉。
過濾完沒有用的告警，還是有很多告警，怎么樣能夠在眾多的鏈路中找到我們最應(yīng)該關(guān)注的鏈路呢？
面積權(quán)重的算法有一個口訣，越靠后的模塊越有可能是根源的問題，相連產(chǎn)生的告警越可能是根源的問題。
基于這樣的一個原則，我們把它變成了每條鏈路都可以算出一個面積值。
這樣把各個功能模塊介紹完之后，我們的架構(gòu)基本上就可以出來了。
首先，要做這個事情，我們必須要有一些基礎(chǔ)數(shù)據(jù)，就是我們的業(yè)務(wù)拓撲、我們的訪問關(guān)系連，通過日積月累的數(shù)據(jù)整理可以得到。
當(dāng)我們各個告警渠道有異常產(chǎn)生的時候，就開始過濾的動作，最終把我們篩選出的鏈路做排序，再套用我們以前遇到的一些模型、經(jīng)驗去分析它，最終給出根源問題。
舉例說明，6個時間片內(nèi)我們收到了4條告警，在關(guān)系鏈路中疊加出一個告警的情況，B告警延時高，有可能是網(wǎng)絡(luò)擁塞的問題，沒有那么快解決，它是長期存在的，必然不是影響這個時間片的問題，我們把它過濾掉。
還有一個是B毛刺，馬上又恢復(fù)了，最后我們關(guān)聯(lián)到A和D是有關(guān)系的，D可能在發(fā)布，A超時了，我們希望得出一個告警的結(jié)果是這樣的，直接告訴我一個結(jié)論。
回到我們做監(jiān)控的本身，是不是光有監(jiān)控能力就能解決一切的問題呢？
大家可以想一下，運維能做的是最大程度地幫助你降低影響，但是不能保證這個問題如果是程序代碼的問題也能被根治。
通過報警能力的建設(shè)，把質(zhì)量生態(tài)建設(shè)起來，光靠運維團隊自己是沒有辦法做好這個事情的，我們?yōu)榱烁玫刈龊帽O(jiān)控，為了能夠讓產(chǎn)品給到用戶最好的體驗，需要有更多的角色與運維配合著一起去做很多事情。
我們把不同的監(jiān)控點，按照一個業(yè)務(wù)架構(gòu)層級的不同做了一個分類。這個分類就代表了每一類最應(yīng)該由誰負責(zé)跟進，相當(dāng)于是給每個人負責(zé)一大堆的監(jiān)控點的現(xiàn)狀做了減法。
以前我們做監(jiān)控的時候，經(jīng)常說這個監(jiān)控點是這個業(yè)務(wù)邏輯影響的，配上他的開發(fā)總監(jiān)，對口的運維也對上，導(dǎo)致一個告警產(chǎn)生首先輻射了一大堆人，很多人收到這個告警不知道要做什么，他可能就看手機震動得快不快。
為了優(yōu)化這樣的問題，我們專門對所有的監(jiān)控點按照不同的角色要關(guān)注的內(nèi)容不同做了一個分類，就像用戶端輿情的監(jiān)控，輿情的監(jiān)控拿手機應(yīng)用舉例，更多的是產(chǎn)品體驗的一些問題，說不定用戶噴的是按鈕擺在右面不習(xí)慣，我要擺在左面，或者說他噴的功能性的問題。
我們希望把系統(tǒng)的告警是分級的，根據(jù)不同的告警優(yōu)先級走不同的告警渠道，有QQ、短信、微信、電話，不同的人不同的告警，不同優(yōu)先級的告警渠道來分發(fā)。
運維是主要構(gòu)建一個監(jiān)控的能力，并不是運維會收所有的告警，運維只收最關(guān)鍵的告警。
這里還有一個DLP（生死點），是下面三層所有監(jiān)控點，這么多監(jiān)控點如果放在一個模塊里，這個模塊所有的點可能都告，但是我們希望這個模塊只告一個，這就是它的DLP。
你的一個agent告警不是決定服務(wù)生死的關(guān)鍵，那就是agent的負責(zé)人去跟進，選定一個能夠決定這個模塊生死的監(jiān)控點作為模塊的唯一運維負責(zé)的監(jiān)控點，質(zhì)量由運維來負責(zé)。
其他的如網(wǎng)絡(luò)問題，負責(zé)基礎(chǔ)網(wǎng)絡(luò)的運維去看。
應(yīng)用運維，負責(zé)業(yè)務(wù)的質(zhì)量，應(yīng)該投入100%的精力處理好DLP監(jiān)控點的所有異常。通過DLP監(jiān)控點再去與智能監(jiān)控分析做整合，再對鏈路中各個模塊的DLP進行一次收斂，每條鏈路只看一個點，每條鏈路根據(jù)相關(guān)性進行收斂之后，得出一條鏈路。
通過這個，我們把監(jiān)控點做一個減法，很好地把告警收斂掉。
我們的監(jiān)控體系是閉環(huán)的：監(jiān)控能力、業(yè)務(wù)可用性、用戶體驗、技術(shù)解決、統(tǒng)計分析、持續(xù)改進。
我們希望構(gòu)建這樣一個質(zhì)量體系，把開發(fā)、運維、客服、QA、老板、產(chǎn)品都卷進來，運維在這里搭這樣一個舞臺，讓大家共同參與演出，貢獻力量。
監(jiān)控其實就是一座很高的雪山，這里的坑很深，很難挖。我們正在探索不同的方法去攀登征服這座雪山，今天分享的這個系統(tǒng)未必能夠解決所有的問題。
但在我們實戰(zhàn)一年多的時間里，確實能夠真正幫助運維解決一些問題，我們的告警沒有以前那么多了，重新梳理了我們整個體系的生態(tài)，讓更多的人進入我們的生態(tài)貢獻自己的一份力量。
我今天的分享結(jié)束了，謝謝大家！
A：其實要看不同的場景，具體的占比沒有計算過，旁路肯定是最少的，但是旁路往往最能說明問題，我們做監(jiān)控的目標是為了監(jiān)控用戶體驗有沒有受影響。
我提到的旁路監(jiān)控就是輿情，監(jiān)控用戶口碑，在用戶反饋的論壇，你的APP有一些快速反饋通道的時候，用戶反饋的自然語言會被分析，分析完了發(fā)現(xiàn)異常
例如QQ發(fā)不了消息，這個關(guān)鍵詞被命中很多就會告警，確實是有用戶遇到這種問題。
但是并不是說它就是萬能的，有些情況下用戶不會反饋，直接卸掉了。
這個時候我們需要結(jié)合主動和被動，我們技術(shù)能做的就是把主動和被動做好，輿情作為我們的一個輔助手段
要說占比的話，主動當(dāng)然是做得越多越好，但是這里往往有一個問題，拿日志舉例，我們?nèi)罩镜囊?guī)范是不是一開始就能夠設(shè)計好？
隨著業(yè)務(wù)的發(fā)展，我們未必考慮得那么清晰
現(xiàn)在在騰訊社交網(wǎng)絡(luò)事業(yè)群，其實我們沒有一套通用的標準化日志，因為從騰訊剛成立就想規(guī)劃清晰標準日志體系。
公司發(fā)展壯大后，QQ打一份自己覺得是規(guī)范的，QQ空間又打一份自己覺得是規(guī)范的，以誰的為準呢？
如果研發(fā)團隊能夠配合運維做好這里的規(guī)范和準則，并且按照運維的要求主動上報，我們的監(jiān)控點肯定是全的，
但是事實上，我們不得不面對這些客觀的問題，我們只能退而求其次用被動的方法。
A：當(dāng)你的報警精準度很高之后，就可以對告警做分類，做自愈了。
A：我們所有的基礎(chǔ)告警都是自愈的，機器宕機等這些都是要求自愈的。業(yè)務(wù)側(cè)的一些告警，目前我們還沒有嚴格的要求你自愈率一定要達到多少，因為這真的是跟研發(fā)投入相關(guān)的，但是我們也正在朝這個方向去做。
我之前還分享過我們自動化的一個平臺，如果是容量導(dǎo)致的業(yè)務(wù)成功率低的話，我們會有一個自動上線的過程，就跟騰訊的藍鯨平臺的是一樣，這些是歸為自愈的，但是這些比較可控。
A：這確實是一個很好的問題，告警的收斂，收斂之后的告警是只給運用運維看的，原生監(jiān)控點產(chǎn)生的問題應(yīng)該是開發(fā)看的，還是會有人看，只是說相對的優(yōu)先級不會那么高，被我收斂后的告警的優(yōu)先級更高。
怎么樣解決覆蓋全的問題，凡事都有一個過程，在我們完全到達巔峰的情況下，還是要兼顧整體的。
目前這條路是不是百分之百覆蓋了社交業(yè)務(wù)所有的場景？
我其實是不敢這么說的，因為隨著業(yè)務(wù)的邏輯、架構(gòu)的不斷變化，有可能會產(chǎn)生新的問題，但是目前我們還在不斷地建設(shè)，把我們的門檻降低，就能夠持續(xù)地優(yōu)化它。
那么，請來將于9月23-24日舉行的GOPS上海站
這一次他將作為運維自動化的出品人
并另外貢獻海量運營規(guī)劃相關(guān)的主題演講
8 折優(yōu)惠截止7月29日，欲購從速！
聯(lián)系客服
