按步骤迁移受攻击业务：清洗接入、灰度切换与回退

攻击期间临时改路由，容易让处置、验证和恢复互相打架。要让受攻击业务迁移至清洗集群的实施步骤真正缩短接入时间，先明确哪些业务受影响、流量将经过哪里，再按准备、切换、验证、回退的顺序操作。具体操作会因网络拓扑、清洗能力和业务依赖而异，以下流程适用于需要把受保护业务流量导向清洗集群的常见场景。

先划清迁移范围，保留可恢复的基线

不要一开始就切换所有业务。整理受攻击的地址、关联服务、正常入口和依赖关系，区分必须优先恢复的核心服务与可暂缓迁移的部分。记录切换前的请求成功率、响应时延、连接数、回源流量和错误类型，作为前后对照基线。

同时指定操作负责人、观察人员和回退决策人，约定变更窗口、通知方式及停止条件。保存当前路由与策略配置，并确认谁有权限恢复原链路。这样即使切换中断，也不必临时寻找配置或判断由谁操作。

核对清洗集群容量。确认可接收的业务范围、可用处理能力、健康状态和告警情况。容量评估要结合攻击流量、正常峰值及流量突增余量；不存在适用于所有环境的固定安全值，无法确认承载能力时不要直接全量导入。
准备清洗策略。将必要的放行规则、限速或挑战策略按业务需求配置，并检查规则顺序与作用范围。先用管理界面或配置校验功能复核，避免宽泛规则误伤正常访问。保留可回退的旧版本。
验证回源链路。从清洗集群侧检查到源站的网络连通、端口可达、路由可返回以及源站是否接受经清洗后的连接。若源站有访问控制，还需确认允许清洗出口访问；同时核实应用依赖和健康检查结果。
执行灰度切换。根据架构选择路由发布、入口配置或其他受控的流量牵引方式。若支持按比例或业务分组切流，可从小比例开始，观察稳定后逐级扩大；每一级观察时长应覆盖该业务的典型请求周期和负载变化，不能只凭短暂正常就全量切换。
逐项验收并记录。对照基线检查业务成功率、响应时间、清洗侧告警、源站负载和回源链路状态，并从实际用户入口验证关键功能。确认流量确实经过清洗集群，而不是仅看到控制台配置已更新。

预先写明回退触发条件，例如成功率明显低于基线、源站负载异常上升、合法请求被大量拦截，或清洗集群健康状态恶化。达到条件后，暂停扩大流量，按变更方案恢复上一条可用路径；随后核对流量是否回到预期入口、源站是否恢复正常，再定位策略、路由或容量问题。回退后保留变更记录和告警时间，避免未经验证便重复切换。

清洗策略应先解决当前攻击影响，不宜在故障排查中同时大幅调整多类规则。一次只改动有限项目，并记录改动前后效果，才能分辨问题来自策略误伤、路径不通还是集群承载不足。

不必。若架构支持分组或比例控制，灰度切换更便于发现问题；依赖关系复杂、无法独立切分的业务，应先完成整体链路验证再变更。

当业务指标在覆盖典型请求与负载变化的观察期内稳定，清洗侧和源站侧数据一致，且回退方案仍可执行时，再结束本轮监控。观察时间取决于业务周期与攻击变化。

检查策略命中是否符合预期、源站负载是否可控、关键功能是否可用，并确认告警和责任人仍能覆盖新的流量路径。

把基线、策略、流量牵引和回退条件提前准备好，才能让受攻击业务迁移至清洗集群的实施步骤既可执行又可恢复；每一步验证通过后再扩大范围，通常比临场全量切换更容易控制风险。