[[212664]]

12 月 7 日中午，有網(wǎng)友發(fā)微博稱，外賣訂單付款出現(xiàn)延遲，部分用戶付款后系統(tǒng)仍提示尚未付款；團(tuán)購頁面內(nèi)容也無法正常顯示。美團(tuán)服務(wù)器出現(xiàn)大面積崩潰。

這是一個上了熱搜，并讓大家吃不上午飯的 Bug。

飯點(diǎn)時間，遇到這種事情，也真的糟心了！而且，這種情況還不是個例，在微博上一搜，反映美團(tuán)外賣這種情況的還真不少。

 

并且有人看到顯示支付不成功，連續(xù)嘗試付款了好多次，但是錢出去了，卻既沒有下成單，也沒有退款。

想找美團(tuán)外賣的客服咨詢情況，但是卻一直聯(lián)系不上，無論是網(wǎng)上客服還是電話客服。

[[212665]]

不過，12:16 分美團(tuán)微博回復(fù)：訂單問題已修復(fù)，訂單問題已修復(fù)，訂單問題已修復(fù)。

12:28 分 APP 仍然處于宕機(jī)狀態(tài)。下午12：43分，美團(tuán)在微博上回應(yīng)：經(jīng)緊急修復(fù)后，現(xiàn)已陸續(xù)恢復(fù)，重復(fù)支付的訂單會原路退回，系統(tǒng)故障期間未完成服務(wù)的訂單，用戶可以無責(zé)取消退款。

隨后，部分重復(fù)下單的網(wǎng)友已經(jīng)獲得了退款和美團(tuán)的致歉紅包。此次事故對美團(tuán)的工程師們來說，簡直是年度災(zāi)難，很可能直接導(dǎo)致美團(tuán)的程序員們錯失豐厚年終獎的機(jī)會。

事實(shí)上，美團(tuán)并非第一次出現(xiàn)類似的問題，據(jù)了解，就在前天，12 月 5 日，美團(tuán)外賣也出現(xiàn)了一次服務(wù)器崩潰事故，中午當(dāng)用戶點(diǎn)完餐，想要查看訂單進(jìn)度時，頁面要么顯示“系統(tǒng)處理異常”，要么是“訂單不存在”，使得用戶無法追蹤自己的餐品配送進(jìn)度。

[[212666]]

美團(tuán)后臺宕機(jī)，對此，不少網(wǎng)友吐槽美團(tuán)的程序員是不是餓了去吃飯了，忽視了系統(tǒng)的 Bug，還是被祭天了？是不是放寒假了？

是不是下一步就要被祭天了

[[212667]]

[[212668]]

繼暴風(fēng)影音、蝦米音樂后，又一程序員要被祭天了。有網(wǎng)友還稱，餓了么安插在美團(tuán)身邊的程序員終于發(fā)力了。

[[212669]]

還遭到了隔壁一遇大事兒就崩潰的微博技術(shù)的調(diào)侃：

對此，有不少網(wǎng)友調(diào)侃道：

網(wǎng)友的陰謀論派：

一次的系統(tǒng)宕機(jī)可能是偶然，或是突發(fā)事件如之前鹿晗公布戀情致微博系統(tǒng)崩潰，但是連續(xù)多次的宕機(jī)，也許就是技術(shù)的缺陷了。

[[212670]]

下面小編給大家?guī)硪恍└韶?，一起來看看日訂單量?600萬的美團(tuán)外賣自動化業(yè)務(wù)運(yùn)維之路。

美團(tuán)外賣業(yè)務(wù)在互聯(lián)網(wǎng)行業(yè)是非常獨(dú)特的，不僅流程復(fù)雜——從用戶下單、商家接單到配送員接單、交付，而且壓力和流量在午、晚高峰時段非常集中。

同時，外賣業(yè)務(wù)的增長非常迅猛，自 2013 年 11 月上線到最近峰值突破 1600 萬，還不到 4 年。

在這種情況下，一旦出現(xiàn)事故，單純靠人工排查解決問題，存在較多的局限性。

