本篇文章內容來自第10期魅族開放日餓了么高級運維經理徐巍的現場分享。

編輯：Cynthia

大家好，首先，先簡單介紹下自己，我是徐巍，目前在餓了么負責基礎設施的運維及開發工作，早些年就職于PPTV、攜程、游族等公司，也算是一個運維的老兵了。

餓了么成立于2008年，2014年底開始迎來業務的大規模爆發性增長，2015-2016年餓了么進入高速發展期，業務和服務器的增長都在數十倍的規模，這種大規模的增長必然帶來很多挑戰，本文將通過餓了么運維基礎設施的進化史和大家分享不同時期應對挑戰的措施和思路。

一、1.0時代

2014年至2015年被稱為餓了么的1.0時代，業務迎來高速發展，這時更多考慮的是業務需要什么就趕緊上什么，而不是長遠的架構等。每個人或團隊負責自己的一部分工作，全力配合業務的需求。可想而知，這個過程中會有很多的由于考慮不周產生的技術債，也就是所謂的“痛”點。

網絡的痛

網絡的痛主要表現在：

● 沒有標準化：IP亂掛。外網IP直接掛到服務器上；有的服務器可能有2個甚至3個IP；有的有bonding，有的沒有；

● 攻擊多：業務高速增長的情況下還會有遭遇大量的攻擊，一遇到攻擊就可能宕機；

● 帶寬收斂比較低。因為流量太大，如緩存高帶寬的情況，交換機上聯端口或者服務器千兆網卡很快被打滿；

● 監控缺失：出了問題技術團隊不知道，騎手或用戶說不能下單了之后各種投訴，由客服反饋過來；

● 單點：從業務到整體架構到每個業務甚至機器都存在很多單點；

● 還有鏈路質量不穩定的問題。

服務器的痛

資源的痛主要表現在：

● 服務器交付不及時：去年到今年我們最高周交付量是3700+臺邏輯服務器。平均下來每個月都是幾千臺的交付、回收，對效率要求非常高；

● 資產管理缺失：無標準，維護成本高。這時處于野蠻增長時期，需要服務器就趕緊買，不會考慮有多少服務器。也不知道服務器都是什么配置的，沒有標準化，可能這一臺有SSD，另一臺就沒有。維護起來成本非常高。

● 交付質量無保證：全部都是人肉裝機，2015年底的情況是買進一批機器就臨時組成一個裝機小分隊，一起裝機。因為都是人肉操作，慢且交付質量無法保證，排查更困難。

基礎服務缺失

基礎服務缺失主要體現在：

● 監控方面最早是用zabbix，配置不一導致有些硬盤沒有監控、IOPS是多少都是缺失的，業務層監控也沒有覆蓋全；

● 負載均衡，每個業務自己搞一兩臺服務器，掛個Nginx做反向代理，都是這么隨便做的；

● 集中式文件存儲。每一臺服務器會把很多文件存在本地，這為整個基礎設施管理帶來很多問題。舉個例子，有的東西，比如理論上互聯網很多的SOA服務都是無狀態的，本地除了代碼之外，不應該有其他的東西，但發生故障的時候，業務因為監控不成熟無法確認問題，需要看日志，這就復雜了，有人說要保留一周，有人說要保留一個月，有時日志一天就是幾十個G怎么辦？那就加一塊硬盤，怎么加？誰來采購和管理？后面的標準化怎么做？集中式日志、集中式文件存儲都是為了解決標準化的問題。

基礎的服務也非常混亂。

二、我們做了什么

面對這么多的問題我們怎么辦？其實運維做三件事情就夠了。

第一是標準化，從硬件到網絡到操作系統到使用的技術棧、軟件的安裝方式、日志的存放路徑、名稱、代碼部署方式、監控從上到下，要建立一套體系化的標準。有了標準就可以用代碼自動化，有了自動化和標準化之后就可以實現良性循環。

第二是流程化，流程化是把很多的需求通過步驟進行規范化和標準化。

