防御DDoS攻击提前制定攻击期间业务预案

DDoS攻击期间的业务预案不是“挨打之后怎么救火”，而是攻击发生前就要确定好的一套可执行流程。多数企业把精力放在采购防护设备和流量清洗服务上，却忽略了攻击真正发生时，内部团队如何协作、业务如何降级、客户如何安抚。攻击流量一旦打过来，如果没有人明确知道下一步该做什么，再好的防护设备也会因为响应混乱而失去作用。预案的核心价值在于把决策时间从小时级压缩到分钟级，让每个岗位在高压状态下仍然知道自己的具体动作。

攻击发生前的准备阶段、攻击持续期间的执行阶段、攻击结束后的恢复与复盘阶段。准备阶段要完成资产梳理、防护策略预配置、人员分工和模拟演练。执行阶段要解决的是实时监控、流量调度、业务降级和对外沟通。恢复阶段则关注服务逐步回切、数据核对和攻击溯源。很多预案只写了执行阶段，却忽略了攻击结束后流量突然回切可能造成的二次故障，以及攻击期间临时关闭的防护策略没有及时恢复带来的隐患。

攻击一旦发生，所有系统同时告警，团队很容易陷入到处救火的状态。预案里必须有一份经过业务部门确认的优先级清单，明确哪些服务必须保持可用，哪些可以暂时降级，哪些可以完全关闭。支付、登录、核心API通常属于最高优先级，而评论、站内消息、后台报表等可以延后处理。优先级排序不能只由技术团队决定，必须拉上业务负责人一起确认，否则攻击期间技术团队单方面关闭某个功能，事后很容易引发内部责任争议。

不要等到攻击来了才去调整防火墙规则或者联系清洗服务商。预案中要写明当前所有关键域名的DNS解析方式、是否已接入云防护、回源IP是否隐藏、防火墙基线策略是什么。对于SYN Flood、UDP Flood、HTTP Flood、CC攻击等常见类型，要分别准备对应的防护模板。更重要的是，这些策略必须定期做演练验证，而不是配置完就放在那里。很多企业直到真实攻击发生才发现，所谓的“已接入高防”只是部分子域名接入，主站仍然暴露在真实IP下。

预案里不能只写“运维负责处理攻击”，而要明确谁负责查看流量监控、谁负责联系运营商或防护服务商、谁负责切换DNS、谁负责通知业务方、谁负责对外发布公告。每个角色都要有备份人员，因为攻击很可能发生在节假日或凌晨，主负责人不一定在线。建议建立一个攻击应急通讯群，提前把相关人员的手机号、即时通讯账号都录入进去，并约定好紧急情况下的通知话术和升级路径。攻击期间最忌讳的是所有人都在群里讨论但没有人拍板执行。

攻击初期往往表现为流量异常上升或连接数激增，如果监控阈值设置得过高，告警触发太晚，就会错过最佳处置窗口。预案中要明确哪些指标需要重点监控，包括入向带宽、每秒新建连接数、并发连接数、HTTP请求速率、源IP分布、响应时间等。同时要为这些指标设置合理的告警阈值，并区分预警和告警两个级别。预警级别触发时，值班人员开始关注并准备响应；告警级别触发时，直接启动预案执行流程。阈值设置要结合历史正常流量基线，不能拍脑袋定。

业务降级不是简单地把整个网站关掉，而是有层次地保留核心功能。比如电商网站可以在攻击期间暂时关闭搜索推荐、商品评论、积分查询等非核心模块，只保留商品浏览、下单和支付。内容站点可以暂时切换为静态缓存模式，减少数据库查询压力。预案中要写明每个降级动作的具体操作步骤、执行人和预计影响范围，并且这些降级操作最好能提前做成脚本或一键开关，避免攻击期间手工操作出错。降级方案还要包含恢复步骤，明确攻击结束后按照什么顺序逐步恢复被关闭的功能。

当攻击流量直接打向源站IP时，快速切换DNS解析到高防节点是常见做法。但DNS切换有一个致命问题：生效时间受TTL影响。如果TTL设置过长，切换后大量用户仍然会按照旧解析结果访问源站，导致源站继续被打。预案中必须提前把关键域名的TTL调低，攻击发生前就保持较低值，而不是攻击来了才去改TTL。同时要准备好备用DNS服务商，防止主DNS服务本身也被攻击。切换DNS时还要注意HTTPS证书的兼容性，避免切换后出现证书不匹配的问题。

很多企业以为购买了高防服务就万事大吉，实际上攻击期间能否快速联系到服务商的技术支持，直接决定了处置效率。预案中要写明各服务商的紧急联系电话、工单模板、需要提供的关键信息，包括攻击开始时间、攻击类型、当前流量峰值、受影响业务、源站IP等。最好提前和服务商约定好紧急情况下的升级机制，比如多长时间内必须响应、什么情况下可以直接电话联系值班工程师。如果企业自身有多个机房或带宽供应商，还要明确攻击期间流量如何在多个出口之间调度。

攻击期间用户可能无法正常访问服务，客服团队会收到大量投诉。如果客服不知道发生了什么，只能反复说“正在处理”，用户体验会非常差。预案中要准备面向用户、面向合作伙伴、面向媒体的不同话术模板，说明服务暂时不可用的原因、预计恢复时间和替代访问方式。同时要明确对外发布信息的审批流程，避免技术人员在社交媒体上随意发言造成二次舆情。对于需要向监管机构报告的攻击事件，还要提前了解报告时限和格式要求。

攻击流量停止不代表业务可以立即恢复原状。首先要确认攻击是否真的结束，还是只是暂时减弱。然后按照预案中定义的顺序逐步恢复被降级的功能和服务，每恢复一个模块都要观察一段时间，确认没有异常后再恢复下一个。攻击期间临时修改的防火墙规则、DNS解析、限流策略等，要在恢复阶段逐一核对，该回滚的回滚，该保留的保留。最后要启动攻击复盘，分析攻击类型、流量特征、防护效果、响应时间、暴露出的问题，并输出改进清单，更新到下一版预案中。

纸面上的预案写得再完整，没有经过演练都是空话。建议每季度至少做一次桌面推演，每半年做一次实战演练。桌面推演可以模拟不同类型的攻击场景，让各角色按照预案走一遍流程，重点发现流程衔接上的问题。实战演练则可以在测试环境或低峰时段进行，比如临时触发一次DNS切换、执行一次业务降级脚本、模拟一次告警升级，验证操作步骤是否可行、耗时是否在可接受范围内。演练结束后必须输出问题清单和整改计划，否则演练就变成了走过场。

业务系统在变，攻击手法也在变，预案必须跟着更新。每次业务上线新功能、更换服务器、调整网络架构、接入新的第三方服务，都要评估对攻击预案的影响。至少每半年全面修订一次预案，更新资产清单、人员联系方式、服务商信息、防护策略和降级方案。预案的版本管理也很重要，要明确当前生效版本存放在哪里、谁有权修改、修改后如何通知所有相关人员。最怕的是攻击发生时，大家手里拿着的是一份过时的预案，联系人和系统架构都对不上。

真正有效的DDoS攻击业务预案，本质上是一套让团队在极端压力下依然能保持有序行动的操作系统。它不追求把所有攻击都挡在门外，而是确保即使攻击打进来了，核心业务还能尽量维持，客户影响还能尽量控制，恢复速度还能尽量加快。提前把能做的决策都做掉，把能准备的操作都准备好，攻击真正发生时，团队要做的只是按步骤执行，而不是临时开会讨论。