貨拉拉公司，3年運維零故障！

2024-07-09碼農

作者丨核心基礎設施部

來源丨公眾號：貨拉拉技術（ID：huolalatech）

背景

眾所周知，業務高峰帶來的流量大幅增加會對系統造成巨大的壓力和風險，就像消防局在火災高發期需要加強火災風險關註一樣，貨拉拉也需要在高風險時段投入更多資源辨識和解決問題。而業務高峰通常還具備一些特殊意義，往往伴隨著公司業務目標的達成，如單日訂單破峰。如果因為系統故障導致目標未達成，影響也會非常惡劣。當前貨拉拉會經歷各種業務高峰場景，像新業務開城放量、優惠權益秒殺、節前貨運需求激增等等，都要求系統具備高度穩定性和抗風險能力。

自2020年下半年起，貨拉拉開始系統化地進行業務高峰保障，經過三年多努力，技術團隊累計發起34次業務高峰保障，且自2021年以來連續三年多在業務高峰期間保持零故障記錄。接下來我將與大家分享在此過程中積累的實踐心得和思路。

一、業務高峰保障應該如何開展？有哪些重難點？

1.明確業務高峰保障的目標

對於業務高峰穩定性保障，毫無疑問，我們最重要的目標是確保期間不發生任何系統故障。除此之外，要與業務部門充分溝通，對齊要保障的具體業務目標。比如，確定使用者下單指標的具體目標數值是多少，100萬還是200萬。如果業務目標單量過於誇張，比如相比日常增長100倍，那技術團隊肯定需要提前評估這一目標的可行性和成本。這樣，我們才能向業務部門提供準確資訊，幫助他們做出合理決策。

除了上述目標之外，技術內部也有一些關鍵過程指標，比如系統的SLA表現、線上問題的應急處理時效等。

最後，難度較大的目標還是關於成本的目標管理，在發展初期，穩定性保障往往需要較大的投入，成本管理也是較容易被忽視的點。這方面需要思考的主要問題，一個是我們在進行保障工作的過程中，人效是否能有所提高；其次，在相同增長規模下，伺服器資源的單位投入是否有所降低：舉例來說，如果之前業務高峰時，需要投入50萬的伺服器成本，那麽下一次同樣的單量增長情況下，投入的資源成本是不是能比之前要少？

2.業務高峰保障應該怎麽開展（計畫管理的視角）

定好目標之後，就需要從計畫管理的視角出發，來審視和規劃後續的工作。

我們先來看下業務高峰保障的特點。穩定性保障計畫相比一般計畫來說，參與的人數更多，涉及的部門跨度也更大。而且，業務高峰保障通常是一個不能延期的計畫——有些業務開城或授權以適當延期，但像雙11這樣的大型促銷活動，以及貨拉拉隨著市場需求增加而面臨的高峰，是不可能推遲的。因此，保障計畫組在整個過程中扮演著至關重要的角色。相比攻克技術難題，如何組織不同職能的人員共同達成目標可能更具挑戰性。

可以透過以下這些措施，確保計畫管理視角下的保障工作有效開展。

建立保障計畫組。

明確組織矩陣——對於整個保障計畫組，在一開始就要明確保障工作的組織結構。需要確定引入哪些人員，以及這些人分別負責哪些領域的工作。

對齊保障節奏——由於這大多數是一個倒排期計畫，必須安排好整個保障計畫的周期，確保每個關鍵裏程碑的達成。

業務輸入/更新。

在整個大橫向組織的對接中，保障計畫組承擔著向上接收業務輸入和資訊更新的任務。需要與業務部門對齊，明確業務高峰保障的具體時間、目標業務指標，以及可能發生的關鍵營運動作。

任務輸出/驗收。

這部份主要面向保障工作的實際執行者——技術研發，下發保障具體工作任務，並對整體完成情況進行驗收。在這個過程中，會采用一些常規的計畫管理手段。計畫Kick-off，計畫整體進展定期溝通，包括保障大群、計畫周例會等組織形式。

3.保障任務的具體內容（技術保障的視角）

從技術視角來看，整個業務高峰保障流程的核心是風險管理，從風險辨識到風險消除，確保沒有遺漏的風險點，並為每個已辨識的風險制定解決方案。