本文將詳細(xì)解析美團(tuán)外賣運(yùn)維過程中問題發(fā)現(xiàn)、根因分析、問題解決等自動化運(yùn)維體系的建設(shè)歷程與相關(guān)設(shè)計原則。

外賣業(yè)務(wù)特點(diǎn) 

首先從業(yè)務(wù)本身具有的一些特點(diǎn)來講一下自動化業(yè)務(wù)運(yùn)維的必要性。

業(yè)務(wù)流程復(fù)雜

圖1：用戶角度的美團(tuán)外賣技術(shù)體系

美團(tuán)外賣的定位是“圍繞在線商品交易與及時送達(dá)的 O2O 電商交易平臺”。

圖 1 就是用戶在使用美團(tuán)外賣 App 過程中涉及到的技術(shù)模塊，歷經(jīng)用戶下單-->系統(tǒng)發(fā)給商家-->商家準(zhǔn)備外賣-->配送，到最后用戶收到商品比如熱乎乎的盒飯，整個過程的時間需要控制在半小時之內(nèi)。

在這背后，整個產(chǎn)品線上還會涉及很多數(shù)據(jù)分析、統(tǒng)計、結(jié)算、合同等各個端的交互，因此，對一致性的要求高，同時并發(fā)量也很高。

每日流量徒增明顯

圖 2：美團(tuán)外賣常規(guī)業(yè)務(wù)監(jiān)控圖

外賣業(yè)務(wù)每天在特定時刻流量陡增明顯，有時候與第三方做的一些活動會造成系統(tǒng)流量瞬間達(dá)到午高峰的 2~3 倍，如圖 2 所示。

業(yè)務(wù)增長迅猛

圖 3：美團(tuán)外賣重要成長里程碑

美團(tuán)外賣自 2013 年上線至 2017 年 10 月份，在不到 4 年的時間里，日提單已達(dá) 2000 萬，日完成訂單突破 1600 萬，如圖 3 所示。

在這期間，業(yè)務(wù)產(chǎn)品一直處在高速迭代的過程中，某些數(shù)據(jù)訪問的服務(wù)量會達(dá)到日均 120 億+次，QPS 近 40 萬?，F(xiàn)在如果在午高峰出現(xiàn)一個小小的事故，就會造成比較大的損失。

綜上所述，我們需要幫助開發(fā)人員準(zhǔn)確地定位問題和快速解決問題。

需要解決問題

圖 4：開發(fā)人員日常監(jiān)控痛點(diǎn)

我們在日常的業(yè)務(wù)運(yùn)維工作中經(jīng)常會碰到一些問題困擾著開發(fā)人員，如圖 4 所示。

現(xiàn)在主要有四大痛點(diǎn)：

• 各種維度的事件通知、報警事件充斥著開發(fā)人員的 IM，我們需要花很多精力去配置和優(yōu)化報警閾值、報警等級才不會出現(xiàn)很多誤報。

我們希望可以將各種服務(wù)的報警指標(biāo)和閾值標(biāo)準(zhǔn)化、自動化，然后自動收集這些事件進(jìn)行統(tǒng)計。一方面可以幫助開發(fā)人員提前發(fā)現(xiàn)問題潛在的風(fēng)險；另一方面為我們找出問題的根本原因提供有力的數(shù)據(jù)支持。

• 公司有多套監(jiān)控系統(tǒng)，它們有各自的職責(zé)定位，但是互相沒有關(guān)聯(lián)，所以開發(fā)人員在排查問題時需要帶著參數(shù)在不同的系統(tǒng)之間切換，這就降低了定位問題的效率。
• 我們的代碼中會有大量的降級限流開關(guān)，在服務(wù)異常時進(jìn)行相應(yīng)的保護(hù)操作。這些開關(guān)隨著產(chǎn)品快速地迭代，我們并不能確定它們是否還有效。

