【51CTO.com原創(chuàng)稿件】餓了么平臺不僅做外賣，還有蜂鳥、早餐和未來餐廳，以及很多其他的一些平臺，正處在快速擴(kuò)張階段。整個外賣的產(chǎn)品鏈條長，從用戶下單到最后配送到達(dá)，時間大概是30分鐘左右，對時效性的要求非常強(qiáng)。

從技術(shù)的角度來看，餓了么遇到的最大挑戰(zhàn)是事故。本文將圍繞事故展開，分成兩部分內(nèi)容：技術(shù)運(yùn)營經(jīng)歷與心得。第一部分經(jīng)歷又分為三個階段：精細(xì)化分工、保穩(wěn)定（容量和變更）和增效。第二部分心得，是作者對運(yùn)維服務(wù)的理解。

[[193657]]

技術(shù)運(yùn)營的職責(zé)是盡最大的努力協(xié)同更多的人來達(dá)成保穩(wěn)定的目標(biāo)，可以劃分為兩個階段：運(yùn)維保障、運(yùn)維服務(wù)?，F(xiàn)在，餓了么處在運(yùn)維服務(wù)的階段，技術(shù)運(yùn)營團(tuán)隊作為乙方，把開發(fā)出來的產(chǎn)品，開發(fā)測試后的服務(wù)，做維護(hù)，保障穩(wěn)定、調(diào)優(yōu)性能、提高資源的利用率。 

在業(yè)務(wù)快速擴(kuò)張階段，技術(shù)團(tuán)隊需要做哪些事情呢？

首先，第一階段，精細(xì)化分工。

通過精細(xì)化分工促進(jìn)并行提速，讓專業(yè)的人利用專業(yè)的知識、最有效的工作方式提高工作效率及代碼吞吐量，建立溝通渠道加速決策、信息流通保穩(wěn)定。

精細(xì)化分工分為三部分內(nèi)容：

第一部分是做數(shù)據(jù)庫拆分和代碼解耦。技術(shù)工作集中在數(shù)據(jù)庫的拆分，先縱向拆分，不得已才做橫向拆分，為了更快地服務(wù)業(yè)務(wù)的擴(kuò)張，又夾雜了一些對代碼解耦的工作。

所謂代碼解耦，是把原來的代碼系統(tǒng)想象成一個泥球，把它逐漸拆分成很多塊?，F(xiàn)在是有十多個業(yè)務(wù)模塊，每一模塊里面都有專門的團(tuán)隊來維護(hù)，內(nèi)部又會劃分域。

餓了么是數(shù)據(jù)庫、代碼拆分并行在做。然后，啟動了強(qiáng)制接入新發(fā)布系統(tǒng)和單實例、單運(yùn)用，也就是物理拆分。 

在整個的代碼解耦和精細(xì)化分工的過程當(dāng)中，他們碰到了很多問題，其中比較典型的兩類事故是：

• 事故1：超時，后端服務(wù)慢，引發(fā)連鎖反應(yīng)，導(dǎo)致前端服務(wù)雪崩。

  用戶的請求耗時依賴于 RPC 調(diào)用路徑上服務(wù)的響應(yīng)時間。當(dāng)其中某個節(jié)點(diǎn)變慢，整個集群都不可用，一般救急措施是要按照調(diào)用鏈從前往后按順序停服務(wù)，然后在從后往前啟動服務(wù)。

  當(dāng)這類問題發(fā)生的時候，如果沒有熔斷機(jī)制，前端的服務(wù)因依賴關(guān)系造成雪崩，而且服務(wù)不能自己恢復(fù)。加了熔斷機(jī)制之后，當(dāng)后端問題節(jié)點(diǎn)重啟或是網(wǎng)絡(luò)抖動恢復(fù)后，前端服務(wù)也會自己恢復(fù)。

• 事故2：連續(xù)三天商戶需要不斷重試才能接單，這與Redis治理有關(guān)。

  當(dāng)交換機(jī)發(fā)生 Bug 導(dǎo)致網(wǎng)絡(luò)抖動，受影響最大的就是 Redis，在網(wǎng)絡(luò)抖動期間積壓的請求會建立太多 Redis 連接，連接過多會導(dǎo)致 Redis 響應(yīng)延遲從 1ms 飆升到 300ms。由于 Redis 請求慢導(dǎo)致服務(wù)的處理速度被拖慢，而外部請求仍在積壓，最后引起雪崩。

  剛開始出現(xiàn)故障的時候，因 Zabbix 的監(jiān)控周期長，運(yùn)維工程師監(jiān)控不到。后來，他們用了三天的時間進(jìn)行壓測復(fù)現(xiàn)，才排查出來故障點(diǎn)。事后，運(yùn)維工程師打造了一種新的基礎(chǔ)設(shè)施監(jiān)控工具，實現(xiàn)方式是每 10 秒鐘把 /proc 目錄下的所有指標(biāo)收集起來，基本能做到 3 分鐘內(nèi)定位問題。

  還有丟包的重傳也會嚴(yán)重影響 Redis 的性能，因為一個 HTTP 引擎到后端有可能產(chǎn)生幾十個甚至上百次的 Redis 請求，其中有一次被命中重試，對服務(wù)的影響都是致命的。

