Akamai 误报事件：边缘安全何以成为可用性风险

摘要

• 最清晰的误报记录是 Akamai 2026 年 4 月 30 日的 Bot Manager 事件，该事件在公开状态镜像中得以保存，期间升高的误报导致合法最终用户流量被拒。该记录支持了可用性观点，但不足以构成完整的根因断言：无需客户登录即可获取的 Akamai 公开详情并未指明事件背后的确切模型、规则、遥测信号、部署过程或客户数量。
• Akamai 更广泛的宕机记录表明，误报为何应在平台风险分析中占一席之地。2021 年 6 月 17 日，Akamai 表示 Prolexic Routed 3.0 使用的一个路由表值被意外超出，影响了该 DDoS 缓解服务的客户。2021 年 7 月 22 日，Akamai 称一项软件配置更新触发了其 Secure Edge Content Delivery Network 的 DNS 系统的一个漏洞，导致部分客户网站不可达长达一小时。
• 责任不仅在于选择了拒绝操作的客户，也不仅在于发布了检测更新的供应商。Akamai 控制着边缘分类引擎、全局目录、平台部署、状态发布、产品遥测和紧急修复。客户则控制着端点策略、机器人评分阈值、监控后拒绝的准则、源站绕过设计、独立可观测性，以及结账、登录、归档、媒体和公共服务流程的业务连续性。
• 该记录不支持声称 Akamai 整个全球网络发生故障、所有客户均受影响、2026 年误报问题对每个客户持续了超过短暂的操作窗口，或已裁定任何法律责任。它确实支持一项治理发现：内联安全服务需要同样的变更控制、回滚、客户可见的证据以及故障开放或故障软化规划，这些通常是核心可用性系统所要求的。

边缘不仅仅是安全边界

Akamai 销售一种有用的承诺：将安全性和交付能力贴近用户，在恶意流量到达源站前将其吸收，同时让应用更快、更安全。这种架构对于大流量 web 服务而言可能非常合适。面临凭据填充、爬虫、拒绝服务流量、API 滥用或虚假账户创建的客户，可能无法从一个小型源站网络解决这些问题。边缘具备全球遥测、规模和执法点，而客户并不具备这些。

同样的部署位置也带来了更棘手的问责问题。当边缘做出错误决策时，错误发生在客户自己的应用能看到请求之前。合法用户可能永远无法到达登录页面。支付调用可能在商家的欺诈引擎评估之前就被拒绝。移动应用可能收到一个看起来像客户端错误的通用失败信息。银行、航空公司、零售商、出版商、学校或公共机构在边缘背后技术上是健康的，但仍然不可用，因为保护层已将怀疑转化为拒绝。

这就是 2026 年 4 月 Bot Manager 记录重要的原因。一个公开的IsDown 事件镜像保存了 Akamai 的状态文本，描述了一个正在发生的 Bot Manager 问题，该问题与升高的误报相关，导致最终用户的合法流量被拒。同一记录称，截至 2026 年 4 月 30 日 UTC 时间 19:00，已实施修复，服务恢复正常运行，并继续监控。StatusGator 的 Akamai Bot Management 页面单独列出了最近的 Bot Management 事件，包括 2026 年 4 月 30 日的 Bot Manager 升高误报问题，以及 2026 年 5 月和 6 月的其他 Bot Manager 问题。

这些来源足以确立主题：一项 Akamai 机器人保护控制将合法流量错误分类并加以拒绝。但它们不足以确定完整的工程机制。此处审查的公开记录并未显示受影响的主机名、最终用户数量、所涉及的国家、各客户选择的策略操作、涉及的机器人评分范围、更改的信号或模型、部署人群或事后纠正措施登记册。Akamai 的状态页面还指明，更深入的多客户事件细节发布在 Akamai Community 服务事件通知中，供具有登录凭据的客户和合作伙伴查阅，如Akamai Status 页面所示。这意味着公开问责存在缺口：更具操作价值的证据可能在仅限客户的墙后。