在主體層面，可以將風險分為三個主要部份：公司內部、外部使用者、三方依賴。根據穩定性保障的通用經驗，風險類別又可大致分為——容量風險、變更風險、鏈路風險、人員風險。結合風險類別和風險主體，可以構建起整個技術保障的框架。

外部客戶。 這方面可能帶來的主要風險是流量沖擊，要求我們根據系統承載能力的上限，提前設定合理的限流閾值。

公司內部。 這部份是主戰場。

在 容量風險 方面，除了進行壓測和系統擴容，還需要準備充分的預案，包括提前的行銷場景數據預熱和緊急情況下的降級預案。

變更管理 是另一個關鍵點，我們通常會采取封網措施，規定在特定時間內不允許進行任何變更。同時，也會在高峰前對核心變更內容進行審查，避免已治理過的內容發生變動，以確保保障工作的效果是可控的。

鏈路健壯性 方面，重點關註服務風險治理，包括各項超時、降級熔斷、依賴關系等等的合理性。完成治理後，我們將在關鍵點進行攻防演練，以檢驗效果。

人員風險 同樣不容忽視。為避免在關鍵時刻找不到處理問題的人，我們要求團隊提前安排好值班人員，並在高峰期間進行系統巡檢和打卡。除此之外，設定小黑屋值班機制也是很有必要的，把各核心系統的關鍵負責人集中在一個大會議室裏，方便快速溝通、將問題消滅在萌芽階段。

三方依賴。 這裏特別要關註容量風險和降級手段。由於三方容量采購流程通常較長，需要確保提前準備到位。對於有備份或弱依賴的服務，要制定一鍵降級預案，並進行演練驗證。另外在應急響應方面，也要提前通知所有廠商業務高峰期的時間，確保他們能夠提供必要的支持。

1）雲商重保

三方依賴這裏，我將就雲服務商的保障重點展開分享，因為雲商的穩定性對完全上雲的業務系統是至關重要的。

資訊拉齊。 貨拉拉會由專業的雲資源團隊負責與雲服務商對接。將業務高峰的資訊拉齊是一開始的關鍵，要確保所有相關人員都能充分理解和重視業務高峰保障的重要性。

資源備貨。 提前備貨是最重要的事項，因為雲商的資源並不是無限的，有些特殊規格的資源存量較小，需要提前與雲商協調準備好所需的資源。

資源預熱。 在高峰期來臨前，某些資源可能需要進行預熱。確保這些資源在高峰期前得到充分預熱，以防止資源短缺或效能問題。

機器巡檢。 對底層物理機器進行必要的巡檢工作，包括檢查硬體是否存在風險。如果發現風險，可以進行硬體替換，以避免風險在業務高峰期間爆發產生故障。

聚合度管理。 雖然服務架構和底層資源已經做到盡可能隔離，但在物理機視角上的資源聚合度仍需關註。之前曾遇到雲商只掛了一台物理機，但對我們系統影響很大，主要原因就是許多核心例項都部署在了這台機器上，聚合度太高。因此，我們要求雲商定期掃描聚合度，如果發現聚合度過高的情況，要提前進行資源打散操作。

變更通知。 盡管無法要求雲商在業務高峰期封網，但可以盡可能要求他們在此期間提前通知任何變更動作。這有助於提前準備，出現問題後快速確認及處理，縮短影響時長。

應急值班。 貨拉拉與主要依賴的兩個雲商都有相關的應急溝通群，這些群組設在我們內部的辦公聊天軟體上，以提高溝通效率，減少使用微信、釘釘等多個平台的麻煩。在一些重要的業務高峰期間（通常一年一兩次），還會要求雲商提供駐場支持，確保得到最大力度的保障。

4.業務高峰保障的重點

最後再次回顧下整個保障思路中的兩個重點內容。

1）計畫組織

①PMO 參與

必須高度重視計畫組織工作。就像修建高樓需要各個工種通力合作一樣，計畫的順利進行也需要專業的PMO人員。在貨拉拉，有專業的PMO團隊負責整體計畫的組織與協調，確保計畫按計劃推進並統籌解決實施過程中的各種問題。

②部門介面人機制

由於計畫涉及的人員眾多，可采用介面人機制。計畫組與各部門介面人對齊，再由介面人與部門內部的具體實施者對接。這樣可以有效降低保障工作的復雜度，明確責任分工，提升溝通效率，確保資訊準確傳遞和任務順利執行。

