面对下一次攻击，容量预留的核心原则是：先定恢复目标，再算冗余，最后用预案兜底，没有预案的容量是摆设，没有容量的预案是空话，两者必须绑定设计。
容量预留方案怎么做：四个步骤定出真实需求
很多团队把容量预留简单理解为“多买几台服务器”，结果不是浪费预算就是攻击来临时依然不够用，业内专家指出，容量预留的本质是对未知流量做有边界的假设，再把这些假设变成可执行的资源池，下面这套流程可以直接拿来用。
第一步：给业务流量画基线
打开你现有的监控系统,拉取最近90天的QPS、带宽、并发连接数曲线，重点看三个值：日均峰值、周内高峰、活动大促峰值，这三个值分别对应日常预留、弹性应对、极端场景三档水位，不要用平均值，攻击流量从来不看平均值。
比如一个电商网站,日常峰值是2000 QPS，周末能到3500 QPS，大促时冲到8000 QPS，那么你的容量预留基线至少是3500 QPS，而不是2000，如果只按平均值预留，攻击流量一进来，源站立刻被打满。
第二步：把攻击流量拆成三种类型
不同类型的攻击对容量消耗完全不同,预留方案也得分开算：
- 流量型攻击（如UDP Flood）：消耗带宽和防火墙性能，预留重点在云高防的清洗能力，一般按基线的3到5倍余量准备。
- 连接型攻击（如SYN Flood）：消耗并发连接表和负载均衡性能，预留重点在LB的并发规格和后端服务器的连接数上限。
- 应用层攻击（如CC攻击）：消耗CPU、内存、数据库连接池，预留重点在应用节点的横向扩展能力和缓存命中率。
每个类型单独画一条预留曲线,最后取各维度的最大值，这个值才是真实容量底线，很多团队只按带宽预留，忽略了连接数和CPU，结果攻击一来，带宽没满，服务先卡死。
第三步：把备份链路和弹性资源做成双层预留
单靠一台高防或者单一云厂商的弹性池,等于把鸡蛋放一个篮子，实际做法是分两层：
- 第一层：主云厂商的弹性伸缩组，设置好触发规则（CPU超过70%持续5分钟就扩容）。
- 第二层：备用链路，比如另一家云厂商的按量计费实例，或者物理机房的临时带宽包，平时不启用，但所有配置、镜像、数据同步都要提前做好。
当第一层扩容到上限依然扛不住时,直接切备用链路，这个切换动作要写进预案，并且每季度演练一次。
第四步：把预留成本控制在预算内
容量预留不是越多越好,而是对业务营收和口碑损失的保险，算一笔账：假设服务宕机1小时损失10万元，那么容量预留投入每年5万元以内都是划算的，如果预算实在有限，优先保障核心链路，边缘业务可以牺牲。
服务器容量预留和按量付费哪个划算：从攻击频率和恢复时间倒推
这是一个很现实的对比,两种方式各有适用场景，关键看你的业务被攻击的概率和恢复容忍度。
高频小攻击：按量付费更灵活
如果你的业务经常被零散的小攻击骚扰,比如单次流量几Gbps，持续十几分钟，那么按量付费+弹性扩容更划算，因为攻击结束后资源立刻释放，费用只按实际使用计算，用按量付费，平时几乎不占成本，攻击来了也能秒级拉起。
低频大攻击：预留实例加竞价资源组合
如果一年只遇到一两次大流量攻击,但每次都需要几十Gbps的清洗能力，这时候预留大量包月实例就很亏，行业共识认为，包年包月预留20%的核心容量，剩余80%用按量付费+竞价实例，竞价实例价格大约只有按量付费的两折，但存在被回收风险，所以只适合无状态的计算节点，不适合数据库。
混合策略：核心链路预留，边缘业务按量
实操中推荐混合方案,核心服务（用户登录、支付、订单）用包年包月预留实例，保证性能稳定，非核心服务（资讯页、推荐流）用按量付费弹性伸缩，这样既保证体验，又控制成本。
以下是一个简单的对比表：
| 维度 | 包年包月预留 | 按量付费弹性 |
|---|---|---|
| 成本 | 单价低，但闲置浪费 | 单价高，但不使用不花钱 |
| 扩容速度 | 固定容量，扩容需额外操作 | 自动伸缩，秒级生效 |
| 适用场景 | 稳定业务+核心链路 | 波动业务+攻击临时应对 |
| 风险 | 容量预估不足则失效 | 大流量下费用可能非常高 |
云上容量预留价格为什么差异大：地域和计费模式是主因
同样规格的预留实例,在不同地域可能差出一倍，搞清楚价格差异的来源，才能选到合适的资源。
地域节点影响价格
主流云平台在不同地域的硬件成本、电力成本和带宽资源不同，导致单价不同。
国内一线城市地域价格较高，西部地区和部分二线城市地域价格较低，如果你的业务对延迟不敏感，比如数据分析、离线计算，可以把备份资源放在低价地域，但注意，攻击发生时切换流量也要考虑网络延迟，不能只图便宜。
包月预留与小时级预留的对比
云平台通常提供两种预留方式：
- 包月或包年预留：锁定资源，折扣较大，但中途不用也不退款。
- 小时级实例：按实际运行时间付费，价格是包月价格的约1.5到2倍，但灵活性高。
如果你的攻击预警机制完善,能在攻击来袭前10分钟自动创建实例，那么小时级预留更合适，如果预警能力弱，只能靠人工排查，那还是包月省心。
如何用价格较低的区域做容灾
想省钱又保证可用性,可以采用双活部署：主地域用包年包月实例，备地域用按量实例，备地域平时只跑最小服务（比如一个nginx返回健康检查），攻击时再扩容业务实例，这样备地域的闲置成本极低，但扩容路径已经验证过，具体的购买路径是：进入云平台控制台，选择地域，在“实例规格”中筛选“竞价实例”或“抢占式实例”，详细阅读释放政策后创建。
面向下一次攻击的预案准备：从容量到动作的闭环
容量预留解决的是“资源够不够”的问题，预案准备解决的是“人知道怎么动”的问题，两者缺一不可。
预案里必须写清楚的三件事
- 触发条件：什么指标达到什么值就启动预案？入口带宽超过总预留的80%持续5分钟”，或者“应用CPU超过75%且扩容后无法回落”。
- 决策人：谁有权确认攻击发生？谁有权切换DNS？谁有权联系云厂商？不要写“相关负责人”，要写具体岗位或姓名，没有决策人的预案，执行时全是扯皮。
- 回滚条件：攻击结束后如何恢复正常流量？如何缩容？如何确认残留风险？很多人只写“怎么进预案”，不写“怎么退”，导致攻击结束后资源一直开着，产生额外费用。
容量触发条件与自动扩容脚本
用Terraform或者云平台自带的弹性伸缩API,写好预置脚本，脚本里要包含：
- 新增节点后自动安装安全 agent
- 从自定义镜像拉取最新的应用版本
- 自动挂载到负载均衡后端
- 执行健康检查并注册到服务发现
把这些步骤固化下来,攻击发生时只需要一键执行，或者完全自动触发，强烈建议在非攻击时间段做一次混沌演练，故意把流量打到触发阈值，看系统是否真的能自动扩容，扩容后是否需要手工干预，很多团队写好了脚本但从不执行，攻击来了才发现脚本里的API权限已经过期。
演练频率与检查清单
每年至少做两次全流程演练,每季度做一次桌面推演，检查清单至少包括：
- DNS切换是否在5分钟内生效
- 备用机房或备用地域的实例镜像是否最新
- 日志系统是否完整记录攻击期间的请求
- 告警通知是否同时发送到邮箱、短信、群机器人
- 备份数据是否可以在1小时内恢复
面向下一次攻击的容量预留与预案准备：常见问题
Q1：容量预留应该预留多少才算合理？
没有一个固定百分比,最合理的做法是：先按业务日常峰值的2倍预留基础容量，再叠加攻击带宽的3倍清洗能力，最后根据成本和历史攻击频率上下调整，如果历史攻击峰值是10Gbps，基础容量就按20Gbps的带宽能力预留，清洗能力按30Gbps准备，预算不足时优先保证清洗能力，因为源站带宽被堵死时，再多计算资源也无意义。
Q2：预案准备中最容易忽略的部分是什么？
最容易忽略的是容量释放流程，很多团队只关注扩容，攻击结束后忘记缩容，导致云费用骤增，预案中必须有明确的缩容条件，攻击流量低于基线的30%且稳定运行30分钟后执行缩容”，攻击期间的变更记录也要单独保存，方便事后复盘，多数情况下，忽略了这一部分会导致账单比预期高出一大截。
Q3：如何验证容量预留和预案真的有效？
在非业务高峰期主动制造一次模拟攻击,可以用流量注入工具向测试环境发送预设的DDoS流量，观察监控指标是否按预期触发扩容，切换是否成功，告警是否送达，整个过程记录下来，对比预设的恢复目标，如果实测恢复时间超过预期，说明预案中存在未覆盖的环节，据工信部的公开安全指导意见，企业每年至少进行一次网络安全事件的应急演练，这是合规要求也是自救底线。
容量预留和预案准备不是一次性工程,而是随业务增长和攻击手法演进而持续迭代的过程，把每一次真实攻击都当成一次免费的演练，每次结束后更新基线数据和预案漏洞，下一次面对攻击时就会更从容。