另外，我們需要較準(zhǔn)確地進(jìn)行容量規(guī)劃以應(yīng)對快速增長的業(yè)務(wù)量。這些都需要通過全鏈路壓測幫我們不斷地驗(yàn)證，并發(fā)現(xiàn)性能瓶頸，有效地評估服務(wù)容量。

• 開發(fā)人員收到各種報警之后，通常都會根據(jù)自己的經(jīng)驗(yàn)進(jìn)行問題的排查，這些排查經(jīng)驗(yàn)完全可以標(biāo)準(zhǔn)化。

比如對某個服務(wù)的 TP99 異常，需要進(jìn)行的排查操作，問題排查流程標(biāo)準(zhǔn)化之后，就可以通過計算機(jī)自動化。我們提高診斷的準(zhǔn)確度，就需要將這個流程更加智能化，減少人為參與。

核心目標(biāo)

我們希望通過一些自動化措施提升運(yùn)維效率，從而將開發(fā)人員從日常的業(yè)務(wù)運(yùn)維工作中解放出來，先來看一個用戶使用場景，如圖 5 所示，觸發(fā)服務(wù)保護(hù)有兩條路徑。

圖 5：自動化業(yè)務(wù)運(yùn)維系統(tǒng)核心建設(shè)目標(biāo)

第一條，當(dāng)用戶在前期接收到我們的診斷報警后，直接被引導(dǎo)進(jìn)入該報警可能會影響到業(yè)務(wù)大盤。

這時我們要查看業(yè)務(wù)圖表，如果影響到業(yè)務(wù)，引導(dǎo)用戶直接進(jìn)入該業(yè)務(wù)圖表對應(yīng)的核心鏈路，定位出問題的根本原因，進(jìn)而再判斷是否要觸發(fā)該核心鏈路上對應(yīng)的服務(wù)保護(hù)開關(guān)或預(yù)案。

第二條，用戶也可以直接通過診斷報警進(jìn)入對應(yīng)的核心鏈路，查看最終引起異常的根本原因，引導(dǎo)用戶判斷是否需要觸發(fā)相應(yīng)的服務(wù)保護(hù)預(yù)案。

發(fā)現(xiàn)問題-->診斷問題-->解決問題，這個過程每一步都需要不斷地提升準(zhǔn)確度，整個流程需要通過全鏈路壓測不斷驗(yàn)證，當(dāng)某些場景準(zhǔn)確度非常高的時候，就可以變?yōu)樽詣踊桨浮?/p>

因此，我們的核心目標(biāo)是，當(dāng)整個方案可以自動化進(jìn)行下去之后，對于用戶來說的使用場景就變成了：收到異常報警->收到業(yè)務(wù)服務(wù)恢復(fù)通知。

隨著自動化方案越來越完備，開發(fā)人員可以更加關(guān)注業(yè)務(wù)邏輯的開發(fā)。

重點(diǎn)系統(tǒng)體系建設(shè)

確定了核心目標(biāo)，我們開始著手開發(fā)產(chǎn)品。接下來就介紹一下我們建設(shè)這套系統(tǒng)的核心產(chǎn)品以及各個產(chǎn)品模塊之間的關(guān)聯(lián)。

體系架構(gòu)

如圖 6 所示，在自動化業(yè)務(wù)運(yùn)維系統(tǒng)中，業(yè)務(wù)大盤與核心鏈路作為用戶使用的入口，一旦用戶查看業(yè)務(wù)指標(biāo)出現(xiàn)問題，我們就需要快速定位該業(yè)務(wù)指標(biāo)異常的根本原因。

圖 6：業(yè)務(wù)監(jiān)控運(yùn)維體系架構(gòu)

我們通過對核心鏈路上服務(wù)狀態(tài)的分析，幫助開發(fā)人員定位最終的問題節(jié)點(diǎn)，并建議開發(fā)人員需要觸發(fā)哪些服務(wù)保護(hù)預(yù)案。

