背景

美團外賣業務在網際網路行業是非常獨特的，不僅流程複雜——從使用者下單、商家接單到配送員接單、交付，而且壓力和流量在午、晚高峰時段非常集中。同時，外賣業務的增長非常迅猛，自2013年11月上線到最近峰值突破1600萬，還不到4年。在這種情況下，一旦出現事故，單純靠人工排查解決問題，存在較多的侷限性。本文將詳細解析問題發現、根因分析、問題解決等自動化運維體系的建設歷程與相關設計原則。

外賣業務特點

圖1 使用者角度的美團外賣技術體系

美團外賣的定位是“圍繞線上商品交易與及時送達的O2O電商交易平臺”。圖1就是使用者在使用美團外賣App過程中涉及到的技術模組，歷經使用者下單–>系統發給商家–>商家準備外賣–>配送，到最後使用者收到商品比如熱乎乎的盒飯，整個過程的時間需要控制在半小時之內。在這背後，整個產品線上還會涉及很多資料分析、統計、結算、合同等各個端的互動，因此，對一致性的要求高，同時併發量也很高。

每日流量徒增明顯

圖2 美團外賣常規業務監控圖

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

業務增長迅猛

圖3 美團外賣重要成長里程碑

美團外賣自2013年上線至2017年10月份，在不到4年的時間裡，日提單已達2000萬，日完成訂單突破1600萬，如圖3所示。這期間，業務產品一直處在高速迭代的過程中，某些資料訪問的服務量會達到日均120億+次，QPS近40萬。現在如果在午高峰出現一個小小的事故，就會造成比較大的損失。

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

需要解決問題

圖4 開發人員日常監控痛點

我們在日常的業務運維工作中經常會碰到一些問題困擾著開發人員，如圖4所示，主要有四大痛點：

① 各種維度的事件通知、報警事件充斥著開發人員的IM，我們需要花很多精力去配置和優化報警閾值、報警等級才不會出現很多誤報。我們希望可以將各種服務的報警指標和閾值標準化、自動化，然後自動收集這些事件進行統計。一方面可以幫助開發人員提前發現問題潛在的風險，另一方面為我們找出問題的根本原因提供有力的資料支援。

② 公司有多套監控系統，它們有各自的職責定位，但是互相沒有關聯，所以開發人員在排查問題時需要帶著引數在不同的系統之間切換，這就降低了定位問題的效率。

③ 我們的程式碼中會有大量的降級限流開關，在服務異常時進行相應的保護操作。這些開關隨著產品快速地迭代，我們並不能確定它們是否還有效。另外，我們需要較準確地進行容量規劃以應對快速增長的業務量。這些都需要通過全鏈路壓測幫我們不斷地驗證，並發現效能瓶頸，有效地評估服務容量。

④ 開發人員收到各種報警之後，通常都會根據自己的經驗進行問題的排查，這些排查經驗完全可以標準化（比如對某個服務的TP99異常，需要進行的排查操作），問題排查流程標準化之後，就可以通過計算機自動化。我們提高診斷的準確度，就需要將這個流程更加智慧化，減少人為參與。

核心目標

我們希望通過一些自動化措施提升運維效率，從而將開發人員從日常的業務運維工作中解放出來，先來看一個使用者使用場景：

如圖5所示，觸發服務保護有兩條路徑。

① 第一條，當用戶在前期接收到我們的診斷報警後，直接被引導進入該報警可能會影響到業務大盤。這時我們要檢視業務圖表，如果影響到業務，引導使用者直接進入該業務圖表對應的核心鏈路，定位出問題的根本原因，進而再判斷是否要觸發該核心鏈路上對應的服務保護開關或預案。

圖5 自動化業務運維繫統核心建設目標

② 第二條，使用者也可以直接通過診斷報警進入對應的核心鏈路，檢視最終引起異常的根本原因，引導使用者判斷是否需要觸發相應的服務保護預案。

發現問題–>診斷問題–>解決問題，這個過程每一步都需要不斷地提升準確度，整個流程需要通過全鏈路壓測不斷驗證，當某些場景準確度非常高的時候，就可以變為自動化方案。

因此，我們的核心目標是，當整個方案可以自動化進行下去之後，對於使用者來說的使用場景就變成了：收到異常報警->收到業務服務恢復通知。隨著自動化方案越來越完備，開發人員可以更加關注業務邏輯的開發。

重點系統體系建設

及各個產品模組之間的關聯，其它設計細節與我們碰到的坑，本文不著重描述了，之後會有更加針對性的文章分享出來。

體系架構