第三是平臺，構建一個平臺實現標準化和自動化。

我理解的是運維需要做兩個生命周期的管理。

第一是資源的生命周期管理，包括資源的采購、上架、部署、代碼、故障處理、服務器回收、報廢等。

第二是應用的生命周期管理，包括應用開發、測試、上線、變更，應用下線、回收等。

2.1 標準化

關于標準化有一個概念，我經常和大家強調，就是要讓我們的用戶做選擇提，而不是問答題。

舉個例子，用戶經常會說我要一臺24核32G 600G硬盤的機器，這時你應該告訴用戶：我現在有A、B、C、D四種機型，分別是計算型、存儲型、內存型、高I/O型，你要哪種？這很重要，很多用戶只是習慣了兩臺機器：一臺配200G硬盤，一臺配250G硬盤。用戶的需求千奇百怪，如果沒有標準化很難做到。我們的服務器型號是統一的，提供各種型號，你需要和用戶談，收集用戶需求，盡量辨別出來用戶的真實需求。

機型采購的時候要做定制化，比如要不要把省電模式關掉。各個廠商還有一些坑，包括直通卡的盤符漂移等問題，如何做自動化，機器來了如何自動上線。

服務器出廠和上架也要做定制化。我們把資源標成一個個模塊，最小的模塊是3個機柜，每個機柜放多少臺服務器是固定的。生產的時候，比如說我要采購一千臺服務器，我告訴廠商我已經規劃好了，這一千臺服務器放在哪一個機房里，哪一個機柜，哪一個U位，廠商會做定制化，機器到貨上架之后，廠家人或服務商把電一接，操作系統自動化安裝，甚至是網絡，每一層都是標準化的。

2.2 流程+自動化

上圖展示的是餓了么的工作流引擎。

可以理解為資源生命周期中有很多流程，比如服務器的申請，包括物理機申請、虛擬機申請、云服務申請等；比如大量狀態，包括回收等。流程的背后是自動化，規范用戶輸入，讓用戶做選擇題，要什么樣的機型、什么樣的配置、多少數量，表單一填好，后臺就自動化地執行了。

2.3 自動化+平臺

● 物理服務器自動化裝機及初始化。比如我有幾千臺服務器，能不能一天裝好？360曾經一天最高裝了5000臺服務器，我們的最高紀錄是一天裝機2500臺物理服務器。

● 網絡設備上線自動化。

● 資源管理平臺。對所有的資源能做統一化管理，類似資源交付流程的管理后臺

● 分布式文件系統，主要用于數據庫備份及圖片處理

● 日志集中平臺，所有的日志集中到elk上，不要上服務器看日志了

2.4 私有云平臺(Zstack)

餓了么早期實行野蠻生長的方式，虛擬機就是自己創建。創建完了會有一個問題：怎么知道一個機器可以再創建呢？比如說我一個機器可以創建6臺虛擬機，已經創建5臺了，怎么知道還有一臺創建在哪里？需要把一個業務布置到10臺物理機，甚至是跨機柜的，避免單點物理機或單個機柜出現故障，影響全局應用，這就涉及到了虛擬機的資源調度，我們選用了ZStack。

為什么選用ZStack呢？

私有云比較火的三個開源技術選型分別是：OpenStack、CloudStack和ZStack。

本著越簡單越好的原則，我們排除了OpenStack，它太重了，沒有人也沒有時間去Hold這么大的系統。而且從行業內得到一些反饋，總體來說不是很好。

CloudStack的開發者也是ZStack的開發者，當時CloudStack社區已經沒有人維護了，并且它不支持centos7。

所以我們選用了ZStack，那個時候ZStack也有不少bug，但還是比較簡單的，我們可以做好。

ZStack的特點：簡單、無狀態、接口化

比較簡單，安裝一下，就可以跑起來了。當然想要用好，后面還是有點難度的。它是一個中心結構，所有的都是基于消息做的，我們的ZStack平臺看不到什么高大上的頁面，后面都是自定義的接口，前端的流程自動調后端的接口，通過一些消息來進行同步。ZStack目前已經管理了超過6000臺虛擬機。