这一缺口并未使事件变得不重要。它使其成为边缘安全悖论的一个清晰例证。其商业价值在于阻止恶意自动化行为的保护层，可能因阻止错误的人类而造成服务中断。它可以在没有网络攻击、没有源站故障、没有客户代码部署、没有常规网络中断的情况下做到这一点。从用户的角度看，服务仍然失败了。

当拒绝内联时，误报即产品故障

监控仪表板中的误报会浪费分析师的时间。内联拒绝路径中的误报则可能中断收入、旅行、政府服务、客户支持、预约安排、身份验证和媒体消费。严重性源于附加在分类上的操作。

Akamai 自己的产品语言支持这种区分。Akamai Bot Manager 产品页面描述了边缘的机器人检测、每个请求的机器人评分、每端点策略，以及可能的操作，包括允许、监控、挑战、节流、提供替代内容、阻止、拒绝或重定向。它还提到，客户可以配置良好和恶意机器人处理方式，使用已知机器人类别和允许列表，注入客户端行为遥测，并使用实时可视性和报告。换句话说，Bot Manager 不仅仅是一个被动分析产品。它是一个置于实时 web、移动和 API 流量前的决策系统。

Akamai 的检测准确性文档清晰地定义了操作问题：应用机器人及滥用安全控制后，客户可能会看到潜在的误报，即合法流量被误分类为恶意，以及漏报，即恶意流量被误分类为合法。该文档并非对任何单一事件的承认。作为一般产品证据，它更有力，因为它表明 Akamai 将误报视为运营调优中预期的一类。

产品文档还解释了为何问责不能简化为“Akamai 的错”或“客户配置的错”。Akamai 的对抗性机器人指南描述了谨慎、严格和激进的响应分段，并指出最高的机器人评分分段可能通过诸如“拒绝”之类的强操作来缓解。Akamai 的检测方法文档建议在最终设置拒绝操作之前监控不需要的机器人类别，并指出经验证的 Akamai 机器人可以区别对待。这些是共享控制：Akamai 提供检测、评分、目录、挑战机制和平台执行；客户为其保护的业务端点决定策略和阈值。

问责测试遵循合法请求的路径：

这张表格很重要，因为“误报”标签可能隐藏多种不同的故障。分类可能错误。操作可能对置信度而言过于严厉。客户可能跳过了监控期。供应商可能过于广泛地部署了目录或模型更新。客户可能缺乏紧急覆盖。支持可能未能提供足够证据让客户决定是否放宽控制。严肃的事后审查必须区分这些可能性。

Akamai 早已目睹保护变为中断

2026 年的误报事件并非 Akamai 记录中，防护或边缘控制功能成为可用性问题的唯一案例。2021 年 6 月 17 日的 Prolexic 事件是最清晰的早期例子，因为受影响的服务明确是一个 DDoS 缓解服务。

在 Akamai 公开发布的Prolexic DDoS 服务影响更新中，该公司称 Prolexic Routed 3.0 在 UTC 时间 4:20 开始经历中断。Akamai 表示，影响仅限于使用该版本 Routed 服务的客户，大约 500 名客户中有许多已自动重新路由，其余大多数客户随后手动重新路由，服务于 UTC 时间 8:47 恢复。Akamai 表示，该问题并非由系统更新或网络攻击引起，而是由于该特定服务使用的一个路由表值被意外超出。

教训不是 DDoS 保护不好。Akamai 当前的Prolexic 产品页面描述了通过路由或按需保护、清洗容量和安全运营支持实现的 DDoS 防御；这正是许多客户所需的能力。教训在于，DDoS 保护位于数据路径中。使用路由缓解服务的客户，有意将供应商的清洗和路由层置于互联网和受保护应用之间。如果该层失去了其对等路径、交付路径或路由状态，源站可以保持就绪，但用户流量无法到达。防护服务已成为依赖项。