如圖6所示，在自動化業務運維繫統中，業務大盤與核心鏈路作為使用者使用的入口，一旦使用者檢視業務指標出現問題，我們就需要快速定位該業務指標異常的根本原因。我們通過對核心鏈路上服務狀態的分析，幫助開發人員定位最終的問題節點，並建議開發人員需要觸發哪些服務保護預案。業務大盤的預測報警、核心鏈路的紅盤診斷報警以及已經收集到各個維度的報警事件，如果能對它們做進一步的統計分析，可以幫助開發人員從更加巨集觀的角度提前發現服務可能潛在問題，相當於提前對服務做健康檢查。我們需要定期通過全鏈路壓測來不斷驗證問題診斷和服務保護是否有效，在壓測時可以看到各個場景下的服務健康狀態，對服務節點做到有效的容量規劃。

圖6 業務監控運維體系架構

業務大盤

外賣業務會有非常多的業務指標進行監控，業務指標和系統指標、服務指標不同，需要業務方根據不同的業務自行上報監控資料。業務大盤作為業務運維繫統的使用入口，可以讓開發人員快速檢視自己關心的業務指標的實時狀態以及最近幾天的走勢。

圖7 業務監控大盤及拓展能力

① 當出現業務指標異常時，根據後臺的監控資料分析，可以手動或者自動進行事件標記，告知開發人員是什麼原因引起了業務指標的波動，做到使用者資訊量的快速同步。

② 可以帶著時間戳與型別快速引導開發人員進入其它監控系統，提高開發人排查問題的效率。

我們會定期對生產系統進行全鏈路壓測，同時為了壓測資料不汙染真實的業務資料，會對壓測流量監控進行隔離。

外賣業務場景，使我們大多數業務監控資料都呈現出很強的週期性，針對業務資料我們可以利用歷史資料使用Holt-Winters等模型進行業務資料預測，當我們的實際值與預測值不在置信區間內將直接進行告警。

因為是更加偏向業務的運維繫統，我們針對敏感的業務指標進行了相應的許可權管理。

為了增加系統使用場景，我們需要支援移動端，使使用者可以在任何地方通過手機就可以檢視自己關心的監控大盤並觸發服務保護預案。

核心鏈路

核心鏈路也是系統主要的使用入口，使用者可以通過核心鏈路快速定位是哪一個呼叫鏈出現了問題。如圖8所示，這裡會涉及兩個步驟：

① 我們需要給核心鏈路上的服務節點進行健康評分，根據評分模型來界定問題嚴重的鏈路。這裡我們會根據服務的各個指標來描繪一個服務的問題畫像，問題畫像中的指標也會有權重劃分，比如：當服務出現了失敗率報警、TP99報警，大量異常日誌則會進行高權重的加分。

② 當我們確認完某條鏈路出現了問題，在鏈路上越往後的節點可能是引起問題的根節點，我們會實時獲取該節點更多相關監控指標來進行分析診斷，這裡會融合開發人員日常排查問題的SOP，最終可能定位到是這個服務節點某些伺服器的磁碟或者CPU等問題。

圖8 核心鏈路產品建設路徑

我們最終會發出問題診斷結果，這個結果在發出之後，還需要收集使用者的反饋，判斷診斷結果是否準確，為我們後續優化評分定位模型與診斷模型提供有力的資料支援。在核心鏈路建設前期，我們會建議開發人員進行相應的服務保護預案觸發，當我們的診斷結果足夠準確之後，可以針對固定問題場景自動化觸發服務保護預案，以縮短解決問題的時間。

服務保護&故障演練

圖9 服務保護&故障演練模組的核心功能

服務保護&故障演練模組是讓我們的業務運維體系形成閉環的重要部分，該模組需要具備的核心功能如圖9所示。針對不同的保護需求，我們會有不同型別的服務保護開關，這裡主要有如下幾種：

① 降級開關：由於業務快速發展，在程式碼中會有成百上千的降級開關。在業務出現異常時需要手動進行降級操作。

② 限流開關：有些針對特定業務場景需要有相應的限流保護措施。比如：針對單機限流主要是對自身伺服器的資源保護，針對叢集限流主要是針對底層的DB或者Cache等儲存資源進行資源保護，還有一些其他限流需求都是希望可以在系統出現流量異常時有效地進行保護。

③ Hystrix自動熔斷：可以通過監控異常數、執行緒數等簡單指標，快速保護我們的服務健康狀態不會急劇惡化。

根據我們的運維經驗，在出現生產事故時可能會涉及到多個開關的切換，這裡就需要針對不同的故障場景預先設定服務保護預案，可以在出現問題時通過一鍵操作對多個服務保護開關進行預設狀態的變更。我們既然有了應對不同故障場景的服務保護預案，就需要時不時來驗證這些服務保護預案是否真的可以起到預期的效果。

