第一次操盤大促，穩定性保障如何做到萬無一失？

業界有很多大促活動，像618、雙11、雙12等等。每一次大促不只是給業務帶來了新高，對於技術同樣也有很重要的意義，縱觀一些優秀的技術團隊，都是跟著業務一起成長的。在高併發大流量的背景下，如何支撐好業務運營，是一件很有挑戰性的事情，它可以從多方面檢驗我們的技術能力，對我們的系統架構和應急保障都提出了很高的要求。

哈啰在去年9月30日開啟了首屆的假日狂歡節，我們也做了很多的穩定性保障工作，最終大促順利渡過，業務體感非常順滑，所以藉此機會總結下我們在穩定性保障這方面的一些工作，分享給大家。

相比日常的穩定性保障來說，大促的主要特點是時間短、流量大、玩法豐富。大促的過程一般都只有幾天甚至數小時，為了儘可能衝到新的業務目標，要充分調動用戶的積極性，所以營銷玩法一般都比較豐富。因此，我們在大促的穩定性保障中，重點從容量規劃、壓測演練、應急預案、變更管控這幾個維度來做保障。

哈啰由於多業務形態共存，每條業務線有自己的發展特點，因此大促開始前，要充分分析業務特點，制定針對性的保障方案。例如兩輪業務(共用單車和共用助力車等)，與典型的通勤場景是一致的，在早晚的上下班高峰期，後臺的系統流量也會特別大。而四輪業務(打車、順風車、送貨等)，則是跟著節假日有較強的關聯性，每到節假日前夕，系統可能會面臨數倍於日常流量的峰值。

順著大促的時間軸來看，一般會包含活動早期的方案制定、壓測演練 ，活動中的應急預案和聯動等，活動後的收尾工作等。下麵按順序介紹下其中的一些重點工作。

公司級大促，需要多個業務線共同協作，涉及多個部門眾多人員，這個時候需要有一個類似大促保障組之類的組織來統籌協調，這個組織是大促保障的決策機構，它是大促保障的第一責任人，同時也賦予相應的權利:在涉及到資源衝突的時候，大促保障組有權拍板，能與業務運營溝通需求，特殊情況下，可以停掉一些非必要的迭代需求，保障大促的事項順利推進。

同時，各個業務研發團隊，也需要明確各自的大促負責人(也稱大促技術PM)，大促技術PM是本業務研發團隊大促保障的首要負責人，要根據業務特點制定詳細的保障方案，配合本業務完成大促目標。

在分工上，大促保障組負責關鍵里程碑的設定，比如說大促項目需求上線時間、什麼時候開始壓測、什麼時候進行封網、封網之後的變更審批(破網)流程，以及給出整體的保障方案框架，例如大促保障模版、技術目標拆解方式等等，可以供業務線的大促技術PM來作為參考依據。

在溝通機制上，大促保障組要能夠從全局視角給出當前的整體工作進度和風險概況，及時彙報給管理層。同時各個業務線的大促技術PM也需要定期向大促保障組彙報工作進展，包括各業務線的大促需求研發進展、當前已知風險、資源瓶頸等等。

我們上面提到過，大促的核心在於對流量的把控，因此目標拆解的目的主要是從業務目標拆解為技術目標。

在業務目標設定的時候，一般會考慮用訂單量/GMV/DAU/PV/UV等各類指標作為目標，但是在我們做保障方案的時候，需要明確地知道技術目標，一般是QPS、用戶數等等。

所以這裡需要有一個轉化的過程，首先是與業務運營深入溝通，搞清楚這次大促的主要策略和玩法，核心點是弄明白這個問題: 相比日常的業務流程來說，這次的流量從哪裡來，這個玩法是如何吸引用戶的，用戶的操作路徑與以往會有哪些不一樣。搞清楚這個，就明白了流量路徑。比如以兩輪騎行為例，會考慮通過一些騎行任務來提升用戶的騎行意願：騎行N單之後給X元獎勵。那這裡面就需要關註騎行流程、營銷活動、任務獎勵等這幾個平臺相關的各個系統。同時進一步深入分析，還發現在大促活動中需要保證供給側有足夠的車輛，線下運維可能會進行一些額外的調度工作等等，這裡面就需要關註運維繫統相關的流量變化。

總的來說，即技術目標 = 業務目標 -> 實現路徑(策略、玩法) -> 找到依賴的系統 -> 明確系統的QPS。

