《美團(tuán)點(diǎn)評運(yùn)維總監(jiān)鐘紅軍：美團(tuán)運(yùn)維的工具化、產(chǎn)品化、運(yùn)營化》要點(diǎn)：
本文介紹了美團(tuán)點(diǎn)評運(yùn)維總監(jiān)鐘紅軍：美團(tuán)運(yùn)維的工具化、產(chǎn)品化、運(yùn)營化，希望對您有用。如果有疑問，可以聯(lián)系我們。

本次分享嘉賓是美團(tuán)點(diǎn)評運(yùn)維中心高級總監(jiān)鐘紅軍,他向我們詳細(xì)介紹了美團(tuán)點(diǎn)評近3年來在大規(guī)模運(yùn)維的理念和實踐方面的探索,尤其是在運(yùn)維自動化和數(shù)據(jù)運(yùn)營方面的工作和效果.

鐘紅軍 / 美團(tuán)點(diǎn)評運(yùn)維中心高級總監(jiān)

美團(tuán)點(diǎn)評集團(tuán)運(yùn)維中心高級總監(jiān),此前曾工作于百度,騰訊,PPTV等互聯(lián)網(wǎng)公司,熟悉系統(tǒng)、網(wǎng)絡(luò)、運(yùn)維、安全、數(shù)據(jù)、開發(fā)等多個領(lǐng)域.

今天我將美團(tuán)點(diǎn)評這幾年在運(yùn)維方面做的一些工作,以及自己的思考與大家分享一下.美團(tuán)點(diǎn)評整個運(yùn)維團(tuán)隊100多人,base在北京和上海,美團(tuán)和點(diǎn)評兩家公司在2015年合并,所以團(tuán)隊也是兩地都有.運(yùn)維中心有SRE團(tuán)隊有數(shù)據(jù)庫的團(tuán)隊,有自動化開發(fā)等.

階段1：工具化

我是2013年從百度加入點(diǎn)評的,之前在騰訊,當(dāng)時想法很明確,因為騰訊、百度的運(yùn)維體系相對比較成熟,包括運(yùn)維工具、自動化的工具都是一整套,比較好用,對我來說最遺憾的是這些工具都不是自己做的,在騰訊我只是一個用戶,每天用那些運(yùn)維工具卻不知道這些工具如何做出來的.所以在美團(tuán)點(diǎn)評給自己的使命,就是要把美團(tuán)點(diǎn)評的運(yùn)維做到騰訊、百度的水平,把缺失的過程、成長的過程由自己做出來.美團(tuán)點(diǎn)評運(yùn)維團(tuán)隊在2014年－2015年業(yè)務(wù)發(fā)展非常快,公司有幾萬人,研發(fā)團(tuán)隊很大,那時候的運(yùn)維做得還是處于相對基礎(chǔ)的階段,遇到了問題,不分白天黑夜操作壓力很大,尤其是出了事故要應(yīng)急,過節(jié)需要各種的準(zhǔn)備,值班也很混亂.

最初想法很簡單,希望把這事情做到極簡、規(guī)范和一致,保證操作能做到幾十年不變,不管誰來做都是同樣的操作.比如裝一臺機(jī)器或者是部署一個應(yīng)用,希望它做一百次、一千次也是這樣.第二,把程序代替繁瑣的工具,第三,所有的操作都可記錄,以免出了事故找不到是誰操作的.第四,把運(yùn)維操作往前推,希望運(yùn)維操作不要由運(yùn)維來做了,由研發(fā)來做,因為需求本身來自于研發(fā),不是來自于運(yùn)維,所以需求來了也應(yīng)該由研發(fā)去做.