Cisco ThousandEyes 的Prolexic Routed 中断分析提供了围绕该事件的独立遥测。它观察到，中断导致一些客户网站无法访问，持续时间不一，有些仅受几分钟影响，其他则更长。它还描述了网络中断的显著激增，因为与 Prolexic 对等的服务提供商失去了与该服务的连接，导致这些路径上的流量完全丢失。外部遥测无法证明 Akamai 的内部原因，但证实了面向互联网的症状：在路由保护层可达性失败。

澳大利亚和新西兰的背景使该事件引人注目，因为据报银行、航空公司和其他服务受到影响，但核心问题是架构性的。必须将一直处于路径中的防御层设计并采购为像关键可用性层一样。自动重新路由、手动重新路由、客户联系、路由多样性、回滚、状态速度和修复证明不是次要特性。它们是保护的一部分。

Prolexic 事件也为误报提供了有用的比较。在这两种情况下，安全服务都拒绝了合法的服务结果。在 Prolexic 中，合法流量因路由故障而无法穿越路由缓解层。在 Bot Manager 中，合法用户因分类控制将其视为恶意流量而被拒绝。一个是网络控制故障；另一个是决策控制故障。从最终用户的角度看，两者可能无法区分：受保护的站点不工作。

DNS 使同样的问责问题在 web 规模上显现

2021 年 7 月 22 日，Akamai 遭遇了另一次公开中断，这次与其 Secure Edge Content Delivery Network 中的 DNS 相关。在其服务中断摘要中，Akamai 称，UTC 时间 15:45，一项软件配置更新触发了该网络 DNS 系统中的一个错误，导致部分客户网站出现可用性影响。中断持续了长达一小时，Akamai 回滚软件配置更新后服务恢复。Akamai 还表示，该事件并非对 Akamai 平台网络攻击的结果。

这一措辞很重要。DNS 常被当做管道，但权威 DNS 是可达性的一个控制点。Akamai 的Edge DNS 文档将 Edge DNS 描述为一项权威 DNS 服务，使用跨多个网络的全球名称服务器部署、IP 任播以及作为 Akamai Intelligent Platform 通用组件的专有 DNS 协议实现。Edge DNS 产品页面将配置、DNSSEC、通过 Control Center 部署、监控和区域管理作为服务的一部分呈现。如果 DNS 路径中的一个错误导致客户名称解析失败，用户的浏览器就无法可靠地找到该名称背后运行的服务。

Cisco Umbrella 的关于 Akamai DNS 中断的客户支持说明以类似措辞总结了该事件：Akamai 工程师推送了一项触发 DNS 错误的软件配置更新，用户在尝试访问数千个网站时遭遇大范围 DNS 故障，回滚后一个多小时服务恢复。ThousandEyes 的2021 年中断回顾同样将 7 月下旬的 Akamai DNS 事件描述为持续超过一小时，影响了银行、航空旅行和游戏等多个行业的许多网站和应用。

7 月的 DNS 事件并非机器人误报。它属于同一问责记录，因为操作问题是相同的：供应商控制的边缘变更扩散为客户可用性问题。状态和根因语言不应被模糊。Prolexic 是路由 DDoS 缓解问题。Secure Edge DNS 是软件配置更新触发 DNS 错误。Bot Manager 是升高的误报拒绝合法流量。它们是不同的机制。它们共同的教训是，边缘集中化将供应商更改、阈值和路由状态变成了许多客户的生产命运。

“非网络攻击”并非问责的终点

Akamai 称 2021 年 6 月的 Prolexic 问题不是系统更新或网络攻击，2021 年 7 月的 DNS 问题也不是对平台的网络攻击。这些界定很重要。它们防止夸大其词，并帮助客户理解他们是在应对恶意入侵、配置错误、路由服务故障还是分类问题。

