攻击来临时，最先暴露的未必是服务器性能不足，也可能是出口带宽、第三方服务或恢复流程不够用。攻击流量峰值下的业务连续性与灾备设计，不能只按平日账单配置资源，而应先确定哪些业务必须维持、能承受多长中断，再为不同风险层级安排容量和恢复手段。
先算清峰值成本由什么组成
成本不只是临时扩容的计算资源，还包括流量清洗、带宽或数据传输费用、备用环境、备份存储，以及监控和演练的人力。不同云服务商的计费口径不同，尤其要核对按量计费项目、流量计费方向和突发容量限制。
用历史监控数据建立基线：记录正常时段的请求量、出口流量、关键服务资源占用和业务交易量，再对照促销发布、报名开放等已知高峰。若历史数据不足，可先用压测结果和业务预估形成区间，并以约 1.3 至 1.5 倍的容量余量做初步方案；这只是容量规划起点，实际值应由压测、服务限额和成本承受能力校准。
预算可拆成“常态运行费用＋备用能力费用＋峰值期间的增量费用＋恢复与演练费用”。不要把攻击峰值简单视作正常容量的永久标准，否则可能长期为闲置资源付费；也不要只看峰值账单，忽略超额流量、依赖服务故障和人工处置时间。
按业务重要性分层，而非全站同规格
核心交易与关键数据
下单、支付确认、身份校验等关键流程，应优先保障正确性和可恢复性。为数据设定 RPO（可接受的数据丢失范围）和 RTO（恢复目标时间），并验证备份能否实际恢复。备份可采用独立账号或权限边界、版本保留与定期恢复测试，降低生产环境故障同时影响备份的风险。
可延迟或可降级的功能
搜索、推荐、报表、图片处理等功能，可根据业务影响降低更新频率、暂停非必要任务，或展示缓存内容。限流和队列能够控制进入后端的工作量，但队列积压也可能延长处理时间；必须设置容量上限、过期规则和恢复后的消费速度，避免积压反过来拖垮系统。
根据恢复速度选择灾备形态
冷备主要保留备份和恢复文档，平时费用较低，但恢复依赖临时准备资源，适合中断容忍度较高的服务。温备保留部分已部署资源，恢复通常更快，代价是持续运行与同步成本。双活或多活能缩短切换时间，但要处理数据一致性、跨区域通信和故障切换复杂度，并不适合所有系统。攻击流量峰值下的业务连续性与灾备设计，应把这些差异写入服务等级和预算，而不是只按架构名称做选择。
若难以确定，可先从关键服务的恢复目标倒推：要求恢复时间短、数据丢失容忍低，通常需要持续复制、可用的备用资源和自动化切换；可以接受较长恢复时间的非核心功能，则可采用定期备份与人工恢复。无论采用哪种方式，都要验证备用环境容量，不要默认生产环境的峰值流量可以不经调整直接切入灾备。
把方案变成可执行的处置流程
- 划定业务等级：列出关键用户路径、依赖服务、责任人，以及每项服务的 RTO 和 RPO。
- 设置分层防护：在入口侧启用流量清洗和速率限制；对可缓存内容使用 CDN；后端为关键请求预留资源，并为非核心任务设置降级开关。
- 建立峰值告警：监测流量、请求成功率、延迟、队列长度和成本变化。阈值应结合正常基线与压测结果设置，避免单一指标触发错误切换。
- 按预案演练：在非高峰窗口验证切换、备份恢复和权限流程，记录恢复耗时、数据差异及未覆盖依赖，再修订容量与预算。
常见问题
问：是否需要按攻击峰值长期购买全部容量？
答：不一定。可将基础容量、弹性资源和备用环境分开核算，并确认供应商的扩容上限和触发时间。
问：流量清洗后就能保证业务连续吗？
答：不能。它主要处理入口流量风险，应用依赖、数据库容量和故障恢复仍需单独设计。
问：备份是否等于灾备？
答：不是。备份保存数据，灾备还要具备可用环境、恢复步骤、权限和经过验证的切换能力。
问：从哪里开始最实际？
答：先选一条关键业务路径，测出正常与高峰容量，明确 RTO、RPO，再做一次恢复演练。以此校正攻击流量峰值下的业务连续性与灾备设计，通常比一次性建设全量冗余更可控。