以上是我去年總結(jié)的四句話,看似很普通的四句話,是美團(tuán)點(diǎn)評做自動化過程中的一個線條.第一句話,凡是不能變成工具的規(guī)范我們都不看.做運(yùn)維大家會想到出一點(diǎn)規(guī)范,比如發(fā)布規(guī)范、部署規(guī)范、命名規(guī)范,機(jī)器取名得有一個規(guī)范,不規(guī)范操作容易出錯.在我看來,任何一個規(guī)范如果不能變成一個工具去約束的話,這規(guī)范沒有意義.寫一篇文檔或者一個要求,發(fā)給研發(fā)去看,只要它不能變成一個工具就沒有意義,因為這個規(guī)范出來,如果布置工具的話,實現(xiàn)100次可能有一次有人不遵守.但其實他一次都不遵守,好過做100次只有一次不遵守,因為每次都不遵守,問題很好查,而做了100次有一次不遵守,就很難查.比如晚上服務(wù)掛了,一千臺的服務(wù)器,是其中一臺的問題其實挺難查的,如果這一千臺有共同的問題,就很好查.

規(guī)范本身沒有任何的意義,只有它變成一個工具才有意義,因為強(qiáng)調(diào)的是一致性,希望它犯錯也是每次犯同樣的錯,不要每次犯不一樣的錯.所以,我們的點(diǎn)評團(tuán)隊沒有howto,沒有文檔,整個運(yùn)維很少做文檔.當(dāng)然現(xiàn)在也做了,100多人還是要做一些不能形成工具的規(guī)范,不過還是堅持這一點(diǎn),規(guī)范應(yīng)該想辦法做一個工具.比如我們有一個靜默期的要求,春節(jié)長假前三天不允許發(fā)版本.那么從2013年開始點(diǎn)評就執(zhí)行這個規(guī)則的,因為它有工具支持,發(fā)布系統(tǒng)要有開關(guān),一到時間就能關(guān)掉,必須走運(yùn)維的審批流通,這個流程是自動化的.但在2015年,新發(fā)布系統(tǒng)不支持這個開關(guān),因此把這個規(guī)范停下來了,不執(zhí)行這個規(guī)范,因為沒有工具支持,執(zhí)行這個規(guī)范沒有意義,發(fā)個通知告訴大家要靜默期,首先要挨罵,其次大家該怎么樣怎么樣,罵完之后扔不執(zhí)行這個規(guī)范,后來我們就停下來,直到今年春節(jié)的時候,終于支持這個功能了再執(zhí)行這個規(guī)范.

第二,不是增加power,而是減少power .解釋一下,在2014年－2016年做運(yùn)維自動化相關(guān)工具的時候,團(tuán)隊的內(nèi)部也是有很多的爭議的,其中一個很重要的爭議就是,有相當(dāng)多的同學(xué)認(rèn)為做自動化工具是給運(yùn)維的人更大的power ,能做更多的事,大家無限暢想這個工具可以怎么樣,一按鍵所有的機(jī)器都重啟起來,其實很悲劇.我的理念是工具是為了減少power ,不是為了增加power ,為什么這么說呢?如果是使之為了更強(qiáng)大的話,其實手工操作是最強(qiáng)大的,給一個ssh命令的窗口,一個root,就是最強(qiáng)大的,什么都可以做.工具本質(zhì)是為了限制,不是為了增強(qiáng),是干不了什么而不是能干什么.比如做自動化流程系統(tǒng),在考核自動化流程系統(tǒng)的時候,看它的流程多不多,流程越多說明做得越爛.作為一個運(yùn)維來說,我認(rèn)為不應(yīng)該有超過10個流程.常見的運(yùn)維操作不會超過10個,加機(jī)器、減機(jī)器、重啟機(jī)器,其他的配一個域名等.如果管理到位一點(diǎn),比如配一個web的IP,這些應(yīng)該都不需要運(yùn)維來做,所以超過10件事是有問題的.

