本篇文章內容來自第10期魅族開放日餓了麼高階運維經理徐巍的現場分享。 編輯：Cynthia
導讀：餓了麼成立於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%的時間做價值輸出，現在這個目標已經在落地的過程當中了。