但它们并未结束问责分析。许多最重要的云和边缘故障都是普通的控制故障：值超出、配置更新触发潜在错误、健康检查撤出容量、检测模型漂移、支持渠道缺乏正确证据，或者客户策略缺乏紧急回滚。攻击者的缺失可以使操作责任更加清晰，而非更弱，因为系统按照设计或控制者未充分测试的方式运行。

2026 年的 Bot Manager 事件尤为暴露，因为误报并非产品已知风险之外。Akamai 自己的机器人管理策略博客将机器人管理框定为漏报（机器人被误认为是人类）和误报（人类被误认为是机器人）之间的平衡。Akamai 的web 信任博客称，阻止合法用户或好机器人可能影响生产力，强大的机器人管理解决方案应具有最小化误报的自动调优能力。这些声明是营销和指南，而非事件证据。它们仍然表明商业风险是已知的：准确性是可用性的一部分。

这一已知风险改变了客户对供应商事后报告的期望。一份有用的报告不应仅说已应用修复。它应回答：

• 哪个检测、评分、目录、规则或操作路径产生了误报？
• 错误决策是全球性的、区域性的、账户特定的、端点特定的、客户端特定的，还是与流量模式相关？
• 受影响请求中有多大比例被拒绝、挑战、节流或重定向？
• 客户选择的策略操作是否放大了 Akamai 端的分类错误？
• 仅有监控或挑战的客户是否看到了问题而未拒绝流量？
• Akamai 从平台遥测检测到误报需要多长时间，从首个客户报告检测到又需要多长时间？
• 修复是回滚、模型更改、目录更正、阈值调整还是紧急例外？
• 向客户交付了哪些证据字段，以便团队识别受影响的用户和交易？
• 将如何防止同类故障再次发生，以及该预防措施将如何测试？

没有这些答案，公众可知道发生了误报事件，但客户只能通过私人支持渠道和自身日志评估控制变更的充分性。

回滚必须在拒绝之前设计

回滚是 Akamai 记录中反复出现的清晰界限。2021 年 7 月，软件配置更新的回滚恢复了 Secure Edge DNS。2021 年 6 月，自动和手动重新路由以不同速度恢复了 Prolexic 客户。2026 年 4 月，公共镜像保存的 Akamai 状态文本称，已实施 Bot Manager 修复，服务恢复正常运行。这些并非可互换。供应商配置回滚、绕过保护服务的路由以及机器人控制修复，具有不同的权限、客户依赖关系和证据要求。

Akamai 自己的配置工具表明了为何这种区别很重要。Property Manager 激活文档描述了快速回退特性：激活完成后，客户有 60 分钟的窗口期可恢复至最近的活动属性版本。生产激活文档说明，激活会将配置部署到 Akamai 生产网络以上线。这些工具很有价值，但它们解决的是客户属性配置。它们并不能证明供应商端的检测更新、机器人目录更新或平台服务变更可被客户回滚。

对于内联安全，回滚至少有四个层面：

一个负责任的设计应在事件发生前决定这些选项。零售商对凭据填充风险暂时增加的容忍度，不同于医院预约系统、航空公司值机流程、政府福利门户或支付授权路径。业务端点可能需要一条故障软化路径，以挑战更多用户而非拒绝他们。内容端点可能接受过期的缓存页面。登录端点可能允许已知设备，但阻止新的高风险会话。结账端点可能暂时降低机器人防御，同时加强交易监控。这些选择都不应在有效用户正被拒绝时临时仓促决定。

证据必须跨越供应商与客户的边界

误报事件难以诊断，因为每一方只能看到路径的一部分。客户看到转化损失、登录失败、支持投诉、合成测试、显示请求缺失的源站日志，或许还有 Akamai 事件流。Akamai 看到边缘分类、机器人评分、策略操作、平台更新、跨客户状态以及支持报告。受影响的用户只看到拒绝。