第三,解決一個復(fù)雜的問題,不可以引入另一個復(fù)雜問題作為代價.很多做運(yùn)維的同學(xué),尤其是做了一段時間后,學(xué)過很多各種各樣的概念,從最早的ITIL,到現(xiàn)在的SRE等等,容易犯一個錯誤,就是喜歡用復(fù)雜的方法解決復(fù)雜的問題,運(yùn)維的體系也好、運(yùn)維自動化也好,其實是一個簡單的問題.回到最初來講,運(yùn)維解決的問題是保障線上的穩(wěn)定,只有這一件事情.運(yùn)維自動化解決什么問題?就是讓所有第三方因素或者是人為的因素對線上穩(wěn)定性造成的傷害越少越好,這個越少越好來自于第一變更越少越好,我們在騰訊后期提出這種理念,沒有變更才是最好.以前大家說管理變更,變更要管理起來,這個變更完了是永遠(yuǎn)管理不好的,最好不要有變更.比如擴(kuò)容,很多同學(xué)提出節(jié)假日了容量不夠,要實現(xiàn)一鍵擴(kuò)容,在我的理解里面,我希望實現(xiàn)不需要擴(kuò)容.

解決一個復(fù)雜問題,如果是用一個復(fù)雜的方法去解決,或者是引入另外一個復(fù)雜問題的話,把這東西搞得更復(fù)雜了,這是不對的.比如做監(jiān)控的時候,是做減法而不是做加法,因為搞太復(fù)雜了沒有意義,假定監(jiān)控報警一天超過一千個了,是沒有區(qū)別的,因為這時候運(yùn)維做的事情肯定就是關(guān)手機(jī),所以要做減法,不能引入復(fù)雜的問題,一定要找一個簡單的方法.

第三句話和第四句話是類似的,就是工具“極簡”是一種使命.我看過很多運(yùn)維自動化的工具,包括騰訊、百度,還有國內(nèi)很多互聯(lián)網(wǎng)公司,因為我當(dāng)時在招人,面試過互聯(lián)網(wǎng)公司做工具的同學(xué),很不幸最后一個人沒有招,我發(fā)現(xiàn)他們做工具的思路和我的不太一樣,很多做自動化工具的同學(xué),往往以為讓工具有價值,就把它做得復(fù)雜,看起來很華麗.總之,這不是我的思路,我的思路是極簡.

比如這個運(yùn)維自動化的工具假設(shè)只有一個按鈕,那當(dāng)然是最好的,但是做不到,我們不是喬布斯.再如做一個擴(kuò)容,有很多選項可以選的,什么機(jī)房、哪個機(jī)房,尤其是規(guī)模比較大的話什么類型的機(jī)器、多少內(nèi)存、多少CPU等等,很多同學(xué)認(rèn)為選項越多,這個工具越好,越強(qiáng)大,在我看來選項越少越好,多了以后,第一容易出錯,萬一選錯了,接下來就涉及到研發(fā)和運(yùn)維的PK了.還有一個是浪費(fèi)了時間,擴(kuò)容一臺機(jī)器應(yīng)該是一件不花時間的事情,選項那么多就要看半天的時間.從工具表現(xiàn)來說,也是工具越簡單越好.但造成一個沒有想到的后果,工具做得很難看,后來我們也招前端的同學(xué)來把它做好看一點(diǎn),而不是做復(fù)雜.這幾年做運(yùn)維自動化總結(jié)下來就這四句話.

美團(tuán)點(diǎn)評的自動化工具

講一下美團(tuán)點(diǎn)評的自動化工具.最早做的是這樣一個系統(tǒng),抽離一下主要是四個東西：中間是一個CMDB,一套流程系統(tǒng),一套操控平臺和一套監(jiān)控系統(tǒng).自動化主要是四件事——

第一,資料.所有的自動化基于非常準(zhǔn)確、詳盡的資料,尤其是虛擬化、云計算比較流行的時代,一臺機(jī)器在哪個交換機(jī)上是很重要的信息.比如自動擴(kuò)容的時候,一定不希望同一個應(yīng)用的兩臺機(jī)器擴(kuò)到同一個交換機(jī)上,所以必須要知道這個信息.資料當(dāng)時做得很詳細(xì),比如它有幾段網(wǎng)卡,是雙向還是單向連接等.資料是非常重要的,因為美團(tuán)點(diǎn)評的規(guī)模很大,大量的機(jī)器部署在不同的城市,不可能每次真正操作的時候臨時再看.再如部署的打散問題是非常關(guān)鍵的,部署一個應(yīng)用100個虛擬機(jī)或者200個虛擬機(jī),要確保這200個虛擬機(jī)是打散的,不能在同一個交換機(jī)或者是同一個物理機(jī),或者是同一個機(jī)柜或者是同一個IDC,要按照一定的規(guī)則打散它,確保掛了之后會止損,比如四分之一、三分之一、二分之一,就全靠資料庫的完備,只要差一點(diǎn)點(diǎn)就都有問題.