精細(xì)化分工的第二部分是組建水平團(tuán)隊，例如大數(shù)據(jù)是水平團(tuán)隊，業(yè)務(wù)線是豎向團(tuán)隊，劃分之后，從整個業(yè)務(wù)的發(fā)展走勢圖上升曲線非常陡，可以推斷技術(shù)并沒有防礙業(yè)務(wù)的快速發(fā)展，也就是技術(shù)的吞吐量、新產(chǎn)品研發(fā)效率是健康的。

期間，運(yùn)維工程師還做了幾件事，比如把監(jiān)控分為 Metric、Log、Trace、基礎(chǔ)設(shè)施四個部分。組建 Noc 團(tuán)隊，負(fù)責(zé)應(yīng)急響應(yīng)，當(dāng)發(fā)現(xiàn)有問題的時候，及時把信息通過 Oncall 通報給各成員。還有梳理各類掃除，接入發(fā)布、 SOA，降級熔斷開發(fā)等。

大掃除

大掃除的概念是什么呢？就是工程師對歷史的事故進(jìn)行分析之后，大概做出技術(shù)總結(jié)，把經(jīng)常犯的一些錯誤，列成一些可做的規(guī)程，給所在部門的骨干進(jìn)行宣傳。具體內(nèi)容包括：

• SOA 的服務(wù)治理，這里主要強(qiáng)調(diào)的是領(lǐng)域劃分，高內(nèi)聚低耦合。

• 對公共組件的治理。這里的數(shù)據(jù)庫 Redis 由兩個專業(yè)的團(tuán)隊組成，一個是 DA，一個是 DBA。DA 治理的主要方案是收集各個產(chǎn)業(yè)伙伴的信息，規(guī)劃容量，治理開發(fā)的使用姿勢，把經(jīng)驗固化到研發(fā)流程里。

• 業(yè)務(wù)指標(biāo)的梳理，包括對 TPS 的概念設(shè)定（狀態(tài)輪轉(zhuǎn)后再根據(jù)返回狀態(tài)打點(diǎn)）、狀態(tài)的停滯時間和狀態(tài)的堆積深度，這個堆積深度主要是后端一些服務(wù)的狀態(tài)輪轉(zhuǎn)。

• 對超時鏈的合理設(shè)定和重試機(jī)制。

• 外部依賴及開關(guān)。為什么強(qiáng)調(diào)外部依賴呢？外部依賴可以分為兩類，一類是跟其他公司的合作，例如調(diào)用其他公司的支付接口。還有一類依賴是團(tuán)隊之間的依賴，這里請不要相信任何人的服務(wù)，Bug 隨時都會發(fā)生。

• 關(guān)鍵路徑。為什么要設(shè)置關(guān)鍵路徑呢？一個是熔斷，一個是降級。當(dāng)非關(guān)鍵路徑出現(xiàn)問題的時候，直接把它降掉就行了，不要影響關(guān)鍵路徑。另外一個好處是接下來做補(bǔ)償?shù)臅r候，可以有針對性去做。

• 日志。團(tuán)隊在日志上發(fā)生的事故也很多，可以逐個通過案例進(jìn)行宣講。

• 正在實現(xiàn)中的制定盲演習(xí)目標(biāo)。因為八九百個技術(shù)工程師之間的代碼交互本身是一個復(fù)雜系統(tǒng)，業(yè)務(wù)又是一個非常長的業(yè)務(wù)鏈，關(guān)鍵路徑涉及的服務(wù)超過 100個，簡單的功能測試是可以的，但是容量大的時候，將很難定位他們之間存在的問題，比如 A 團(tuán)隊和 B 團(tuán)隊之間的代碼耦合驗收。這時想到的解決方案就是盲演習(xí)。

  盲演習(xí)除了在業(yè)務(wù)方可以做驗收之外，還可以做基礎(chǔ)設(shè)施，包括 Redis 集群、 MySQL 集群和網(wǎng)絡(luò)。曾經(jīng)做過一個測試，把一個 Redis 實例上的包量，按照百分之一的丟包率計算，導(dǎo)致整個全站的業(yè)務(wù)都掉底。當(dāng)時整個 Redis 集群有12臺，有幾百個實例，其中一個實例有問題，就造成這么大的影響。通過盲演習(xí)，技術(shù)正在尋求單個節(jié)點(diǎn)宕機(jī)影響最小化的解決方案。