三、2.0時代

在1.0時代我們做了一些標準化、自動化的工作，讓我們的東西順暢地跑起來。從2016年開始，我們進入了2.0時代，這個階段也存在一些痛點：SLA是什么？有數據嗎？你說效率很高了，如何證明？一天交付1000就是高嗎？數據怎么衡量？在IT圈里，除了上帝，所有的東西都要用數據說話，一切要可量化，可衡量。

四、我們做了什么

這個時期我們解決痛點的措施從兩方面著手：精細化運維和數據化運營。運維和運營是不一樣的。

4.1 精細化運維

精細化運維包括以下方面。

● 網絡架構的持續升級

● 服務器性能基線制定

● 服務器交付質量校驗(不合格不交付)

● 硬件故障報修自動化

● 網絡流量分析

● 服務器重啟自動化

● Bug fix:省電模式、bonding。。。

網絡架構持續升級

早期我們有一個數據中心，使用的核心交換機是華為的5700SE，這意味著什么？在一次流量突發中，這個設備引發了我們P0級的事故。所有我們重新定義了網絡標準，并持續做了大量的網絡升級，包括核心、負載均衡、匯聚到核心的帶寬，以及網絡架構優化。

還有IDC間鏈路，最早我們一些IDC間鏈路是打的VPN，現在同城的用裸纖，跨城的都是用傳輸。這里也有依稀持續的投入。

網絡優化

如圖所示，北京和上海的IDC，從辦公室訪問IDC我們都拉了裸纖和專線，全部做到足夠的強壯。還包括到第三方支付的，比如支付寶、微信支付等等。

服務器的性能基線制定，交付質量校驗

交付的服務器是否足夠好，要用數據說話。我們所有的服務器都有一個基線，比如一種計算型的機型，計算能力、I/O能力是多少、網卡小包的PPS可以達到多少等都是可以測試的。在交付的時候會進行性能測試，達到基線才可以交付，否則就不能交付。

網絡流量分析

我們當初遇到過匯聚到接入之間某根光纖帶寬跑滿的情況，因為早期帶寬收斂比不夠，4個10G在上面，由于網絡流量的算法原因，導致4個10G端口的其中一個被跑滿了。我們要知道關鍵節點的流量是哪一個業務在跑、跑的怎么樣，有問題要告警出來。

硬件故障保修自動化

目前我們的服務器數量很多，每周可能存在數十臺的故障，怎么第一時間知道故障，并且在不影響業務的情況下快速修復？

還有一些其他的工作，如服務器的自動化重啟，做運維都很辛苦，如果半夜有一個故障或者服務器壞了，需要重啟，如果你還得通過遠程管理卡輸入密碼登錄進去重啟，就太low了，要實現自動化重啟。

服務器自動化報修總體來說是幾個邏輯。

● 故障發現

● 故障通知：用戶、IDC、供應商

● 故障處理

● 故障恢復校驗

● 故障分析

第一是故障發現，如何發現資源故障？監控，帶內、帶外、日志多方位監控。所有監控的報警到一個地方來做初步的收集，最后就會到這個系統。

這是9月19日的圖，可以看到有非常多的故障，發現這些故障之后要通知，通知也是很復雜的，是短信、電話還是內部的工具？我們要多渠道地進行通知。有的用戶比較牛，他說你不用給我發郵件，我這邊有一個接口，可以做自動化的發送，比如我們的服務器故障了，自動給他發一個消息，收到這個消息之后，業務就開始把這個機器關掉，甚至把數據操作等一系列操作做完，做完之后返還給報修系統一個消息：這個服務器你可以去維修了，收到這個消息之后，通知IDC、供應商：哪一個機房、哪一個機柜、哪一個U位、序列號多少的服務器發生了什么問題，請于什么時間段上門維修，同時通過各種方式告訴IDC：誰身份證號多少，什么時間會帶著什么設備上門做哪一個地方的維修。