業(yè)務(wù)大盤的預(yù)測報警、核心鏈路的紅盤診斷報警以及已經(jīng)收集到各個維度的報警事件，如果能對它們做進(jìn)一步的統(tǒng)計分析，可以幫助開發(fā)人員從更加宏觀的角度提前發(fā)現(xiàn)服務(wù)可能潛在的問題，相當(dāng)于提前對服務(wù)做健康檢查。

我們需要定期通過全鏈路壓測來不斷驗(yàn)證問題診斷和服務(wù)保護(hù)是否有效，在壓測時可以看到各個場景下的服務(wù)健康狀態(tài)，對服務(wù)節(jié)點(diǎn)做到有效的容量規(guī)劃。

業(yè)務(wù)大盤

外賣業(yè)務(wù)會對非常多的業(yè)務(wù)指標(biāo)進(jìn)行監(jiān)控，業(yè)務(wù)指標(biāo)和系統(tǒng)指標(biāo)、服務(wù)指標(biāo)不同，需要業(yè)務(wù)方根據(jù)不同的業(yè)務(wù)自行上報監(jiān)控數(shù)據(jù)。

業(yè)務(wù)大盤作為業(yè)務(wù)運(yùn)維系統(tǒng)的使用入口，可以讓開發(fā)人員快速查看自己關(guān)心的業(yè)務(wù)指標(biāo)的實(shí)時狀態(tài)以及最近幾天的走勢。

圖 7：業(yè)務(wù)監(jiān)控大盤及拓展能力

如圖 7 所示，業(yè)務(wù)大盤不光需要展示業(yè)務(wù)監(jiān)控指標(biāo)，還需要有很強(qiáng)的對外擴(kuò)展能力，比如：

• 當(dāng)出現(xiàn)業(yè)務(wù)指標(biāo)異常時，根據(jù)后臺的監(jiān)控數(shù)據(jù)分析，可以手動或者自動進(jìn)行事件標(biāo)記，告知開發(fā)人員是什么原因引起了業(yè)務(wù)指標(biāo)的波動，做到用戶信息量的快速同步。
• 可以帶著時間戳與類型快速引導(dǎo)開發(fā)人員進(jìn)入其他監(jiān)控系統(tǒng)，提高開發(fā)人排查問題的效率。

我們會定期對生產(chǎn)系統(tǒng)進(jìn)行全鏈路壓測，同時為了壓測數(shù)據(jù)不污染真實(shí)的業(yè)務(wù)數(shù)據(jù)，會對壓測流量監(jiān)控進(jìn)行隔離。

外賣業(yè)務(wù)場景，使我們大多數(shù)業(yè)務(wù)監(jiān)控數(shù)據(jù)都呈現(xiàn)出很強(qiáng)的周期性，針對業(yè)務(wù)數(shù)據(jù)我們可以利用歷史數(shù)據(jù)使用 Holt-Winters 等模型進(jìn)行業(yè)務(wù)數(shù)據(jù)預(yù)測，當(dāng)我們的實(shí)際值與預(yù)測值不在置信區(qū)間內(nèi)將直接進(jìn)行告警。

因?yàn)槭歉悠驑I(yè)務(wù)的運(yùn)維系統(tǒng)，我們針對敏感的業(yè)務(wù)指標(biāo)進(jìn)行了相應(yīng)的權(quán)限管理。

為了增加系統(tǒng)使用場景，我們需要支持移動端，使用戶可以在任何地方通過手機(jī)就可以查看自己關(guān)心的監(jiān)控大盤并觸發(fā)服務(wù)保護(hù)預(yù)案。

核心鏈路

核心鏈路也是系統(tǒng)主要的使用入口，用戶可以通過核心鏈路快速定位是哪一個調(diào)用鏈出現(xiàn)了問題，如圖 8 所示：

圖 8：核心鏈路產(chǎn)品建設(shè)路徑

這里會涉及兩個步驟：

• 我們需要給核心鏈路上的服務(wù)節(jié)點(diǎn)進(jìn)行健康評分，根據(jù)評分模型來界定問題嚴(yán)重的鏈路。
• 這里我們會根據(jù)服務(wù)的各個指標(biāo)來描繪一個服務(wù)的問題畫像，問題畫像中的指標(biāo)也會有權(quán)重劃分，比如：當(dāng)服務(wù)出現(xiàn)了失敗率報警、TP99 報警，大量異常日志則會進(jìn)行高權(quán)重的加分。

