攻击告警并不总是等于业务故障，流量峰值也不一定代表所有请求都是恶意。前 15 分钟的目标是建立共同事实，而不是立刻叠加所有可用规则。
0–3 分钟：确认范围
- 哪些域名、IP、端口和业务受影响。
- 网络层峰值、连接数和请求量是否同时异常。
- 登录、支付、搜索和静态资源是否同样失败。
- 源站 CPU、连接池、数据库和出口带宽是否正常。
3–8 分钟：保护最关键的资产
确认源站地址是否暴露，检查回源白名单和清洗入口是否正常。若攻击已经耗尽源站连接或带宽，应先保护源站，再继续细分请求。不要为了看清攻击而让源站持续承受全部流量。
8–15 分钟：建立处置记录
记录每次规则调整的时间、目标、预期和实际结果。新增规则要说明会影响哪些用户，以及什么条件下撤回。没有记录的连续试错，会让事后无法解释误杀和恢复过程。
判断标准：业务成功率、核心接口延迟和正常用户错误率，比单纯的“已拦截多少请求”更重要。
如果攻击类型仍未确认，保留网络、WAF、CDN 和源站日志，按相同时间窗口对齐。下一步再决定精细化清洗或应用层规则。