Akamai 提供了有助于弥合这一缺口的安全事件集成。其SIEM 集成文档指出，连接器可以近实时地从 Akamai Security Events Collector 收集 JSON 事件数据，并将其发送到客户的 SIEM。Akamai 的采样报告文档称，需要完整数字的客户可以使用 SIEM 集成来分析从 Akamai 平台生成的所有安全事件，并在采样报告有限时保留记录。Akamai 的DataStream 安全日志页面描述了由安全配置生成的安全信息和事件管理事件流。

这些能力并不能自动解决证据问题。客户必须启用它们，必须在受影响的工作流之外保留数据，并且必须有员工能够将拒绝的边缘请求与业务指标进行比较。供应商仍必须发布足够的事件级细节，以告知客户其证据是更广泛平台问题的一部分还是局部配置错误。状态页面、私密社区帖子、支持案例和 SIEM 日志需要相互对应。

Akamai 的状态设计也产生了一种透明度权衡。公开的Akamai Status 页面列出了组件状态，并说明影响多个客户的事件的详细信息将发布在 Akamai Community 服务事件通知组中，拥有有效 Control Center 凭据的客户和合作伙伴可访问。公开的状态 FAQ 页面解释了状态页面机制和服务事件通知的路由。这对付费客户有用。对于公共部门用户、受影响的最终用户、记者、投资者以及试图了解被拒请求是否属于供应商事件的下游企业而言，则用处较小。

针对误报事件的恰当证据包应是机器可读且客户可操作的。它应包括受影响的产品、UTC 时间窗口、操作类型、区域（如果相关）、策略路径、供应商修复状态、已知客户缓解措施、事件字段指南以及 Akamai 可确定的限制。它还应区分“我们正在监控”、“客户仍需更改策略”和“所有平台端缓解已完成”。这些区分并非行文上的细枝末节。它们决定客户是继续放宽控制、恢复更严格的规则、补偿用户、重放交易，还是开启隐私和法律审查。

补偿不等于恢复

服务积分可承认未履行的承诺，但很少能为安全控制阻止合法用户的实际后果买单。一小时的误报可能妨碍购买、旅行值机、账户访问、表单提交、流媒体启动、新闻消费和公共服务互动。这些交易中有许多无法通过每月账单的部分积分来弥补。

此处审查的公开来源并未确定 2026 年 4 月 Bot Manager 事件、2021 年 6 月 Prolexic 中断或 2021 年 7 月 DNS 事件适用哪些客户合同、服务计划或积分。任何法律主张都将取决于合同措辞、受影响的服务、客户配置、通知、排除条款、因果关系和管辖范围。这种不确定性应保持明确。

然而，Akamai 的公司文件显示出该问题为何具有实质性。Akamai 的 2025 年Form 10-K将公司描述为提供安全、交付和云计算服务，并包含围绕故障、中断、网络攻击、技术变更和客户信任的风险因素表述。Akamai 的 2025 年业绩也显示了规模。在其2025 年第四季度及全年财报中，公司报告 2025 年总收入为 42.08 亿美元，并按安全、交付和云计算类别划分了收入。供应商规模不能证明特定事件中的过错。它确实显示了业务背景：Akamai 并非互联网边缘的小型设备供应商。它是一个主要平台，其安全决策可能影响众多下游服务。

该规模也改变了客户采购。购买内联安全的客户不应只询问正常运行时间百分比。它应询问误报检测阈值、事件日志保留、紧急支持路径、策略回滚权限、独立状态信息流、客户特定影响范围报告、事后细节以及不会掩盖运营损害的积分条款。对于关键公共服务，采购还应要求一种连续性模式，以便在供应商的安全层拒绝合法流量时，能够维持公共职能运行。