我們數以萬計的服務器只有兩個人來進行運維。供應商維修、故障處理是人肉的，處理之后登陸外部系統，給我們發一個消息，告訴我們這個服務器修好了，我們的程序會自動檢查故障有沒有恢復，如果恢復了，就通知用戶說資源什么時候修好了，用戶接到消息，會把服務器再拉回來。同時所有的故障信息都會進入我的數據庫，自動進行分析，看到哪一個品牌的服務器不好、哪一個機型或者是哪一個配件壞的比較多，在做供應商和機型選擇的時候就可以有一個參考。

精細化運維還有各種Bug Fix等很多細節，細節是魔鬼。當初被省電模式坑得很慘，包括網卡的問題，從硬件到服務，代碼的Bug就更多了。

運維管理平臺

我們有很多機柜、機房，這些數據都通過自動化的系統進行采集和展示。

運維重點需要考慮三件事情：質量、效率和成本。上圖中可以看到這是一個模塊，這個模塊當中有很多的機柜，這些機柜用電量很大，這就體現出了成本，我們大量的機柜是黃色，黃色是告警。一個機柜的電量是4000W、5000W，我們會盡量把資源充分利用起來，成本相對最優，所以我們的機柜都是一些比較高電的，比如說47U的機柜我們會放很多的設備。

4.2 數據化運營

IT所有的東西都要用數據說話。

資產情況

資產情況包括：我們有多少服務器，分布在哪些機房，有多少機柜，服務器是什么機型，品牌和型號，哪些是占用的，哪些是未用的。

網絡流量分析

網絡流量分析包括：網絡流量來自于哪些人，比如說這里有一個異常突起，我就知道這是在在跨城帶寬傳輸造成的。跨城帶寬大家都知道，是非常貴的10G帶寬一下子跑滿了，擴容要三個月，這個時候整體業務會受到嚴重影響。我們要第一時間知道誰在用這些流量。

服務器去哪兒了

我們買了那么多公司的東西，得知道這些機器誰在用？圖中的這條線是資源利用率，這是大數據部門，圖中可以看到大數據的資源利用率是很高的。而其他的部門資源利用率不高。通過這個數據我給你發報表，告訴你花了多少錢，用了多少服務器，什么類型的服務器，分布情況和利用率是多少。這是運營的思想，而不是運維的思想。

資源交付SLA

我們的工作量如何衡量？我們交付了很多服務器，什么時間交付的、交付的是什么型號、交付的效率如何？一定要可衡量。舉個例子，做年終KPI考核的時候，你說我們部門做了很多工作，這個工程、那個項目，這些都是廢話。只要告訴我，今年做了幾個項目，這些項目分別部署了多少資源、效率是什么，以前平均交付時間是2小時，現在是20分鐘，未來是5分鐘。

成本核算

今年我們花了很多錢，這么多錢花在哪里？誰花的？買了什么？給誰用了？用得怎么樣？從各個維度來看，這些成本的構成等等，甚至我們的成本和友商的成本對比，都通過這些東西可以看出來。

供應商的質量評價

比如每個配件什么時候故障了，故障率是多少？自動給廠商打分，報表會自動交到采購，作為采購的一個技術評分，這個過程沒有人的介入。包括質量方面，某一個廠商這一段時間的質量下降了，可以要對他進行售后管理。

五、總結

這次分析主要是資源生命周期管理，本文大部分內容偏向于底層資源，但思想可以落到所有的模塊，比如日志、不同運維系統、監控等。

最后談一些感想。

簡單及可用。我從入行到現在從事互聯網運維差不多十年時間，早期服務器的故障需要很懂的人一臺一臺地去看，現在的做法是一臺服務器出問題了，拉掉，另外一臺服務器快速頂上去，成本可控、質量可控、效率第一，這種情況下一定要簡單及可用。

