季節性活動將數量、期限和客戶期望壓縮到短時間內。準備工作應該回答一個實際問題：現有的郵件系統能否提供預期的合法工作負載，同時仍支援收據、帳戶存取和操作警報？更大的活動清單本身並不是容量計劃。
排練前凍結假設
記錄受眾資格、訊息類別、目的地分佈、計畫的發送視窗和預期的交易高峰。記錄哪些輸入是估計值。在匯入期間保留禁止清單和許可歷史記錄；季節性出口不應默默地重新啟動那些選擇退出的人。
盤點準確的生產路線和身分驗證身分。檢查代表性的最終訊息，而不是僅查看DNS配置畫面。對範本、供應商、簽名身分或追蹤主機的變更應指定所有者和回溯計畫。除非企業接受額外的不確定性，否則請避免在最後一刻同時進行遷移和重大活動。
排練共享瓶頸
受控演練應練習應用程式調度、提供者提交、回撥處理和支援可見性，而無需發送未經請求的測試郵件。負載測試可以使用本機接收器或授權提供者測試設施；這證明是內部處理，而不是真正的收件者接受。即時路由檢查應使用經批准的受控接收者。
谷歌的寄件者指南警告不要突然爆發。 Yahoo建議透過 IP 或 DKIM 領域。這些記錄在案的建議有助於建立設計審查，但它們並不提供通用的容量權利。 Gmail指南 和 Yahoo最佳實踐.
誠實地計算淨空
綜合容量固定裝置假設內部提交上限為每秒 100 則訊息，估計峰值為每秒 15 個交易訊息。每秒為交易需求保留 25 個，剩下 75 個用於活動提交。按照這個恆定速率，270,000 則訊息的活動至少需要 3,600 秒或一小時。
這些發明的輸入說明了計劃計算，而不是提供者批准的配額或交付承諾。預留每秒包含十則訊息，假設餘裕高於估計值。如果實際需求超過 25，或者提供者降低了接受度，則計劃必須進一步放慢活動速度。重試和不均勻的目標分佈可能會延長完成時間。
保留的確定性調度程序在本次審查中離線重新運行，以每秒 15 次的速度執行相同的 5,000 個緊急作業，以及在零時間排隊的 9,000 個活動作業。總容量仍為每秒 100 個作業。 FIFO 調度在 60 秒佇列目標上產生了 540 個緊急作業，即 10.8%。在此固定模型中，每秒預留 25 個緊急時隙可產生零延遲緊急作業。每個作業都保留創建、發送、提供者接受、接收者接受和應用程式到期時間戳。對於在09:00:00 UTC 建立的第一個作業，FIFO 在09:01:31發送，假設提供者在09:01:32接受，接收者在09:01:33接受；到期時間為09:05:00 。預留調度在09:00:01發送。接受偏移量是綜合假設，而不是SMTP模擬。這兩個結果都無法預測即時容量或收件匣放置情況。
在啟動前準備事件決策
分配誰可以暫停活動、誰處理郵件提供者升級以及誰更新客戶支援。使用佇列壽命、身份驗證失敗和錯誤分佈設定特定觸發器。不要等到高峰期才決定收入訊息是否比帳戶存取郵件更重要。
保留活動版本記錄，以便可以撤回有問題的模板，而無需停止不相關的收據。測試抑制變更並確保回滾不會恢復舊的受眾快照。在重播作業之前協調不確定的提交結果。
活動結束後，依階段比較計畫負荷和實際負荷，並保留例外狀況。記錄哪些產能假設成立，哪些失敗，以及下一季必須改變哪些內容。有用的回顧可以改進營運計劃，但不會將一次成功的事件轉化為永久的交付保證。