带宽升高不等于业务恢复：攻击流量可能先占满接入链路，也可能让应用或数据库过载。制定大流量攻击下的业务连续性方案，应先回答三个问题：谁有权切换、切换后保留哪些功能、满足什么条件才能切回。以下方法适用于提供网站、移动应用或线上服务的组织，不依赖特定行业。
先把切换目标写清楚
准备预案时，分别确定恢复时间目标（RTO）和恢复点目标（RPO）：前者是业务允许中断多久，后者是可接受的数据回退范围。目标应由业务负责人、技术团队共同确认，不能只按设备能力填写。实时交易与可延后处理的查询服务，通常不应使用同一组目标。
再列出服务依赖：入口解析、应用、身份认证、数据库、支付或消息处理等。为每项注明负责人、备用路径、切换权限和验证方式。备用环境若与主环境共用同一出口、账号或故障域，攻击或误操作时仍可能一起失效。
按影响分级，避免盲目切换
确认是攻击还是正常流量增长
同时查看入口流量、有效请求比例、错误率、响应时间及关键依赖负载，并与自身同一时段的基线比较。单看总流量容易误判：活动带来的正常访问增长，和大量无法完成业务的请求，处置方式不同。阈值应通过历史峰值与演练设定；例如可把持续数分钟的错误率异常、接入余量快速下降作为升级信号，具体数值须结合服务容量验证。
设定三级动作
- 观察：指标偏离基线但关键功能正常，增加监控频率并通知值班负责人。
- 保护：启动上游流量清洗、收紧非必要请求配额，并对高成本功能启用限流；保留登录、下单或查询等核心路径，具体取舍按业务排序。
- 切换：主入口持续不可用，或主环境资源已无法安全承载时，由授权人员按预案切至备用环境或简化服务模式，并记录时间、操作人与指标。
流量清洗适合处理入口侧异常流量，但不能修复应用逻辑、数据库或第三方依赖故障。限流能保护剩余容量，却会拒绝部分请求；因此应明确哪些功能先降级、每类用户如何提示，以及请求是否允许稍后重试。
把切换步骤做成可执行清单
- 确认告警来自至少两类指标，并由值班负责人判断是否进入应急状态。
- 冻结非必要发布与配置变更，保存当前监控、日志和关键配置，避免处置中丢失线索。
- 先启用预定的防护和降级策略；若主环境仍不能提供核心服务，再切换入口或启用备用服务。
- 核对备用环境的版本、密钥、依赖连通性与数据状态。使用 PostgreSQL 等数据库时，还要检查复制延迟和写入方向，避免主备同时接收写入造成数据冲突。
- 用内部探测和真实业务流程验证登录、读取、写入及必要的下游操作；逐步放量，观察错误率和延迟是否回稳。
入口切换可能受解析缓存影响，DNS TTL 调低也不代表所有递归解析器都会立刻更新。若采用备用站点，应事先验证证书、会话、数据同步和依赖访问，而不是等攻击发生后临时拼装。
恢复要分阶段，不要立即切回
攻击流量下降只是恢复条件之一。先确认上游防护仍有效、主环境容量稳定、数据一致，再决定是否回切。常见做法是先让少量流量进入主环境，观察一段由团队设定的稳定窗口；无异常后分批提高比例。若备用环境产生了新数据，必须先制定并验证数据合并或反向同步方案，不能直接覆盖。
大流量攻击下的业务连续性方案还应规定解除应急状态的负责人、证据留存要求和事后复盘时限。每次演练至少验证一次备用路径，并记录实际切换耗时、数据差异和未覆盖依赖；发现的问题要落实到责任人与改进日期。
常见问题
只有一个生产环境，怎么准备？
先准备简化服务模式、异地配置备份和可恢复的数据备份，再逐步建设备用环境；明确备份恢复时间，不能把“有备份”当作“能立即接管”。
什么时候应该切换？
当核心功能持续不可用，且已执行的保护措施不能让主环境稳定服务时，按授权流程切换。不要只因流量数字变大就自动切换。
切换后多久可以恢复正常？
取决于入口缓存、数据同步、依赖验证和攻击是否持续。用演练测得的实际耗时制定目标，并为异常回退留出时间。
怎样避免反复切换？
预先设定进入、退出和回退条件；回切前先小比例验证，并确保同一时刻只有明确的写入主端。
