黑洞路由触发后，相关流量可能被引导至丢弃路径，攻击压力下降并不代表业务已经具备恢复条件。黑洞路由触发后如何制定业务恢复预案，关键是先确认流量和路由状态，再逐步恢复可用路径，并预先写明失败时如何回退。以下八项可整理成值班人员能直接执行的操作清单。
一、明确触发范围和决策权限
记录触发时间、受影响的网段或服务、执行黑洞路由的人员，以及触发依据。区分单个目标地址受影响，还是整个业务网段被丢弃；确认变更由谁批准、谁操作、谁负责通知。若处置依赖上游网络服务商，预案还应列明联络渠道和升级联系人。
二、保存触发前后的路由证据
操作前后分别保存路由表、路由公告记录、监控截图和告警时间线。采用 BGP RTBH（远程触发黑洞）时，核对目标前缀及服务商约定的社区值；不同网络的社区值和接受策略可能不同，不应照搬其他环境的配置。这样可区分黑洞仍生效、路由已撤销但尚未收敛，还是业务本身另有故障。
三、先确认攻击缓解，再决定恢复
不能仅凭流量下降就撤销黑洞：下降可能是攻击转移、监测点变化，也可能是正常用户同样被丢弃。综合检查边界设备负载、上游反馈、连接成功情况和业务告警。若已具备清洗路径，可先核实清洗设备容量、路由范围及回源链路；流量清洗与直接放行的差别在于前者先过滤异常流量，但需要确认清洗策略不会误拦正常请求。
四、准备明确的恢复路径
列出黑洞撤销后的目标路径，例如恢复原有公告、切至备用网络，或先经清洗后再回源，并逐一写出操作入口、前置检查和责任人。逐项确认路由优先级、地址范围及上游是否接受公告。若备用路径无法承载全部流量，就不能将其视为完整恢复方案，应限制切入规模并保留原有隔离措施。
五、采用分阶段切回
在设备和路由策略支持的情况下，优先小范围验证，再扩大恢复范围；若只能整体切换，则先约定维护窗口和快速回退步骤。每次变更后等待路由状态稳定，再观察业务指标，避免连续改动掩盖问题。DNS 缓存可能使用户在一段时间内仍访问旧目标，因此切换后需同时检查解析结果和实际连接路径。
六、设定验证指标与观察窗口
恢复检查至少覆盖三类证据：网络侧确认目标路由已退出黑洞路径；服务侧确认关键功能可用；用户侧确认不同网络位置均能正常访问。观察窗口应结合业务流量周期、路由收敛情况和告警延迟设定，不能用短暂恢复代替稳定性判断。可以预先定义错误率、响应时延或连接失败率的回退阈值，阈值应采用本系统平时的基线。
七、写清回退和二次触发条件
出现异常时，值班人员应能快速恢复到已验证的安全状态。预案要写明谁有权回退、撤销哪项变更、是否重新启用黑洞，以及何时升级为再次攻击处置。若攻击特征仍存在，直接恢复全部流量可能造成重复中断；此时应优先恢复经过过滤的路径，并保留重新隔离受影响目标的能力。
八、记录通知、复核与解除条件
恢复过程中统一记录时间、命令或工单编号、变更人、观察结果和对外通知。业务恢复后，由网络与业务负责人共同确认告警解除、备用路径状态和遗留限制，再关闭事件。事后复盘应补齐耗时、误拦范围、依赖方响应及预案缺项；不要只写“恢复正常”，而要留下可核验的状态和证据。
执行顺序与常见问题
- 确认受影响对象及黑洞路由状态。
- 确认攻击缓解和可用恢复路径。
- 按预案切回并检查网络、服务与用户侧表现。
- 达到既定观察条件后解除事件；指标恶化则按步骤回退。
黑洞路由撤销后，业务会立即恢复吗？
不一定。路由传播和收敛需要时间，DNS 缓存、应用连接及其他故障也可能影响恢复，应以实际路径和服务检查为准。
攻击流量下降后能否直接恢复全部流量？
不建议只凭流量下降决定。应结合上游反馈和业务指标判断；存在清洗路径时，优先验证其策略与承载能力。
预案中最重要的回退信息是什么？
明确回退触发条件、具体操作、授权人和恢复后的验证项，确保夜间或交接班时也能执行。
归纳来说，黑洞路由触发后如何制定业务恢复预案，应把路由核验、分阶段恢复、业务验证和回退责任写成连续步骤，并在演练中检查每一步是否可执行。