這句話最早是百度傳出來的，這也是我做運維的一個準則，一切的東西都要簡單。有一些開源的解決方案具備很多很牛的功能，但你要深刻思考你真的需要嗎？它真的對你有幫助嗎？真正核心的價值是什么？所有軟件程序必須要做到高類聚低耦合，避免很強的依賴。

標準化能標準化的，自動化可以自動化的。標準化一定是未來的趨勢，現在隨著阿里云、騰訊云的發展，小的公司很多東西都會遷移到云上，未來混合云的架構，運維可以做什么？怎么做到快速的擴容和彈性計算，彈性計算包括容量規劃、壓測等，這當中有很多的點，這些點的基石就是標準化、自動化。

盡量不要重復造輪子，自己造輪子。搞開發的人很喜歡造輪子，總覺得我到一家公司，不寫點東西，顯得我很Low或者沒有績效。“用好”軟件比用“好”軟件更重要。工具沒有好壞之分，就看你能不能用好，在對的時間做對的事情，不要有對工具有偏見，它只是一塊磚，我們要做的是把這些磚做好合并，用好這些磚。

先有，后好(80分萬歲)。萬事起頭難，第一步一定要先有。不要說我想一個東西想得很宏大，各個方面設計特別牛，要考慮的是這個東西能落地嗎？落地是最重要的。那有人會問做了很多東西，可是很爛怎么辦？先收口，收口之后慢慢優化。

互聯網快速發展，互聯網應用一定要快速迭代，我們公司每天有數百次發布，敏捷式開發快速更新非常重要。這個過程一定是螺旋式上升的，甚至有前進兩步后退一步的情況。不要說誰家的架構就是最牛的，只有適合你才是最好的，而且不同階段適合你的東西是不一樣的，需要不斷重構和迭代。

現有用戶和新用戶同等重要。這是亞馬遜提出來的。亞馬遜有一件很有名的事情：當年有一個用戶要將服務遷移到亞馬遜，預計上千萬美金。亞馬遜評價說，這個服務遷過來，要做什么樣的改造，這個改造會對現有業務的穩定性造成什么影響。經過層層上報，最后的結論是這個用戶我不要了。因為接受后現有用戶得不到保障。

這一點非常重要。2016年9月份，我們的日志系統上線，剛剛上線的時候，峰值8萬/秒的請求量，到10月份達到80萬/秒，這時還不斷有用戶過來說要接入。我當時感覺硬件、架構等方面都快Hold不住了，我跟大家說了這件事情，給自己爭取了1個月的緩沖期，做了大量的技術改造，現在峰值每天超過260萬條日志，也可以進行實時的收集、傳輸、存儲、分析。這當中一定要找一個平衡，在服務好現有用戶的同時，逐步接入新用戶，當然也不能很生硬的說“no way”，這樣你的品牌就沒有了。

擁抱變化，不要有玻璃心。我工作了很多年，也去過好幾家公司，可以看到每家公司在不同階段都有不同的變化。比如我的團隊中基本上都是開發沒有運維了，標準化做好了，底層就是一個硬件軟件，一個操作系統專家，其他的都是一些程序員。可是很多人本身是做運維的怎么辦？要開始學習代碼，要有變化和成長。今年我給團隊的目標是2017年要把我們這個團隊做沒了。意思是要做到無人值守，或者只花10%、20%的時間和精力做后臺的bug fix，其他80%的時間做價值輸出，現在這個目標已經在落地的過程當中了。

Q & A

Q：你們會對業務部門的服務器需求進行指導嗎？

A：我們的服務器分為好幾種，包括計算型、存儲型、內存型、高I/O型（數據庫專用）。存儲型主要是大數據在用，計算型是做虛擬化和計算的，比如SOA無狀態服務，在申請機型的時候，每個業務的機型基本上都是一模一樣的。新業務起來的時候會有架構評審，評審架構有沒有認證、有沒有數據打點、有沒有日志規范、有沒有日志規范、整個架構設計是否合理、資源需求是否合理。

