【51CTO.com原創(chuàng)稿件】餓了么業(yè)務(wù)快速發(fā)展，給技術(shù)帶來了海量請求和高并發(fā)、微服務(wù)的挑戰(zhàn)，同時(shí)開發(fā)團(tuán)隊(duì)快節(jié)奏的版本迭代和服務(wù)快速上線的要求也驅(qū)動運(yùn)維團(tuán)隊(duì)提供穩(wěn)定、高效的運(yùn)維服務(wù)。

[[224540]]

2017 年 12 月 01 日-02 日，由 51CTO 主辦的 WOTD 全球軟件開發(fā)技術(shù)峰會在深圳中州萬豪酒店隆重舉行。

餓了么技術(shù)運(yùn)營負(fù)責(zé)人程炎嶺在創(chuàng)新運(yùn)維探索專場與來賓分享了"跨越籬笆-餓了么多活運(yùn)維上下求索"的主題演講，從業(yè)務(wù)發(fā)展和多活后的技術(shù)運(yùn)營保障，結(jié)合具體案例，分享餓了么在運(yùn)維方面的探索以及實(shí)踐經(jīng)驗(yàn)。

我是餓了么的技術(shù)運(yùn)營負(fù)責(zé)人，見證了餓了么業(yè)務(wù)的飛速發(fā)展。記得 2015 年加入餓了么的時(shí)候，我們的日訂單量只有 30 萬筆；而到了 2017 年，我們的日訂單量已經(jīng)超過 1000 萬筆。

考慮到我們在整個(gè)市場的體量和單個(gè)機(jī)房至多只能處理 2000 萬筆訂單的上限，我們逐步推進(jìn)了面向***冗余多活的新規(guī)劃。

今天的分享主要分為三個(gè)部分：

• 多活場景及業(yè)務(wù)形態(tài)
• 餓了么多活運(yùn)維挑戰(zhàn)
  
• 餓了么運(yùn)營體系探索

多活場景及業(yè)務(wù)形態(tài)

餓了么多活的現(xiàn)狀

首先介紹一下餓了么整個(gè)多活的現(xiàn)狀：我們在北京和上海共有兩個(gè)機(jī)房提供生產(chǎn)服務(wù)。機(jī)房和 ezone 是兩個(gè)不同的概念，一個(gè)機(jī)房可以擴(kuò)展多個(gè) ezone，目前是一對一關(guān)系。

我們還有兩個(gè)部署在公有云的接入點(diǎn)，作為全國流量請求入口。它們分別受理南北方的部分流量請求，接入點(diǎn)都部署在阿里云上面，同時(shí)從運(yùn)維容災(zāi)角度出發(fā)。

我們考慮到兩個(gè)云入口同時(shí)“宕掉”的可能性，正在籌建 IDC 內(nèi)的備用接入點(diǎn)，作為災(zāi)備的方案。

多活從 2017 年 5 月份的***次演練成功到現(xiàn)在，我們經(jīng)歷過 16 次整體性的多活切換。

這 16 次切換既包含正常的演練，也包含由于發(fā)生故障而進(jìn)行的真實(shí)切換。其中，最近的一次切換是因?yàn)槲覀兩虾C(jī)房的公網(wǎng)出口發(fā)生了故障，我們將其所有流量都切換到了北京。

實(shí)現(xiàn)多活的背景

下面我從五方面介紹實(shí)施多活之前的一些背景狀況：

• 業(yè)務(wù)特點(diǎn)
• 技術(shù)復(fù)雜
• 運(yùn)維兜底
• 故障頻發(fā)
• 機(jī)房容量

業(yè)務(wù)特點(diǎn)：我們有三大流量入口，分別是用戶端、商戶端以及騎手端。

一個(gè)典型的下單流程是：用戶打開 App 產(chǎn)生一個(gè)訂單，店家在商戶端進(jìn)行接單，然后生成一個(gè)物流派送服務(wù)的運(yùn)單。

而該流程與傳統(tǒng)電商訂單的區(qū)別在于：如果在商城生成一個(gè)訂單，后臺商戶端可以到第二天才收到，這種延時(shí)并無大礙。

