劉宏偉

美團北京102208

引言

美團外賣業(yè)務(wù)在互聯(lián)網(wǎng)行業(yè)是非常獨特的，其定位是“圍繞在線商品交易與及時送達的O2O電商交易平臺”。不僅流程復(fù)雜，歷經(jīng)用戶下單→系統(tǒng)發(fā)給商家→商家準備外賣→配送，到最后用戶收到商品(比如熱乎乎的盒飯)，整個過程的時間需要控制在半小時之內(nèi)，而且壓力和流量在午、晚高峰時段非常集中。在這背后，整個產(chǎn)品線上還會涉及很多數(shù)據(jù)分析、統(tǒng)計、結(jié)算、合同等各個端的交互，對一致性的要求高。同時，外賣業(yè)務(wù)的增長非常迅猛，自2013年11月上線到最近峰值突破1 600萬，還不到4年。在這種情況下，一旦出現(xiàn)事故，單純靠人工排查解決問題，存在較多的局限性。為了提升效率需要盡可能自動化，而自動化的前提需要有足夠準確的檢測與診斷結(jié)果，檢測與診斷結(jié)果又需要有貼近真實業(yè)務(wù)場景的工具不斷驗證。

1 需要解決的問題

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

1)各種維度的事件通知、報警事件充斥著開發(fā)人員的IM，需要花很多精力去配置和優(yōu)化報警閾值、報警等級才不會出現(xiàn)很多誤報。希望可以將各種服務(wù)的報警指標和閾值標準化、自動化，然后自動收集這些事件進行統(tǒng)計。一方面可以幫助開發(fā)人員提前發(fā)現(xiàn)問題潛在的風(fēng)險，另一方面為能夠找出問題的根本原因提供有力的數(shù)據(jù)支持。

2)公司有多套監(jiān)控系統(tǒng)，它們有各自的職責(zé)定位，但是互相沒有關(guān)聯(lián)，所以開發(fā)人員在排查問題時需要帶著參數(shù)在不同的系統(tǒng)之間切換，這就降低了定位的效率。

3)項目代碼中會有大量的降級限流開關(guān)，在服務(wù)異常時進行相應(yīng)的保護操作。這些開關(guān)隨著產(chǎn)品快速地迭代，并不能確定它們是否還有效。另外，需要較準確地進行容量規(guī)劃以應(yīng)對快速增長的業(yè)務(wù)量。這些都需要通過全鏈路壓測進行不斷地驗證，并發(fā)現(xiàn)性能瓶頸，有效地評估服務(wù)容量。

4)開發(fā)人員收到各種報警之后，通常都會根據(jù)自己的經(jīng)驗進行問題的排查，這些排查經(jīng)驗完全可以標準化(比如對某個服務(wù)的平均耗時異常，需要進行的排查操作)，問題排查流程標準化之后，就可以通過計算機自動化。為了提高診斷的準確度，就需要將這個流程更加智能化，減少人為參與。

2 核心目標

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

圖2 自動化業(yè)務(wù)運維系統(tǒng)核心建設(shè)目標

1)第一條，當用戶在前期接收到診斷報警后，直接被引導(dǎo)進入該報警可能會影響到業(yè)務(wù)大盤。這時要查看業(yè)務(wù)圖表，如果影響到業(yè)務(wù)，引導(dǎo)用戶直接進入該業(yè)務(wù)圖表對應(yīng)的核心鏈路，定位出問題的根本原因，進而再判斷是否要觸發(fā)該核心鏈路上對應(yīng)的服務(wù)保護開關(guān)或預(yù)案。

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

發(fā)現(xiàn)問題→診斷問題→解決問題，這個過程每一步都需要不斷地提升準確度，具體數(shù)據(jù)可以通過全鏈路壓測來獲得，當某些場景準確度非常高的時候，就可以變?yōu)樽詣踊桨?；因此，核心目標是，當整個方案可以自動化進行下去之后，對于用戶來說的使用場景就變成了：收到異常報警→收到業(yè)務(wù)服務(wù)恢復(fù)通知。隨著自動化方案越來越完備，開發(fā)人員可以更加關(guān)注業(yè)務(wù)邏輯的開發(fā)。

3 重點系統(tǒng)體系建設(shè)

3.1 體系架構(gòu)

