遭遇突发流量时，真正棘手的往往不只是入口拥塞：共享数据库、身份认证或第三方接口也可能被连带拖慢。大流量攻击下业务连续性保障，不能只依赖临时扩容，而要提前约定哪些服务先保、何时切换、切换失败如何退回。
先找出业务链路中的薄弱点
画出从用户请求到核心数据的依赖关系，标明域名解析、网络入口、应用服务、缓存、数据库及外部接口。再按功能区分必须保持的核心流程、可以延迟的非核心流程和可暂停功能。分类应由业务负责人确认，避免技术团队在压力下临时猜测。
同时检查单点依赖：备用站点是否有可用容量，账号和配置是否同步，证书是否有效，数据是否能在允许的时间内恢复。容灾切换只能转移可承接的负载；若主备共用同一网络出口、数据库或身份服务，切换后故障仍可能存在。
把切换条件写成操作规则
预案应包含触发信号、决策人、执行人和退出条件。可综合观察入口流量、错误率、请求延迟、连接耗尽情况及关键交易成功率，不要仅凭流量突然升高就切换，因为真实活动也可能造成峰值。阈值应由平时基线和容量测试确定，并明确观察窗口与升级路径。
一份可执行的切换流程
- 确认影响：核对监控、网络设备和应用日志，区分入口拥塞、资源耗尽与依赖故障，同时记录开始时间及受影响功能。
- 先做局部止损：启用限流、连接数控制或请求排队，保护核心接口；对高成本、非关键功能实施降级，减少计算量和下游调用。
- 评估备用环境：确认备用入口、应用容量、数据状态和依赖可用，再按预案调整流量。采用 DNS 切换时，缓存和解析生效时间会受 TTL、递归解析器及客户端行为影响，不能假定所有用户立即转向。
- 分阶段放量：先导入小部分流量，检查错误率、延迟和关键业务结果；指标稳定后再扩大。若异常加重，按预案回退，避免主备同时承受不受控流量。
- 恢复并复盘：攻击缓解后逐步恢复被降级的功能，核验数据一致性、积压任务和重复提交，再更新阈值、联系人及操作记录。
降级与容灾不是同一件事
降级是在当前环境里减少非必要工作，通常启动快，但无法解决网络链路或站点整体失效；容灾切换是把请求转到另一套承载环境，适合主环境无法继续服务的情况，却会带来数据同步、容量和流量收敛风险。两者可以组合：先保护关键路径，再判断是否需要故障转移。
降级规则应具体到功能及恢复条件，例如暂停非关键的历史记录导出、降低公开内容的刷新频率，同时保留必要的查询与提交流程。被关闭的功能要有明确提示和恢复检查，避免用户重复操作，或让后台积压任务在恢复时形成新的流量峰值。
用演练验证，而不是只保存文档
在低风险时段进行桌面推演和受控切换，逐项验证权限、配置、监控告警、数据同步与回退步骤。可记录从触发到核心功能恢复的耗时，并与业务目标比较；数据恢复点则按可接受的数据丢失范围设定。测试环境和生产环境的网络、容量可能不同，演练结果不能直接视为真实攻击表现。
大流量攻击下业务连续性保障的重点，是让人员能依据同一套规则快速止损、切换和恢复。把依赖、阈值、降级清单和回退条件落实到经过验证的流程，才能缩短攻击对业务的影响，同时降低误切换与恢复失序的风险。
常见问题
流量升高就应该切换吗？
不一定。先判断流量来源、错误率和关键功能状态；若备用环境没有余量，直接切换可能扩大影响。
DNS 切换能立即生效吗？
不能保证。解析缓存和客户端行为会影响生效时间，应提前验证解析配置，并准备其他流量调度方案。
降级时应该优先关闭什么？
优先评估高成本、非核心且可暂停的功能，并确认关闭不会破坏核心流程或造成数据不一致。
多久演练一次？
没有适用于所有业务的固定周期。应在架构、依赖或人员流程发生重要变化后复测，并按业务风险安排定期演练。
