活動實錄|工具化、產品化、運營化——「美團點評」運維團隊背後的故事

數人云「當西方的SRE趕上東方的互聯網」Meetup第一彈實錄來啦！

本次分享嘉賓是美團點評運維中心高級總監鍾紅軍，他向咱們詳細介紹了美團點評近3年來在大規模運維的理念和實踐方面的探索，尤爲是在運維自動化和數據運營方面的工做和效果——

鍾紅軍 / 美團點評運維中心高級總監

美團點評集團運維中心高級總監，此前曾工做於百度，騰訊，PPTV等互聯網公司，熟悉系統、網絡、運維、安全、數據、開發等多個領域。

今天我將美團點評這幾年在運維方面作的一些工做，以及本身的思考與你們分享一下。美團點評整個運維團隊100多人，base在北京和上海，美團和點評兩家公司在2015年合併，因此團隊也是兩地都有。運維中心有SRE團隊有數據庫的團隊，有自動化開發等。

階段1：工具化

我是2013年從百度加入點評的，以前在騰訊，當時想法很明確，由於騰訊、百度的運維體系相對比較成熟，包括運維工具、自動化的工具都是一整套，比較好用，對我來講最遺憾的是這些工具都不是本身作的，在騰訊我只是一個用戶，天天用那些運維工具殊不知道這些工具如何作出來的。因此在美團點評給本身的使命，就是要把美團點評的運維作到騰訊、百度的水平，把缺失的過程、成長的過程由本身作出來。美團點評運維團隊在2014年－2015年業務發展很是快，公司有幾萬人，研發團隊很大，那時候的運維作得仍是處於相對基礎的階段，遇到了問題，不分白天黑夜操做壓力很大，尤爲是出了事故要應急，過節須要各類的準備，值班也很混亂。

最初想法很簡單，但願把這事情作到極簡、規範和一致，保證操做能作到幾十年不變，無論誰來作都是一樣的操做。好比裝一臺機器或者是部署一個應用，但願它作一百次、一千次也是這樣。第二，把程序代替繁瑣的工具，第三，全部的操做均可記錄，以避免出了事故找不到是誰操做的。第四，把運維操做往前推，但願運維操做不要由運維來作了，由研發來作，由於需求自己來自於研發，不是來自於運維，因此需求來了也應該由研發去作。

以上是我去年總結的四句話，看似很普通的四句話，是美團點評作自動化過程當中的一個線條。第一句話，凡是不能變成工具的規範咱們都不看。作運維你們會想到出一點規範，好比發佈規範、部署規範、命名規範，機器取名得有一個規範，不規範操做容易出錯。在我看來，任何一個規範若是不能變成一個工具去約束的話，這規範沒有意義。寫一篇文檔或者一個要求，發給研發去看，只要它不能變成一個工具就沒有意義，由於這個規範出來，若是佈置工具的話，實現100次可能有一次有人不遵照。但其實他一次都不遵照，好過作100次只有一次不遵照，由於每次都不遵照，問題很好查，而作了100次有一次不遵照，就很難查。好比晚上服務掛了，一千臺的服務器，是其中一臺的問題其實挺難查的，若是這一千臺有共同的問題，就很好查。

規範自己沒有任何的意義，只有它變成一個工具纔有意義，由於強調的是一致性，但願它犯錯也是每次犯一樣的錯，不要每次犯不同的錯。因此，咱們的點評團隊沒有howto，沒有文檔，整個運維不多作文檔。固然如今也作了，100多人仍是要作一些不能造成工具的規範，不過仍是堅持這一點，規範應該想辦法作一個工具。好比咱們有一個靜默期的要求，春節長假前三天不容許發版本。那麼從2013年開始點評就執行這個規則的，由於它有工具支持，發佈系統要有開關，一到時間就能關掉，必須走運維的審批流通，這個流程是自動化的。但在2015年，新發布系統不支持這個開關，所以把這個規範停下來了，不執行這個規範，由於沒有工具支持，執行這個規範沒有意義，發個通知告訴你們要靜默期，首先要捱罵，其次你們該怎麼樣怎麼樣，罵完以後扔不執行這個規範，後來咱們就停下來，直到今年春節的時候，終於支持這個功能了再執行這個規範。

