业务规模增长后，防护容量必须在流量峰值到来前完成系统性重新盘点，核心步骤是：梳理资产清单、压测当前阈值、对比增长曲线、分优先级扩容。
这是多数企业在业务翻倍后最容易忽略的隐患,防护系统不像服务器那样有明确的扩容提示，它更像一件穿了很久的铠甲表面完好，但关节处可能已经开裂，当业务规模从日均百万请求涨到千万级，原来的WAF策略、DDoS高防带宽、日志存储空间都会悄悄逼近临界点。
为什么业务规模增长后防护容量会失效
业务增长不是简单的流量数字变大,用户的访问路径变长，API调用次数增加，数据回源频率提高，这些都会让防护链路中的每一个节点承受更大压力。
流量模型变了，旧阈值不再适用
原来的防护策略是基于过去的流量模型配置的,比如限流阈值、连接数上限、CC防护的触发条件，这些都是根据当时业务峰值设定的，当业务规模增长后，正常流量本身就接近甚至超过了原来的告警阈值，导致防护系统频繁误报，或者更糟糕在真正遭受攻击时，防护系统把正常用户和攻击流量一起拦截。
防护设备本身的性能瓶颈
行业共识认为,大多数WAF设备和DDoS高防服务在性能衰减上存在一个临界点：当吞吐量达到额定值的70%左右时，延迟会明显上升，规则匹配效率下降，这不是设备故障，而是硬件资源竞争的结果，业务规模增长后，如果没有提前扩容，防护设备就会成为整个链路的瓶颈。
新业务形态带来的盲区
业务增长往往伴随着新功能的上线直播、短视频、在线客服、文件传输，这些新功能有各自的协议特征和流量模式，原有防护策略未必覆盖，比如以前是纯Web业务，现在加了APP接口，那API防护、Bot管理这些能力就需要重新评估。
重新盘点防护容量的具体操作步骤
第一步：梳理资产与依赖清单
这一步的核心是搞清楚到底有哪些东西需要防护,建议按以下维度逐一核对：
- 域名与子域名：包括新上线的域名、CDN回源域名、静态资源域名
- 业务系统：Web应用、API接口、小程序后端、APP网关
- 数据流向：用户访问入口、WAF节点、源站服务器、数据库
- 防护组件：DDoS高防实例、WAF策略组、速率限制规则、IP黑名单库
操作建议：直接登录云控制台的资产中心或使用CMDB系统导出清单，重点标注近三个月新增的资产，如果发现新增业务没有接入防护，优先补齐。
第二步：采集当前流量基线数据
在业务低峰期（建议凌晨2点到5点）采集一周的流量数据，包括：
- 峰值QPS和平均QPS
- 入向带宽和出向带宽
- 新建连接数和并发连接数
- 请求来源地域分布
- 请求类型占比（GET/POST/WebSocket等）
将这些数据与防护设备上的监控图表做对比,如果设备显示的流量已经超过规格说明书的推荐值，就说明需要扩容了，以简米云WAF为例，控制台的“监控与告警”页面会直接显示当前实例的QPS使用率，当使用率持续超过80%时，系统会给出扩容提示。
第三步：进行压力测试验证真实容量
静态指标看完了,还需要做一次真实的压测，这一步的目的是验证防护设备在满负载时的表现，而不是只看规格参数。
压测建议分三档：
- 1倍当前峰值流量：确认现有配置能正常扛住
- 5倍当前峰值流量：观察延迟和错误率变化
- 2倍当前峰值流量：测试极限容量，找出告警阈值
压测工具可使用wrk、JMeter或云服务商自带的压测平台，注意压测前要通知运维团队，避免触发云平台的限流机制，测试过程中重点观察：WAF的规则命中率是否下降、DDoS高防的回源带宽是否充足、源站服务器的CPU和内存余量。
第四步：对比业务增长曲线制定扩容计划
把当前流量数据和一年前的数据放在一起对比,计算增长比例，然后预测未来6-12个月的流量规模。
对比维度包括：
| 指标 | 去年数据 | 当前数据 | 预估半年后 |
|---|---|---|---|
| 日均请求量 | 200万 | 600万 | 1000万 |
| 峰值QPS | 8000 | 25000 | 40000 |
| 入向带宽 | 300Mbps | 800Mbps | 5Gbps |
| 日志量 | 20GB/天 | 60GB/天 | 120GB/天 |
扩容原则建议：防护容量按照预估峰值的1.5到2倍进行预留，因为攻击流量往往会叠加在业务流量之上，如果只按预估峰值扩容，一旦遇到大流量攻击，防护设备依然会先于业务崩溃。
第五步：分优先级执行扩容
不是所有组件都需要同时扩容,按照业务影响程度排序：
- DDoS高防带宽：这是最紧急的，因为大流量攻击可以直接打垮整个业务
- WAF实例规格：影响所有HTTP/HTTPS请求的安全检测
- 日志存储容量：影响事后溯源和安全审计
- 速率限制规则：需要根据新的业务基线重新配置
扩容时注意弹性扩缩容策略的配置,多数云厂商的WAF和DDoS高防支持按量付费模式，可以在业务高峰时段临时扩容，低谷时段缩容以节省成本。
网站防护容量不够用怎么办：常见信号与应对
业务规模增长后,防护容量不够用的信号往往提前出现，如果能在这些信号变严重之前处理，就能避免故障。
用户反馈访问变慢或打不开
这不是网络问题,可能是防护设备已经到达处理极限，排查方法很简单：在业务低峰期临时将WAF切换到观察模式，对比延迟变化，如果延迟明显下降，说明WAF已经拖慢了整体响应速度。
安全告警数量异常增多
业务增长后,正常用户行为本身就更多样化，如果防护系统的告警数量暴增，先不要急着加规则，而是分析告警的准确率，很多情况下是原来的规则已经不适合新的业务模式，需要调整而不是扩容。
日志系统频繁报错
日志是防护系统运行状态的晴雨表,当日志写入速度超过存储系统的处理能力时，日志就会丢失，事后排查攻击事件时无从下手，据行业统计，相当一部分企业在业务翻倍后遇到的第一问题是日志存储不足，而不是防护性能不够。
应对策略：对冷数据做归档压缩，将90天前的日志转存到对象存储服务，只保留近30天的热数据在ES集群中。
不同防护层级的容量评估方法
网络层：DDoS高防带宽评估
DDoS高防的容量评估相对直接,就是看带宽和清洗能力，具体操作：在云盾控制台查看近30天的入向流量峰值，然后对比当前高防实例的保底带宽和弹性带宽。
注意弹性带宽的价格会比保底带宽贵,但业务规模增长后，建议直接提升保底带宽，因为保底带宽决定了高防节点在清洗攻击时能否保障正常流量通过，如果保底带宽设置过低，攻击发生时高防节点会率先拥堵。
应用层：WAF性能评估
WAF的性能评估不只是看QPS,还要看规则数量和请求体大小，规则越多，每个请求的检测时间越长，请求体越大，内存占用越高，如果业务有大量文件上传功能，WAF的请求体限制设置就非常关键。
压测WAF时,除了关注QPS，还要关注一个容易被忽视的指标：P99延迟，P99延迟代表最慢的1%请求的响应时间，这个指标更能反映WAF在高负载时的稳定性，当P99延迟超过500ms时，用户就会明显感知到页面卡顿。
数据层：日志与存储容量评估
日志存储的评估公式是：日均请求量 × 平均单条日志大小 × 保存周期，以一个日均1000万请求的业务为例，单条日志约200字节，一天就是2GB，保存30天需要60GB存储空间，如果日志中需要记录完整的请求头和响应体，这个数字会膨胀5到10倍。
建议给日志存储预留30%的冗余空间，因为攻击发生时日志量会暴涨，平时够用的空间在攻击期间可能迅速填满。
Q&A：防护容量相关常见问题
问：云WAF和硬件WAF在容量规划上有什么区别？
云WAF采用弹性架构,容量上限由厂商的集群资源决定，扩容只需在控制台升配，分钟级生效，但受限于公网带宽和回源链路，硬件WAF的容量在采购时就已固定，升级需要重新采购设备，部署周期以天甚至周计算，但延迟更低，适合对数据主权有严格要求的内网部署场景，业务规模增长较快时，云WAF的灵活性优势更明显。
问：如何估算DDoS高防的带宽容量需要多大？
一个实用的估算方法是：取过去30天业务峰值带宽的2倍作为保底带宽，再在保底带宽基础上加50%作为弹性带宽，比如业务峰值为500Mbps，保底带宽建议1Gbps，弹性带宽加到1.5Gbps，这个估算方法考虑到了攻击流量和业务流量叠加的场景，同时避免保底带宽过大造成的成本浪费。
问：业务规模增长后，原有防护策略需要调整吗？
需要,特别是速率限制、IP黑白名单、地区封禁这类基于统计的防护策略，业务增长后，原来的频率阈值可能已经低于正常用户的访问频率，造成大量误拦截，建议每季度重新统计一次正常用户的访问行为基线，更新速率限制规则，同时检查黑名单中的IP段是否包含云服务商的出口IP，避免误伤使用云服务的正常用户。