DDoS告警处置年度十项清单：核实、分级与恢复

DDoS告警出现后，先判断是否发生真实攻击，再决定缓解措施，能减少误封正常用户和无效升级。下面这份年度清单可用于检查值班流程、联系人和技术权限是否齐备；它不预设行业，也不以单一流量指标代替业务影响判断。

一、核实告警：先确认信号从哪里来

确认告警来源与时间。记录监测系统名称、触发规则、首次出现时间、持续时间和通知渠道。核对设备或服务是否处于维护、发布、促销等已知变更窗口；变更只能解释异常，不能直接证明没有攻击。
交叉检查不同观测点。查看网络运营商、云平台或本地设备提供的流量与连接记录，并对照应用侧的请求错误、超时和用户反馈。DDoS告警若只在单一探针出现，先排查探针失联、采样变化和数据延迟。
判断流量类型与目标。辨认异常更接近大流量耗尽链路、协议层连接消耗，还是针对应用功能的请求洪泛；确认受影响的公网地址、端口、域名或具体服务。源地址分布可作线索，但不能仅凭少数地址判定攻击者身份。

评估实际影响。记录外部用户能否访问、哪些功能失败、影响是否扩大，以及备用入口是否可用。区分“指标异常但服务可用”和“关键服务已不可达”，据此确定响应级别与通知对象。
先做低风险缓解。检查是否有不必要的公网服务暴露；对明确异常的请求，可在边界设备或应用策略中采取适度的速率限制。保留规则变更记录和回退办法，避免把共享出口、移动网络用户或搜索引擎访问一并拦截。
评估上游清洗。当入口链路已被挤满时，单在源站限流通常来不及，需联系网络运营商或云服务商评估流量清洗。它适用于需要在到达受保护网络前过滤攻击流量的情况，但接入方式、可清洗类型和服务影响取决于具体合同与网络架构。
谨慎使用黑洞路由。黑洞路由可将被攻击的目标流量丢弃，以保护其他网络资源；代价是该目标的正常流量也可能无法到达。只有当保全其他服务优先于维持受攻击目标可用，且授权人员确认范围后，才应考虑实施。
指定指挥与沟通责任人。明确谁负责技术操作、谁批准高影响变更、谁向业务团队和用户更新状态。DDoS告警升级时，使用统一时间线记录决策、执行结果和下一次复查时间，避免多人重复下令。

设定解除条件。不要仅因流量短暂回落就立即撤销措施。结合告警趋势、服务可用性和业务方确认，分阶段恢复原策略；解除后继续观察一段适合本系统的时间，留意异常是否反弹。
保存必要证据。归档告警通知、流量摘要、规则变更、服务商工单和处置时间线。按组织的访问控制和留存制度保存，限制敏感数据的接触范围；无需为复盘无限收集个人信息。
复盘并验证预案。在事件后检查发现是否及时、升级联系人是否有效、缓解措施是否带来误伤，以及服务商协作是否顺畅。每年至少复核联系人、权限、备用沟通渠道和回退步骤；桌面演练可检查决策流程，不能替代对实际网络配置的验证。

不一定。业务突增、配置变化或监测异常也可能触发告警，应结合多个观测点和服务表现核实。

若异常请求尚未压满入口，限流可能有帮助；若链路已拥塞，应尽快联系有能力在上游处理流量的一方。具体选择取决于攻击位置和网络架构。

在异常趋势稳定回落、业务功能恢复且责任人确认后，按计划撤销临时措施并继续观察。DDoS告警的关闭应记录依据，而非只看一条告警是否消失。