收到DDoS告警后先记录什么？应急取证与工单信息整理
第一份记录应同时描述告警与业务
收到平台告警时，先记录告警时间、时区、目标资源和告警原文，再核实用户受到什么影响。网站响应变慢、部分地区超时、全部入口无法连接，以及只有后台监控异常，处理优先级和协作对象并不相同。
告警是一条检测结果，不是对事件全部事实的证明。流量突增可能同时包含恶意请求、正常活动流量和客户端重试，不能只凭总量给每个来源贴标签。事件记录应区分“平台判断”“现场观测”和“仍待确认的假设”，避免后续复盘把推测当作已证实结论。
NIST的事件响应建议把准备、检测、响应和恢复放在持续风险管理中考虑。对于网站运维，实际落点是让证据与处置动作都能被追溯。NIST官方指南
网络层与应用层证据分别保存
网络侧记录入站与出站速率、包速率、连接变化和平台提供的丢弃或缓解统计。应用侧记录请求量、错误比例、响应延迟、热点路径与源站资源状态。它们的计量单位不同，不能把每秒请求数直接写成网络带宽。
例如假设带宽并未达到平时峰值，但某个昂贵查询接口大量超时，应重点检查应用处理压力与请求分布。如果网络入口已经无法到达，而应用日志没有新增请求，则应把入口平台的观测一并交给网络支持。这个区分有助于减少在错误层次反复重启。
平台安全分析通常提供已缓解请求、规则命中和过滤维度，但可能采用采样或限定统计范围。导出时保留时间窗口和过滤条件，避免把一个筛选视图当成全部流量。Cloudflare的安全分析文档可以作为理解这类面板口径的实例。安全分析说明
形成能直接处理的工单
工单应包含受影响的公开服务、资源标识、开始时间、当前是否持续，以及正常业务基线。附上故障时的几个具体请求时间和对应状态，比单张总流量截图更容易关联平台日志。需要提供地址时通过供应商正式支持渠道提交。
写清已经采取的措施：修改了哪条规则、何时开始、作用范围、观察到的结果。不要只写“已经加防护”。如果多个人同时调整，应指定一人维护时间线，防止彼此不知道上一项变更正在生效。
日志和抓包按事件相关范围保存。对外分享前移除会话凭据、客户资料和无关业务正文；保留原始副本并记录导出时间，分析时使用副本。取证不应为了追求完整而无限写盘，使本来就紧张的服务器耗尽空间。
缓解动作需要能观察和撤回
在已有权限与预案内，按证据调整入口限制、应用保护或供应商缓解配置。每次记录预期效果与回退条件，并检查正常用户能否完成核心操作。来源封锁、挑战或限流都可能影响共享网络中的合法用户，不能只看拦截数量增加就认定效果更好。
避免在压力期间进行没有明确目的的反复压测，也不要对可疑来源实施报复性探测。需要扩大证据采集时，先确认采集开销和业务承受能力。平台能提供的上游观测，通常比在已经拥塞的源站无限加日志更合适。
恢复验收和复盘使用同一条时间线
事件结束不能只以告警消失为依据。应确认关键入口、登录或其他核心流程恢复，错误和延迟回到可接受范围，再观察一段与业务节奏相符的时间。临时规则如果继续保留，应写明用途、负责人和复查日期。
复盘记录实际影响时间、证据支持的原因、有效措施和未确认事项。不要把采样峰值包装成全程规模，也不要把一次成功缓解写成对未来攻击的保证。下一步应是补齐监控和预案，让下一次事件更快找到对应人员与证据。