技術目標設定好之後，就要進行壓測了，然後根據壓測的結果進行調整和優化。在設定技術目標的同時，我們還要根據業務線的具體業務玩法，設定對應的應急預案，這些預案也要經過演練來驗證。

因為壓測演練講得比較多，這裡就不做過多展開，感興趣的同學可以翻閱以往的文章。

變更是導致線上故障的最大來源之一，因此大促期間，變更需要提前做好管控。根據大促的具體節奏，提前設定好相應的封網計劃，包括應用發佈、配置變更、運維變更等等，同時也準備好相應的應急流程，對於某些特殊情況需要變更的，做好記錄，以便活動結束後進行復盤。

大促活動因為有時間視窗限制，所以在正式上線之後要做充分的測試，避免出現意外情況。在做好灰度發佈的基礎上，對於大促的活動業務邏輯，也要進行灰度驗證，一般可以用內部、外灰逐步放量、擴全的方式進行。這次大促活動正式上線之前，我們採用了內灰的方案進行驗證，先讓公司內部同事加入到灰度白名單，去體驗一下大促玩法等等。但是要註意數據的隔離，避免內灰測試中，消耗了真實的獎勵等等。

大促開始前，要明確好信息同步機制，即大促值班紀律和規範，比如說系統核心owner必須到作戰室進行值班，同時在IM中提前規範各個溝通群的名稱和作用，把相應的研發、產品、業務、運營、客服都關聯同學都拉到對應的溝通群。

比如說可以建一個全員溝通群，用於信息同步和相關通知。同時為了高效決策，還需要把一些有決策權的TL拉到會議室一起值班，出現問題之後快速決策，下發執行等等。

上面主要是大促過程中的幾個關鍵環節，看完了這些，相信大家對大促保障已經有一個整體認識了，接下來我們重點聊一下保障方案具體怎麼做，如果你是大促技術PM，你會如何制定保障方案？

大促保障方案是一個整體的框架，在實際的工作中，是由大促保障組產出了這個框架，然後各個大促技術PM根據業務特點，制定出具體的保障方案，接下來大家一起評審併進行相應的壓測演練驗證。

為了讓大家理解一致，每個模塊下都有了明確的產出物要求，即具體要做什麼事情。

大促的關鍵點在於流量，想要治理好流量，就需要對流量路徑做到瞭如指掌。比如說，本次大促有哪些關鍵入口，這些入口對應了哪些後端系統、涉及了哪些資源，目前這些系統和資源的水位怎麼樣，預估哪裡會成為瓶頸，是否需要提前治理等等。這些都是鏈路需要重點關註的地方。

在鏈路梳理中，也應該明確強弱依賴，比如說某個系統的下游依賴中，哪些是必不可少的強依賴，哪些是可以容忍出現故障的弱依賴，以及這些依賴的降級熔斷配置、超時時間設置等等，都需要詳細分析。

在分析流量路徑的時候，要註意著重識別是否存在熱點流量，例如產品一般在大促開始前對大量人群做push，那麼用戶點擊push之後，跳轉的落地頁對應的介面可能會存在熱點流量，要進行重點保障。

產出物：

容量水位分析，是為了分析當前系統是否存在資源瓶頸，有無需要提前擴容的資源等等。如果暫時無法明確，也可以先輸出現狀，待壓測之後再確認具體情況。

產出物：

參考格式：

無論是在常態化穩定性保障還是大促穩定性保障，監控告警的治理都是重中之重。

在大促場景中，需要特別註意兩個點：

當前各個系統的監控告警配置情況，指標覆蓋是否完善和閾值設置是否合理。包括基礎設施監控、中間件監控、應用層監控、流量入口監控等等。

與本次大促有關的一些業務監控是否完備，是否能夠通過業務指標觀察當前大促的流量路徑。比如說業務活動的轉化一般是呈漏斗型，以「一個通過發放優惠券來促進下單」的場景為例：需要有一套對應的業務大盤，能看到從優惠券曝光、用戶領取、下單核銷等各個環節的情況。

產出物：

各項監控大盤的地址和梳理結果，監控監控的覆蓋度是否完整，告警策略是否正常等。

監控指標check完了之後，要通過故障演練來模擬資源水位變化，看監控告警是否正常。