NIST 的网络安全框架 2.0很有帮助，因为它将供应商风险管理视为一项治理职能，包括为供应商、客户和合作伙伴确立角色和职责，并将供应链风险整合到企业风险管理中。CISA 的安全设计指南主张，安全负担不应仅落在客户身上，技术制造商应对结果透明并负责。NIST 的网络弹性工程指南将弹性定义为预测、承受、恢复和适应由网络资源引发的不利条件的能力。这些是通用标准，并非对 Akamai 的调查结果。它们提供了正确的问责词汇：供应商角色必须明确，安全必须在无隐藏脆弱性的情况下可用，恢复必须经过工程化设计。

客户责任仍然真实存在

供应商责任并不消除客户责任。将每个可疑机器人评分都映射为收入关键端点上的“拒绝”的客户，是做了一个商业决策。从不监控新规则、从不查看安全事件数据、从未定义旁路路由、从未演练紧急放宽策略的客户，无法将所有后果推给上游。边缘安全之所以强大，正是因为客户授权供应商代表他们执行策略。

客户端基线应包括：

• 对于新的高影响机器人类别、检测变更和受保护端点，在拒绝模式之前采用监控模式；
• 为浏览、登录、结账、账户恢复、API、移动应用、管理路径和公共信息页面制定独立策略；
• 在拒绝与分类置信度不相称的情况下，使用挑战或节流选项；
• 在适当情况下，为已知合作伙伴、搜索引擎爬虫、辅助功能工具、正常运行时间监控器和紧急服务集成建立明确的允许列表；
• 从多个网络和设备（包括移动和辅助技术配置文件）穿越 Akamai 边缘的独立合成测试；
• 将安全事件导出到具有足够保留期的独立存储中，以便重建有争议的拒绝窗口；
• 授权一个指定团队可快速放宽策略，并已事先定义业务批准；
• 为关键工作流制定源站或替代路由程序，认识到绕过可能增加安全暴露并应有时限；
• 面向客户的消息传递，区分“我们正在阻止可疑流量”和“我们的供应商正在错误分类有效请求”。

这并非建议在无机器人保护的情况下运行。这是承认拒绝操作是一次生产变更。要求在进行维护关闭结账之前进行审查的同一组织，也应要求在允许第三方评分拒绝结账用户之前进行审查。

客户监控还必须注意到缺失。在误报边缘事件中，源站日志可能看起来更干净，因为边缘在请求到达之前将其阻止。转化率可能下降，登录尝试可能减少，支持联络可能增加，合成探测可能因边缘生成的响应而失败。仅关注源站错误率的团队可能会错过问题，因为源站不再接收被拒绝的用户。流量的缺失就是证据。

Akamai 的责任远不止于正常运行时间

Akamai 作为供应商方的责任不仅仅是保持数据包流动。它要让内联安全足够安全，以便同时代表众多企业运行。这意味着要衡量准确性、控制部署、保留回滚、提供证据，并在产品本身成为拒绝原因时使状态有用。

公开记录支持几项具体责任。

首先，平台变更需要影响范围控制。2021 年 7 月的 DNS 事件始于一项触发漏洞的软件配置更新。Prolexic 事件涉及路由 DDoS 服务中的一个值被超出。Bot Manager 事件涉及升高的误报。每个案例都提出了这样一个问题：该变更或状况是否本可以通过金丝雀部署检测到、通过客户群组限制、通过自动护栏阻止，或在产生广泛影响之前还原。

其次，边缘安全需要与业务成果挂钩的准确性遥测。Bot Manager 可以报告机器人评分和安全事件，但误报往往通过客户业务信号变得明显：失败的登录率、放弃、支付拒绝模式、呼叫中心投诉或有效合作伙伴流量的突然下降。Akamai 无法看到每个业务成果，但它可以看到跨客户异常和拒绝激增。客户无法看到全局模式，但他们可以看到局部后果。供应商应让这些信号的关联变得容易。