③固定會議把控進度

確保計畫例會制度嚴格執行，以把控整體計畫進展。透過定期例會，各部門可以及時溝通任務進展、分享工作經驗、暴露過程風險、提出訴求、協調資源配置等等，確保計畫按計劃高品質推進。

2）系統容量

另一個重點，作為系統工程師，在高峰來臨前應當特別重視系統容量風險。業務高峰意味著流量的增加，如果系統健壯性不足，可能還有容錯空間，但如果容量不足，問題一定會發生。在容量方面，應當關註以下幾點：

①打好提前量

不論是三方容量還是雲商資源，如果這一點有疏漏，當緊急需要資源時，將無計可施，大機率要犧牲業務或使用者體驗。

②關註爬坡階段

與秒殺場景不同，貨拉拉的業務高峰在高峰當日會有一個緩慢的爬坡過程。在這段黃金時間內密切關註系統表現，迅速發現並解決短板容量問題，可以大幅降低故障發生的機率。

③為最壞的情況做好打算

如果容量保障做得不夠好，出了問題，需要準備保大舍小，部份使用者可使用總比所有使用者都不能使用要好得多。例如，是否可以將流量做進一步限制，以確保系統容量水位健康，或者根據前期準備進行必要的業務功能降級。哪怕業務因為降級而減半或者使用者體驗大幅受損，也比完全崩潰要好。

二、貨拉拉具體是怎麽做的？效果如何？

1.業務高峰保障的策略

首先，站在巨人的肩膀上，借鑒他人成功經驗。如果完全靠自己摸索，效率會非常低。

其次，有意識做好本土化工作。因為從他人那裏學來的知識或方法，不一定完全適用於自己的情況。

第三，必須不斷最佳化。要透過不斷復盤和最佳化，確保每次都比上一次做得更好。

最後，保持激情至關重要。采用一些營運手段來激發團隊的激情。相比簡單地下達指令驗收執行效果，我們更傾向於激發大家的主動意識。所有人自發地為即將到來的業務高峰考慮要做什麽，能帶來更好的結果。

2.策略落地

1）如何站在巨人的肩膀上？

我之前在阿裏本地生活有幾年工作經驗，因此借鑒了阿裏雙11大促的保障經驗，快速建立起了貨拉拉業務高峰保障的初步方案。這樣做的好處是，確保了整個保障工作覆蓋的顆粒度足夠細致。阿裏的保障經驗已經經過了大量最佳化改良和實踐檢驗，可以有效避免重復別人已經踩過的坑。

貨拉拉在業務穩定性保障發展初期只提供了一些高峰保障的待辦事項列表，對問題的認知不夠全面。現在已經有了一套完整的保障框架體系，主要圍繞風險預防和應急快恢兩大主題開展。

2）如何做本土化改善？

我們在實踐過程中發現，按照最初的一套方案執行後，有些保障手段在貨拉拉的收益並不大，同時存在可能還沒有關註到一些風險。因為相比電商大促，貨拉拉作為一個訂單撮合平台，更關心供需特征訂單匹配。

展開說一下。業務高峰時，需求量通常比供給量要多很多。使用者下單量增長迅猛，但能夠承接的訂單的司機數量不會一下子增加，甚至還可能減少，比如在五一前，有些司機可能選擇休假。這種運力不足的情況非常明顯，直接導致系統裏待配對的訂單越來越多。

對於待配對的訂單，我們的系統會有一些既有策略。例如，如果一個訂單釋出後沒有人接單，系統會擴大搜尋範圍，比如從10公裏擴大到20公裏，從而圈選到更多的司機重復推播這個訂單（實際策略要復雜很多）。所以在業務高峰運力不足場景下，系統的壓力增長是非常恐怖的，單純依靠擴容代價太大。

因此，我們將保障重心調整到了整個訂單排程系統的穩定性保障上。在研發團隊出色完成架構最佳化的基礎上，結合著相關場景降級預案的梳理和演練，比如最嚴重的情況下可以完全關閉重推邏輯以降低系統負載，現在我們面對這種場景具備非常充足的信心。

3.具體實施

1）時空維度上的策劃（宏觀視角）

