工具化、產品化、運營化—「美團點評」運維的故事

本次分享嘉賓是美團點評運維中心高階總監鍾紅軍，他向我們詳細介紹了美團點評近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，要按照一定的規則打散它，確保掛了之後會止損，比如四分之一、三分之一、二分之一，就全靠資料庫的完備，只要差一點點就都有問題。

　　第二，標準操作。剛才說到流程不會超過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毫秒，這個要求一旦定出來，就出質量報表，看公司所有的應用，現在的平均值是多少、高了是多少、低了是多少，分成團隊、部門，馬上出TOP10、TOP20的列表，推動做得比較差的同學改進。還比如APP的響應時間，也是類似的。慢SQL見得比較多，我們的打壓還是比較有用的，這樣做下來，慢SQL引起的故障就少了很多。

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

　　總結與思考

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

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