DDoS防御业务的高峰期不是“带宽被打满”那一刻才开始的，而是在攻击流量突然超过日常基线、同时正常业务又必须保持可用时，防御策略、资源调度和应急流程同时承压的状态。制定高峰期防护预案，核心要解决三个问题：攻击峰值预估、清洗资源弹性、业务降级与隔离的优先级。预案如果只写“发现攻击联系运营商”，基本等于没有预案。

先确定业务高峰和攻击高峰是否重叠

很多团队做预案时默认攻击发生在业务最高峰，但实际情况更复杂。电商大促、游戏开服、在线教育放榜这类业务高峰，往往也是竞争对手或勒索团伙发起攻击的高概率时段。预案第一步要把时间轴拆开：业务高峰的持续时间、历史同时段的攻击记录、攻击类型分布。比如过去三次大促期间，SYN Flood和HTTP Flood的比例是多少，攻击峰值是日常的几倍，攻击持续最长多久。这些数据决定了清洗设备要预留多少冗余，而不是拍脑袋定一个“按日常三倍准备”。

如果业务高峰和攻击高峰高度重叠，防御策略就不能只依赖云端清洗的“先牵引后回注”，因为牵引本身会增加时延，对实时交易类业务影响明显。此时需要把防御节点前置到业务入口更近的位置，或者启用本地清洗设备加云端备用的混合模式。预案里要明确：当攻击流量超过本地清洗阈值时，自动切换云清洗的触发条件是什么，切换过程中允许的最大丢包率和时延是多少。

清洗资源弹性是预案中最容易失效的部分

高峰期防御失败最常见的原因不是没有清洗能力，而是清洗资源被单点耗尽。比如一台清洗设备同时处理多个客户流量，某个客户突然遭受超大流量攻击，设备CPU或会话表先被打满，其他客户的正常流量也被连带影响。预案必须把“资源隔离”写清楚：不同业务是否共用清洗集群，如果共用，单个业务的最大清洗带宽上限是多少，达到上限后是限速还是丢弃，是否触发独立清洗通道。

云清洗服务商通常宣称T级防护能力，但实际调度到单个IP或单个业务时，可用清洗资源远小于标称值。预案中要和服务商确认：高峰期是否保证独享清洗节点，攻击流量超过承诺值后的处理策略是黑洞还是继续清洗，黑洞的触发阈值和恢复时间是多少。很多事故发生在“服务商说能扛500G，实际攻击到300G就把IP黑洞了”，因为清洗集群整体负载已经很高。

如果自建清洗系统，预案要包含清洗设备本身的性能基线。高峰期前做一次压力测试，记录设备在模拟攻击下的吞吐、新建会话速率、并发连接数上限。攻击类型不同，瓶颈点不同：SYN Flood打的是新建速率，HTTP Flood打的是应用层处理能力，UDP反射放大打的是带宽和包转发率。预案中要针对每种攻击类型列出对应的资源瓶颈和扩容手段，而不是笼统写“增加清洗设备”。

业务降级和隔离的优先级必须提前定好

高峰期防御不能追求“所有业务都正常”，这不现实。攻击流量大到一定程度时，必须牺牲部分非核心功能来保住核心交易链路。预案里要有一个明确的业务优先级表：哪些接口可以限流，哪些页面可以静态化，哪些功能可以暂时关闭，哪些用户请求可以排队。比如登录接口被HTTP Flood打满时，可以先对非活跃用户启用验证码，再对风控评分低的请求直接拒绝，最后才考虑限制整体登录频率。

隔离策略同样关键。攻击者经常针对某个活动页面或某个API接口发起精准打击，如果这个接口和核心业务共用同一套后端服务，攻击会导致整个服务不可用。预案要规定：哪些接口在检测到异常流量时可以自动从主服务中剥离，转发到独立的降级服务或直接返回静态提示页。剥离动作的执行时间、回滚条件、对用户体验的影响都要写清楚。

对于多租户或平台型业务，还要考虑“受害者隔离”。一个租户被攻击，不能影响其他租户。预案中要明确租户级的流量限速、连接数限制和独立清洗策略。如果某个租户的攻击流量超过预设上限，是将其流量单独牵引到清洗节点，还是直接对该租户做访问限制，需要提前和业务方确认授权。