從以往的穩定性治理經驗中可得，即使我們做了萬全的準備仍然有可能出現意外情況。因此，大促保障中更是要對各種“可能出現”的意外情況，做好充分準備。比如說上面提到的鏈路梳理中，有些依賴可能需要手動調整，在系統壓力過大的情況下需要屏蔽掉一些非核心邏輯，比如說為了保證極端情況下的用戶用車，可以暫時關閉紅包車檢查等等。

按照大促時間軸，從“事前、事中、事後”三個維度來梳理預案，對於一些對業務可能產生的預案，要寫清楚業務影響面和預期，以及提前與業務方溝通清楚。

產出物：應急預案手冊，可以用表格形式呈現，包括預案的類型、觸發條件、執行動作、預估影響、執行人、生效速度等等。

一場大促會牽扯到多方，包括產品、業務、客服、其他關聯部門等等。聯動機制主要包括應急值班和信息同步機制，比如說大促進行中，出現了線上故障，在處理故障的同時，要把相關信息同步給關聯方。某些情況下，需要執行預案了，這個執行預案的動作也需要同步給關聯方。

應急值班：包含值班人員名單和聯繫方式。

信息同步機制：包含與產品/業務/客服等的溝通通道和機制。

產出物：

• 值班干係人名單，值班信息。

• 各業務應急值班群&溝通流程。

想要順利通過大促，除了內部的各種保障，也需要註意外部的一些合作方的保障。避免業務流量過大，影響了合作方的介面質量等，本次活動是否依賴外部合作方(開放API/外部HTTP交互等)，對於合作方的介面質量是否有監控告警手段，例如合作方介面的rt、錯誤率等指標是否可觀測，是否具備切換能力，例如從A合作方切換到B合作方。

提前明確我方的流量目標，與合作方進行溝通，要求合作方制定相應的保障策略，例如讓合作方在大促期間儘量避免變更等操作。最終一起與合作方輸出流量評估結果和應急手段。

產出物：

• 與合作方的評估結果表格，包含: 業務場景、評估結果、合作方值班人、應急預案等。

上文我們提到過，在具體保障工作中，要結合各團隊的業務特點，制定出相符的保障方案。在多業務形態的公司中，就有個比較典型的情況：前臺業務和中後臺業務的保障要點是不一樣的。比如說，以哈啰的業務場景為例，會有下麵的兩個特點。

例如兩輪、四輪、電動車、電池等等，核心的目標是保障用戶體驗和支撐業務流程，因為重點是保證自身和相關下游強依賴系統的穩定性。註意兩個點：

在整體的方案設計中，要結合業務邏輯，準備充足的應急預案。

例如用戶平臺、支付平臺、交易平臺、地圖&AI等等，在保障全鏈路穩定性的基礎之上，還需要格外註意多個上游之間的流量疊加之後的壓力。例如在平時的時候，兩輪和四輪的高峰期可能重疊度不高，大促期間進行了大量的營銷推廣，高峰期可能會疊加；以及具備對不同上游的流量做隔離的能力，例如某個業務對平臺側服務調用量過大，平臺側應該有自我保護機制，避免系統被擊垮後影響了其他業務線。

930大促順利結束了，對於哈啰來說，各項業務指標也上了新的臺階。

但是對於有追求的技術人來說，大促結束之後，並不是一切都結束了，穩定性保障工作想要精益求精，就是要在日常的細節中做到位，在項目復盤中，要回顧大促期間的系統表現，與此前的預估模型、壓測期間的系統表現進行對比。有沒有哪些系統資源的水位出現了異常，利用率是否出現了過高或者過低的情況。要反過來思考為什麼在此前的方案制定、壓測演練中沒能發現這些問題。進而優化後續的保障工作。

同時，也要回顧一些應急預案執行、變更破網等情況，比如預案的執行過程、執行結果是否都符合預期，有無優化餘地。一些手動預案能否變成自動化預案等等。破網的變更有哪些，是否都是必要的，後續的大促中，能不能儘量提前變更，降低大促期間變更風險等等。

穩定性的工作因為覆蓋面比較廣，事項比較大，因此大家總是覺得比較瑣碎，我們要做的是從這些瑣碎的事項中抽象提煉出共性的東西，對它進行歸納總結，將其形成我們自己的方法論，這樣才能慢慢成長起來。這一次大促保障，不管是系統本身，還是我們的穩定性經驗保障，都得到了很大的提升。但是技術是無止境的，我們也從不敢大意，仍然以謹慎的心態去做好穩定性保障。