DDoS事件复盘报告应包含哪些指标，不能只看攻击峰值。报告还要说明服务受到什么影响、哪些措施生效，以及恢复是否完整。建议把事件时间线、攻击流量、业务影响、防护处置、检测质量和根因改进分成六类，统一记录统计口径，便于技术团队和业务负责人核对。
一、事件时间线与影响范围
记录首次异常、告警触发、确认事件、启动缓解、流量回落和服务恢复的时间，并注明采用的时区。时间点尽量取自监控、网络设备和工单记录；若存在时钟偏差，应在报告中说明。还要列出受影响的域名、IP、端口、协议和业务功能，区分直接受影响的服务与依赖它的系统。
不要把整个异常时段简单合并成一个起止时间。可分别标记攻击开始、缓解生效和恢复稳定的区间，避免把处置前后的指标混在一起。
二、攻击流量与特征
至少记录峰值和分时变化，常用单位包括带宽比特每秒（bps）、数据包每秒（pps）及应用请求每秒（RPS）。注明指标来自网络边界、主机还是应用层；不同采集点的数值不能直接当作同一口径比较。TCP SYN洪泛、UDP洪泛、DNS放大等类型也应分别描述，不能只写“流量异常”。
如能确认，可补充源地址分布、协议与端口分布、连接数及报文特征。源IP数量多不一定代表攻击者数量相同，地址可能经过伪造或代理；地理位置统计也只能作为辅助线索。将攻击期间与相同业务时段的正常基线对照，比孤立的峰值更有解释力。
三、业务与基础设施影响
将网络指标对应到用户实际感受。建议记录服务可用率、请求成功率、响应延迟分位值、超时和错误数量，以及关键功能是否可用。涉及数据库或主机时，可补充连接池、CPU、内存、网络接口丢包等指标，并标明采样间隔和受影响组件。
对外部用户不可见的资源变化也值得记录，例如上游链路是否接近容量上限、递归DNS查询是否延迟。只有当监控能支持结论时，才写明具体影响；不要用单一服务器负载推断所有用户都无法访问。
四、防护措施与处置过程
每项措施都记录启用时间、执行位置、策略内容和结果，包括运营商侧清洗、边界访问控制、速率限制、黑洞路由或应用层验证等。注明策略针对何种流量、覆盖哪些服务，以及是否改变了正常访问路径。
可用下表作为报告骨架：
| 指标类别 | 建议记录内容 | 核对重点 |
|---|---|---|
| 时间与范围 | 告警、处置、恢复时间及目标服务 | 时区、时钟偏差 |
| 攻击流量 | bps、pps、RPS及协议特征 | 采集点、统计区间 |
| 业务影响 | 成功率、延迟、错误与资源状态 | 用户侧与服务侧是否对应 |
| 防护处置 | 策略、启用时间、覆盖范围和结果 | 策略前后变化 |
| 检测质量 | 告警准确性、误拦截与漏报线索 | 正常请求是否受损 |
| 恢复改进 | 恢复验证、根因及责任人与期限 | 措施能否验收 |
五、检测质量与误拦截
报告应交代告警何时出现、由什么信号触发，以及人工确认花了多久。记录被拦截的请求量时，也要检查合法用户是否被误挡，例如来自共享出口的访问是否因过宽规则受影响。若无法准确计算误拦截比例，应明确数据缺口，不要把防护设备的丢弃计数直接当成攻击请求总量。
六、恢复验证、根因与改进
说明攻击流量下降后，如何验证服务恢复：检查关键页面或接口、成功率与延迟，并观察一段适合业务风险的时间。随后区分直接原因、放大因素和处置短板，例如容量余量不足、告警阈值不合适或升级联系人不清晰。每项改进写明负责人、完成期限、验证方法；尚未确认的根因标为待调查。
整理报告的可执行步骤
- 先统一时区、采样间隔、服务清单和指标来源。
- 按事件时间线导出监控、告警、网络设备与工单记录。
- 对照正常基线标出攻击前、处置中和恢复后的变化。
- 由技术与业务人员共同核对影响、误拦截和恢复结论。
- 把改进项落实到负责人、期限和可验证结果。
归根结底，DDoS事件复盘报告应包含哪些指标，要以能解释影响、处置效果和后续行动为准。峰值数字只是起点；口径清晰、证据可追溯、改进可验收，报告才真正便于下一次响应。
常见问题
没有完整流量日志，还能复盘吗？
可以。先用监控图表、设备计数、告警和工单还原可确认的部分，并标出缺失数据及其影响，不要补猜数值。
峰值带宽是不是最重要的指标？
不是。峰值有助于描述流量规模，但业务成功率、延迟、持续时间和防护生效时间，才能说明事件对服务的实际影响。
报告应记录多细的时间粒度？
按监控可用粒度记录，常见做法是保留分钟级趋势；短时突发事件可结合更细的设备日志。不同来源的时间粒度应注明，避免造成虚假的精确感。