季节性活动将数量、期限和客户期望压缩到短时间内。准备工作应该回答一个实际问题：现有的邮件系统能否提供预期的合法工作负载，同时仍然支持收据、帐户访问和操作警报？更大的活动列表本身并不是容量计划。
排练前冻结假设
记录受众资格、消息类别、目的地分布、计划的发送窗口和预期的交易峰值。记录哪些输入是估计值。在导入期间保留禁止列表和许可历史记录；季节性出口不应默默地重新激活那些选择退出的人。
盘点准确的生产路线和身份验证身份。检查代表性的最终消息，而不是仅查看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模拟。这两个结果都无法预测实时容量或收件箱放置情况。
在启动前准备事件决策
分配谁可以暂停活动、谁处理邮件提供商升级以及谁更新客户支持。使用队列寿命、身份验证失败和错误分布设置具体触发器。不要等到高峰期才决定收入消息是否比帐户访问邮件更重要。
保留活动版本记录，以便可以撤回有问题的模板，而无需停止不相关的收据。测试抑制更改并确保回滚不会恢复旧的受众快照。在重播作业之前协调不确定的提交结果。
活动结束后，按阶段比较计划负荷和实际负荷，并保留例外情况。记录哪些产能假设成立，哪些失败，以及下一季必须改变哪些内容。有用的回顾可以改进运营计划，但不会将一次成功的事件转化为永久的交付保证。