第二階段，保穩(wěn)定期。頭號敵人是容量問題。

在業(yè)務(wù)快速擴(kuò)張階段，影響系統(tǒng)穩(wěn)定性最大的敵人是容量，類似溫水煮青蛙，或突然雪崩。因為不同語言判定容量的方式不同，餓了么1000多個服務(wù)組成的復(fù)雜系統(tǒng)，業(yè)務(wù)場景快速變換，服務(wù)變更頻繁等等因素，導(dǎo)致容量問題困擾了近一年的時間。

最后采用的是定期線上全鏈路壓測的方法，發(fā)動了一次百人戰(zhàn)役，歷時一個多月，整改了近 200 個隱患點(diǎn)，基本解決了容量問題。即便在低谷期的時候，也采用全聯(lián)路壓制。還可以配合技術(shù)在上線前的壓測一起來做，然后把這些數(shù)據(jù)統(tǒng)籌起來進(jìn)行分析。

秒殺事故

在 517 秒殺大促準(zhǔn)備階段，技術(shù)的運(yùn)營思路是想用日常服務(wù)的集群來對抗秒殺，活動前把整個的容量提高了兩倍多。但是當(dāng)日訂單量飆漲，秒殺開始后的那幾秒鐘，瞬時并發(fā)請求達(dá)到平常的 50 倍。當(dāng)流量洪峰到來的時候，洪峰直接把前端 Nginx 的網(wǎng)絡(luò)擁塞了。

反思下來，出現(xiàn)問題的原因是秒殺場景的經(jīng)驗少，對活動帶來洪峰數(shù)據(jù)的預(yù)估過低，URL 的限流未區(qū)分優(yōu)先級等等。改進(jìn)措施是專門針對秒殺搭建了一套系統(tǒng)，主要做了分級保護(hù)、建立用戶端緩存、泳道、云集群和競爭緩存等。

第三階段，增效。通過工具、資源、架構(gòu)改造，提高效率。 

事故1：連續(xù)兩周蜂鳥配送出現(xiàn)各類事故

原因是消息不斷的批量重試導(dǎo)致 RMQ 堆積，UDP 句柄耗盡，熔斷判定使用姿勢不對?？梢钥闯?，新業(yè)務(wù)在快速交付過程中，代碼質(zhì)量、外部組建的使用姿勢是事故高危隱患點(diǎn)。

事故2：MySQL

SQL 慢查詢，從每周的 2 到 3 起，降低到近期很少出現(xiàn)。解決辦法是使用組件治理。組件治理首先是服務(wù)化自己的資源、容量。第二個是設(shè)限流，做降級。第三個主要是限制開發(fā)的一些姿勢。 

這三點(diǎn)做完之后，接下來技術(shù)做了自動化相關(guān)的一些工作，主要是信息、標(biāo)準(zhǔn)化和編排。再一個是前置指標(biāo)KPI，就是當(dāng)一些組件剛使用起來時，要做一些量化的考慮。把這幾條做到以后，技術(shù)基本上能避免出現(xiàn)大的故障問題。

對于使用姿勢的治理，對穩(wěn)定的收益最大。這里特別介紹幾個關(guān)鍵點(diǎn)：

• 必須要有對組件精通的伙伴，看過源碼，了解社區(qū)里碰到的所有的坑，還要深入業(yè)務(wù)開發(fā)一線，了解業(yè)務(wù)場景，初步判定組件在業(yè)務(wù)中的使用場景。

• 工程師進(jìn)行知識傳遞，通過各種渠道把標(biāo)準(zhǔn)化、開發(fā)規(guī)范、集群化、開發(fā)使用姿勢等知識點(diǎn)傳遞到位。

• 盡快把經(jīng)驗或紅線固化到資源申請、架構(gòu)評審等流程、工具里。

事故3：RMQ

在餓了么，RMQ 的使用場景非常多，有 Python，也有 Java。2016年年初的時候，工程師雖然做了一個技術(shù)、配置的梳理，還是留有很多的場景是沒有想到的，主要涉及的問題有如下幾個：

• 分區(qū)，就是技術(shù)在做割接的時候，核心交換是升級換設(shè)備。當(dāng)設(shè)備網(wǎng)絡(luò)割接完了，雖然在 RMQ 集群里面的配置是可以自恢復(fù)的，但是仍然還有很多集群沒有做到自恢復(fù)。

  所以，技術(shù)特意預(yù)留了一個冷備 RMQ 集群，把現(xiàn)網(wǎng)所有的配置都部署到那一個冷備集群里面去。線上 20 多個 RMQ 集群中，如有一個宕掉的時候，可以及時切過來。

• 隊列堵塞。主要是追查消費(fèi)能力，因為業(yè)務(wù)飆升，消費(fèi)能力不夠，極容易導(dǎo)致隊列堵塞。