生產對應的事故不常有，肯定也不能只指望生產真的出現問題才進行預案的驗證，還需要針對不同的故障進行模擬。當我們生產服務出現問題時，不管是因為網路原因還是硬體故障，大多數表現在服務上的可能是服務超時或者變慢、丟擲異常。我們前期主要針對這幾點做到可以對核心鏈路上任一服務節點進行故障演練，生產故障可能會同時多個節點出現故障，這裡就需要我們的故障演練也需要支援預案管理。

服務保護是業務運維終端措施，我們需要在軟體上可以讓使用者很方便地直達對應的服務保護，這裡我們需要將服務保護與業務大盤、核心鏈路進行整合，在開發人員發現問題時可以方便地進入對應的服務保護預案。有了這些保護措施與故障演練功能，結合與核心鏈路的關係，就可以結合故障診斷與全鏈路壓測進行自動化方面的建設了。

整合全鏈路壓測

我們現在定期會組織外賣全鏈路壓測，每次壓測都會涉及很多人的配合，如果可以針對單一壓測場景進行壓測將會大大縮短我們組織壓測的成本。如圖10所示，我們現在主要在全鏈路壓測的時候，針對壓測流量進行不同場景的故障演練，在製造故障的同時，驗證服務保護預案是否可以像預期那樣啟動保護服務的目的。後面會講一下我們針對全鏈路壓測自動化建設思路。

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

自動化路程

前面主要介紹了我們在做基於業務的運維繫統時需要的各個核心功能，下面重點介紹一下，我們在整個系統建設中，自動化方面的建設主要集中在什麼地方。

異常點自動檢測

圖11 異常點自動檢測

我們在做核心鏈路建設的時候，需要收集各個服務節點的報警事件，這些報警事件有服務呼叫時端到端的監控指標，還有服務自身SLA的監控指標。在和開發人員進行溝通的時候瞭解到他們平時配置這些監控指標的時候耗費了大量的人力，每個指標的報警閾值都需要反覆調整才能達到一個理想狀態，基於這些監控痛點，我們希望可以通過分析歷史資料來自動的檢測出異常點，並自動計算出應有的報警閾值並設定。如圖11所示，我們根據不同監控指標的特點，選擇不同的基線演算法，並計算出其置信區間，用來幫助我們更加準確的檢測異常點。比如我們的業務週期性比較強，大多數監控指標都是在歷史同期呈現出正太分佈，這個時候可以拿真實值與均值進行比較，其差值在N倍標準差之外，則認為該真實值是異常點。

自動觸發服務保護

圖12 異常檢測與服務保護聯動

我們的服務保護措施有一部分是通過Hystrix進行自動熔斷，另外一部分是我們已經存在的上千個降級、限流開關，這部分開關平時需要開發人員根據自己的運維經驗來手動觸發。我們如果能夠根據各種監控指標準確的診斷出異常點，並事先將已經確定的異常場景與我們的服務保護預案進行關聯，就可以自動化的進行服務保護預案的觸發，如圖12所示。

壓測計劃自動化

圖13 壓測計劃自動化

我們定期進行的外賣全鏈路壓測，需要召集相關業務方進行準備和跟進，這其中涉及的資料構造部分會關聯到很多業務方的改造、驗證、準備工作。如圖13所示，我們需要通過壓測計劃串聯整個準備、驗證過程，儘量少的有人為活動參與到整個過程中。這其中我們需要進行如下工作的準備：

• 針對真實流量的改造，基礎資料構造、資料脫敏、資料校驗等儘可能通過任務提前進行。
• 進入到流量回放階段，我們可以針對典型的故障場景進行故障預案的觸發（比如：Tair故障等）。
• 在故障演練的同時，我們可以結合核心鏈路的關係資料準確定位出與故障場景強相關的問題節點。
• 結合我們針對典型故障場景事先建立的服務保護關係，自動觸發對應的服務保護預案。
• 在整個流程中，我們需要最終確認各個環境的執行效果是否達到了我們的預期，就需要每個環節都有相應的監控日誌輸出，最終自動化產出最終的壓測報告。

整個壓測計劃的自動化程序中，將逐漸減少系統執行中人為參與的部分，逐步提升全鏈路壓測效率。我們希望，使用者點選一個開關開始壓測計劃，然後等待壓測結果就可以了。

結語

圖14 自動化建設後期發力點

在整個業務運維繫統建設中，只有更加準確定位問題根節點，診斷出問題根本原因才能逐步自動化去做一些運維動作（比如：觸發降級開關，擴容叢集等）。如圖14所示，我們會在這些環節的精細化建設上進行持續投入，希望檢測到任意維度的異常點，向上推測出可能會影響哪些業務指標，影響哪些使用者體驗；向下依託於全鏈路壓測可以非常準確的進行容量規劃，節省資源。

作者介紹

劉巨集偉，2016年加入美團點評，主要負責外賣業務架構相關工作，現正在圍繞業務建設監控運維體系。