當(dāng)我們確認(rèn)完某條鏈路出現(xiàn)了問題，在鏈路上越往后的節(jié)點(diǎn)可能是引起問題的根節(jié)點(diǎn)，我們會實(shí)時獲取該節(jié)點(diǎn)更多相關(guān)監(jiān)控指標(biāo)來進(jìn)行分析診斷。

這里會融合開發(fā)人員日常排查問題的 SOP，最終可能定位到是這個服務(wù)節(jié)點(diǎn)某些服務(wù)器的磁盤或者 CPU 等問題。

我們最終會發(fā)出問題診斷結(jié)果，這個結(jié)果在發(fā)出之后，還需要收集用戶的反饋，判斷診斷結(jié)果是否準(zhǔn)確，為我們后續(xù)優(yōu)化評分定位模型與診斷模型提供有力的數(shù)據(jù)支持。

在核心鏈路建設(shè)前期，我們會建議開發(fā)人員進(jìn)行相應(yīng)的服務(wù)保護(hù)預(yù)案觸發(fā)，當(dāng)我們的診斷結(jié)果足夠準(zhǔn)確之后，可以針對固定問題場景自動化觸發(fā)服務(wù)保護(hù)預(yù)案，以縮短解決問題的時間。

服務(wù)保護(hù)&故障演練

圖 9：服務(wù)保護(hù)&故障演練模塊的核心功能

服務(wù)保護(hù)&故障演練模塊是讓我們的業(yè)務(wù)運(yùn)維體系形成閉環(huán)的重要部分，該模塊需要具備的核心功能如圖 9 所示。

針對不同的保護(hù)需求，我們會有不同類型的服務(wù)保護(hù)開關(guān)，這里主要有如下幾種：

• 降級開關(guān)：由于業(yè)務(wù)快速發(fā)展，在代碼中會有成百上千的降級開關(guān)。在業(yè)務(wù)出現(xiàn)異常時需要手動進(jìn)行降級操作。
• 限流開關(guān)：有些針對特定業(yè)務(wù)場景需要有相應(yīng)的限流保護(hù)措施。比如：針對單機(jī)限流主要是對自身服務(wù)器的資源保護(hù)，針對集群限流主要是針對底層的 DB 或者 Cache 等存儲資源進(jìn)行資源保護(hù)，還有一些其他限流需求都是希望可以在系統(tǒng)出現(xiàn)流量異常時進(jìn)行有效地保護(hù)。
• Hystrix自動熔斷：可以通過監(jiān)控異常數(shù)、線程數(shù)等簡單指標(biāo)，快速保護(hù)我們的服務(wù)健康狀態(tài)不會急劇惡化。

根據(jù)我們的運(yùn)維經(jīng)驗(yàn)，在出現(xiàn)生產(chǎn)事故時可能會涉及到多個開關(guān)的切換，這里就需要針對不同的故障場景預(yù)先設(shè)置服務(wù)保護(hù)預(yù)案，可以在出現(xiàn)問題時通過一鍵操作對多個服務(wù)保護(hù)開關(guān)進(jìn)行預(yù)設(shè)狀態(tài)的變更。

我們既然有了應(yīng)對不同故障場景的服務(wù)保護(hù)預(yù)案，就需要時不時來驗(yàn)證這些服務(wù)保護(hù)預(yù)案是否真的可以起到預(yù)期的效果。

生產(chǎn)對應(yīng)的事故不常有，肯定也不能只指望生產(chǎn)真的出現(xiàn)問題才進(jìn)行預(yù)案的驗(yàn)證，還需要針對不同的故障進(jìn)行模擬。