但是對于餓了么就不行，外賣的時(shí)效性要求很高，如果在 10 分鐘之內(nèi)商戶還未接單的話，用戶要么會去投訴，要么可能就會取消訂單，更換美團(tuán)、百度外賣，從而會造成用戶的流失。

另外，我們也有很強(qiáng)的地域性。比如說在上海生成的訂單，一般只適用于上海本地區(qū)，而不會需要送到其他地方。

同時(shí)，我們的業(yè)務(wù)也有著明顯的峰值，上午的高峰，一般在 11 點(diǎn)；而下午則會是在 5 點(diǎn)到 6 點(diǎn)之間。

我們通過整個(gè)監(jiān)控曲線便可對全鏈路的請求一目了然。這就是我們公司乃至整個(gè)外賣行業(yè)的業(yè)務(wù)特點(diǎn)。

技術(shù)復(fù)雜：上圖是流量請求從進(jìn)入到底層的整個(gè)技術(shù)架構(gòu)。

SOA（面向服務(wù)的體系結(jié)構(gòu)）系統(tǒng)架構(gòu)本身并不復(fù)雜，其實(shí)大部分互聯(lián)網(wǎng)公司的技術(shù)架構(gòu)演進(jìn)到***都是類似的。

我們真正的復(fù)雜之處在于：各種組件、基礎(chǔ)設(shè)施以及整個(gè)的接入層存在多語言的問題。

在 2015 年之前，我們的前端是用 PHP 寫的，而后端則是 Python 寫的。在經(jīng)歷了兩年的演進(jìn)之后，我們現(xiàn)在已把所有由 PHP 語言寫的部分都替換掉了。而為了適用多種語言，我們的組件不得不為某一種語言多做一次適配。

比如說：我們要跟蹤（trace）整個(gè)鏈路，而且用到了多種語言，那么我們就要為之研發(fā)出多種 SDK，并需要花大量的成本去維護(hù)這些 SDK。

可見，復(fù)雜性往往不在于我們有多少組件，而是我們要為每一種組件所提供的維護(hù)上。

我們當(dāng)前的整個(gè) SOA 框架體系主要面向兩種語言：Python 和 Java，逐漸改造成更多地面向 Java。

中間的 API Everything 包含了許多為不同的應(yīng)用場景而開發(fā)的各種 API 項(xiàng)目。而我們基礎(chǔ)設(shè)施方面，主要包括了整個(gè)存儲與緩存，以及公有云和私有云。

運(yùn)維兜底：在業(yè)務(wù)飛速發(fā)展的過程當(dāng)中，我們的運(yùn)維團(tuán)隊(duì)做得更多的還是“兜底”工作。

***的統(tǒng)計(jì)，我們現(xiàn)在有將近 16000 臺服務(wù)器、1600 個(gè)應(yīng)用、1000 名開發(fā)人員、4 個(gè)物理 IDC、以及部署了防護(hù)層的兩朵云。也有一些非常小的第三方云服務(wù)平臺，包括 AWS 和阿里聚石塔等。

在業(yè)務(wù)增長過程當(dāng)中，基于整個(gè) IDC 的基礎(chǔ)設(shè)施環(huán)境，我們對交付的機(jī)型統(tǒng)一定制，并且改進(jìn)了采購的供應(yīng)鏈，包括：標(biāo)準(zhǔn)化的整機(jī)柜交付和數(shù)據(jù)清洗等。

對于應(yīng)用使用的數(shù)據(jù)庫與緩存，我們也做了大量的資源拆分與改造工作，比如數(shù)據(jù)庫，改造關(guān)鍵路徑隔離，垂直拆分，sharding，SQL 審核，接入數(shù)據(jù)庫中間件dal，對緩存 redis 使用治理，遷移自研的 redis cluster 代理 corvus，聯(lián)合框架實(shí)現(xiàn)存儲使用的規(guī)范化，服務(wù)化。

曾經(jīng)面臨比較大的挑戰(zhàn)是數(shù)據(jù)庫 DDL，表設(shè)計(jì)在每家公司都有一些自己的特點(diǎn)，例如阿里、百度他們每周 DDL 次數(shù)很少。

