1.為什么要做大促保障

    在討論大促質量保障可以做些什么之前，我們先了解一下為什么要做大促質量保障？

    一般而言，平臺大促即意味著流量暴漲和優惠力度暴增，特別是每年的618、雙11和雙12等大促更是一場電商圈的狂歡；暴漲的流量對系統穩定性的沖擊，高額優惠對業務資損防控的考驗，都比平常要高出數倍，出現了問題也會被放大數倍；這是一場沒有硝煙的戰爭，寧可準備充足但毫無用武之地，也不能出現問題束手無策。

2.面臨的挑戰

    既然大促保障如此重要，那么我們要準備點什么來確保大促活動的穩定性，是我們要重點思考的問題。在得出答案之前，我們首先分析下大促活動我們主要面臨的挑戰點到底有哪些，再針對性的一條條去準備，去解決，便是當下我們比較有效的方案。

2.1   系統穩定性

     在GMV增長的欣喜之余，暴漲的流量的對系統的穩定性沖擊，是首要面臨的一個挑戰點；

由上圖可看出，在有活動的20:00和00:00點，都會有一波瞬時的流量高峰，0點的高峰相對于20:00點前的日常流量有至少3倍以上的增長。那么這里有兩個不同類型的挑戰點：

• 瞬時突增的流量高峰
• 數倍于平時的流量

與此同時，增加的請求量對服務器和中間件的考驗等都是我們需要面臨的挑戰點。

2.2   業務資損

刨除流量暴增對系統層面的影響之外，另一個需要我們重點關注的點就是業務資損問題。

流量的增長對應的就是我們訂單量的增長，此時如果發生資損問題，那么對應的資損金額也會因為單量增加而被放大；再加上大促的節點一般優惠的力度都會比平時要更大一些，就會更進一步放大資損的金額。

3.應對措施

     首先從系統層面來說，對于一些核心的節點而言，最重要的是保障系統的高可用；在Google SRE中有一個層級模型來描述系統可靠性基礎和高層次需求，由下圖可見，金字塔最底層的基座就是監控（Monitoring），再往上的層次是應急響應(Incident Response)和事后總結以及根因分析(Postmortem&Root Caue Analysis)，也就是我們的復盤。

3.1   全局評估

• 大促業務時長：關注大促活動的運行周期，在活動前做好一系列的準備工作，包括各業務鏈路人員值班安排、全鏈路壓測時間安排以及緩存預熱等。
• 業務量預估體量：根據業務給出的預估業務體量來進行系統容量規劃。
• 預估峰值日期：重點時間段重點保障。

3.2   監控&告警

    穩定性金字塔的底座是監控(Monitoring)，這是一個系統對于穩定性最基礎的要求；缺少監控的系統，如同蒙上眼睛狂奔的野馬，無從談及可控性，更遑論穩定性。所以在針對于大促類的活動，前置就需要梳理出可能的系統及業務異常點，做好監控和告警。

     在進行大促穩定性監控梳理時，要先脫離現有監控，先從核心、資損鏈路開始，按照業務、應用（中間件、JVM、DB）、系統三個層次梳理需要哪些監控，再從根據這些索引找到對應的監控告警，如果不存在，則相應補上；如果存在還要考慮閾值、時間、告警人是否合理。

    另外針對一些可能的資損場景，我們也可以增加一些資損或數據核對，做一個雙重的保障。

3.3   應急響應

    發生了問題不可怕，可怕的是短時間內不能恢復導致業務受損程度加大；這里就需要從另一層面來考量，這樣來進行應急響應，快速定位并解決問題。這里我們可以從以下幾點入手：

3.3.1   限流&降級

    每一個系統或者應用的承載能力都是有限的，如果有超出保障目標之外的流量過來，風險就很高，限流能力是必須要有的。所以在大促類的活動中，需要我們評估核心接口的承載能力，增加接口限流配置，防止突增的QPS把系統打掛。也需要增加降級配置，對鏈路中位置的異常進行降級處理。

3.3.2   預案

    預案就是對于突發情況的應對處理，所謂有備無患，執行時機和執行動作一定要清晰明確并記錄在文檔中，發生緊急情況時，按照預案執行步驟來操作。針對大促活動的功能或系統預案前期一定要梳理并完善，大促期間封網無法執行線上變更發布操作，預案是進行線上操作的唯一入口。

   有了預案，那么這個預案是否能解決相應的問題，就需要我們對預案的有效性進行驗證，也就是我們的預案驗證與演練，在我們的測試環境一定要完整的走一遍預案的流程。對于生產環境，我們可以視具體情況進行相應的演練驗證。

3.3.3   功能預演

  大促時所用到的業務能力，不一定是我們新增的業務功能，還有一部分是歷史沉淀的功能，對于這些能力則需要我們進行一次有效的功能預演，確保我們的功能能夠穩定運行。