當(dāng)我們生產(chǎn)服務(wù)出現(xiàn)問題時，不管是因?yàn)榫W(wǎng)絡(luò)原因還是硬件故障，大多數(shù)表現(xiàn)在服務(wù)上的可能原因是服務(wù)超時或者變慢、拋出異常。

我們前期主要針對這幾點(diǎn)做到可以對核心鏈路上任一服務(wù)節(jié)點(diǎn)進(jìn)行故障演練，生產(chǎn)故障可能會同時多個節(jié)點(diǎn)出現(xiàn)故障，這里就需要我們的故障演練也支持預(yù)案管理。

服務(wù)保護(hù)是業(yè)務(wù)運(yùn)維終端措施，我們需要在軟件上可以讓用戶很方便地直達(dá)對應(yīng)的服務(wù)保護(hù)，這里我們需要將服務(wù)保護(hù)與業(yè)務(wù)大盤、核心鏈路進(jìn)行整合，在開發(fā)人員發(fā)現(xiàn)問題時可以方便地進(jìn)入對應(yīng)的服務(wù)保護(hù)預(yù)案。

有了這些保護(hù)措施與故障演練功能，結(jié)合與核心鏈路的關(guān)系，就可以結(jié)合故障診斷與全鏈路壓測進(jìn)行自動化方面的建設(shè)了。

整合全鏈路壓測

我們現(xiàn)在定期會組織外賣全鏈路壓測，每次壓測都會涉及很多人的配合，如果可以針對單一壓測場景進(jìn)行壓測將會大大縮短我們組織壓測的成本。

圖 10：提升全鏈路壓測給我們帶來的收益

如圖 10 所示，我們現(xiàn)在主要在全鏈路壓測的時候，針對壓測流量進(jìn)行不同場景的故障演練，在制造故障的同時，驗(yàn)證服務(wù)保護(hù)預(yù)案是否可以像預(yù)期那樣啟動保護(hù)服務(wù)的目的。

后面會講一下我們針對全鏈路壓測自動化建設(shè)思路。

自動化路程

前面主要介紹了我們在做基于業(yè)務(wù)的運(yùn)維系統(tǒng)時需要的各個核心功能，下面重點(diǎn)介紹一下，我們在整個系統(tǒng)建設(shè)中，自動化方面的建設(shè)主要集中在什么地方。

異常點(diǎn)自動檢測

我們在做核心鏈路建設(shè)的時候，需要收集各個服務(wù)節(jié)點(diǎn)的報警事件，這些報警事件有服務(wù)調(diào)用時端到端的監(jiān)控指標(biāo)，還有服務(wù)自身 SLA 的監(jiān)控指標(biāo)。

在和開發(fā)人員進(jìn)行溝通的時候了解到他們平時配置這些監(jiān)控指標(biāo)的時候耗費(fèi)了大量的人力，每個指標(biāo)的報警閾值都需要反復(fù)調(diào)整才能達(dá)到一個理想狀態(tài)。

基于這些監(jiān)控痛點(diǎn)，我們希望可以通過分析歷史數(shù)據(jù)來自動的檢測出異常點(diǎn)，并自動計算出應(yīng)有的報警閾值并設(shè)置。

圖 11：異常點(diǎn)自動檢測

如圖 11 所示，我們根據(jù)不同監(jiān)控指標(biāo)的特點(diǎn)，選擇不同的基線算法，并計算出其置信區(qū)間，用來幫助我們更加準(zhǔn)確的檢測異常點(diǎn)。

比如我們的業(yè)務(wù)周期性比較強(qiáng)，大多數(shù)監(jiān)控指標(biāo)都是在歷史同期呈現(xiàn)出正態(tài)分布，這個時候可以拿真實(shí)值與均值進(jìn)行比較，其差值在 N 倍標(biāo)準(zhǔn)差之外，則認(rèn)為該真實(shí)值是異常點(diǎn)。

自動觸發(fā)服務(wù)保護(hù)

我們的服務(wù)保護(hù)措施有一部分是通過 Hystrix 進(jìn)行自動熔斷，另外一部分是我們已經(jīng)存在的上千個降級、限流開關(guān)，這部分開關(guān)平時需要開發(fā)人員根據(jù)自己的運(yùn)維經(jīng)驗(yàn)來手動觸發(fā)。

