总结
- Akamai 2021 年 6 月 17 日的更新指出，一次 Prolexic Routed 3.0 服务事件影响了部分使用路由式 DDoS 缓解服务的客户，警报于美国东部时间上午 8:47 启动，客户流量自动或手动重新路由，直至服务恢复。
- 责任问题是委托式缓解。客户通过清洗服务发送流量以抵御 DDoS 攻击，但当缓解提供商内部的验证或路由状态失效时，该路由就成了业务连续性依赖。
- Akamai 表示该事件并非由系统更新或网络攻击引起，而是由于一个路由表值意外超出限制。这将分析范围缩小到了运营路由验证、容量/状态控制、重新路由和客户恢复。
- ThousandEyes 的外部测量记录之所以重要，是因为它显示了客户受影响程度的差异以及备份计划的价值。路由式缓解事件应根据客户在防御路径受损时能否安全旁路或回传流量来判断。
- 持久的修复证据应涵盖路由表护栏、预验证旁路、客户通知、自动重新路由范围、人工支持能力、流量回传安全，以及缓解路径不会造成比其试图吸收的攻击规模更大的中断的证明。
委托式缓解改变了连续性控制权
Akamai 的公开更新《Akamai 提供 Prolexic DDoS 服务影响更新》是核心事件记录。该公司表示，Prolexic Routed 3.0 经历了一次服务事件，影响了部分客户。警报于美国东部时间上午 8:47 启动，受影响客户流量由 Akamai 团队自动或手动重新路由，服务于美国东部时间下午 12:47 恢复。它还表示，该事件并非由系统更新或网络攻击引起，问题在于一个路由表值意外超出限制。
这一声明使责任问题变得明确。关键不在于 Akamai 是否遭受攻击，而在于防护服务如何控制客户流量的路径，以及当路径失效时客户如何逃离该路径。DDoS 缓解不仅仅是一个附加安全功能。在路由模型中，它可以成为客户实时网络拓扑的一部分。
Akamai 的 Prolexic 材料将该服务描述为基础设施的 DDoS 防护。Prolexic 产品页面、Prolexic 产品简介页面以及Prolexic 产品简介 PDF解释了其防御目的：在恶意流量到达客户源站之前进行吸收、检查和缓解。后续/当前的产品语言不应被视为 2021 年事件的调查结论，但它阐明了产生依赖的服务模型。
这种依赖很容易被误解。客户可能将 DDoS 缓解视为置于服务前方的盾牌。而路由式设计不仅仅是一面盾牌。它改变了流量到达客户的方式。如果流量通过清洗中心、路由状态、GRE 隧道、直连、回传路径和提供商操作进行通告或重定向，这些都将成为可用性的一部分。当防护路径失效时，客户可能需要一个已经设计、授权、测试并理解的旁路路径。
“旁路”一词至关重要。旁路不是防护服务受损后的慌乱应急措施。它是一种预先规划的方法，用于将流量安全地回传至一条路径，同时权衡客户再次面临恶意流量的风险。客户并不希望在攻击期间随意移除防护。但在缓解提供商中断期间，客户可能需要选择继续通过失效的防御路径，还是通过备份路径暴露源站。这一决定必须在事件发生前设计好。
路由式防护将路由验证转化为客户关怀
Akamai 的服务描述材料之所以重要，是因为它们展示了路由式缓解如何依赖网络控制机制。Akamai 服务描述 PDF描述了 Prolexic Routed 如何通过 BGP 将流量引导至 Akamai 清洗中心。Akamai 关于Prolexic 和 Equinix Cloud Exchange的博客讨论了如何通过互联将 DDoS 防御更靠近客户源站。这些材料并非故障复盘，但它们解释了为何路由控制本身就是服务。
BGP 本身定义于RFC 4271。GRE（常用于缓解架构中的流量回传或隧道设计）定义于RFC 2784。这些标准并未说明 Akamai 在 2021 年做错了或做对了什么。它们澄清了技术词汇：路由通告、流量路径、隧道和回传机制并非背景细节。它们就是产品的表层。
如果提供商的路由表值被超出，客户需要知道这对其流量意味着什么。受影响的状态是否阻止了新的路由编程？是否影响了回传流量？是否只影响了特定客户、特定前缀、特定区域或特定路由关系？Akamai 的公开声明很简短，因此负责任的分析不应编造细节。但这种简短本身提出了修复问题：现在有哪些护栏可防止路由式缓解控制以影响客户可用性的方式超出状态值？
在此背景下，路由验证就是客户关怀。这不仅仅是内部网络工程检查。提供商的验证保护着客户收入、公共门户、API、银行访问、SaaS 应用和面向应急的服务。验证失败将把工作转移到客户运维团队身上，他们必须决定是等待、重新路由、旁路、与用户沟通还是通过支持渠道升级。
RFC 7454《BGP 运营与安全》提供了关于路由策略、过滤和运营规范的通用运营安全期望。MANRS 的网络运营商行动以及 CISA 的保护互联网路由为路由纪律提供了公共和社区框架。这些都是通用参考，并非针对特定事件的调查结论。它们之所以重要，是因为路由式缓解服务将运营商的路由纪律直接置于客户连续性之中。
排版说明
外部测量显示影响各异
ThousandEyes 的Akamai Prolexic Routed 中断分析很有价值，因为它从提供商外部进行观察。它观察到可达性差异、对等行为差异以及客户间的差异。ThousandEyes 随后将该事件列入震撼 2021 年的七次中断，并强调一些拥有充分备份计划的组织能够减少影响。这正是责任教训：路由式缓解故障不仅是提供商的问题；它们也是对客户旁路准备情况和提供商支持重新路由的考验。
影响程度的存在不应变成指责受害者。客户购买 DDoS 缓解服务，是因为他们希望专业提供商来吸收他们无法安全独自处理的问题。如果服务路径失效，提供商仍需对路由安全、状态通知、自动重新路由、支持能力以及事后修复负责。同时，提供关键公共服务的客户需要经过测试的旁路和回退设计，因为没有哪条防护路径能免于故障。
次级报道，包括 SecurityWeek 的《Akamai 将中断归咎于 DDoS 防护服务》和 iTnews 的《Akamai 路由错误导致大面积中断》，描述了影响面向公共服务的中断现象。此类报道可以说明范围，但不应用来断言所有组织的中断持续时间相同或恢复状态一致。路由式缓解对客户的影响因前缀、路由伙伴、旁路计划、应用设计和沟通速度而异。
测量证据还显示了为什么公共路由可见性是必要的。即使客户的源站服务器健康，其网站或 API 也可能不可用。用户看到应用处于宕机状态。客户可能看不到明显的源站问题。提供商可能正在进行重新路由。外部探测可以显示流量在何处失败或恢复。没有这种可见性，响应人员会浪费时间调试错误层次。
对于提供商而言，教训是公开的事后沟通应包含足够的路由和客户影响结构，以使测量有意义。如果公开声明只说“服务事件”，客户无法判断自己的操作手册是否需要更改。如果说明了哪个服务、哪种路由状态失败、流量如何重新路由、哪些自动控制有效、需要哪些人工控制以及哪些复发护栏发生了改变，客户就可以改进自己的架构。
旁路是共享设计，而非临时决策
一个良好的旁路计划包含若干要素。客户知道哪些前缀和服务受到保护。客户知道在始终在线和按需模式下会发生什么。提供商和客户知道谁可以授权流量更改。上游运营商知道是否允许备选通告。DNS、TLS、防火墙、源站访问控制和应用程序限制已为更改后的流量路径做好准备。支持团队知道哪些业务服务优先级最高。沟通模板已为最终用户准备就绪。
缺乏这种设计，旁路可能会带来新的风险。将流量绕过清洗服务可能使源站暴露于该服务本应吸收的攻击之下。将流量留在失效的缓解路径内可能延长中断时间。通告更具体的前缀可能产生路由策略副作用。更改 DNS 可能太慢或依赖缓存。禁用源站限制可能造成安全暴露。当公共服务已经不可用时，这些权衡无法冷静做出。
NIST SP 800-61 修订版 2《计算机安全事件处理指南》是通用指南，但其事件生命周期是相关的：准备、检测、遏制、根除、恢复和总结教训。在路由式缓解中，准备包括了解如何安全地移动流量。恢复包括恢复正常的受保护路由，同时不造成流量激增、泄露或安全缺口。
客户旁路问题也涉及经济因素。中小企业可能没有自己的网络工程人员。他们可能完全依赖提供商和托管主机。如果路由式缓解失败，他们可能不知道哪些前缀被通告、哪些联系人可以批准更改，或者是否存在旁路。向此类客户销售防护服务的提供商应提供实用的操作手册语言，而不仅仅是企业级架构图。
大型企业面临不同的问题。他们可能拥有复杂的网络和多家提供商，但其治理可能缓慢。如果紧急重新路由需要安全、网络、法务、业务和高管团队的批准，旁路可能只停留在纸面上而无法使用。因此，提供商的事件沟通应帮助客户快速做出基于证据的决策。
自动重新路由需要覆盖范围证明
Akamai 的更新提到，受影响的客户流量由 Akamai 团队自动或手动重新路由。这一表述很重要，因为它指出了两种恢复模式。自动重新路由意味着预先构建的故障转移逻辑。手动重新路由意味着对自动路径未覆盖、未完成或需要特定客户处理的情况进行人工干预。责任问题在于事件后这些类别发生了怎样的变化。
自动重新路由应针对现实中的提供商端故障进行测试。仅仅证明重新路由在计划演练或客户请求的切换中有效是不够的。它应在提供商自身路由状态受损、告警量高、许多客户同时需要帮助以及状态沟通面临压力时仍能工作。DDoS 缓解提供商的恢复系统必须设计为能够应对多客户同时受影响，因为该服务本身是共享基础设施。
人工支持能力很重要，因为客户不可能同时排在第一位。提供商可能拥有出色的工程师，但当许多客户同时来电时仍可能面临排队。公开的修复记录应说明人工路由步骤是否减少、更多客户是否获得了自动重新路由、支持操作手册是否变更、以及通知是否更加精确。Akamai 表示将确保每位客户在发生故障时都能自动重新路由到最近清洗中心。这一承诺是一个修复标志，但客户需要后续的完成证据。
流量回传是恢复的另一部分。一旦提供商路径修复，如果路由收敛、缓存行为、防火墙状态、隧道状态或攻击流量未得到管理，将客户流量移回防护状态可能会带来风险。服务可能已恢复，但马虎的回传路径可能造成间歇性故障。因此，事件记录不仅应包括中断开始和结束时间，还应包括流量如何恢复到稳定的受保护状态。
Akamai 的 2021 年 10-K 表格（SEC 文件）提供了更广泛的业务风险背景：Akamai 销售客户用于性能、安全和可用性的服务。该文件并未对 Prolexic 事件做出裁决。它说明了为什么安全与交付基础设施中的提供商中断可能成为客户治理问题。当供应商的角色是连续性时，供应商自身的连续性控制就是产品的一部分。
状态通知应明确依赖关系和决策点
在路由式缓解事件期间，客户需要的不仅仅是通用的可用性通知。他们需要知道受影响的服务是 Prolexic Routed 还是 Akamai 的其他功能，问题是影响所有客户还是部分客户，攻击缓解是否仍处于活动状态，旁路是推荐还是有风险，是否正在进行自动重新路由，以及如果其应用无法访问，客户应采取什么行动。
公众可以容忍事件早期的一些不确定性。但不能容忍的是模糊的安抚，让客户猜测是否要更改路由。状态通知应逐步演进：首先识别受影响的服务和症状；然后识别路由或清洗依赖；然后说明流量是自动还是手动重新路由；然后为客户上报提供指导；最后发布事后说明，解释发生了什么变化。这一过程减少了二次伤害。
Prolexic 事件就是提供商状态与客户操作手册相交织的案例。如果客户的受保护服务宕机，它必须决定是等待提供商重新路由还是激活自己的回退。提供商对服务端故障有最佳视角。客户对业务优先级和本地应用影响有最佳视角。良好的状态通知能让这些视角快速会合。
沟通还应避免过度宽泛的声明。Akamai 表示该事件并非系统更新或网络攻击。这一事实很重要，因为客户可以专注于运营路由恢复，而不是入侵响应。但客户仍需知道自己的服务是否受影响、是否存在攻击流量、以及数据完整性或机密性是否受到牵连。可用性事件的范围应精确界定，以便客户既不过度反应也不应对不足。
对于关键公共服务，状态通知具有社会功能。银行、政府门户、医疗保健接口和通信服务可能需要通知其用户。如果上游缓解提供商的解释具体且及时，下游组织就能准确沟通。如果延迟或模糊，下游通知也会变得模糊。成本转移往往先在不确定性中传播，然后才通过金钱转移。
清洗服务需要故障域透明度
DDoS 清洗有意进行了抽象化。客户不希望管理每个攻击特征、全局容量池、对等关系、隧道或缓解规则。他们购买提供商服务，是因为提供商能够规模化运营专业化防御。但抽象化不应隐藏影响连续性的故障域。客户需要了解提供商路径的哪些部分可能失效，以及他们如何应对。
产品文档可以用受控术语描述这些内容。它可以解释始终在线与按需路由、BGP 通告责任、隧道回传路径、直连选项、最大路由规模、对客户前缀规范性的依赖、紧急旁路程序和支持联系点。它可以说明如果流量自动重新路由到最近清洗中心会发生什么变化。它可以描述在主动攻击期间哪些客户操作是危险的。这些都无需透露敏感的缓解方法。
当安全性和可用性需要权衡时，故障域透明度尤其重要。客户可能选择一种严格的受保护路径，以最大化 DDoS 弹性，但增加对提供商的依赖。另一个客户可能接受更多源站暴露，以换取更快的旁路。这些都是业务决策。它们应基于提供商的证据，而不是在中断期间才发现。
因此，2021 年的事件应成为采购教训。路由式 DDoS 缓解的购买者应询问：如果清洗服务本身出现路由故障会怎样？每个受保护前缀是否都启用了自动重新路由？旁路如何授权？测试频率如何？客户能否看到路由状态？将提供哪些状态详情？流量多久能恢复正常防护？当防护路径本身成为中断路径时，有哪些合同承诺适用？
如果提供商拥有强大的控制措施，他们应欢迎这些问题。它们将痛苦的事件转化为更清晰的客户设计。它们还能减轻下一次事件期间的响应负担，因为拥有经过测试的旁路计划的客户会带着更好的信息来电，并做出更安全的决策。
剩余未知数与责任问题
公开记录并未揭示 Akamai 所识别的路由表值的每个细节。它没有提供按客户划分的停机时间、自动重新路由、人工干预或旁路准备情况的映射。它没有独立验证每个客户后来是否都拥有到最近清洗中心的自动重新路由。它没有显示客户、提供商和上游网络之间的所有合同分配。这些未知数应保持可见。
已知的信息足以定义责任。Akamai 运营着 Prolexic Routed 3.0 服务。该服务使用路由式流量路径来保护客户免受 DDoS 攻击。Akamai 表示一个路由表值被意外超出，受影响的客户被自动或手动重新路由。外部测量显示客户影响各不相同，备份计划至关重要。客户和用户承担了防护依赖变得不可用的后果。
责任问题在于事件后路由式缓解是否变得更安全。Akamai 是否增加了验证以防止路由状态限制变成客户中断？自动重新路由是否按承诺覆盖了所有客户？客户旁路文档是否变得更清晰？状态通知是否更快地识别决策点？流量回传程序是否得到改进？客户是否收到了测试证据或架构指导？该服务是否减少了提供商端故障条件下的人工干预？
答案应根据证据来评判。提供商声明服务已恢复只是开始。事后修复记录、客户操作手册、经过测试的旁路路径以及后续服务行为才是证据。因为 DDoS 缓解是作为敌对压力下的连续性来销售的，所以提供商自身的路由连续性必须达到高标准。
最终教训并非路由式 DDoS 缓解不好。而是委托式防护产生了委托式依赖。客户需要防护路径，但当防御系统受损时，他们还需要一条绕过防护路径的安全路线。Akamai 的 Prolexic 事件使这一设计要求变得可见。责任标准在于这种可见性是否转化为持久的客户控制，而非仅仅一日中断的记忆。
提供商端容量控制需要客户可见的意义
Akamai 的“路由表值”一词必然简洁。它没有公开披露内部架构，也不应被延伸到公司声明之外。但即使是一个简洁的词语也具有治理后果。客户需要理解提供商端路由状态可能成为客户面临的限制。如果某个值被以中断服务的方式超出，那么围绕该值的验证就是客户弹性模型的一部分。
公开的修复问题不是该值的字面名称，而是控制类别。该值是否被监控？在客户受影响之前是否有告警？该限制是否在增长和故障条件下进行过测试？是否有护栏防止不安全的路由编程？当接近该值时是否有回退？该情况是否可能在其他清洗中心、区域或客户群中再次发生？这些问题将简短的陈述转化为实用的责任检查清单。
客户可以要求这些信息，而无需要求敏感的实现细节。提供商可以说明路由状态阈值被监控、发布或路由变更经过限制测试、自动重新路由覆盖定义场景、操作手册涵盖人工例外、以及客户通知将标识决策点。它还可以在适当的保密条件下为企业客户提供更深入的保证。关键不在于公开系统，而在于与客户相关的保证。
容量控制还应针对 DDoS 紧急情况的形态进行测试。攻击流量可能造成路由和缓解措施的突然变化。客户可能在压力下激活按需保护。提供商可能在清洗中心之间转移流量。在平静维护窗口中有效的相同控制措施，在多客户同时事件中可能表现不同。为对抗恶意流量而构建的服务应在类似敌对条件下验证路由状态，而不仅仅是日常运营。
Prolexic 事件表明，防护提供商的内部限制可以被从未听说过该服务的最终用户感知到。试图访问银行或公共门户的人看到网站宕机。客户看到供应商事件。提供商看到内部路由状态问题。责任要求在各方视角之间进行翻译，以便掌握限制的一方证明其已减少公众症状。
客户应按旁路风险对受保护服务进行分类
并非所有受保护服务都应以相同方式旁路。公开营销网站、支付 API、在线银行登录、医疗门户、SaaS 控制面和政府服务在 DDoS 保护移除后面临不同的风险。将所有受保护前缀一视同仁的旁路操作手册过于粗放。客户应根据停留在失效缓解路径上的风险和离开保护的风险对受保护服务进行分类。
对于低风险信息类网站，如果源站能够吸收正常流量，旁路可能很快可以接受。对于高风险交易系统，旁路可能需要上游速率限制、源站访问变更或区域流量整形。对于已受攻击的服务，除非有另一条缓解路径准备就绪，否则旁路可能很危险。对于受监管服务，该决定可能需要业务批准和公开通知。这种分类应在提供商中断之前完成，而非在中断期间。
提供商可以通过提供旁路决策树来提供帮助。该决策树可以询问客户是否处于主动攻击中、是否存在备用缓解、DNS 或 BGP 变更哪个更快、源站容量是否充足、防火墙规则是否允许直接访问、以及支持部门能否协助安全回传。此类指导不能替代客户工程。它使客户工程在时间压力下成为可能。
客户还应测试恢复保护。常见的是测试故障转移而忘记回切。提供商事件解决后，流量必须返回清洗服务，而不中断会话、丢失路由稳定性、暴露源站或重新引入攻击流量。如果不演练回切，组织可能延迟恢复保护或造成第二次中断。完整的操作手册应将旁路和返回作为一个生命周期来覆盖。
因此，即使对于未受影响的客户，Prolexic 的记录也很有用。任何使用路由式 DDoS 缓解的组织都可以询问其旁路分类是否是最新的。它可以进行一次桌面演练：Akamai 或另一家提供商报告路由式缓解故障；自动重新路由对某些前缀有效，但并非全部；公共用户正在失败；没有可见攻击；前十五分钟我们该怎么做？答案将揭示防护依赖是否得到治理。
多提供商缓解可降低风险但增加复杂性
一些客户通过考虑多家 DDoS 提供商来应对路由式缓解事件。这可以减少单一提供商依赖，但也可能带来路由策略复杂性。多家提供商可能需要不同的前缀通告、隧道、DNS 策略、源站限制、健康检查、合同和支持联系点。设计不当的多提供商计划可能造成它本想解决的混乱。
正确的问题并非简单地问“有多少家供应商？”，而是问“哪些故障域被分离了？”如果两家提供商依赖相同的上游路径、相同的 DNS 控制、相同的源站瓶颈或相同的内部审批流程，那么实际的弹性增益可能小于供应商数量所暗示的。如果客户无法在压力下操作第二家提供商，那么第二家提供商可能只是文档，而非连续性。
提供商多样性还会改变攻击处理方式。DDoS 事件是对抗性的。在攻击期间切换缓解提供商可能暴露源站地址、重置过滤上下文或需要规则转换。客户必须知道哪家提供商具有权威、流量如何转移、谁与上游协调以及遥测如何比较。这些细节过于重要，不能临时决定。
尽管如此，如果经过设计和测试，多样性仍可提供帮助。客户可以维护一条备用清洗路径、一个针对低敏感流量的云端回退方案或一套应急 DNS 策略。它可以根据关键性划分服务，并分配不同的缓解模型。它可以在旁路期间合同约定提供商协助。Akamai 事件的教训并非每个客户都需要两家完整的提供商。而是每个客户都需要一个经过深思熟虑选择的故障域策略。
供应商可以通过透明地说明其路由服务如何失效、客户如何离开和返回、以及哪些客户自有组件是前提条件来支持这一策略。当提供商抵制任何关于旁路的讨论时，它要求客户绝对信任单一路径。Prolexic 事件表明为何对单一防护路径的绝对信任并非弹性计划。
防护合同应包括中断合作条款
DDoS 缓解合同通常侧重于攻击容量、响应时间、服务可用性、支持和定价。Prolexic 事件提出了额外的问题。合同是否定义了缓解路由受损时提供商的责任？是否要求在有条件时进行自动重新路由？是否规定了手动重新路由的优先级？是否明确了客户在前缀数据、隧道配置、紧急联系人和旁路批准方面的义务？是否包括事后证据？
合同条款无法解决所有运营问题，但它们可以强制准备。如果合同要求提供最新的紧急联系人，双方就有理由维护它们。如果要求定期进行故障转移测试，旁路就不太可能只是理论上的。如果要求提供包含可操作信息的状态更新，客户就可以规划下游沟通。如果要求进行事后审查，修复承诺就更难被遗忘。
合同还应涉及数据和遥测。在路由式缓解中断期间，客户需要日志或报告来显示流量何时失败、何时重新路由、哪些区域或前缀受影响、以及正常防护何时恢复。没有这些证据，客户就无法向其用户、审计人员或监管机构解释事件。提供商遥测是客户责任的一部分。
对于面向公众的基本服务，合同合作应包括公开沟通。银行、政府机构或医疗服务可能需要告诉用户上游缓解提供商受损。提供商的措辞有助于防止错误信息。在支持的情况下，它还可以确认事件是可用性和路由问题，而非数据泄露。清晰的供应商语言减轻了客户的负担。
广泛的教训是，委托式缓解是一种关系，而非黑箱。提供商控制着专业防御。客户拥有服务使命。在提供商端故障期间，这些责任会合。良好的合同、操作手册、状态通知和测试使这种会合变得可预测。没有它们，供应商环境中的一个路由表值就可能变成具有不明确决策权的公共中断。
回传路径证据应纳入缓解保证
路由式缓解有两个公共面：进入清洗服务的路径和返回客户的路径。买家通常关注前者，因为它更容易理解。攻击流量进入提供商的防御网络，提供商对其进行过滤，然后干净流量到达源站。回传端同样重要。隧道、直连、路由偏好、防火墙规则和源站限制都决定了受保护用户是否实际接收到服务。
Prolexic 事件使回传路径证据成为保证的一部分。如果提供商自动或手动重新路由流量，客户需要知道回传路径是否有效、隧道是否健康、源站白名单是否仍然匹配、以及回切是否能保持保护。路由式服务可能在提供商层面技术上已恢复，但客户端仍存在源站侧不匹配。这种不匹配可能表现为提供商持续中断、客户配置错误或部分恢复问题。
因此，客户应在入职时要求提供路由和回传路径测试用例。第一项测试应证明普通的受保护运行。第二项应证明提供商端重新路由。第三项应证明客户授权的旁路。第四项应证明安全返回保护。第五项应证明沟通：谁收到告警、告警内容以及预期采取何种行动。从未在受控演练中移动流量的计划不是一个可靠的旁路计划。
Akamai 关于流量已自动或手动重新路由的声明提供了一个有用的起点，但客户需要本地证据。他们的受保护前缀是否参与了自动重新路由？他们的应用是否需要人工支持？日志是否显示了路由变更发生的时间？当提供商状态显示已恢复时，用户是否恢复了？客户是否需要更改源站控制？这些问题使提供商事件具有可操作性，而无需超出公开记录进行推测。
回传路径保证对于小型组织也很重要。大型企业可能拥有能够检查 BGP、GRE 和防火墙状态的网络团队。较小的客户可能只知道网站宕机。提供商仪表板、通俗易懂的状态说明以及客户团队的操作手册可以弥合这一差距。如果提供商向没有高级网络人员的组织销售高级缓解服务，则应使恢复状态易于理解。
责任标准在于防护能够安全离开并重新进入的证据。DDoS 缓解的特殊性在于，失败决策无论怎样都会带来安全后果。停留在失效路径上可能导致服务拒绝。离开路径可能暴露源站。过快或未经验证的返回可能重新引入风险。这就是为什么路由式缓解保证应将流量进入、流量回传、旁路和回切证明作为一个控制系列来对待。
客户沟通应区分中断与攻击
DDoS 防护客户可能合理假设缓解服务附近的任何可用性问题都是攻击。Akamai 的更新称 Prolexic Routed 事件并非由网络攻击引起。这一区别在运营上很有价值。如果客户认为中断是由攻击驱动的，他们可能会避免旁路、加强控制、启动危机沟通或上报安全领导。如果提供商能够确认是内部路由服务问题，客户的决策路径就会改变。
提供商应在有证据支持时尽快做出这种区分。“我们正在调查”在早期是合适的。一旦知道，说“这是一个服务路由问题，未观察到针对您源站的攻击流量”或“攻击状态仍在审查中”能为客户提供更好的行动依据。沟通还应说明客户是否应避免路由更改、准备旁路或联系支持部门进行手动重新路由。
这就是状态通知成为共享控制文档的地方。提供商知道服务状态。客户知道业务关键性。双方需要共同语言。如果提供商的通知过于技术化，业务团队可能不会行动。如果过于模糊，网络团队可能猜测。好的通知会指明受影响的产品、客户症状、已知原因类别、推荐操作和下次更新时间。
下游用户受益于这种清晰度。银行、SaaS 公司或公共机构可以告诉其用户上游 DDoS 缓解提供商正在经历可用性问题，而不是暗示存在泄露或应用缺陷。准确的措辞可以减少谣言、支持负担和不必要的安全恐慌。它还有助于提供商在仍拥有其控制的服务依赖关系的同时，避免因不受证据支持的损害而被指责。