拒绝服务攻击应急响应中的跨团队协作清单，重点不是让所有人同时操作，而是明确谁负责判断、谁能执行变更、信息如何汇总，以及何时升级处置。流量异常时，团队若各自限流、切换或通知用户，可能相互抵消，甚至让正常服务更难恢复。
先定职责：一个人统筹，多组按权限行动
事件开始后，应指定事件负责人统一维护时间线、分配任务和记录决策。安全团队负责研判攻击特征与影响范围；网络或平台团队检查链路、边缘防护和容量；业务负责人确认关键功能及可接受的降级；客服与沟通人员准备对内、对外说明。若涉及托管服务或内容分发网络（CDN），同步通知相应服务商的应急支持渠道。
执行权限也要提前说清：谁可以调整流量策略，谁批准关闭非核心功能，谁负责回滚。值班人员可以先采取已授权的低风险措施；涉及全站访问、交易流程或数据处理的变更，应由业务负责人确认影响后实施。避免在多个群组中出现互相矛盾的指令。
统一信息：把现象、影响和未知项分开
协作信息应简短且可核对。每次更新至少记录发生时间、受影响的服务或区域、用户可见症状、已采取措施、当前结果和下一次更新时间。注明信息来自监控、用户反馈还是服务商告警；尚未确认的原因标为“待核实”，不要把流量激增直接等同于攻击已归因。
优先共享能推动决策的信息：错误率或请求延迟是否异常、哪些功能仍可用、缓解措施是否影响正常用户、是否存在容量或上游依赖限制。保留相关日志、告警和配置变更记录，并按组织的安全与隐私要求控制访问和保存。
按顺序处置：观察、缓解、验证、恢复
- 确认影响。对照服务监控、边缘防护告警和客服反馈，判断异常是否集中在特定入口、功能或地区。先确认业务影响，不凭单一告警贸然扩大处置范围。
- 选择缓解方式。由安全与网络团队评估上游流量清洗、CDN缓存、速率限制或临时挑战等措施。缓存适合可缓存内容；速率限制可用于保护特定入口，但阈值过严可能误伤共享网络中的正常用户。具体配置应依据服务特性和实时监测逐步调整。
- 小范围验证。记录变更人、时间、目标和回滚办法。先观察受影响入口及关键业务指标，再决定是否扩大措施；若错误率上升或正常访问明显受阻，立即复核规则并按预案回退。
- 协调服务商与沟通。提供时间范围、受影响资源、观察到的现象和已经尝试的措施，避免只发送“网站不可用”。客服使用经业务负责人确认的统一口径，区分已确认事实与仍在调查的内容。
- 分阶段恢复。攻击压力缓和后，不要一次撤销全部防护。按预先约定的观察窗口逐步恢复功能，确认关键路径稳定，并持续检查限流规则是否仍造成误拦截。
用清单交接，减少重复判断
- 事件负责人、技术执行人、业务批准人和沟通联系人均已明确。
- 影响范围、已知事实、未知事项及更新时间已写入共享记录。
- 每项变更都有执行人、验证指标和回滚条件。
- 外部服务商已收到可操作的故障描述与联络方式。
- 解除措施前，业务、安全和平台团队共同确认风险。
事件结束后，复盘重点放在协作是否顺畅：告警是否及时到达、权限是否清晰、信息是否重复或冲突、缓解措施是否可回退。将发现的问题落实为负责人和期限，并更新值班通讯录、预案及演练内容。这样，拒绝服务攻击应急响应中的跨团队协作清单才能从一次性记录变成可执行的工作机制。
常见问题
是否要等确认攻击后再启动协作？
不必。服务影响达到组织设定的升级条件时，可先启动事件协调，同时继续核实原因。
客服可以自行发布故障说明吗？
客服可使用已批准的模板；涉及影响范围、恢复时间或原因的新增判断，应先由事件负责人和业务负责人确认。
什么时候可以解除限流或其他防护？
没有适用于所有服务的固定时间。应结合流量变化、错误率、正常用户访问和业务指标，分阶段验证后再调整。
复盘需要记录哪些内容？
记录事件时间线、影响、决策依据、配置变更、沟通情况、回滚过程及后续改进负责人，避免只留下技术告警截图。