如圖3所示，在自動化業(yè)務(wù)運維系統(tǒng)中，業(yè)務(wù)大盤與核心鏈路作為用戶使用的入口，一旦用戶查看業(yè)務(wù)指標出現(xiàn)問題，就需要快速定位該業(yè)務(wù)指標異常的根本原因。系統(tǒng)通過對核心鏈路上服務(wù)狀態(tài)的分析，幫助開發(fā)人員定位最終的問題節(jié)點，并建議開發(fā)人員需要觸發(fā)哪些服務(wù)保護預(yù)案。業(yè)務(wù)大盤的預(yù)測報警、核心鏈路的紅盤診斷報警以及已經(jīng)收集到各個維度的報警事件，如果能對它們做進一步的統(tǒng)計分析，可以幫助開發(fā)人員從更加宏觀的角度提前發(fā)現(xiàn)服務(wù)可能存在的問題，相當于提前對服務(wù)做健康檢查。開發(fā)人員需要定期通過全鏈路壓測來不斷驗證問題診斷和服務(wù)保護是否有效，在壓測時可以看到各個場景下的服務(wù)健康狀態(tài)，對服務(wù)節(jié)點做到有效的容量規(guī)劃。

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

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

外賣業(yè)務(wù)會有非常多的業(yè)務(wù)指標進行監(jiān)控，業(yè)務(wù)指標和系統(tǒng)指標、服務(wù)指標不同，需要業(yè)務(wù)方根據(jù)不同的業(yè)務(wù)自行上報監(jiān)控數(shù)據(jù)[1]。業(yè)務(wù)大盤作為業(yè)務(wù)運維系統(tǒng)的使用入口，可以讓開發(fā)人員快速查看自己關(guān)心的業(yè)務(wù)指標的實時狀態(tài)以及最近幾天的走勢。

如圖4所示，業(yè)務(wù)大盤不光需要展示業(yè)務(wù)監(jiān)控指標，還需要有很強的對外擴展能力。

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

1)當出現(xiàn)業(yè)務(wù)指標異常時，根據(jù)后臺的監(jiān)控數(shù)據(jù)分析，可以手動或自動進行事件標記，告知開發(fā)人員是什么原因引起業(yè)務(wù)指標的波動，做到用戶信息快速同步。

2)可以帶著時間戳與類型快速引導(dǎo)開發(fā)人員進入其它監(jiān)控系統(tǒng)，提高開發(fā)人排查問題的效率。該系統(tǒng)會定期進行全鏈路壓測，同時為了壓測數(shù)據(jù)不污染真實的業(yè)務(wù)數(shù)據(jù)，會對壓測流量監(jiān)控進行隔離。外賣業(yè)務(wù)場景使大多數(shù)業(yè)務(wù)監(jiān)控數(shù)據(jù)都呈現(xiàn)出很強的周期性，針對業(yè)務(wù)數(shù)據(jù)可以利用歷史數(shù)據(jù)使用Holt-Winters等模型進行業(yè)務(wù)數(shù)據(jù)預(yù)測，當實際值與預(yù)測值不在置信區(qū)間內(nèi)將直接進行告警。因為是更加偏向業(yè)務(wù)的運維系統(tǒng)，項目針對敏感的業(yè)務(wù)指標進行了相應(yīng)的權(quán)限管理。為了增加系統(tǒng)使用場景，需要支持移動端，使用戶可以在任何地方通過手機就可以查看自己關(guān)心的監(jiān)控大盤并觸發(fā)服務(wù)保護預(yù)案。

3.3 核心鏈路

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

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

1)需要給核心鏈路上的服務(wù)節(jié)點進行健康評分，根據(jù)評分模型來界定問題嚴重的鏈路。這里會根據(jù)服務(wù)的各個指標來描繪一個服務(wù)的問題畫像，問題畫像中的指標也會有權(quán)重劃分[2]，比如：當服務(wù)出現(xiàn)了失敗率報警、平均耗時報警、大量異常日志報警則會進行高權(quán)重的加分。

2)當確認完某條鏈路出現(xiàn)了問題，在鏈路上越往后的節(jié)點越可能是引起問題的根節(jié)點，系統(tǒng)會實時獲取該節(jié)點更多相關(guān)監(jiān)控指標來進行分析診斷，這里會融合開發(fā)人員日常排查問題的標準流程，最終可能定位到是這個服務(wù)節(jié)點某些服務(wù)器的磁盤或者CPU等問題。