但是我們每周則會有將近三位數(shù)的 DDL 變更，這和項(xiàng)目文化以及業(yè)務(wù)交付有關(guān)。

DBA 團(tuán)隊(duì)以及 DAL 團(tuán)隊(duì)為此做了幾件事情：表數(shù)據(jù)量紅線，基于 Gh-OST 改進(jìn) online schema change 工具，Edb 自助發(fā)布。這樣大大減少了數(shù)據(jù)庫 DDL 事故率以及變更效率。

在多活改造過程中，工具的研發(fā)速度相對落后，我們在運(yùn)維部署服務(wù)，組件的推廣和治理過程中，大部分都還是人工推廣、治理。

我們還負(fù)責(zé)全網(wǎng)的穩(wěn)定性，以及故障管理，包括預(yù)案演練、故障發(fā)現(xiàn)、應(yīng)急響應(yīng)、事故復(fù)盤等，以及對事故定損定級。

故障管理并不是為了追責(zé)，而是通過記錄去分析每一次故障發(fā)生的原因，以及跟進(jìn)改進(jìn)措施，避免故障再次發(fā)生。

我們還定義了一個(gè)全網(wǎng)穩(wěn)定性計(jì)數(shù)器，記錄未發(fā)生重大事故的累計(jì)時(shí)間，當(dāng)故障定級應(yīng)達(dá)到 P2 以上時(shí)清零重新開始。

歷史上我們保持最長的全網(wǎng)穩(wěn)定性紀(jì)錄是 135 天，而美團(tuán)已經(jīng)超過了 180 天，還有一些差距。

故障頻發(fā)：根據(jù)上圖“故障頻發(fā)”所反映的數(shù)據(jù)，大家可以看到，2015 年和 2016 年的數(shù)據(jù)慘不忍睹。

按天計(jì)算，我們經(jīng)常會出現(xiàn) P2 級別以上的事故，最短的是隔 1 天就出現(xiàn) 1 個(gè) P2 以上事故。

我們不得不進(jìn)行改進(jìn)，于是我們組建了一個(gè)叫 NOC（Notification Operation Center）的團(tuán)隊(duì)。

這個(gè)是參照 Google SRE 所建立的負(fù)責(zé) 7*24 應(yīng)急響應(yīng)團(tuán)隊(duì)，以及初步原因判斷，執(zhí)行常規(guī)的演練，組織復(fù)盤，跟進(jìn)復(fù)盤改進(jìn)落地情況。

NOC 定義公司通用故障定級定損/定責(zé)的標(biāo)準(zhǔn)：P0—P5 的事故等級，其參照的標(biāo)準(zhǔn)來自于業(yè)務(wù)特性的四個(gè)維度，它們分別是：

• 在高峰期/非高峰期的嚴(yán)重影響，包括受損時(shí)間段和受損時(shí)長。
• 對全網(wǎng)業(yè)務(wù)訂單的損失比。
• 損失金額。
• 輿情的影響。包括與美團(tuán)、百度外賣、其他平臺的競爭。不過區(qū)別于外賣食材的本身品質(zhì)，我們這里討論的是技術(shù)上的故障。

比如商家無緣無故取消了客戶的訂單，或是由于其他各種原因?qū)е驴蛻粼谖⒉⒒蛳蚩头块T投訴的數(shù)量上升。

上述這些不同的維度，結(jié)合高峰期與低峰期的不同，都是我們定級的標(biāo)準(zhǔn)。

根據(jù)各種事故運(yùn)營定級/定責(zé)的規(guī)范，我們建立了響應(yīng)的排障 SOP（標(biāo)準(zhǔn)操作流程），進(jìn)而我們用報(bào)表來進(jìn)行統(tǒng)計(jì)。

除了故障的次數(shù)之外，MTTR（平均恢復(fù)時(shí)間）也是一個(gè)重要的指標(biāo)。通過響應(yīng)的 SOP，我們可以去分析某次故障的本身原因，是因?yàn)榘l(fā)現(xiàn)的時(shí)間較長，還是響應(yīng)的時(shí)間較長，亦或排障的時(shí)間比較長。