圖 12：異常檢測與服務(wù)保護(hù)聯(lián)動

如圖 12 所示，我們?nèi)绻軌蚋鶕?jù)各種監(jiān)控指標(biāo)準(zhǔn)確的診斷出異常點(diǎn)，并事先將已經(jīng)確定的異常場景與我們的服務(wù)保護(hù)預(yù)案進(jìn)行關(guān)聯(lián)，就可以自動化的進(jìn)行服務(wù)保護(hù)預(yù)案的觸發(fā)。

壓測計劃自動化

我們定期進(jìn)行的外賣全鏈路壓測，需要召集相關(guān)業(yè)務(wù)方進(jìn)行準(zhǔn)備和跟進(jìn)，這其中涉及的數(shù)據(jù)構(gòu)造部分會關(guān)聯(lián)到很多業(yè)務(wù)方的改造、驗(yàn)證、準(zhǔn)備工作。

圖 13：壓測計劃自動化

如圖 13 所示，我們需要通過壓測計劃串聯(lián)整個準(zhǔn)備、驗(yàn)證過程，盡量少的有人為活動參與到整個過程中。

我們需要進(jìn)行如下工作的準(zhǔn)備：

• 針對真實(shí)流量的改造，基礎(chǔ)數(shù)據(jù)構(gòu)造、數(shù)據(jù)脫敏、數(shù)據(jù)校驗(yàn)等盡可能通過任務(wù)提前進(jìn)行。
• 進(jìn)入到流量回放階段，我們可以針對典型的故障場景進(jìn)行故障預(yù)案的觸發(fā)（比如：Tair 故障等）。
• 在故障演練的同時，我們可以結(jié)合核心鏈路的關(guān)系數(shù)據(jù)準(zhǔn)確定位出與故障場景強(qiáng)相關(guān)的問題節(jié)點(diǎn)。
• 結(jié)合我們針對典型故障場景事先建立的服務(wù)保護(hù)關(guān)系，自動觸發(fā)對應(yīng)的服務(wù)保護(hù)預(yù)案。
• 在整個流程中，我們需要最終確認(rèn)各個環(huán)境的運(yùn)行效果是否達(dá)到了我們的預(yù)期，就需要每個環(huán)節(jié)都有相應(yīng)的監(jiān)控日志輸出，最終自動化產(chǎn)出最終的壓測報告。

整個壓測計劃的自動化進(jìn)程中，將逐漸減少系統(tǒng)運(yùn)行中人為參與的部分，逐步提升全鏈路壓測效率。

我們希望，用戶點(diǎn)擊一個開關(guān)開始壓測計劃，然后等待壓測結(jié)果就可以了。

結(jié)語

在整個業(yè)務(wù)運(yùn)維系統(tǒng)建設(shè)中，只有更加準(zhǔn)確定位問題根節(jié)點(diǎn)，診斷出問題根本原因才能逐步自動化去做一些運(yùn)維動作（比如：觸發(fā)降級開關(guān)，擴(kuò)容集群等）。

圖 14：自動化建設(shè)后期發(fā)力點(diǎn)

如圖 14 所示，我們會在這些環(huán)節(jié)的精細(xì)化建設(shè)上進(jìn)行持續(xù)投入，希望檢測到任意維度的異常點(diǎn)，向上推測出可能會影響哪些業(yè)務(wù)指標(biāo)，影響哪些用戶體驗(yàn)；向下依托于全鏈路壓測可以非常準(zhǔn)確的進(jìn)行容量規(guī)劃，節(jié)省資源。

作者：劉宏偉

簡介：2016 年加入美團(tuán)點(diǎn)評，主要負(fù)責(zé)外賣業(yè)務(wù)架構(gòu)相關(guān)工作，現(xiàn)正在圍繞業(yè)務(wù)建設(shè)監(jiān)控運(yùn)維體系。