系統(tǒng)最終會發(fā)出問題診斷結(jié)果，這個結(jié)果在發(fā)出之后，還需要收集用戶的反饋，判斷診斷結(jié)果是否準確，為后續(xù)優(yōu)化評分定位模型與診斷模型提供有力的數(shù)據(jù)支持[3]。在核心鏈路建設(shè)前期，系統(tǒng)會建議開發(fā)人員進行相應(yīng)的服務(wù)保護預(yù)案觸發(fā)，當診斷結(jié)果足夠準確之后，可以針對固定問題場景自動化觸發(fā)服務(wù)保護預(yù)案，以縮短解決問題的時間。

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

服務(wù)保護&故障演練模塊是讓該業(yè)務(wù)運維體系形成閉環(huán)的重要部分，該模塊需要具備的核心功能如圖6所示。針對不同的保護需求，會有不同類型的服務(wù)保護開關(guān)，這里主要有如下3種。

1)降級開關(guān)。由于業(yè)務(wù)快速發(fā)展，在代碼中會有成百上千的降級開關(guān)。在業(yè)務(wù)出現(xiàn)異常時需要手動進行降級操作。

2)限流開關(guān)。有些特定業(yè)務(wù)場景需要有相應(yīng)的限流保護措施。比如針對單機限流主要是對自身服務(wù)器的資源保護，針對集群限流主要是針對底層的DB或者Cache等存儲資源進行資源保護，還有一些其他限流需求都是希望可以在系統(tǒng)出現(xiàn)流量異常時有效地進行保護。

3)服務(wù)自動熔斷?？梢酝ㄟ^監(jiān)控異常數(shù)、線程數(shù)等簡單指標，快速保護服務(wù)健康狀態(tài)不會急劇惡化。

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

生產(chǎn)對應(yīng)的事故不常有，肯定也不能只指望生產(chǎn)真的出現(xiàn)問題才進行預(yù)案的驗證，還需要針對不同的故障進行模擬。當生產(chǎn)服務(wù)出現(xiàn)問題時，不管是因為網(wǎng)絡(luò)原因還是硬件故障，大多數(shù)表現(xiàn)在服務(wù)上的可能是服務(wù)超時或者變慢、拋出異常。針對這幾點，做到可以對核心鏈路上任一服務(wù)節(jié)點進行故障演練，生產(chǎn)故障可能會同時多個節(jié)點出現(xiàn)故障，所以需要故障演練也支持預(yù)案管理。

服務(wù)保護是業(yè)務(wù)運維終端措施，需要在軟件上可以讓用戶很方便地直達對應(yīng)的服務(wù)保護，可以很容易地將服務(wù)保護與業(yè)務(wù)大盤、核心鏈路進行整合，在開發(fā)人員發(fā)現(xiàn)問題時可以方便地進入對應(yīng)的服務(wù)保護預(yù)案。有了這些保護措施與故障演練功能，結(jié)合與核心鏈路的關(guān)系，就可以與故障診斷與全鏈路壓測進行自動化方面的建設(shè)了。

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

3.5 整合全鏈路壓測

目前，對外賣全鏈路的定期壓測每次都會涉及很多人的配合，如果可以針對單一壓測場景進行壓測將會大大縮短組織壓測的成本。如圖7所示，在全鏈路壓測的時候，針對壓測流量進行不同場景的故障演練，在制造故障的同時，驗證服務(wù)保護預(yù)案是否可以像預(yù)期那樣啟動以達到保護服務(wù)的目的。

圖7 全鏈路壓測帶來的收益

4 自動化路程

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

4.1 異常點自動檢測

進行核心鏈路建設(shè)的時候，需要收集各個服務(wù)節(jié)點的報警事件，這些報警事件有服務(wù)調(diào)用時端到端的監(jiān)控指標，還有服務(wù)自身SLA的監(jiān)控指標。通過跟開發(fā)人員進行溝通了解到他們平時配置這些監(jiān)控指標的時候耗費了大量的人力，每個指標的報警閾值都需要反復(fù)調(diào)整才能達到一個理想狀態(tài)，基于這些監(jiān)控痛點，希望可以通過分析歷史數(shù)據(jù)來自動檢測出異常點，并自動計算出應(yīng)有的報警閾值并進行設(shè)置。如圖8所示，根據(jù)不同監(jiān)控指標的特點，選擇不同的基線算法，并計算出其置信區(qū)間，用來幫助系統(tǒng)更加準確地檢測異常點。比如業(yè)務(wù)指標周期性比較強，大多數(shù)監(jiān)控指標都是在歷史同期呈現(xiàn)出正太分布，這個時候可以拿真實值與均值進行比較，其差值在N倍標準差之外，則認為該真實值是異常點。