通過落地的標(biāo)準(zhǔn)化流程，并且根據(jù)報(bào)表中的 MTTR，我們就可以分析出在發(fā)生故障之后，到底是哪個(gè)環(huán)節(jié)花費(fèi)了較長的時(shí)間。

提到“故障頻發(fā)”，我們認(rèn)為所有的故障，包括組件上的故障和底層服務(wù)器的故障，都會最終反映到業(yè)務(wù)曲線之上。

因此我們 NOC 辦公室有一個(gè)大屏幕來顯示重要業(yè)務(wù)曲線，當(dāng)曲線的走勢發(fā)生異常的時(shí)候，我們就能及時(shí)響應(yīng)通知到對應(yīng)的人員。

在訂單的高峰期，我們更講求時(shí)效性。即發(fā)生了故障之后，我們要做的***件事，或者說我們的目標(biāo)是快速地止損，而不是去花時(shí)間定位問題。

這就是我們?nèi)?shí)現(xiàn)多活的目的，而多活正是為我們的兜底工作進(jìn)行“續(xù)命”。原來我只有一個(gè)機(jī)房，如果該機(jī)房的設(shè)施發(fā)生了故障，而正值業(yè)務(wù)高峰期的時(shí)候，后果是不堪設(shè)想的。

機(jī)房容量：我們再來看看整個(gè)機(jī)房的容量，在 2015 年之前，當(dāng)時(shí)訂單量很少，我們的服務(wù)器散落在機(jī)房里，機(jī)型也比較隨意。

而到了 2015 年，我們大概有了 1500 臺服務(wù)器；在 2016 年間，我們增長到了 6000 臺；2017 年，我們則擁有將近 16000 臺。這些還不包括在云上的 ECS 數(shù)量。

有過 IDC 相關(guān)工作經(jīng)歷的同學(xué)可能都知道：對于大型公司的交付，往往都是以模塊簽的合同。

但初期我們并不知道業(yè)務(wù)發(fā)展會這么快，服務(wù)器是和其他公司公用模塊和機(jī)架，服務(wù)器也是老舊而且非標(biāo)準(zhǔn)化，同時(shí)組網(wǎng)的環(huán)境也非常復(fù)雜。甚至有一段時(shí)期，我們就算有錢去購買服務(wù)器，機(jī)房里也沒有擴(kuò)容的空間。

為什么要做多活

為什么要做多活，總結(jié)一下有四個(gè)方面：容災(zāi)續(xù)命、服務(wù)擴(kuò)展、單機(jī)房容量、和其他的一些原因。

如上圖右側(cè)所示，我們通過一個(gè)類似 X/Y 軸的曲線進(jìn)行評估。隨著業(yè)務(wù)規(guī)模的增長，技術(shù)投入，服務(wù)擴(kuò)展，故障損失已不是一種并行增長的關(guān)系了。

餓了么多活運(yùn)維挑戰(zhàn)

下面分享一下我們當(dāng)時(shí)做了哪些運(yùn)維的規(guī)劃，主要分為五個(gè)部分：

• 多活技術(shù)架構(gòu)
  
• IDC 規(guī)劃
  
• SOA 服務(wù)改造
• 數(shù)據(jù)庫改造
• 容災(zāi)保障

多活技術(shù)架構(gòu)

我們通過設(shè)置既可把昆山劃分到上海，又可以劃到蘇州（這與行政區(qū)無關(guān)、僅關(guān)系到外賣的遞送半徑）。因此我們提出了地理圍欄的概念，研發(fā)了 GZS 組件。

我們把全國省市在 GZS（globalzone service）服務(wù)上區(qū)分地理圍欄，將全國分成了 32 個(gè) Shard，來自每個(gè) Shard 的請求進(jìn)入系統(tǒng)之后，通過 GZS 判斷請求應(yīng)該路由到所屬的機(jī)房。

如圖最下方所示，對于一些有強(qiáng)一致性需求的數(shù)據(jù)要求，我們提出了 Global zone 的概念。屬于 Global zone 的數(shù)據(jù)庫，寫操作僅限于在一個(gè)機(jī)房，讀的操作可以在不同 zone 內(nèi)的 local slave 上。