第三，供应商应避免使仅限客户的证据成为唯一的公开问责路径。客户特定细节可能需要访问控制，敏感的规则逻辑不应公开倾倒。但广泛的事件事实可以在不泄露客户秘密的情况下公开：产品、时间窗口、故障类别、操作类型、缓解措施、客户剩余步骤和补救主题。

第四，事件后补救应可验证。“我们已实施修复”是恢复里程碑，而非复发预防记录。更有力的记录将说明添加了哪些护栏、如何测试、回滚时间是否改善、检测延迟是否下降以及客户是否收到了事件证据。无需客户登录即可见的 2026 年 Bot Manager 误报事件的公开记录，并未提供这种保证水平。

责任图谱

责任遵循可在事件前、事件中或事件后改变结果的能力。

答案将因客户而异。媒体网站可能比银行登录接受更多的挑战摩擦。票务平台可能在发布期间积极保护库存，但保持账户恢复较宽松。公共福利门户可能认为，在短暂的紧急窗口内，拒绝有效用户比滥用流量的一定增加更有害。安全供应商无法为每个客户选择这些业务价值，但它必须提供使此类选择切实可行的控制。

该记录未证明什么

此处审查的公开记录具有重要边界。

它没有证明 2026 年 4 月 Bot Manager 误报事件影响了每个 Akamai 客户、每个 Bot Manager 客户或任何指名客户。它没有证明所有用户均被拒绝、客户源站宕机，或某个特定模型或规则导致了该问题。它没有解决公开镜像中持续时间列表的明显不一致，尤其是 StatusGator 页面上较长的故障行，因为原始的 Akamai 仅限客户细节在公开记录中不可得。更稳妥的解读是，Akamai 承认存在升高的误报，并于 4 月 30 日实施了修复，而公开镜像不足以进行完整的持续时间或影响范围计算。

它没有将 2026 年 Bot Manager 事件与 2021 年 Prolexic 和 Secure Edge DNS 中断混为一谈。这些是独立事件，具有独立机制。将它们进行比较，是因为它们都展示了边缘或保护层控制成为可用性依赖项。

它没有表明 Akamai 后来未能补救。Akamai 可能拥有仅限客户的事后细节、内部关闭证据和合同特定的补救措施，而这些在此处不可得。因此，本文认为补救有效性是公开未经验证的，而非缺失。

它没有做出法律认定。这些事实可以在不判定疏忽、违约、保证、违规或损害的情况下，支持运营问责。法律责任将取决于客户协议、产品条款、管辖范围、因果关系和损失证明。

实践教训

旧的 web 安全思维是边界优先：在边缘阻止恶意流量，以便应用能够完成其工作。现代的问责观更为严格。边缘是应用的一部分。机器人评分、DDoS 路由、DNS 应答、挑战、拒绝规则和回滚按钮都是可用性控制。它们理应得到与数据库故障转移或支付处理相同的证据规范。

因此，Akamai 的记录具有超越 Akamai 自身的价值。它展示了保护层可能演变为中断的三种方式：合法用户被误报机器人分类拒绝、受保护流量因 DDoS 缓解路由故障而滞留、客户站点因配置更新触发的 DNS 错误而不可用。每个事件都得到了解决。每个事件也表明，客户不能像购买与连续性无关的东西那样购买边缘安全。

可问责的标准不是“永不拒绝合法请求”。在互联网规模上，这不可信。标准是供应商和客户能否使误报保持有界、可见、可逆和可解释。一个好的边缘安全系统应允许客户从监控模式开始，逐步谨慎地升级控制，查看完整的安全事件，测试业务关键路径，在紧急情况下放宽策略，并在平台端变更出错时收到供应商证据。一个好的供应商应发布足够的公开事件信息，使故障类别和纠正措施可理解，同时为客户提供其自身流量的详细证据。

安全控制在阻止攻击时赢得信任。当它们在出错期间能够证明，保护并未成为一个无法问责的拒绝服务层时，它们保持信任。