第二,標(biāo)準(zhǔn)操作.剛才說到流程不會超過10個,這種運(yùn)維的標(biāo)準(zhǔn)操作也不會超過十幾個,把這些操作提煉為標(biāo)準(zhǔn)的操作,叫做原子化的操作.想象一下,自己做一個擴(kuò)容、做一個上線為例,申請一個機(jī)器,初始化它的環(huán)境,把它加入監(jiān)控,做一個配置,基本上這些操作是相對固定的,原子操作是可以落地下來的,它是一個標(biāo)準(zhǔn)化的動作.這個標(biāo)準(zhǔn)化的動作把它形成一個操作庫,會有人確保這個標(biāo)準(zhǔn)化動作本身的健壯性,比如重啟一臺機(jī)器這樣的操作,肯定要把操作本身做得特別健壯,確保所有的運(yùn)維,無論任何時間,做重啟動作的時候一定用的同一個標(biāo)準(zhǔn)的操作.

第三,場景是一個復(fù)雜的動作,我們叫做流程.比如今天要給業(yè)務(wù)部署300臺機(jī)器,或是今天上線一個新業(yè)務(wù)等等這是一個場景,一定能分解很多標(biāo)準(zhǔn)化的操作去完成的,場景就是流程,所以在開發(fā)的時候我們是流程系統(tǒng).

獨(dú)立于這三個之外就是監(jiān)控.這個監(jiān)控是多層面的,操作系統(tǒng)、監(jiān)控應(yīng)用,也要監(jiān)控發(fā)布變更,我要知道有多少變更,多少發(fā)布.總的來說,美團(tuán)點(diǎn)評自動化的體系就是基于這么一個大框架,當(dāng)然框架有4個,里面的產(chǎn)品有很多.只要框架框好了,產(chǎn)品多是沒有關(guān)系的,比如流程系統(tǒng)做兩套沒有關(guān)系,只要在同一個框架就好.

自動化工具講完了,講一下當(dāng)時的過程.當(dāng)我們按剛才說的思路做了很多自動化工具之后,很快陷入了一個迷茫,覺得運(yùn)維不過如此,人生好像很灰暗的感覺,而且這種工具很會帶來一種副作用,剛開始的時候大家還是挺開心的,有了工具之后迅速的工作效率提高了,需要半夜應(yīng)急的事情就少了,有些事情真的可以研發(fā)去處理了.有一次運(yùn)維團(tuán)隊年會,大家出發(fā)了以后突然接到電話,有一個事情研發(fā)那邊需要線上做一個操作,我就跟他說有流程,在流程上申請一下就好了,而且是自動的,果然他一申請把它的操作做好了.

換做以前,那一年在騰訊的時候,我們的大部門去越南團(tuán)建,萬一出故障了誰處理?于是大家都去了,我一個人沒有去,在家里守著電腦,等著處理故障.后來在美團(tuán)點(diǎn)評,研發(fā)自己的流程就可以把這件事搞定,說明自動化工具確實是有效的, 2014年底,這套東西還獲得了公司季度大獎.今年我們運(yùn)維團(tuán)隊獲得了美團(tuán)點(diǎn)評的年度大獎,還是非常不容易的.當(dāng)時我們做自動化做完后,覺得很開心,然而開心沒有幾天大家陷入迷茫了.工具做太多之后,很快陷入了一種失控,解決問題開始帶來問題了,帶來問題非常多,開發(fā)也很多,很亂,信息開始不一致,工具越來越危險,于是我們開始思考——