多活技術(shù)架構(gòu)五大核心組件：

• API Router：流量入口 API Router，這是我們的***個(gè)核心的組件，提供請求代理及路由功能。
• GZS：管理地理圍欄數(shù)據(jù)及 Shard 分配規(guī)則。
• DRC：DRC（Data replication center）數(shù)據(jù)庫跨機(jī)房同步工具，同時(shí)支持?jǐn)?shù)據(jù)變更訂閱，用于緩存同步。
• SOA proxy：多活非多活之間調(diào)用。
• DAL：原本是數(shù)據(jù)庫中間件，為了防止數(shù)據(jù)被路由到錯(cuò)誤的機(jī)房，造成數(shù)據(jù)不一致的情況，多活項(xiàng)目中配合做了一些改造。

整個(gè)多活技術(shù)架構(gòu)的核心目標(biāo)在于：始終保證在一個(gè)機(jī)房內(nèi)完成整個(gè)訂單的流程。

為了實(shí)現(xiàn)這個(gè)目標(biāo)，研發(fā)了 5 大功能組件，還調(diào)研識別有著強(qiáng)一致性的數(shù)據(jù)需求，一起從整體上做了規(guī)劃和改造。

IDC 規(guī)劃

在 2016 年底啟動多活項(xiàng)目，確定了南北兩個(gè)機(jī)房，以及流量入口，開始進(jìn)行 IDC 選型，實(shí)地考察了幾家上海的 IDC 公司，最終選擇了萬國數(shù)據(jù)機(jī)房。同時(shí)結(jié)合做抗 100% 流量服務(wù)器預(yù)算、提交采購部門采購需求。

規(guī)劃多活聯(lián)調(diào)測試環(huán)境，模擬生產(chǎn)雙 ezone、劃分 vpc，以及***的業(yè)務(wù)同期改造。

如上圖右側(cè)所示，以兩處不同的流量為例，不同區(qū)域通過接入層進(jìn)來的流量，分別對應(yīng)北京和上海不同的機(jī)房，在正常情況下整個(gè)訂單的流程也都會在本區(qū)域的機(jī)房被處理，同時(shí)在必要時(shí)能夠相互分流。

SOA 服務(wù)改造

我們對 SOA 服務(wù)注冊發(fā)現(xiàn)也做了一些改造工作。先說下多活以前是什么情況，某一個(gè)應(yīng)用服務(wù) AppId 要上線，物理集群環(huán)境準(zhǔn)備好，在 SOA 注冊時(shí)對應(yīng)了一個(gè) SOA cluster 集群。

另外一些大的集群，對不同的業(yè)務(wù)調(diào)用劃分不同的泳道，并將這些泳道在應(yīng)用發(fā)布的時(shí)候，定義到不同的應(yīng)用集群上，這就是整個(gè) AppId 部署的邏輯。

這對于單機(jī)房來說是很簡單的，但是在雙機(jī)房場景中，需要改造成同一個(gè) AppId，只調(diào)用本機(jī)房的 SOA cluster，我們在甬道和分布集群的基礎(chǔ)上引入了一個(gè)類似于單元的 ezone 概念。

SOA Mode 的改造方案，其中包括如下三種模式：

• Orig：兼容模式，默認(rèn)的服務(wù)注冊發(fā)現(xiàn)方式。
• Prefix：收回服務(wù)注冊、統(tǒng)一 SOA 服務(wù)注冊的方式。此模式主要針對的是我們許多新上線的多活應(yīng)用。對于一些老的業(yè)務(wù)，默認(rèn)還是沿用 Orig 模式。
• Route：這是回收 SOA 服務(wù)調(diào)用的最終模式，進(jìn)一步實(shí)現(xiàn)了統(tǒng)一 SOA 的服務(wù)注冊發(fā)現(xiàn)。整個(gè) IDC、ezone、運(yùn)維架構(gòu)等信息對于業(yè)務(wù)方都是透明，從而降低了業(yè)務(wù)方對于 SOA 所產(chǎn)生的維護(hù)工作量。

數(shù)據(jù)庫改造