• 使用場景。舉例來說，在發(fā)送、接收消息的時候，如果每發(fā)一個消息，每收一個消息，都重建一次鏈接或者都重建 Queue。這種重建會導(dǎo)致 RMQ 內(nèi)部的一個Event機(jī)制。當(dāng)請求增長到一定程度的時候，就會直接影響 RMQ 的吞吐量，RMQ 的容量會掉到是原來的十分之一。

老大難：故障定位、恢復(fù)效率

故障定位慢的最主要原因是餓了么整個系統(tǒng)的信息量太大，當(dāng)一個問題出現(xiàn)的時候，主導(dǎo)這個事故定位的工程師拿到的信息非常多，比如拿到三個信息，他很難決定到底是什么故障，需要如何檢測出來。

當(dāng)前的做法是進(jìn)行碎片化、地毯式的大掃蕩來排障。什么是地毯式的大掃蕩呢？就是把足夠多的信息先拿到，進(jìn)行分工，要求涉及的每個工程師都來查看。內(nèi)容涉及到外賣、商戶、支付和物流，然后還有基礎(chǔ)業(yè)務(wù)和網(wǎng)絡(luò)監(jiān)控，外網(wǎng)的一些流量，還有服務(wù)器的一些負(fù)擔(dān)等等。

這時，技術(shù)工程師的有序自證就變得非常重要，當(dāng)前能做到的是每一個人能看到當(dāng)前負(fù)責(zé)的服務(wù)是不是有問題。還需要做的就是提供工具，比如交換機(jī)的丟包、服務(wù)器的丟包。通過一些工具，讓技術(shù)工程師及時發(fā)現(xiàn)問題，但是這個過程是需要時間的。 

另外一個是在自證的時候，一定要仔細(xì)地檢查。作為團(tuán)隊中的一個成員，每一個技術(shù)工程師負(fù)責(zé)相應(yīng)的板塊，但一旦因為個人疏忽或是自檢不足造成一些失誤，要自己“刷鍋”。故障定位后，提升恢復(fù)效率解決問題才是關(guān)鍵。

還有，應(yīng)急演習(xí)很重要。應(yīng)急演習(xí)直接關(guān)系到系統(tǒng)恢復(fù)的效率，當(dāng)一個集群出問題的時候，技術(shù)能不能快速的恢復(fù)。 

本次分享大部分圍繞事故來講。每一次事故的出現(xiàn)都不是偶然的，很多問題是可以通過正確的使用姿勢、提前做容量預(yù)估、灰度等方法規(guī)避的。如果說技術(shù)只是就事論事把這一件事情解決的話，事故往往在另外一個時間點(diǎn)還會出現(xiàn)。

這就要求工程師以思考的方式去做事，比如做事故復(fù)盤、事故報道審核，還有驗收小組等。然后，通過在各個階段，多次把一個事故涉及的關(guān)鍵點(diǎn)提出來，不斷地進(jìn)行總結(jié)并制定可行的操作規(guī)范。

問題的解決往往需要思維模式的轉(zhuǎn)變，需要伙伴們多想想怎么從日常重要緊急的事務(wù)里抽離出時間思考。 

還有要敢于折騰。折騰是什么概念呢？就是要不斷的演習(xí)、搗亂，工程師對于維護(hù)的系統(tǒng)，自己要非常的熟悉，這樣在定位和解決故障的時候，就會非常精準(zhǔn)。 

最后一個是燈下黑的問題，特別是基礎(chǔ)設(shè)施這塊。這在當(dāng)時讓人很頭疼，查一個問題在基礎(chǔ)設(shè)施上花費(fèi)的時間是十多分鐘到一個小時。后來有一個小伙伴改變思路，做出了一套系統(tǒng)，幫助團(tuán)隊非常好地解決了這個大問題。所以敢于思考，勤于嘗試是餓了么技術(shù)團(tuán)隊非常重要的一個心得。

作者：徐盎

編輯：孫淑娟

本文選自《CTO說》

[[193658]]

徐盎，擅長精益運(yùn)維、精細(xì)化風(fēng)控，通過與公司其他團(tuán)隊協(xié)作、推動并完善運(yùn)維信息化、標(biāo)準(zhǔn)化、服務(wù)化的建設(shè)，逐步實現(xiàn)自動化運(yùn)維及交付，數(shù)據(jù)可視化，進(jìn)而做到低成本的保障系統(tǒng)穩(wěn)定;通過數(shù)據(jù)與規(guī)則適配，以及產(chǎn)品設(shè)計、人工審計、風(fēng)控平臺建設(shè)使每一元補(bǔ)貼用在公司既定目標(biāo)的實現(xiàn)上。

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請注明原文作者和出處為51CTO.com】