階段2：產(chǎn)品化

思考的結(jié)果,我們把它叫做產(chǎn)品化.一開始做工具,認(rèn)為它是一個工具,實現(xiàn)自動化的工具,沒有把它理解為產(chǎn)品,后來思路轉(zhuǎn)變了一下,把這工具轉(zhuǎn)變成產(chǎn)品,就跟開發(fā)一個美團(tuán)這樣的APP一樣的,它是一個產(chǎn)品,比如把這個CMDB或者流程定位成一個產(chǎn)品而不是一個工具,當(dāng)想到這一點(diǎn)之后就豁然開朗了,產(chǎn)品就不一樣了,做產(chǎn)品首先有產(chǎn)品經(jīng)理,也可以招女同學(xué)來做PM,諸如此類運(yùn)營都做起來了.

階段3：運(yùn)營化

做了產(chǎn)品之后,工具確實解決了剛剛說的失控問題,但又陷入一個迷茫,簡單來說就是運(yùn)維和業(yè)務(wù)的關(guān)系.運(yùn)維可以說在整個技術(shù)鏈條的最后端,食物鏈的最低端,如何才能體現(xiàn)運(yùn)維價值?這時我們又整理出一套新的思路出來,叫做質(zhì)量運(yùn)營,這里面的想法與SRE有一些類似.質(zhì)量運(yùn)營的想法很簡單,從監(jiān)控系統(tǒng)里面不斷的提煉數(shù)據(jù),把監(jiān)控的數(shù)據(jù)變成一個質(zhì)量指標(biāo),以這個指標(biāo)去驅(qū)動整個研發(fā)體系.因為很多的問題都是開發(fā)相關(guān)的,比如這個研發(fā)SQL語句寫得比較差,慢SQL比較多,就比較容易出故障,線上壓力一旦大一點(diǎn),數(shù)據(jù)庫都抗不住了.對這個問題以前的做法,現(xiàn)在線上掛了,查出來是一條慢SQL引起的,大家開始互相PK,研發(fā)說我沒有改過,這條SQL一直都是這樣的,運(yùn)維說就是你這條SQL引起的,這是常見的套路.但是,現(xiàn)在反過來,運(yùn)維平時就監(jiān)控每個應(yīng)用的慢SQL的個數(shù),如果比較多,我們認(rèn)為它是一個亞健康的狀態(tài),即使沒有出問題,也應(yīng)該降下來.

美團(tuán)點(diǎn)評做的不止是一個慢SQL這么簡單,我們把運(yùn)營上很多的質(zhì)量數(shù)據(jù),根據(jù)這個質(zhì)量數(shù)據(jù)去推動研發(fā)把質(zhì)量數(shù)據(jù)改善,運(yùn)維不斷的檢測這個數(shù)據(jù),直到這個數(shù)據(jù)確實降下去了.DOM是美團(tuán)點(diǎn)評的質(zhì)量平臺,類似于報表的平臺,在上面不斷放入很多的質(zhì)量數(shù)據(jù),拿這個數(shù)據(jù)去推動研發(fā),基本上能想到的都有,跳板機(jī)、質(zhì)量運(yùn)營、消息隊列,CAT、云平臺、Nginx等,計劃中的每一件事情都被定義了出來,有一套質(zhì)量指標(biāo),質(zhì)量指標(biāo)完全可以追溯和詳細(xì)化的,所謂的追溯就是可以看到過去以來所有的,詳細(xì)就是可以一直往下點(diǎn),比如這個部門這臺DB得分是75分,點(diǎn)進(jìn)去看到為什么得75分?可能有慢SQL5000個,再點(diǎn)進(jìn)去可以看到慢SQL5000個到底是哪5000個,這5000個到底是誰的?因為CMDB里面記錄了所有的應(yīng)用信息,研發(fā)人員對應(yīng)的信息,所以效率非常高.

