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

業界有很多大促活動，像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大促順利結束了，對于哈啰來說，各項業務指標也上了新的臺階，

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

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

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