圖8 異常點自動檢測

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

系統(tǒng)的服務(wù)保護措施有一部分是通過自動熔斷框架Hystrix進行自動熔斷，另外一部分是已經(jīng)存在的上千個降級、限流開關(guān)，這部分開關(guān)平時需要開發(fā)人員根據(jù)自己的運維經(jīng)驗來手動觸發(fā)。如果能夠根據(jù)各種監(jiān)控指標準確地診斷出異常點，并事先將已經(jīng)確定的異常場景與服務(wù)保護預(yù)案進行關(guān)聯(lián)，就可以自動進行服務(wù)保護預(yù)案的觸發(fā)，如圖9所示。

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

4.3 壓測計劃自動化

定期進行的外賣全鏈路壓測，需要召集相關(guān)業(yè)務(wù)方進行準備和跟進，這其中涉及的數(shù)據(jù)構(gòu)造部分會關(guān)聯(lián)到很多業(yè)務(wù)方的改造、驗證、準備工作[4]。如圖10所示，需要通過壓測計劃串聯(lián)整個準備、驗證過程，盡量減少人為活動參與到整個過程中。這其中需要進行如下工作的準備。

圖10 壓測計劃自動化

1)針對真實流量的改造，基礎(chǔ)數(shù)據(jù)構(gòu)造、數(shù)據(jù)脫敏、數(shù)據(jù)校驗等盡可能通過任務(wù)提前進行。

2)進入到流量回放階段，可以針對典型的故障場景進行故障預(yù)案的觸發(fā)(比如：Tair故障等)。

3)在故障演練的同時，可以結(jié)合核心鏈路的關(guān)系數(shù)據(jù)準確定位出與故障場景強相關(guān)的問題節(jié)點。

4)結(jié)合典型故障場景事先建立的服務(wù)保護關(guān)系，自動觸發(fā)對應(yīng)的服務(wù)保護預(yù)案。

5)在整個流程中，需要最終確認各個環(huán)境的運行效果是否達到了預(yù)期，就需要每個環(huán)節(jié)都有相應(yīng)的監(jiān)控日志輸出，并自動化產(chǎn)出最終的壓測報告[5]。

整個壓測計劃的自動化進程中，將逐漸減少系統(tǒng)運行中人為參與的部分，逐步提升全鏈路壓測效率。最終希望用戶點擊一個開關(guān)開始壓測計劃，然后等待壓測結(jié)果就可以了。

5 結(jié)語

在整個業(yè)務(wù)運維系統(tǒng)建設(shè)中，只有更加準確定位問題根節(jié)點，診斷出問題根本原因才能逐步自動化去做一些運維動作(比如：觸發(fā)降級開關(guān)、擴容集群等)。如圖11所示，項目會在這些環(huán)節(jié)的精細化建設(shè)上進行持續(xù)投入，希望檢測到任意維度的異常點，向上推測出可能會影響哪些業(yè)務(wù)指標，影響哪些用戶體驗；向下依托于全鏈路壓測可以非常準確地進行容量規(guī)劃，節(jié)省資源。

圖11 自動化建設(shè)后期發(fā)力點

[1]侯明,李書領(lǐng).智能監(jiān)控網(wǎng)絡(luò)的系統(tǒng)集成及其應(yīng)用[J].電子技術(shù)與軟件工程,2014(05):25

[2]田新廣,孫春來,段洣毅,等.基于機器學(xué)習(xí)的用戶行為異常檢測模型[J].計算機工程與應(yīng)用,2006,42(19):101-103

[3]左申正.基于機器學(xué)習(xí)的網(wǎng)絡(luò)異常分析及響應(yīng)研究[D].北京:北京郵電大學(xué),2010

[4]李杰,屈玉貴,張英堂.一種自適應(yīng)的Web壓力測試模型[J].計算機工程與應(yīng)用,2006,42(02):90-92

[5]馬琳,羅鐵堅,宋進亮,等.Web系統(tǒng)性能測試及優(yōu)化[J].計算機工程,2005,31(12):229-231