第二，不是增長power，而是減小power 。解釋一下，在2014年－2016年作運維自動化相關工具的時候，團隊的內部也是有不少的爭議的，其中一個很重要的爭議就是，有至關多的同窗認爲作自動化工具是給運維的人更大的power ，能作更多的事，你們無限暢想這個工具能夠怎麼樣，一按鍵全部的機器都重啓起來，其實很悲劇。個人理念是工具是爲了減小power ，不是爲了增長power ，爲何這麼說呢？若是是使之爲了更強大的話，其實手工操做是最強大的，給一個ssh命令的窗口，一個root，就是最強大的，什麼均可以作。工具本質是爲了限制，不是爲了加強，是幹不了什麼而不是能幹什麼。好比作自動化流程系統，在考覈自動化流程系統的時候，看它的流程多很少，流程越多說明作得越爛。做爲一個運維來講，我認爲不該該有超過10個流程。常見的運維操做不會超過10個，加機器、減機器、重啓機器，其餘的配一個域名等。若是管理到位一點，好比配一個web的IP，這些應該都不須要運維來作，因此超過10件事是有問題的。

第三，解決一個複雜的問題，不能夠引入另外一個複雜問題做爲代價。不少作運維的同窗，尤爲是作了一段時間後，學過不少各類各樣的概念，從最先的ITIL，到如今的SRE等等，容易犯一個錯誤，就是喜歡用複雜的方法解決複雜的問題，運維的體系也好、運維自動化也好，實際上是一個簡單的問題。回到最初來說，運維解決的問題是保障線上的穩定，只有這一件事情。運維自動化解決什麼問題？就是讓全部第三方因素或者是人爲的因素對線上穩定性形成的傷害越少越好，這個越少越好來自於第一變動越少越好，咱們在騰訊後期提出這種理念，沒有變動纔是最好。之前你們說管理變動，變動要管理起來，這個變動完了是永遠管理很差的，最好不要有變動。好比擴容，不少同窗提出節假日了容量不夠，要實現一鍵擴容，在個人理解裏面，我但願實現不須要擴容。

解決一個複雜問題，若是是用一個複雜的方法去解決，或者是引入另一個複雜問題的話，把這東西搞得更復雜了，這是不對的。好比作監控的時候，是作減法而不是作加法，由於搞太複雜了沒有意義，假定監控報警一天超過一千個了，是沒有區別的，由於這時候運維作的事情確定就是關手機，因此要作減法，不能引入複雜的問題，必定要找一個簡單的方法。

第三句話和第四句話是相似的，就是工具「極簡」是一種使命。我看過不少運維自動化的工具，包括騰訊、百度，還有國內不少互聯網公司，由於我當時在招人，面試過互聯網公司作工具的同窗，很不幸最後一我的沒有招，我發現他們作工具的思路和個人不太同樣，不少作自動化工具的同窗，每每覺得讓工具備價值，就把它作得複雜，看起來很華麗。總之，這不是個人思路，個人思路是極簡。

好比這個運維自動化的工具假設只有一個按鈕，那固然是最好的，可是作不到，咱們不是喬布斯。再如作一個擴容，有不少選項能夠選的，什麼機房、哪一個機房，尤爲是規模比較大的話什麼類型的機器、多少內存、多少CPU等等，不少同窗認爲選項越多，這個工具越好，越強大，在我看來選項越少越好，多了之後，第一容易出錯，萬一選錯了，接下來就涉及到研發和運維的PK了。還有一個是浪費了時間，擴容一臺機器應該是一件不花時間的事情，選項那麼多就要看半天的時間。從工具表現來講，也是工具越簡單越好。但形成一個沒有想到的後果，工具作得很難看，後來咱們也招前端的同窗來把它作好看一點，而不是作複雜。這幾年作運維自動化總結下來就這四句話。

美團點評的自動化工具

講一下美團點評的自動化工具。最先作的是這樣一個系統，抽離一下主要是四個東西：中間是一個CMDB，一套流程系統，一套操控平臺和一套監控系統。自動化主要是四件事——

