Akamai 与误报：边缘安全如何成为可用性风险

概要

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

边缘不仅仅是安全边界

Akamai 销售一个实用的承诺：将安全与分发靠近用户，在恶意流量抵达源站之前将其吸收，同时让应用更快更安全。这种架构可能恰好适合大流量网络服务。面临撞库、爬虫、拒绝服务流量、API 滥用或虚假账户创建等问题的客户，可能无法仅凭小型源站网络解决问题。边缘具备全球遥测、规模和执行点，这些都是客户不具备的。

同样的位置也带来了更棘手的问责问题。当边缘做出错误决策时，错误发生在客户自身应用看到请求之前。合法用户可能永远无法到达登录页面。支付调用可能在商户反欺诈引擎评估之前就被拒绝。移动应用可能收到一个看似客户侧故障的通用错误。银行、航空公司、零售商、出版商、学校或公共机构，可能在边缘之后技术上一切正常，却因防护层将怀疑转化为拒绝而无法访问。

正因如此，2026 年 4 月 Bot Manager 记录才显得重要。一个公开的IsDown 事件镜像保存了 Akamai 的状态文本，描述了 Bot Manager 出现的新问题，与导致终端用户合法流量被拒绝的升高误报有关。同一记录称，修复已于 UTC 时间 2026 年 4 月 30 日 19:00 实施，服务正在恢复正常运行，并保持持续监控。StatusGator 的 Akamai Bot Management 页面单独列出了近期的 Bot Management 事件，包括 2026 年 4 月 30 日的 Bot Manager 升高误报问题，以及 2026 年 5 月和 6 月的其他 Bot Manager 问题。

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

这种缺口并不会让事件变得无关紧要。它反而使其成为边缘安全悖论的一个鲜明例子。一个业务价值在于阻断不良自动化的防护层，可能因阻断错误的人类而制造中断。它可以在没有网络攻击、没有源站故障、没有客户代码部署、也没有传统网络切断的情况下做到这一点。从用户的角度看，服务仍然失败了。

当拒绝处于内联路径时，误报就是产品故障

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

Akamai 自身的产品语言支持这种区分。Akamai Bot Manager 产品页面描述了边缘的机器人检测、每请求的机器人评分、每端点策略，以及可能的操作，包括允许、监控、挑战、节流、提供替代内容、阻止、拒绝或重定向。该页面还表示，客户可以配置善意的和恶意的机器人处理方式，使用已知机器人类别和允许列表，注入客户端行为遥测，并利用实时可见性和报告。换句话说，Bot Manager 不仅仅是一个被动分析产品。它是一个摆在实时网页、移动和 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 家客户中的许多自动重路由，剩余大部分客户随后不久手动重路由，服务在 8:47 UTC 恢复。Akamai 称事件并非由系统更新或网络攻击引起，而是该特定服务所用的一个路由表值被意外超出。

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

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

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

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

DNS 使同样的问责问题在互联网规模上显现

2021 年 7 月 22 日，Akamai 经历了另一次公开中断，这次关联到其 Secure Edge 内容分发网络中的 DNS。在其服务中断概要中，Akamai 表示在 UTC 15:45，一个软件配置更新触发了该网络 DNS 系统中的一个缺陷，导致部分客户网站出现可用性影响。中断持续最长一小时，至 Akamai 回滚该软件配置更新后服务恢复。Akamai 还称事件并非针对 Akamai 平台的网络攻击。

措辞很重要。DNS 常被视为管道，但权威 DNS 是可达性的控制点。Akamai 的Edge DNS 文档将 Edge DNS 描述为一项权威 DNS 服务，使用跨多网络的全球名称服务器部署、IP 任播以及作为 Akamai 智能平台公共组件的 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 的网络信任博客表示，阻止合法用户或善意机器人会影响生产力，强大的机器人管理解决方案应具备自动调优以减少误报的能力。这些表述是营销和指南，而非事件证据。但它们仍表明业务风险是已知的：准确性是可用性的一部分。

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

• 哪个检测、评分、目录、规则或动作路径产生了误报？
• 错误决策是全球性的、区域性的、账户特定的、端点特定的、客户端特定的，还是关联到某个流量模式？
• 受影响的请求中，有多少比例被拒绝、挑战、节流或重定向？
• 客户选择的策略操作是否放大了 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 安全事件收集器近实时收集 JSON 事件数据，并发送至客户 SIEM。Akamai 的采样报告文档称，需要完整数字的客户可以使用 SIEM 集成分析从 Akamai 平台生成的所有安全事件，并在采样报告受限时保留记录。Akamai 的DataStream 安全日志页面描述了用于由安全配置生成的安全信息和事件管理事件的数据流。

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

Akamai 的状态设计也带来了透明度权衡。公开的Akamai 状态页面列出了组件状态，并说明影响多个客户的事件详情将发布在 Akamai 社区服务事件通知组中，对拥有有效 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 可能拥有此处不可得的仅限客户事后细节、内部关闭证据和特定合同的补救措施。因此，本文将该修复的有效性视为公开未验证，而非不存在。

它未做出法律结论。事实可以在不确定过失、违约、保证、违规或损害赔偿的情况下支持操作问责。法律责任将取决于客户协议、产品条款、司法管辖区、因果关系和损失证明。

实际教训

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

因此，Akamai 的记录对 Akamai 之外的领域亦有参考价值。它显示出防护层可能成为中断的三种方式：合法用户被误报机器人分类拒绝、受保护流量因 DDoS 缓解路由故障受阻、以及配置更新触发的 DNS 缺陷使客户站点不可用。每起事件均得到解决。每起事件也说明了为何客户不能像采购与连续性无关的东西一样采购边缘安全。

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

安全控制在阻止攻击时赢得信任。它们在出差错时，通过证明保护未成为无法问责的阻断服务层来保持信任。