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

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

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

　　 一、大促保障與日常保障的差別

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

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

　　 二、大促的整體流程　　

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

　　1、組織保障

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

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

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

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

　　2、目標拆解

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

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

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

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

　　3、壓測演練

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

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

　　4、變更管控

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

　　5、內灰上線

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

　　6、應急值班

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

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

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

　　 三、大促保障方案詳解　　

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

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

　　1、鏈路梳理

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

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

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

　　產出物：

　　一張能反應當前系統實際情況的鏈路關係圖，要能夠看到流量路徑、反映出強弱依賴關係。

　　目前服務之間的依賴關係的檢查結果List，是否存在風險項。　　

　　2、技術目標&容量水位

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

　　產出物：

　　一張當前系統入口的qps表格，包括目標qps、當前實際qps、是否需要擴容等。

　　參考格式：　　

　　3、監控告警

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

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

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

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

　　產出物：

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

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

　　4、應急預案

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

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

　　事前預案：提前擴容、配置限流、快取預熱等、邊緣業務降級等。

　　事中預案：即應急預案，動態配置開關等。

　　事後預案：大促結束後要做的預案，一般為系統縮容、恢復邊緣業務等。

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

　　5、聯動機制

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

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

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

　　產出物：

　　值班干係人名單，值班資訊。

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

　　6、外部合作方保障

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

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

　　產出物：

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

　　 四、不同團隊的保障要點

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

　　1、前臺業務

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

　　全鏈路：從業務流程開始到業務流程，整個業務鏈條的穩定性。

　　端到端：從APP(小程式/H5)端開始，到閘道器、業務系統、儲存等穩定性。

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

　　2、中後臺業務

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

　　 五、事後覆盤

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

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

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

　　 六、寫在最後

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