Q：日志統一平臺的是自己做的嗎？

A：我們有集中的管理中心，寫了一套腳本自動安裝Flume，也在Flume上也做了二次開發，比如 Java有的是跨行日志，我們要做合并行的處理；比如有的業務異常日志2M，我扛不住的，這種異常日志我會做判斷，丟棄；比如有的可能目錄里有多個日志，怎么處理？

Q：用戶查看日志，對各個業務索引是怎么實現的？比如說我是業務方，我只看自己業務的日志？

A：目前這個沒有做到，大家知道kibana的權限管理是很弱的，目前我們還沒有做這一塊。這里我要提一個點，我們有一個系統，業務代碼里面會埋一個SDK，把堆棧的調用鏈的關系都打到這個系統，最終會展示出列表，這個系統會和我們的日志系統對接，用戶看到調用鏈，一點就可以把類似信息拖過去了。現在kibana這個頁面用的人不多，相當于只是后端的服務了。

Q：您剛剛提到會有一個性能測試跑壓測，你們的壓測怎么做呢？

A：用系統自帶的一些I/O壓測。每個機型的基本指標，比如說CPU能力、IOPS、PPS能力。

Q：剛剛說到日志，當我的應用達到十幾萬請求的時候，如果都往Flume上寫，就把服務器的CPU占滿了。我目前的做法是先把日志放在本地，再通過網上推上去。

A：Flume是很好的工具，但性能不是很強。我們壓測它的處理能力最高是2萬條/秒，實際上它是跑不到這么高的，包括它在跑的過程當中會有一些假死，甚至有的時候sink會滿掉，這當中要做大量的監控，你應該把Flume做成分布式的。比如說我每個業務服務器上都有一個Flume，通過TCP、UDP、日志直接讀文件的方式。這個要看業務的容忍度，我們有一些業務堆日志說一條都不能丟，我們測試下來UDP有30%-50%的丟棄，如果說對日志完整性要求很高，不建議使用。

Flume1.7版本可以支持基于偏移量的日志，而且是支持多文件的。越簡單越好，越標準化越好，因為打到本地你的磁盤空間也可能有問題，甚至是I/O也可能有問題。

Q：你們開發和運維團隊是如何運作的？是放在一起嗎？

A：關于這個問題，我和阿里也聊過，他們做了3次探索。第一個是開發開發，開發好了給運維用。很多公司都會這么做，這么做有一個壞處：運維說你開發的是什么東西，我不愿意用；開發就說運維一天到晚就知道提需求。雙方關系很不好，最后做出來的東西沒有人用，那就沒有意義了。

阿里做了第二個嘗試。既然這樣，那所有的開發自己開發自己運維，運維做其他的事情，公司這么大，肯定有事情做。這樣的壞處是：開發對運維理解不深刻，運維系統和線上業務開發是很不一樣的，運維系統對可靠性要求相對差，但是對質量和效率的要求很高。開發不懂運維，容易出現各種故障。

因此阿里做了第三件嘗試，把開發和運維合在一起。

餓了么有部分專職的開發和運維團隊，也有開發和運維合在一起的團隊。

11月9-12日 北京國家會議中心 第六屆TOP100全球軟件案例研究峰會

餓了么資深項目經理陳士朋將分享《自我做空-新思維模式下敏捷管理者的供給側改革》

餓了么 中間件團隊首席架構師、異地多活項目總架構師李雙濤將分享《餓了么整體服務異地多活改造》

TOP100全球軟件案例研究峰會已舉辦六屆，甄選全球軟件研發優秀案例，每年參會者達2000人次。包含產品、團隊、架構、運維、大數據、人工智能等多個技術專場，現場學習谷歌、微軟、騰訊、阿里、百度等一線互聯網企業的最新研發實踐。

TOP100大會將于11月9日-12日在北京國家會議中心舉辦，在現場通過對案例的復盤總結，分享成功者背后的經驗和方法。大會開幕式單天體驗票免費入口。