3.3.4   內部灰測

   像是我們每一次的大促活動，基本的都會有一些新增的功能提供，對于這些功能，在正式開放對外之前，需要我們進行一次內部小范圍灰測，確保核心能力運行正常。

3.3.5   主會場走查

    大促的某些活動往往都是由一個主會場來承載，在大促節點，不僅僅要關注我們的核心大促活動的單個能力，也要關注整個主會場的各模塊功能是否正常，體驗是否良好等。對于主會場我們可以在上線對外之前由內部產研和業務一起進行一輪人工的走查；不過對于眾多的分會場，我們沒有那么多的人力，可以借用我們當前的自動化巡檢能力來完成C端頁面的巡檢。

3.3.6   故障演練

    我們還可以進行故障演練，以此來提高系統、流程和人員在面對突發狀況的應對能力，真正實現故障快速發現，快速止損，快速恢復，提升系統的整體的穩定性。

4.案例分析

 我們以營銷活動中常見的抽獎功能為例，來看看我們在大促活動中對這些穩定性保障手段的實際應用情況。這里說的抽發獎能力也在我們2022年的周年慶及雙十一的大促活動中承受住了考驗，主要功能是在指定的時間段內定時去抽取部分參與活動的用戶發放優惠券，C端在指定的時間段內連續公示中獎用戶。整體的玩法流程如下：

4.1   核心功能

這里的抽發獎流程中，結合我們的業務玩法來看，可以分析出比較重要的是連續的抽獎能力和后續的發獎能力，保障C端能夠連續的公示出最近中獎的用戶。

以20:00-21:00時間段連續開獎為例，實際上我們服務端會在19:55分即開始了第1輪次的抽獎，抽出20個中獎的用戶，供C端在20:00開始每隔15s展示1個中獎人。實際上也是為了留出5分鐘的應急響應時間。

4.2   穩定性保障

4.2.1   全局評估

    首先我們需要在上線前明確下我們活動的運行周期，比如我們這里的活動是10.26-11.1運行一周的時間，其中開獎的時間是每天的10:00-20:00，那么在10.26活動正式對外的時候，需要協調安排人員值班，關注線上會場運行情況，每天的10:00-20:00開獎時間段需要對應研發測試全天候在線值班。

• 與業務方的溝通中了解到，在其中的某幾天會再購買首頁的中通位投放活動，那么這首頁透出的時間段需要研發同學關注系統水位，關注系統運行情況，適時調整機器進行縮擴容操作。

4.2.2   監控告警

•     接著來看看監控告警這一塊，上面分析了我們的重點要保障的能力，那么我們業務層面的監控就可以從重點能力來展開；以此我們可以得出以下幾個監控點：

• 開獎結果監控（成功/失敗）
• 開獎類型監控（正常/兜底）
• 開獎數量監控（庫存比對）

同時可以將一些非核心的關聯信息打印出來，方便有問題是可以直接獲取信息去排查。

4.2.3   應急響應

• 預案：

接下來重點關注下抽發獎能力相關的預案，假設19:55分開獎異常，那么在這5min的時間里，我們可以做哪些預案呢？下面我們按時間維度來分析一下：

如果滿足抽獎資格的人數不足20人或其他原因導致開出的中獎人數不足20人，未完成當前輪次的開獎，則會基于我們的預案，在接下來的19:56及19:57分再補開2次，只至開出足夠的數據。

這樣可以確保在短時發生了系統或業務異常時依然能夠持續開獎，保障C端用戶不受影響。

以上關于抽獎這塊功能的預案，都屬于系統會自動觸發的類型，無需人工操作，能有效的避免系統及業務異常帶來的負面影響。

預案準備完成，那么我們測試環境就需要針對預案進行驗證，確保我們的預案能夠正常執行，并實現預期的效果，避免在生產發生問題時無法及時處理。

• 灰測&走查：

在活動上線之后，我們和業務方對活動具體配置進行溝通，按生產正式投放標準配置一場測試活動，用于整體功能在生產環境的驗證，進行一輪灰測，確保小流量場景下的功能鏈路能夠正常走通。

灰測正常結束后也不代表就已經完事大吉，業務方對于正式活動的配置，也有可能出現差池，所以在正式活動投放出去之前，還需要進行一場功能預演。前期和業務方溝通達成一致，配置的活動開始時間可以從25日下午開始，產研側可以一起確保配置數據正常，同時可以通過直接訪問H5網頁進行業務功能驗證及整體用戶體驗的評估，確保整體體驗無誤后，活動會在26日0點正式投放對外。

5.總結

    大促相關活動的質量保障壓力會更大一些，需要更多的思考業務異常點和對應的解決方案，需要做更多的保障措施來保證業務及系統的穩定性，需要更大范圍的去探索和實踐質量保障的措施；這不僅僅是質量保障團隊需要考慮和落實的措施，也需要研發、產品、運營和業務團隊共同參與，相互協同來保障整個業務系統的穩定運行，帶來更高的價值產出。