按照前面對整個(gè)應(yīng)用部署的劃分，即多活、非多活以及強(qiáng)一致性的 Global zone，對數(shù)據(jù)庫也進(jìn)行了相應(yīng)的規(guī)劃。

我們先后進(jìn)行了業(yè)務(wù)數(shù)據(jù)一致性的調(diào)研，復(fù)制一致性的規(guī)劃，多活的集群改造成通過 DRC 來雙向復(fù)制，Global zone 則采用原生的 Replication。

具體改造可分為三部分：

• 數(shù)據(jù)庫集群改造，根據(jù)倒排期的時(shí)間點(diǎn)，分派專門的團(tuán)隊(duì)去跟進(jìn)，將整個(gè)過程拆分出詳細(xì)的操作計(jì)劃。
• 數(shù)據(jù)庫中間件 DAL 改造，增加校驗(yàn)功能，保證 SQL 不會寫入錯(cuò)誤的機(jī)房。實(shí)現(xiàn)了寫入錯(cuò)誤的數(shù)據(jù)保護(hù)，增加一道兜底防護(hù)。
• DRC 改造，多活兩地實(shí)例間改造程 DRC 復(fù)制。

容災(zāi)保障

容災(zāi)保障，區(qū)分了三個(gè)不同的等級：

• 流量入口故障，常見的有 DNS 解析變更，網(wǎng)絡(luò)出口故障，某省市骨干線路故障，以及 AR 故障。
• IDC 內(nèi)故障，常見的有變更發(fā)布故障，歷史 Bug 觸發(fā)，錯(cuò)誤配置，硬件故障，網(wǎng)絡(luò)故障，容量問題等。
• 單機(jī)房完全不可用。目前尚未完全實(shí)現(xiàn)，但是我們?nèi)缃裾谶M(jìn)行斷網(wǎng)演練。模擬某個(gè)機(jī)房里的所有 zone 都因?yàn)椴豢煽沽﹀吹袅耍惨ＷC該機(jī)房的所有應(yīng)用能夠被切換到另一個(gè)機(jī)房，繼續(xù)保障服務(wù)可用。

當(dāng)然這沒能從根本上解決雙機(jī)房同時(shí)發(fā)生故障的情況。當(dāng)雙機(jī)房同時(shí)發(fā)生問題時(shí)，目前還是要依賴于有經(jīng)驗(yàn)的工程師，以及我們自動化的故障定位服務(wù)。

餓了么運(yùn)營體系探索

在整個(gè)餓了么運(yùn)維轉(zhuǎn)型的過程中，我們?nèi)绾螌⒔M織能力轉(zhuǎn)型成為運(yùn)營能力？下面是我們的五個(gè)思路：

• 應(yīng)用發(fā)布
• 監(jiān)控體系
• 預(yù)案和演練
• 容量規(guī)劃
• 單機(jī)房成本分析

應(yīng)用發(fā)布

首先來看應(yīng)用發(fā)布。在單機(jī)房的時(shí)候，我們一個(gè) AppId 對應(yīng)一個(gè)或多個(gè) SOA cluster 集群，同時(shí)運(yùn)維會配置灰度機(jī)器群組，并要求關(guān)鍵應(yīng)用需要灰度 30 分鐘。

那么在多活情況下，應(yīng)用如何實(shí)現(xiàn)發(fā)布呢？我們在規(guī)劃中采用了兩種方式可選：

• 把所有 zone 看成一個(gè)大型的“集群”，沿用灰度機(jī)器群體的發(fā)布策略。我們先在單個(gè)機(jī)房里做一次灰度，然后延伸到所有的 zone，保證每個(gè)關(guān)鍵應(yīng)用都遵循灰度大于 30 分鐘的規(guī)則，***再全量到所有的 zone 上。
• 把單個(gè) zone 看成一個(gè)“集群”，有多少個(gè) zone 就有多少個(gè)“集群”。首先灰度 zoneA、并全量 zoneA，然后灰度 zoneB、并全量 zoneB。