第一，資料。全部的自動化基於很是準確、詳盡的資料，尤爲是虛擬化、雲計算比較流行的時代，一臺機器在哪一個交換機上是很重要的信息。好比自動擴容的時候，必定不但願同一個應用的兩臺機器擴到同一個交換機上，因此必需要知道這個信息。資料當時作得很詳細，好比它有幾段網卡，是雙向仍是單向鏈接等。資料是很是重要的，由於美團點評的規模很大，大量的機器部署在不一樣的城市，不可能每次真正操做的時候臨時再看。再如部署的打散問題是很是關鍵的，部署一個應用100個虛擬機或者200個虛擬機，要確保這200個虛擬機是打散的，不能在同一個交換機或者是同一個物理機，或者是同一個機櫃或者是同一個IDC，要按照必定的規則打散它，確保掛了以後會止損，好比四分之1、三分之1、二分之一，就全靠資料庫的完備，只要差一點點就都有問題。

第二，標準操做。剛纔說到流程不會超過10個，這種運維的標準操做也不會超過十幾個，把這些操做提煉爲標準的操做，叫作原子化的操做。想象一下，本身作一個擴容、作一個上線爲例，申請一個機器，初始化它的環境，把它加入監控，作一個配置，基本上這些操做是相對固定的，原子操做是能夠落地下來的，它是一個標準化的動做。這個標準化的動做把它造成一個操做庫，會有人確保這個標準化動做自己的健壯性，好比重啓一臺機器這樣的操做，確定要把操做自己作得特別健壯，確保全部的運維，不管任什麼時候間，作重啓動做的時候必定用的同一個標準的操做。

第三，場景是一個複雜的動做，咱們叫作流程。好比今天要給業務部署300臺機器，或是今天上線一個新業務等等這是一個場景，必定能分解不少標準化的操做去完成的，場景就是流程，因此在開發的時候咱們是流程系統。

獨立於這三個以外就是監控。這個監控是多層面的，操做系統、監控應用，也要監控發佈變動，我要知道有多少變動，多少發佈。總的來講，美團點評自動化的體系就是基於這麼一個大框架，固然框架有4個，裏面的產品有不少。只要框架框好了，產品可能是沒有關係的，好比流程系統作兩套沒有關係，只要在同一個框架就好。

自動化工具講完了，講一下當時的過程。當咱們按剛纔說的思路作了不少自動化工具以後，很快陷入了一個迷茫，以爲運維不過如此，人生好像很灰暗的感受，並且這種工具很會帶來一種反作用，剛開始的時候你們仍是挺開心的，有了工具以後迅速的工做效率提升了，須要半夜應急的事情就少了，有些事情真的能夠研發去處理了。有一次運維團隊年會，你們出發了之後忽然接到電話，有一個事情研發那邊須要線上作一個操做，我就跟他說有流程，在流程上申請一下就行了，並且是自動的，果真他一申請把它的操做作好了。

換作之前，那一年在騰訊的時候，咱們的大部門去越南團建，萬一出故障了誰處理？因而你們都去了，我一我的沒有去，在家裏守着電腦，等着處理故障。後來在美團點評，研發本身的流程就能夠把這件事搞定，說明自動化工具確實是有效的， 2014年末，這套東西還得到了公司季度大獎。今年咱們運維團隊得到了美團點評的年度大獎，仍是很是不容易的。當時咱們作自動化作完後，以爲很開心，然而開心沒有幾天你們陷入迷茫了。工具作太多以後，很快陷入了一種失控，解決問題開始帶來問題了，帶來問題很是多，開發也不少，很亂，信息開始不一致，工具愈來愈危險，因而咱們開始思考——

階段2：產品化

思考的結果，咱們把它叫作產品化。一開始作工具，認爲它是一個工具，實現自動化的工具，沒有把它理解爲產品，後來思路轉變了一下，把這工具轉變成產品，就跟開發一個美團這樣的APP同樣的，它是一個產品，好比把這個CMDB或者流程定位成一個產品而不是一個工具，當想到這一點以後就豁然開朗了，產品就不同了，作產品首先有產品經理，也能夠招女同窗來作PM，諸如此類運營都作起來了。

階段3：運營化

作了產品以後，工具確實解決了剛剛說的失控問題，但又陷入一個迷茫，簡單來講就是運維和業務的關係。運維能夠說在整個技術鏈條的最後端，食物鏈的最低端，如何才能體現運維價值？這時咱們又整理出一套新的思路出來，叫作質量運營，這裏面的想法與SRE有一些相似。質量運營的想法很簡單，從監控系統裏面不斷的提煉數據，把監控的數據變成一個質量指標，以這個指標去驅動整個研發體系。由於不少的問題都是開發相關的，好比這個研發SQL語句寫得比較差，慢SQL比較多，就比較容易出故障，線上壓力一旦大一點，數據庫都抗不住了。對這個問題之前的作法，如今線上掛了，查出來是一條慢SQL引發的，你們開始互相PK，研發說我沒有改過，這條SQL一直都是這樣的，運維說就是你這條SQL引發的，這是常見的套路。可是，如今反過來，運維平時就監控每一個應用的慢SQL的個數，若是比較多，咱們認爲它是一個亞健康的狀態，即便沒有出問題，也應該降下來。

