美團外賣業務在互聯網行業是十分奇特的，除了流程復雜——從用戶下單、商家接單到配送員接單、交付，但是壓力和流量在午、晚高峰時段特別集中。同時，外賣業務的下降特別迅猛，自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業務監控盤面及拓展能力
如圖7所示，業務盤面不光須要展示業務監控指標，還須要有很強的對外擴充能力，例如：
①當出現業務指標異常時，按照后臺的監控數據剖析，可以自動或則手動進行風波標記，告知開發人員是哪些緣由造成了業務指標的波動，做到用戶信息量的快速同步。
②可以帶著時間戳與類型快速引導開發人員步入其它監控系統，提升開發人排查問題的效率。
我們會定期對生產系統進行全鏈路壓測，同時為了壓測數據不污染真實的業務數據，會對壓測流量監控進行隔離。
外賣業務場景，使我們大多數業務監控數據都呈現出很強的周期性，針對業務數據我們可以借助歷史數據使用Holt-等模型進行業務數據預測，當我們的實際值與預測值不在置信區間內將直接進行告警。
由于是愈發偏向業務的運維系統，我們針對敏感的業務指標進行了相應的權限管理。
為了降低系統使用場景，我們須要支持聯通端，使用戶可以在任何地方通過手機就可以查看自己關心的監控盤面并觸發服務保護預案。
核心鏈路
核心鏈路也是系統主要的使用入口，用戶可以通過核心鏈路快速定位是哪一個調用鏈出現了問題。如圖8所示，這兒會涉及兩個步驟：
①我們須要給核心鏈路上的服務節點進行健康評分，按照評分模型來劃分問題嚴重的鏈路。這兒我們會依照服務的各個指標來勾勒一個服務的問題畫像，問題畫像中的指標也會有權重界定，例如：當服務出現了失敗率報案、TP99報案，大量異常日志則會進列寬權重的加分。
②當我們確認完某條鏈路出現了問題外賣軟件開發，在鏈路上越往前的節點可能是造成問題的根節點，我們會實時獲取該節點更多相關監控指標來進行剖析確診，這兒會融合開發人員日常排查問題的SOP，最終可能定位到是這個服務節點個別服務器的c盤或則CPU等問題。
圖8核心鏈路產品建設路徑
我們最終會發出問題確診結果，這個結果在發出以后，還須要搜集用戶的反饋，判定確診結果是否確切，為我們后續優化評分定位模型與確診模型提供有力的數據支持。在核心鏈路建設前期，我們會建議開發人員進行相應的服務保護預案觸發，當我們的確診結果足夠確切以后，可以針對固定問題場景手動化觸發服務保護預案，以減短解決問題的時間。
服務保護&故障演習
圖9服務保護&故障演習模塊的核心功能
服務保護&故障演習模塊是讓我們的業務運維體系產生閉環的重要部份，該模塊須要具備的核心功能如圖9所示。針對不同的保護需求，我們會有不同類型的服務保護開關，這兒主要有如下幾種：
①降級開關：因為業務快速發展，在代碼中會有成百上千的降級開關。在業務出現異常時須要自動進行降級操作。
②限流開關：有些針對特定業務場景須要有相應的限流保護舉措。諸如：針對單機限流主要是對自身服務器的資源保護，針對集群限流主要是針對底層的DB或則Cache等儲存資源進行資源保護外賣軟件開發，還有一些其他限流需求都是希望可以在系統出現流量異常時有效地進行保護。
③自動熔斷：可以通過監控異常數、線程數等簡單指標，快速保護我們的服務健康狀態不會隨之惡化。
按照我們的運維經驗，在出現生產車禍時可能會涉及到多個開關的切換，這兒就須要針對不同的故障場景預先設置服務保護預案，可以在出現問題時通過一鍵操作對多個服務保護開關進行預設狀態的變更。我們既然有了應對不同故障場景的服務保護預案，就須要時常來驗證這種服務保護預案是否真的可以起到預期的療效。
生產對應的車禍不常有，肯定也不能只指望生產真的出現問題才進行預案的驗證，還須要針對不同的故障進行模擬。當我們生產服務出現問題時，不管是由于網路緣由還是硬件故障，大多數表現在服務上的可能是服務超時或則變慢、拋出異常。我們前期主要針對這幾點做到可以對核心鏈路上任一服務節點進行故障演習，生產故障可能會同時多個節點出現故障，這兒就須要我們的故障演習也須要支持預案管理。
服務保護是業務運維終端舉措，我們須要在軟件上可以讓用戶很便捷地直達對應的服務保護，這兒我們可以很容易就將服務保護與業務盤面、核心鏈路進行整合，在開發人員發覺問題時可以便捷地步入對應的服務保護預案。有了這種保護舉措與故障演習功能，結合與核心鏈路的關系，就可以與故障確診與全鏈路壓測進行手動化方面的建設了。
整合全鏈路壓測
我們如今定期會組織外賣全鏈路壓測，每次壓測就會涉及好多人的配合，假如可以針對單一壓測場景進行壓測將會大大減短我們組織壓測的成本。如圖10所示，我們如今主要在全鏈路壓測的時侯，針對壓測流量進行不同場景的故障演習，在制造故障的同時，驗證服務保護預案是否可以像預期那樣啟動保護服務的目的。前面會講一下我們針對全鏈路壓測手動化建設思路。
圖10提高全鏈路壓測給我們帶來的利潤
后面主要介紹了我們在做基于業務的運維系統時須要的各個核心功能，下邊重點介紹一下，我們在整個系統建設中，手動化方面的建設主要集中在哪些地方。
異常點手動檢查
圖11異常點手動檢查
我們在做核心鏈路建設的時侯，須要搜集各個服務節點的報案風波，這種報案風波有服務調用時端到端的監控指標，還有服務自身SLA的監控指標。在和開發人員進行溝通的時侯了解到她們平常配置這種監控指標的時侯花費了大量的人力，每位指標的報案閥值都須要反復調整就能達到一個理想狀態，基于這種監控痛點，我們希望可以通過剖析歷史數據來手動的測量出異常點，并手動估算出應有的報案閥值并設置。如圖11所示，我們依照不同監控指標的特性，選擇不同的基線算法，并估算出其置信區間，拿來幫助我們愈發確切的檢查異常點。例如我們的業務周期性比較強，大多數監控指標都是在歷史同期呈現出正太分布，這個時侯可以拿真實值與均值進行比較，其差值在N倍標準差之外，則覺得該真實值是異常點。
手動觸發服務保護
圖12異常測量與服務保護聯動
我們的服務保護舉措有一部份是通過進行手動熔斷，另外一部份是我們早已存在的上千個降級、限流開關，這部份開關平常須要開發人員按照自己的運維經驗來自動觸發。我們假如才能依據各類監控指標確切的確診出異常點，并事先將早已確定的異常場景與我們的服務保護預案進行關聯，就可以手動化的進行服務保護預案的觸發，如圖12所示。
壓測計劃手動化
圖13壓測計劃手動化
我們定期進行的外賣全鏈路壓測，須要召集相關業務方進行打算和跟進，這其中涉及的數據構造部份會關聯到好多業務方的整修、驗證、準備工作。如圖13所示，我們須要通缺相測計劃串聯整個打算、驗證過程，盡量少的有人為活動參與到整個過程中。這其中我們須要進行如下工作的打算：
整個壓測計劃的手動化進程中，將逐步降低系統運行中人為參與的部份，逐漸提高全鏈路壓測效率。我們希望，用戶點擊一個開關開始壓測計劃，之后等待壓測結果就可以了。
圖14手動化建設后期加碼點
在整個業務運維系統建設中，只有愈發確切定位問題根節點，確診出問題根本誘因能夠逐漸手動化去做一些運維動作（例如：觸發降級開關，擴容集群等）。如圖14所示，我們會在這種環節的精細化建設上進行持續投入，希望檢查到任意維度的異常點，向下猜想出可能會影響什么業務指標，影響什么用戶體驗；向上依托于全鏈路壓測可以十分確切的進行容量規劃，節約資源。
劉宏偉，2016年加入美團，主要負責外賣業務構架相關工作，現正在圍繞業務建設監控運維體系。
**美團外賣C端業務構架組：基于業務、服務、數據，進行深度整合、統一構架、規范，為外賣提供統一基礎服務，搜集各業務線監控數據，進行實時剖析統計。我們正在努力將開發人員從日常運維工作中徹底解放下來，構建高效的業務運維平臺。我們十分歡迎有業務運維經驗，熟悉異常檢查算法，對業務監控運維產品有深刻理解的同仁加入我們，共同提高美團外賣服務穩定性。
聯系郵箱：#**
免責聲明：部分文章信息來源于網絡以及網友投稿，本站只負責對文章進行整理、排版、編輯，出于傳遞更多信息之目的，并不意味著贊同其觀點或證實其內容的真實性，如本站文章和轉稿涉及版權等問題，請作者在及時聯系本站，我們會盡快為您處理。