首先，我們會進行一個宏觀視角上的策劃。這個策劃工作主要是在年初時，就會列出全年會遇到的業務高峰和重大事件的時間表。這樣做的好處是，全年的保障工作計劃都能心中有數，能夠提前規劃好在大概什麽時間需要開展哪個業務高峰的保障工作，並給出訊息提醒，避免遺漏。

圖1 - 貨拉拉全年大事件一覽表

其次，所有保障工作都會進行文件沈澱，將相關資訊統一存放在一個共享空間中，方便查閱。

圖2 - 貨拉拉高峰保障文件空間

2）計畫視角下的管理（執行落地）

從計畫管理的視角出發，確保整個保障團隊的構成清晰明確。我們需要知道每個領域的介面人和負責人是誰，他們主要負責哪些內容，以及整個領域的協作成員包括哪些人。

圖1 - 業務高峰保障組織

在明確了團隊成員和責任分配之後，我們會和各領域團隊成員進行溝通，商討制定保障方案，並進行KO會議。在會議中，我們會收集大家的反饋，看看方案中有哪些地方需要補充或改進。

圖2 - 業務高峰保障方案框架

隨後，PMO會設立一個計畫進度看板，用來跟進整個計畫的進度和完成情況。

圖3 - 業務高峰保障計畫進度看板

3）組織營運提振士氣

高峰當日，我們會有一個被稱為「小黑屋」的作戰室。在這裏，會確定關鍵人員的名單、時間安排，以及一些物資的準備工作。這些準備工作包括為團隊成員安排下午茶等福利，以確保他們在緊張的工作中也能得到適當的休息和營養補充。

其次，在保障工作結束後，我們也會註重儀式感。PMO會提前準備一些物料，比如橫幅、KT板等，組織大家一起進行合影留念。這樣的活動不僅能夠增強團隊的凝聚力，也能讓團隊成員對參與高壓力工作的辛苦付出有一個難忘的回憶。

4）復盤總結更進一步

在業務高峰過後，第一件事就是開展全面的復盤總結工作。

首先，我們會回顧目標達成情況。

接下來，我們會進行兩個重要分析：

①對每一個保障子項進行深入分析。 檢查保障的目標是否達成，以及在治理過程中是否存在可以後續最佳化的點。

② 收集復盤參與方的反饋和建議，幫助我們辨識出後續改進項。 這些改進項將被跟蹤並反饋到下一次的保障工作中。

5）踩過的一些坑

貨拉拉在業務高峰保障過程中，也遇到了一些教訓——

只關註研發服務釋出配置變更，結果因為其他領域的變更出了問題。 之前在封網前只關註了研發自己服務的釋出和配置變更。但問題卻出在了其他領域的變更上，比如營運的一些配置變更，或者是業務上的AB實驗變更，包括安全策略等的變更。後續我們把這類變更也被納入了整個保障範圍。

有個服務和業務流量負相關，結果出現在了待擴容名單裏。 我們在容量管理方面一直做得還不錯，但在成本控制方面，確實也經歷了一些摸索。比如有一個服務實際上與業務流量負相關，即業務單量越多，它的壓力反而越小。這個服務和訂單熱力圖有關，而訂單熱力圖的作用是告訴司機哪裏更容易接到訂單。但在業務高峰時，司機其實並不缺單子，因此對熱力圖的存取量並不大。後來，我們對這類服務實施了更精細化的管理。

縮容的時候沒有精打細算，如果縮掉特定的伺服器，能更省錢。 在縮容時，需要註意的不僅僅是擴容後的機器要縮容回來，更重要的是要思考縮容哪些機器才能更節省成本。因為擴容時擴的是新機器，但縮容時，並不一定非得縮容這些新擴的機器，而是可以選擇已經在使用中的機器。這樣做會涉及到一些成本計算規則，能夠幫助節省更多的成本。在這方面，我們有專業的雲成本團隊來幫助我們進行管控。

3.業務高峰保障成效

經過2020年至今3年多時間的建設，貨拉拉已經具備了非常成熟的業務高峰保障能力。截至目前，貨拉拉技術穩定性團隊已累計發起34次業務高峰保障；且2021年至今，貨拉拉業務高峰期間已連續3年保持0故障水平。同時，業務高峰保障也幫助強化了日常穩定性水平，貨拉拉全年故障數也在逐年下降。