摘要:今天我將美團點評這幾年在運維方面做的一些工作,以及自己的思考與大家分享一下。所以在美團點評給自己的使命,就是要把美團點評的運維做到騰訊百度的水平,把缺失的過程成長的過程由自己做出來。美團點評的自動化工具講一下美團點評的自動化工具。
數人云“當西方的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,要按照一定的規則打散它,確保掛了之后會止損,比如四分之一、三分之一、二分之一,就全靠資料庫的完備,只要差一點點就都有問題。
第二,標準操作。剛才說到流程不會超過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研究更深等等,到底應該如何走?這是我們尚在思考的話題。謝謝大家。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/25187.html
摘要:今天我將美團點評這幾年在運維方面做的一些工作,以及自己的思考與大家分享一下。所以在美團點評給自己的使命,就是要把美團點評的運維做到騰訊百度的水平,把缺失的過程成長的過程由自己做出來。美團點評的自動化工具講一下美團點評的自動化工具。 數人云當西方的SRE遇上東方的互聯網Meetup第一彈實錄來啦! 本次分享嘉賓是美團點評運維中心高級總監鐘紅軍,他向我們詳細介紹了美團點評近3年來在大規模運...
摘要:正在走遠,新年之初,小數精選過去一年閱讀量居高的技術干貨,從容器到微服務云原生,匯集成篇精華集錦,充分反映了這一年的技術熱點走向。此文值得收藏,方便隨時搜索和查看。,小數將繼續陪伴大家,為朋友們奉獻更有逼格的技術內容。 2017正在走遠,新年之初,小數精選過去一年閱讀量居高的技術干貨,從容器、K8S 到微服務、云原生、Service Mesh,匯集成52篇精華集錦,充分反映了這一年的技...
摘要:本文為喜茶喜茶互聯網事業部總經理陳霈霖老師分享的數字化三支柱傳統企業數字化轉型的眾妙之門案例實錄。在我講述數字化三支柱之前,我們不妨先來看看喜茶誕生的故事。 showImg(https://segmentfault.com/img/bVblRz3?w=640&h=427); 喜茶憑借「喜茶GO」小程序躋身第七屆全球軟件案例研究峰會(簡稱:TOP100summit),為100個技術案例中...
摘要:本文將介紹美團點評整個數據庫平臺的演進歷史,以及我們當前的情況和面臨的一些挑戰,最后分享一下我們從自動化到智能化運維過渡時,所進行的思考探索與實踐。 從自動化到智能化運維過渡時,美團DBA團隊進行了哪些思考、探索與實踐?本文根據趙應鋼在第九屆中國數據庫技術大會上的演講內容整理而成,部分內容有更新。 背景 近些年,傳統的數據庫運維方式已經越來越難于滿足業務方對數據庫的穩定性、可用性、靈活...
閱讀 2029·2021-11-08 13:14
閱讀 2939·2021-10-18 13:34
閱讀 2027·2021-09-23 11:21
閱讀 3589·2019-08-30 15:54
閱讀 1758·2019-08-30 15:54
閱讀 2929·2019-08-29 15:33
閱讀 2578·2019-08-29 14:01
閱讀 1945·2019-08-29 13:52