高峰期监控和自动化响应链路

高峰期人工处理DDoS攻击基本来不及。从发现异常到启动清洗，如果靠人工判断和操作，往往要几分钟到十几分钟，而攻击流量可能在几十秒内就打满带宽。预案必须包含自动化检测和响应流程：流量基线如何动态计算，异常阈值如何设定，触发后自动执行哪些动作，自动化失败时人工介入的兜底方案是什么。

检测层面，不能只看总带宽，要结合包速率、新建连接速率、特定协议占比、源IP分布熵值等指标。比如一个正常业务突然出现大量来自同一网段的UDP小包，即使总带宽不高，也可能是反射攻击的前兆。预案中要列出关键监控指标和告警阈值，以及不同告警级别对应的响应动作。

自动化响应层面，建议把动作分级：一级动作是自动启用本地限速和过滤规则，二级动作是自动通知云清洗并开始流量牵引，三级动作是自动执行业务降级和隔离。每一级动作都要有明确的触发条件和回退机制。自动化脚本或平台在高峰期前要做演练，确认在攻击真实发生时能按预期执行，而不是因为配置错误导致正常流量被误杀。

高峰期防护预案的实战演练和更新机制

预案写完后不演练，等于没有预案。高峰期前至少要做一次完整的模拟攻击演练，覆盖从检测、告警、自动化响应、人工介入到业务恢复的全流程。演练中要记录每个环节的实际耗时，和预案中的目标值对比，找出差距。比如预案要求30秒内完成云清洗切换，实际演练发现DNS解析变更生效需要3分钟，这就必须调整方案，比如提前将业务域名解析到高防IP，或者使用BGP宣告方式缩短切换时间。

演练还要模拟极端场景：攻击流量超过预估峰值、清洗服务商节点故障、自动化系统本身被攻击或出现误判。这些场景下如何手动接管，如何联系备用清洗资源，如何快速恢复业务，都要在预案中有明确步骤和责任人。

预案更新机制同样重要。业务架构、攻击手法、清洗服务商能力都在变化，预案不能一年不变。每次高峰期结束后，要复盘实际攻击情况和预案执行效果，把新的攻击特征、有效的防御策略、暴露的问题更新到预案中。至少每季度做一次预案评审，确认联系人、资源配额、技术方案仍然有效。

容易被忽略的细节：证书、DNS和源站保护

高峰期防御失败有时不是因为清洗能力不够，而是因为一些基础配置问题。比如启用云清洗后，HTTPS证书没有同步到清洗节点，导致用户访问时证书错误；或者DNS解析切换后，部分用户因为本地DNS缓存仍然访问源站IP，攻击流量绕过清洗直接打到源站。预案中要包含这些细节的检查清单：证书是否在所有清洗节点生效，DNS TTL是否提前调低，源站IP是否做了严格的白名单访问控制，是否关闭了源站对外暴露的所有非必要端口。

源站保护是高峰期防御的最后一道防线。即使清洗系统正常工作，攻击者仍然可能通过历史DNS记录、搜索引擎缓存、第三方接口等方式获取源站真实IP，然后直接攻击源站。预案要规定：高峰期前是否更换源站IP，更换后如何快速更新所有业务配置，源站防火墙是否只允许清洗节点回源IP访问，其他来源一律拒绝。

还有一个常被忽视的问题是回源带宽。清洗完成后，正常流量要从清洗节点回源到源站，如果源站本身的接入带宽小于正常业务流量加清洗后残留的攻击流量，源站仍然会被打满。预案中要评估源站带宽是否足够，是否需要临时扩容，或者将部分静态资源缓存到清洗节点，减少回源压力。

高峰期DDoS防御预案的本质是“在资源有限的前提下，保证核心业务可用的决策和执行框架”。它需要把攻击预估、资源调度、业务取舍、自动化响应和基础配置检查全部串起来，并且通过演练验证每个环节的可靠性。没有经过实战检验的预案，在真正的攻击高峰期往往只是一份安慰剂。