美團點評作的不止是一個慢SQL這麼簡單，咱們把運營上不少的質量數據，根據這個質量數據去推進研發把質量數據改善，運維不斷的檢測這個數據，直到這個數據確實降下去了。DOM是美團點評的質量平臺，相似於報表的平臺，在上面不斷放入不少的質量數據，拿這個數據去推進研發，基本上能想到的都有，跳板機、質量運營、消息隊列，CAT、雲平臺、Nginx等，計劃中的每一件事情都被定義了出來，有一套質量指標，質量指標徹底能夠追溯和詳細化的，所謂的追溯就是能夠看到過去以來全部的，詳細就是能夠一直往下點，好比這個部門這臺DB得分是75分，點進去看到爲何得75分？可能有慢SQL5000個，再點進去能夠看到慢SQL5000個究竟是哪5000個，這5000個究竟是誰的？由於CMDB裏面記錄了全部的應用信息，研發人員對應的信息，因此效率很是高。

還有一個DB的健康表，其中有慢查詢得分多少，磁盤使用率、鎖狀況得分多少，延遲一致性、綠帽子庫，大表，容量係數等等，數據會不斷的迭代。由於公司人比較多，美團點評的作法通常是橫向對比。任何一件事情總有團隊作得比較好，有團隊作得比較差，讓你們作橫向對比，能夠看到哪一個團隊作得比較好，哪一個團隊作得比較差。經過這樣的方式刺激你們作改進，由於誰也不肯意本身團隊作得比別的團隊差，這是做爲技術團隊的修養。

質量運營，一句話就是提煉指標出來，不是等到它出事了，也不是響應研發需求，而是運維主動提煉這種指標出來，並推進研發把可能形成影響的指標降下去。去年2016年作的比較多的，一個是應用的平均響應時間，好比一個java 應用， call一下的平均響應時間，時間很長確定容易出故障，負載一高就有超時等等各類故障，平時響應的時間100毫秒看起來還好，可是負載一旦提升就會有問題了，因此要求不能超過50毫秒，這個要求一旦定出來，就出質量報表，看公司全部的應用，如今的平均值是多少、高了是多少、低了是多少，分紅團隊、部門，立刻出TOP十、TOP20的列表，推進作得比較差的同窗改進。還好比APP的響應時間，也是相似的。慢SQL見得比較多，咱們的打壓仍是比較有用的，這樣作下來，慢SQL引發的故障就少了不少。

自此以後，運維團隊和以前有了很大的變化，從徹底輔助被動的狀態，開始進入所謂的主導的狀態。過去都是研發須要運維作什麼，而後運維作什麼。如今都是運維須要研發作什麼，你們來作什麼。團隊的職責比之前有很大的變化，如今大概有三部分：第一是質量運營，第二是自動化的開發，第三是DO分離的O。三年前美團點評基本上就在作這三部分，D是開發O是運維，咱們是將DO分離的O逐漸減小。

總結與思考

簡單總結一下，美團運維的探索之路，從一開始作工具、到作產品，到作運營， 2016年主要的精力是作運營，團隊也變成了四大部分。之前自動化工具注重的是一些功能，團隊績效就是看今年作什麼功能，可是這兩年不看功能了，看的是工具推廣得如何，運營得怎麼樣。如今已是數據驅動了，早期是事故驅動比較多，出問題了由你們來驅動，作各類改進、各類輔助、各類case study。流程驅動，運維設計各類各樣的規則，其實都沒有用，沒有哪一次規則起過做用。如今是數據驅動，看數據報表，並且不斷的迭代。

最後留給你們兩句話：雲時代之後，你們離基礎設施愈來愈遠以後，運維怎麼體現價值？第二，究竟是往上走仍是往下走？所謂的往上走就是往業務的角度走，往下走就是相對比較傳統的，好比說我對OS研究更深等等，到底應該如何走？這是咱們尚在思考的話題。謝謝你們。