或者您也可以先灰度 zoneA、并灰度 zoneB，然后同時(shí)觀察、并驗(yàn)證發(fā)布的狀態(tài)，***再全量 zoneA、并全量 zoneB。您可以根據(jù)自身情況自行選擇和實(shí)現(xiàn)。

監(jiān)控體系

餓了么目前有三大監(jiān)控體系：

• 全鏈路監(jiān)控。在 Agent 啟動時(shí)讀取一個(gè)文件，以獲知當(dāng)前處于哪個(gè) zone，然后會在 metric 中為 ezoneid 增加一個(gè) tag，并且進(jìn)行指標(biāo)聚合。默認(rèn)在一個(gè)機(jī)房里可有多個(gè) zone。
• 業(yè)務(wù)監(jiān)控。進(jìn)行分機(jī)房的部署，將 statsd 打到各自所在機(jī)房，而在查看時(shí)則需要切換 Data Source。
• 基礎(chǔ)設(shè)施監(jiān)控。而對于服務(wù)器、網(wǎng)絡(luò)設(shè)備監(jiān)控則不必區(qū)分 ezone，通過 host link 來進(jìn)行查詢。

預(yù)案和演練

對于常見的故障做了預(yù)案，制定常規(guī)演練計(jì)劃，并且定期演練。目前我們也正在做一套演練編排系統(tǒng)，上線之后應(yīng)該會有更好的效果。

容量規(guī)劃

至于容量規(guī)劃（Capacity planning），我們目前只是采集到 AppId 的服務(wù)器 CPU 利用率。

結(jié)合現(xiàn)有兩地機(jī)房的常態(tài)化負(fù)載應(yīng)該是：北京的 zone 承載 52% 的流量；而上海機(jī)房分?jǐn)?48%。

常規(guī)情況每周三會進(jìn)行全鏈路壓力測試。通過評估，我們能獲知整個(gè)關(guān)鍵路徑的容量。

未來我們也會假設(shè)倘若再增加了 15% 的流量，那么在現(xiàn)有的 AppId 基礎(chǔ)上，我們還需要增加的服務(wù)器臺數(shù)。

同時(shí)，在承載了現(xiàn)有訂單數(shù)量的基礎(chǔ)上，我們要估算現(xiàn)有的單個(gè) SOA cluster 所能承載的訂單請求極限。

如上圖所示，通過獲取 AppId 利用率統(tǒng)計(jì)列表，我們能夠發(fā)現(xiàn)：由于前期業(yè)務(wù)的爆炸式增長，我們在不計(jì)成本的情況下所購置的服務(wù)器機(jī)，其利用率實(shí)際上是比較低下的。

單機(jī)房成本分析

對于現(xiàn)有 IDC 成本核算，是按照一定的折舊標(biāo)準(zhǔn)將它們分?jǐn)偟矫總€(gè)月，并與業(yè)務(wù)上單月的總體完成訂單量進(jìn)行對比，最終計(jì)算出每筆訂單的 IT 成本，以及計(jì)算出每核成本。

另外，我們還可以與租用云服務(wù)的成本相比較，從而得出成本優(yōu)劣。

對于一些公共池化資源，把池化的各種組件服務(wù)分?jǐn)偟礁鱾€(gè)部門和每個(gè) AppId 之上。

這樣就能指導(dǎo)每個(gè) AppId 使用了多少臺服務(wù)器，IT 成本是多少，我們便可以進(jìn)一步開展成本分析。

[[224542]]

程炎嶺，現(xiàn)任餓了么技術(shù)運(yùn)營負(fù)責(zé)人，從數(shù)據(jù)庫到運(yùn)維，再到技術(shù)+運(yùn)營。目前主要負(fù)責(zé)餓了么上千個(gè) AppId 的運(yùn)維、IDC 建設(shè)及穩(wěn)定性保障工作。2015 年加入餓了么，兩年多來經(jīng)歷了餓了么體量和技術(shù)的蓬勃發(fā)展，在一次次挑戰(zhàn)和困境中伴隨技術(shù)運(yùn)營團(tuán)隊(duì)的成長。作為一位 10 多年的運(yùn)維老兵，希望把故事分享給大家，也很期待和大家一起學(xué)習(xí)和交流。

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