還有一個DB的健康表,其中有慢查詢得分多少,磁盤使用率、鎖情況得分多少,延遲一致性、綠帽子庫,大表,容量系數(shù)等等,數(shù)據(jù)會不斷的迭代.因為公司人比較多,美團(tuán)點(diǎn)評的做法一般是橫向?qū)Ρ?任何一件事情總有團(tuán)隊做得比較好,有團(tuán)隊做得比較差,讓大家做橫向?qū)Ρ?可以看到哪個團(tuán)隊做得比較好,哪個團(tuán)隊做得比較差.通過這樣的方式刺激大家做改進(jìn),因為誰也不愿意自己團(tuán)隊做得比別的團(tuán)隊差,這是作為技術(shù)團(tuán)隊的修養(yǎng).

質(zhì)量運(yùn)營,一句話就是提煉指標(biāo)出來,不是等到它出事了,也不是響應(yīng)研發(fā)需求,而是運(yùn)維主動提煉這種指標(biāo)出來,并推動研發(fā)把可能造成影響的指標(biāo)降下去.去年2016年做的比較多的,一個是應(yīng)用的平均響應(yīng)時間,比如一個java 應(yīng)用, call一下的平均響應(yīng)時間,時間很長肯定容易出故障,負(fù)載一高就有超時等等各種故障,平時響應(yīng)的時間100毫秒看起來還好,但是負(fù)載一旦提高就會有問題了,所以要求不能超過50毫秒,這個要求一旦定出來,就出質(zhì)量報表,看公司所有的應(yīng)用,現(xiàn)在的平均值是多少、高了是多少、低了是多少,分成團(tuán)隊、部門,馬上出TOP10、TOP20的列表,推動做得比較差的同學(xué)改進(jìn).還比如APP的響應(yīng)時間,也是類似的.慢SQL見得比較多,我們的打壓還是比較有用的,這樣做下來,慢SQL引起的故障就少了很多.

自此之后,運(yùn)維團(tuán)隊和之前有了很大的變化,從完全輔助被動的狀態(tài),開始進(jìn)入所謂的主導(dǎo)的狀態(tài).過去都是研發(fā)需要運(yùn)維做什么,然后運(yùn)維做什么.現(xiàn)在都是運(yùn)維需要研發(fā)做什么,大家來做什么.團(tuán)隊的職責(zé)比以前有很大的變化,現(xiàn)在大概有三部分：第一是質(zhì)量運(yùn)營,第二是自動化的開發(fā),第三是DO分離的O.三年前美團(tuán)點(diǎn)評基本上就在做這三部分,D是開發(fā)O是運(yùn)維,我們是將DO分離的O逐漸減少.

總結(jié)與思考

簡單總結(jié)一下,美團(tuán)運(yùn)維的探索之路,從一開始做工具、到做產(chǎn)品,到做運(yùn)營, 2016年主要的精力是做運(yùn)營,團(tuán)隊也變成了四大部分.以前自動化工具注重的是一些功能,團(tuán)隊績效就是看今年做什么功能,但是這兩年不看功能了,看的是工具推廣得如何,運(yùn)營得怎么樣.現(xiàn)在已經(jīng)是數(shù)據(jù)驅(qū)動了,早期是事故驅(qū)動比較多,出問題了由大家來驅(qū)動,做各種改進(jìn)、各種輔助、各種case study.流程驅(qū)動,運(yùn)維設(shè)計各種各樣的規(guī)則,其實都沒有用,沒有哪一次規(guī)則起過作用.現(xiàn)在是數(shù)據(jù)驅(qū)動,看數(shù)據(jù)報表,而且不斷的迭代.

最后留給大家兩句話：云時代以后,大家離基礎(chǔ)設(shè)施越來越遠(yuǎn)之后,運(yùn)維怎么體現(xiàn)價值?第二,到底是往上走還是往下走?所謂的往上走就是往業(yè)務(wù)的角度走,往下走就是相對比較傳統(tǒng)的,比如說我對OS研究更深等等,到底應(yīng)該如何走?這是我們尚在思考的話題.謝謝大家.

轉(zhuǎn)載請注明本頁網(wǎng)址：
http://www.snjht.com/jiaocheng/4301.html