Fastly 的潜在缺陷与集中化 CDN 边缘的问责

摘要

• Fastly 表示，2021 年 5 月 12 日开始的一次软件部署引入了一个潜在缺陷。6 月 8 日，一位客户进行了一次有效的配置更改，其中包含了激活该缺陷的异常条件。由此产生的故障导致 Fastly 网络 85%的部分返回错误。Fastly 在一分钟内检测到了中断，并在 49 分钟内将 95%的网络恢复到正常运行状态。
• 该事件未被公开认定为 BGP 路由泄漏、对等互联故障、传输不足、网络攻击或无效的客户行为。独立观察发现，虽然网络层看起来正常，但应用层出现了错误。这种区别很重要：CDN 可以拥有广泛的物理和运营商多样性，却仍通过共同的软件、配置语义、部署系统和恢复控制而相关联。
• 客户的结果取决于架构和运营准备情况。GOV.UK 拥有一个持续可用的辅助 CDN，并有文档化的故障转移流程，但 DNS 传播和降级模式下的权衡仍然耗费了时间。GitLab 在其主要服务中仅部分依赖 CDN，但一个外部软件包依赖阻碍了工程师们想要用来绕过故障 CDN 的常规管道。
• 因此，责任位于服务边界的双方，但并非平等。Fastly 控制着平台代码、测试、发布遏制、全局故障隔离和提供商恢复。客户控制着依赖映射、替代交付、源站容量、DNS 和证书准备、恢复工具以及业务影响容忍度。董事会和监管机构应要求双方提供经过测试的证据，而不是将高可用性百分比或第二供应商合同视为弹性的证明。

一次有效更改，一个全局故障域

UTC 时间 2021 年 6 月 8 日 09:47，互联网上很大一部分开始返回错误。新闻网站、电子商务服务、开发者平台、流媒体资产以及英国中央政府网站都是可见的受害者。从外部看，这个事件像是许多不相关的组织同时出现故障。从基础设施的角度，它们是相关的：这些服务的请求都汇聚到了 Fastly 的内容分发网络。

Fastly 的6 月 8 日中断总结提供了核心因果说明。一次从 5 月 12 日开始的软件部署引入了一个缺陷。该缺陷一直潜伏，直到一位客户在触发它所需的特定条件下推送了一次有效的配置更改。Fastly 表示，其网络 85%的部分随后返回错误。监控在 09:48，即中断开始一分钟后，检测到了全局中断。首次公开状态更新在 09:58 发布。工程师们在 10:27 确定了客户的配置，恢复于 10:36 开始，95%的网络在中断后 49 分钟内正常运行。Fastly 在 12:35 标记事件缓解，12:44 标记解决，然后于 17:25 开始部署永久性缺陷修复。

存档的Fastly 状态事件增加了一个简单的上下时间线所遗漏的操作细节。随着服务恢复，客户可能会经历更高的源站负载和更低的缓存命中率。边缘的恢复不一定是整个客户服务的恢复。缓存需要预热，通常应在边缘处理的请求可能会以异常的数量到达源站，每个客户自身的依赖也需要稳定下来。提供商恢复是一个关键里程碑，但不是影响的通用结束点。

Fastly 道歉并称该事件广泛且严重。它还做出了一个宝贵的问责声明：尽管触发条件依赖于特定条件，但提供商本应预见到它。这句话拒绝了最简单但最无用的解释，即客户更改了什么，因此导致了中断。客户的行为是有效的。平台接受了它。灾难性的响应来自提供商软件及其故障传播的方式。

公开账户仍然故意保持较高层次。它没有披露受影响的子系统、确切的配置组合、软件缺陷、内部测试覆盖范围、部署拓扑，也没有说明一个客户的配置如何在无关的客户服务中产生错误。这些遗漏在简短的公开报告中可能是合理的，尤其是在涉及客户保密和平台安全的情况下。但它们也限制了外部保证。公众可以对照观察验证时间线；仅凭 Fastly 的帖子，无法独立确定永久修复是否只移除了触发条件、修复了底层缺陷，还是改变了允许如此广泛影响范围的架构。

这个差距应该塑造结论。记录支持存在一个潜在缺陷、一个有效的触发条件、全局错误行为、快速检测和相对快速的缓解。它不支持关于缺陷代码或个别工程师行为的详细理论。问责分析应保持在控制层面：测试设计、配置隔离、部署安全性、全局故障遏制、可观测性、事件授权以及提供给客户和董事的证据。

时间线将休眠风险与主动中断分开

对于许多用户来说，该事件持续不到一小时，但相关的控制窗口几乎在四周前就开始了。一个缺陷可以在不产生可见症状的情况下操作性地存在。这就是为什么潜在故障很难处理，以及为什么发布保证不仅仅是观察部署后的最初几分钟。

此序列表明，常见的说法“配置更改导致了中断”过于松散。配置更改在一个价值包括可编程性的边缘平台上经常发生。有效的配置可能是因果链中的最终刺激，就像正常的请求可能触发服务器缺陷一样。控制方是拥有使有效输入变得安全、拒绝其无法处理的组合或限制故障影响提供这些服务的服务的能力的一方。

同样错误的是声称触发器无关紧要。触发器分析对于重现、检测、回滚和未来保障措施都很重要。重点在于，触发器归因和责任归属回答的是不同的问题。客户提供了条件。Fastly 提供了软件行为和共享的生产环境。Fastly 自己的账户承认，该条件本应被预见到。

休眠间隔同样重要。一个存活数周的发布已经积累了生产暴露，而不是对未经测试状态的证明。可配置的平台面临组合问题：版本化的软件与客户的 VCL、头部、来源、缓存规则、屏蔽、访问控制、功能标志和边缘逻辑交互。彻底测试每一种组合可能是不可能的。这使得遏制、分阶段发布、不变量检查、模糊测试、代表性配置语料库、运行时隔离和快速自动化回滚变得更加重要，而不是更不重要。

这是一次应用故障，而非路由崩溃

该中断属于对等互联和传输讨论的范畴，因为 CDN 既是一个互联业务，也是一个软件平台。它不应被改写为对等互联或传输事件。证据指向相反的方向。

Kentik 的同步网络观察看到事件从 UTC 时间 09:49 开始，测量到 Fastly 的流量大约下降了 75%，然后在 10:39 开始恢复。Cisco ThousandEyes 的逐层分析观察到服务错误，而网络路径继续正常工作，并描述了随着流量在交付提供商之间转移，客户恢复模式的不同。后来的一份 ThousandEyes 产品分析直接表明了区别：503 错误出现在应用层，而网络层看起来正常。

Fastly 自己的对等互联政策将 AS54113 标识为其与互联网服务提供商和内容网络交换流量的自治系统。其全球 POP 文档解释说，接入点（POP）位于密集的互联网交换地点附近，提供商多样性和网络邻近性是设计因素之一。DNS 和任播将用户引导至最近的 Fastly 容量。在物理局部故障中，这些属性可以绕过受损的链路、运营商、设施或 POP。

在该事件之前，Fastly 描述了一个由 26 个国家、六大洲的 68 个 POP 组成的网络，通过转接、互联网交换中心、云对等互联和专用互连的组合进行连接。其容量规划说明称，它模拟了 POP 和连接故障，并保持区域溢出余量。这些都是有意义弹性形式。它们减少了对单一电缆、单一运营商、单一建筑和单一城市场地的依赖。

它们并没有解决 6 月 8 日的故障模式。如果许多 POP 运行相同的缺陷平台代码并接受共同的配置模型，地理多样性可能会复制而不是隔离缺陷。多条传输路径可以可靠地将用户传送到可靠地返回错误的边缘节点。更多的对等会话可以提高可达性和路径选择，而让服务的应用不可用。任播可以将请求移动到另一个 POP，但如果该 POP 共享相同的软件命运，用户改变了位置却没有改变结果。

这是通过互连视角得出的核心教训：路径多样性不是服务多样性。网络运营商长期以来一直在设计应对链路和路由故障，因为这些故障在其运营的层中是可见的。云和边缘服务增加了更高层的共同模式。共享代码、全局配置分发、身份、日志记录、控制平面、证书系统、部署自动化以及事件工具可能会使看起来物理上独立的基础设施相关联。

因此，一个严肃的弹性评审需要一个故障域矩阵，而不是 POP 或运营商的数量。一列应列出物理设施、电力、硬件、光纤、传输、对等互联和路由。另一列应列出软件版本、配置编译器、部署控制器、密钥和证书服务、命名、可观测性和管理访问。第三列应列出客户控制的依赖项，如权威 DNS、源站托管、备用 CDN、WAF 策略、对象存储和发布管道。只有当同一事件无法同时禁用主要服务和用于恢复的路径时，多样性才存在。

分布和集中可以共存

这次中断产生了一个视觉上的悖论。受影响的基础设施遍布全球，但单一的潜在条件在许多地方和组织中同时产生了故障。分布描述了资源在哪里。集中描述了在故障和广泛危害之间站立的多少独立决策、实施和恢复路径。一个系统可以在第一点上得分很高，而在第二点上得分很低。

该事件后发表的研究有助于量化更广泛的背景，而不需要证明 Fastly 当天的确切市场份额。一项针对50 个国家第三方服务依赖的研究发现，各国广泛依赖外部 DNS、CDN 和证书颁发机构提供商，且各国之间存在很大差异，提供商集合高度集中。另一项研究，《DNS 和 Web 托管提供商整合的初步观察》发现，Cloudflare、Amazon、Akamai、Fastly 和 Google 共托管了 Tranco 前 10,000 名中约 62%的索引页面，并为许多网站的外部资源提供了多数服务。

这些测量是具有方法局限性的快照。不应将其转化为 62%的 Web 依赖 Fastly 或所有测量到的托管关系都至关重要的说法。它们的相关性是结构性的。流行的服务通常依赖一个小型的提供商组，而单个页面可能包含来自其中几个提供商的资源。因此，集中可以出现在以下几个层面：

• 客户可能对所有基本对象使用一个 CDN 提供根文档。
• 客户可能使用多个 CDN，但将关键脚本、字体、图像、API、证书或重定向路径留在一个提供商上。
• 两个名义上独立的 CDN 可能共享一个源站云、权威 DNS 提供商、传输路径、配置库、身份系统或部署管道。
• 许多不相关的组织可能独立选择相同的提供商，从而产生一个任何单个客户都无法完全观察到的跨部门共同依赖。
• 备用方案可能在技术上是存在的，但需要人员、凭证、代码、软件包存储库、状态信息或通信渠道，而这些在相同事件中可能受损。

市场集中和架构集中是相关的，但并不相同。一个市场可以有几个主要供应商，而一个特定的组织仍然是单供应商的。相反，一个客户可以与两个供应商签约，却通过共享 DNS、共享源站、同步错误配置或未经测试的切换，创建一个逻辑故障域。董事会应该抵制将供应商数量作为依赖分析的替代品。

CDN 的社会触及范围也很重要。Fastly 并不拥有受影响的报纸、商店、软件项目或政府服务。然而，用户通过一个大多数用户从未见过的共享中介经历了这些服务不可用。这是一种委托的操作权力。提供商可以改善速度并以每个客户难以复制的规模吸收负载，但提供商的缺陷也可以同步那些原本可能独立的故障。

这并不意味着集中本质上是不可取的。集中的专业知识和基础设施可以比数千个脆弱的单独部署带来更好的安全性、性能和可靠性。问责问题是，从共同基础设施中获得的效率是否被更强的共同模式控制、透明的事件证据和现实可行的退出或备用选项所匹配。聚合越重要，将平台范围的安全视为普通产品质量问题的说服力就越低。

GOV.UK 有备份，但仍发生了中断

政府数字服务关于GOV.UK 中断的公开事件报告是客户方决策最清晰的记录之一。GOV.UK 在中断开始四分钟后检测到影响，设立了事件和通信负责人，确认主要 CDN 为来源，并找到了一个具有文档化的故障转移到辅助提供商的流程。

这并不是纸上谈兵的冗余。辅助 CDN 是持续可用的，尽管它通常不承载生产流量。故障转移代码已准备就绪。团队了解主要 CDN 可能是一个单点故障。这些控制使 GOV.UK 处于比在中中断期间发现选项的组织实质上更强有力的位置。

即便如此，用户还是无法访问 GOV.UK 的信息和服务不到一个小时。团队在检测后有意等待了 15 分钟才决定故障转移，因为辅助 CDN 提供降级的体验。搜索和基于位置的服务等动态功能将无法以其通常的质量运行，而在短暂的提供商中断期间过早切换可能会延长或加剧中断。在做出决定后，DNS 更改仍需要时间传播。30 分钟内，更改已部署，流量开始移动，但 Fastly 已经在恢复。然后，团队切换回性能更好的主要服务。

这就是真正的弹性面貌：一个带有成本、状态转换、判断和延迟的选项。备份降低了长时间中断的风险。它并没有使故障转移即时或无后果。该事件还暴露了一个用户通信依赖项。Fastly 的通用 503 页面超出了 GOV.UK 的内容控制，且低于该服务对有用公共信息的标准。

GOV.UK 的记录提供了几个问责测试。辅助 CDN 是否实际预热？是的。是否有文档化的流程和指定的权限？是的。降级是否被理解？是的。切换机制是否足够快以满足服务的影响容忍度？观察到的时间线为决策者提供了回答的证据，而不是理论上的保证。该报告还证明了为什么董事会应该询问将显著用户流量转移的中值和最坏情况时间，而不仅仅是是否签订了第二份 CDN 合同。

对于公共服务，这一区别尤其重要。呈现层边缘的中断可能导致税务指南、福利信息、健康材料、监管指令和紧急更新无法访问，即使底层的部门系统仍然健康。当它是公共入口点时，边缘就不是装饰性的。业务影响映射应将交付损失视为用户实际能接触到的服务损失。

GitLab 在恢复路径中发现了依赖项

GitLab 的公开生产事件记录显示了不同的架构和不同的故障。Fastly 为 GitLab.com 提供资产服务，因此对于浏览器缺少缓存 JavaScript 和图像的用户来说，主站点严重降级。About.GitLab.com 完全无法访问，Fastly 是其进入点。API、Git、Registry 和 Pages 功能继续运行，显示出分离服务路径的价值。

在 UTC 时间 10:18，GitLab 工程师准备了一个合并请求，以替换用于资产的 CDN。他们无法通过正常的管道应用它，因为该管道中的一个镜像尝试从同样受到 Fastly 中断影响的外部存储库安装一个软件包。一个预期的恢复机制通过一个依赖项继承了相同的外部事件，而这个依赖项并不是正在被更改的 CDN 设置。

这是一个传递性集中的紧凑示例。在架构图上，应用、配置管道、容器镜像、软件包索引和 CDN 可以显示为不同的框。在操作上，恢复操作依赖于执行它所需的每一个框。如果一个构建步骤到达一个不可用的外部服务，那么在需要移除另一个依赖项的那一刻，管道就是不可用的。

GitLab 在 Fastly 恢复的同时，在暂存环境中测试了手动绕过，然后在金丝雀切片上进行了测试。其纠正措施包括为关键组件的不可变镜像、用于手动应用更改的操作手册、用于更快 CDN 恢复的后端存储桶和负载均衡器、考虑冗余 CDN，以及在正常流程因外部因素受损的情况下进行消防演练。这些行动很有价值，因为它们针对的是恢复能力，而不仅仅是原始供应商故障。

GitLab 影响的部分性质也警告了不要使用二元的依赖登记册。标记“Fastly：第三方”几乎说明不了什么。一个有用的映射识别哪些主机名、路径、对象和用户旅程需要该提供商；浏览器是否可以使用缓存的资产；API 是否仍然可达；TLS 在哪里终止；重定向如何工作；以及员工是否可以在不联系故障路径的情况下部署绕过。服务分解可以保留高价值功能，但前提是影响评估反映了当视觉或客户端组件缺失时用户能完成什么。

GitLab 和 GOV.UK 取得了不同的结果，因为弹性是实现层面的本地化。提供商事件是共同的。客户的影响范围并不相同。这就是为什么不能因为供应商宕机就忽视客户的责任，也不能因为一些客户缺乏第二个 CDN 而淡化提供商的责任。Fastly 拥有共同故障的预防和恢复。每个客户拥有其依赖的形状和准备程度。

恢复可以将缓存效率转化为源站压力

CDN 通常将源站从大量请求负载中屏蔽出来。GOV.UK 表示其约 93%的请求是从缓存提供的。Fastly 的屏蔽文档描述了通常的模式：边缘 POP 提供缓存的对象，而指定的屏蔽可以在未命中到达源站之前合并它们。该架构提高了性能，并可以大幅减少源站流量。

在恢复期间，这种效率可能会逆转。如果缓存是冷的或命中率下降，更多的边缘请求将向上游流动。如果客户完全绕过 CDN，源站可能会收到它从未被设计用于的流量，因为正常的容量规划假设了边缘的吸收。如果许多用户在反复错误后重试，激增的流量可能会比正常需求更大。因此，Fastly 关于源站负载增加的状态警告不是脚注。它指出了恢复产生的二阶风险。

多 CDN 设计必须考虑这一点。没有热对象的辅助提供商可能立即从相同的源站拉取。两个正在恢复的提供商可能会产生重复的未命中。屏蔽配置可以减少负载，但会创建另一个重要的集中点。速率限制、认证、允许列表、WAF 规则和源站连接限制可能因供应商而异。日志可能以不同的格式或不同的速度到达，而此时事件响应者需要一个连贯的视图。

直接到源站的备用并不自动更安全。发布源站地址可能会改变攻击面。证书和主机路由必须正确。源站必须能够吸收需求，并在没有通常在边缘提供的服务的情况下自我防御。恢复静态页面但禁用登录、结账、搜索、个性化或滥用控制的绕过可能是正确的降级模式，但这种模式需要明确的业务批准和用户沟通。

实践测试是流量演练。组织能否在不引起危机的情况下将一定比例的生产流量引导到备用路径？备用路径是否返回相同的基本内容和安全标头？它能否处理预期的负载和重试激增？缓存失效和紧急发布是否可用？工程师能否使用主供应商故障域外部的凭证、设备、存储库和通信系统来操作它？恢复步骤是否可逆而不产生第二个事件？

服务水平协议不回答这些问题。信用在事后补偿一个狭窄的合同度量。它们不能恢复丢失的交易、延迟的公共通知或开发者工作流程。依赖 SLA 而不是演练备用方案的客户转移了一些财务后果，但没有转移连续性的运营责任。

多 CDN 是一种运营模式，而不是采购复选框

ThousandEyes 观察到，拥有多个交付提供商的客户取得了不同程度的成功。一些客户将根流量转移离开 Fastly，但继续从它加载关键页面对象。其他客户花费更长时间移除所有 Fastly 依赖项。这种行为说明了一个设计陷阱：如果页面后来需要来自受损提供商的脚本、样式、API、图像、字体、重定向或认证资产，那么在第一个请求处进行流量引导是不够的。

一个可执行的多 CDN 设计至少具有八个苛刻的属性。

第一，配置必须是可移植的。缓存键、生存时间规则、陈旧内容行为、源站选择、重定向、边缘代码、WAF 策略、机器人控制和标头操作因供应商而异。名义上等效的配置在异常请求下可能有不同的行为。可移植性要求经过测试的语义等效，而不是一个存放在存储库中的翻译文件。

第二，命名必须支持及时更改。低 DNS 生存时间值可以缩短某些转换，但解析器和客户端并非都在理想时刻刷新。顶级记录、CNAME 链、任播地址和证书验证施加了约束。引导层本身可以成为一个集中的依赖项。组织需要来自真实故障转移演练的测量传播数据。

第三，源站必须接受两个交付提供商。网络允许列表、双向 TLS、签名请求、健康检查、连接池和速率限制需要在紧急情况之前工作。一个无法向源站认证的备用 CDN 只是库存，而不是弹性。

第四，关键内容必须完整。根页面、基本对象、错误页面、重定向、API 和用户通信需要独立的交付。只提供图像的第二个供应商可能改善性能，但不能提高可用性。依赖映射应遵循用户旅程，而不是供应商合同。

第五，备用方案需要容量和商业许可。一个休眠的提供商可能没有为突然的全球转移预留容量。承诺的流量水平、突发定价、DDoS 假设和支持响应应提前商定。集中不能通过创建一个在第一次实际负载下就失败的辅助方案来解决。

第六，遥测必须存活。外部探测应通过不同的接入网络和区域进行测试。来自两个提供商的日志必须到达一个独立的分析路径。状态页面和寻呼工具不应仅位于它们报告状态的服务后面。客户需要快速区分 DNS、路由、TLS、边缘应用、源站和对象级别的故障。

第七，权限必须明确。GOV.UK 的团队有一个事件负责人和一个决定降级备用何时更可取的阈值。没有这种决策设计，响应者可能会在辩论他们是否被允许转移流量、接受减少的功能或承担更高的成本时浪费中断时间。

第八，故障恢复需要与故障转移相同的纪律。当流量回归时，缓存、DNS 应答、会话、证书和源站负载可能不稳定。Fastly 的初始恢复和最终事件解决是分开的里程碑。客户应根据成功的用户旅程和稳定的容量来定义自己的恢复点，而不是自动镜像供应商的状态颜色。

这些要求解释了为什么多 CDN 对于关键服务可能是合理的，而对每个站点来说并不经济。较小的组织可能理性地接受一个短暂的中断，而不是为重复的交付工程提供资金。问责不需要每个客户都采用相同的架构。它要求明确的影响容忍度、被理解的依赖、相称的恢复选择，并且不虚假声称普通的供应商冗余覆盖了整个平台的软件故障。

Fastly 的响应很快，但公共保证是狭窄的

在响应时间线上，Fastly 在几个方面表现良好。监控在一分钟内检测到全局问题。工程师在 40 分钟内识别出触发配置。禁用它使 95%的网络在 49 分钟内恢复。同一天晚些时候开始部署永久修复。公司传达说客户更改是有效的，并接受了它本应预见到该条件。

这些事实不应被最小化。快速检测和恢复实质上减少了公共伤害。分布式系统确实会失败，事件问责应同时承认控制性能和控制失败。一个暴露严重缺陷然后在一小时内控制住它的组织呈现出与一个无法看到或逆转自己平台状态的组织不同的风险。

然而，公开的事后分析使预防案例悬而未决。它说 Fastly 将调查为什么质量保证和测试没有检测到缺陷，评估改进修复时间的方法，并追求通过 WebAssembly 和 Compute@Edge 实现更大的隔离。它没有公布由此产生的调查、行动负责人、截止日期、关闭证据或独立评估。没有公开解释为什么一个配置会影响无关的服务，部署是否按 POP 或客户队列分阶段进行，或者现在有什么措施防止同类问题复发。

这并未证实 Fastly 内部没有执行这些行动。大型提供商通常根据保密条款向客户提供私人报告。它建立了一个公共信任的边界。外部人士可以相信观察到的恢复和声明的承诺；他们不能将简短的帖子当作已完成修复的证明。

Fastly 的2021 年 6 月季度报告将事件转化为正式的风险披露。文件描述了一个由人为错误导致、由有效客户配置触发的未发现软件缺陷。它说客户已经减少或移除了流量，并提出了服务水平索赔。它还披露了对合同带宽的更广泛依赖，以及提供商中断、争议、网络提供商故障、自然事件、流量限制或监管可能导致该容量不可用的可能性。

“由人为错误导致”的措辞不如公司技术序列提供的信息量丰富。所有软件都是由人编写和操作的。治理问题是哪个系统允许一个普通的人为行为造成广泛、相关的故障。个体-错误的语言可能会掩盖那些因为人和代码都是可能出错的而存在的设计和保证机制。

经济记录使可靠性成为治理问题

Fastly 的第二季度股东信称中断影响了几乎所有客户。流量减少，客户信用被发放，包括一家前十客户在内的几家客户尚未恢复流量，几家客户推迟了新项目。因为 Fastly 的模式是基于使用量的，更少的流量直接转化为收入压力。公司表示，中断和延迟的流量将影响其第三季度和全年的展望。

同一封信报告第二季度收入为 8500 万美元，并将全年收入指导设定在 3.4 亿至 3.5 亿美元，同时声明展望反映了中断、流量回升时间和预期的续约。这些因素无法与公开数据干净地分离，因此将整个预期变化归因于一小时的停机是不合理的。可辩护的结论是狭窄的：中断产生了服务信用和客户流量决策，将其经济影响扩展到了技术事件之外。

Fastly 的2021 年年报后来称受影响的客户已恢复流量，但并非所有流量都恢复到中断前的水平。它还披露了更早的 2021 年 1 月由软件更新中未发现的缺陷引起的平台中断，这导致了服务水平索赔。这两个事件未被描述为具有相同的技术原因。然而，它们的共存确实使得软件发布弹性成为董事会持续关注的合理主题，而不是一次性的操作异常。

公司的2021 年委托投票说明书在年会之前的 6 月提交，称董事会负责对风险进行知情监督，并监控战略风险敞口，而高管们日常管理重大风险。它将信息安全风险监督分配给了审计委员会。该文件未披露董事会在中断前对平台范围可用性风险了解多少，或之后审查了什么。它建立了治理架构，而不是董事会实际调查的质量。

对于一个产品是共享操作基础设施的提供商来说，可用性属于战略监督，即使审计委员会的职责侧重信息安全。一小时的中断改变了客户的路由决策、服务信用敞口、收入预期和信任。这是从工程控制到企业价值的直接桥梁。董事不需要调试边缘软件，但他们确实需要证据表明管理层能够约束软件发布、隔离租户配置、安全恢复，并验证修复。

问责是共享的，但不是模糊的

在云事件之后，共享责任经常被援引，仿佛它将责任传播得如此之广，以至于没有一方保持清晰的责任。更好的方法是根据控制能力分配责任。

Fastly 控制了引入缺陷的代码部署。它控制了接受和处理有效配置的解析器、编译器、运行时或其他平台机制。它控制了一个客户范围的变化是否会影响不相关的客户，软件如何到达 POPs，监控能看到什么，以及平台能够多快地禁用触发器并部署修复。这些都是提供商的责任，因为客户无法检查或操作它们。

客户控制了将特定用户旅程放在 Fastly 后面的决定，源站和备用的容量和安全性，使用一个或多个 CDN，DNS 和证书安排，静态备用内容，备用路径，以及恢复程序的准备程度。他们还控制了关键内部部署和通信工具是否共享相同的依赖项。这些都是客户的责任，因为 Fastly 无法确定每个服务的可接受中断时间为客户提供资金或为每个客户提供备用方案。

对等伙伴和转接提供商将流量传递到和传出 Fastly，但公开记录并未将其确定为主要原因。它们的多样性可能帮助保持了网络的可达性，而应用却失败了。将责任归咎于“互联网”或 BGP 会抹去层级证据。

提供触发配置的客户控制了其自己有效的服务更改。公开记录未识别该客户，未披露配置，也未暗示不当行为。一个多租户平台应假设有效的租户操作将会发生。不应将任何责任分配给该客户，除了作为触发器的这一不受支持的事实。

双方的董事会控制了风险偏好和证据要求。Fastly 的董事会可能询问一个平台发布是否具有独立的爆炸半径控制，以及一个租户操作是否可以跨越服务边界。客户董事会可能询问哪些重要服务是单供应商的，以及切换时间是否在业务影响容忍度之内。任何一方的董事会都不能将自己的问题外包给对方。

在共同提供商支持关键行业的地方，监管机构有一个较窄但重要的角色。金融稳定委员会的第三方风险工具包区分了公司层面的第三方管理与当局识别系统性依赖的需求。英格兰银行的SS2/21 关于外包和第三方风险的政策期望受监管公司管理集中和操作弹性。欧盟的数字运营弹性法案后来正式确立了对 ICT 第三方集中和管理机构责任对受覆盖金融实体的关注。

这些框架并不构成对 Fastly 的追溯性发现，它们也并不同样适用于每个 CDN 客户。它们显示了政策方向：关键服务用户对其依赖负责，而监管机构也需要对共同提供商的可见性，这些提供商的故障可能同时影响许多公司。公司层面的故障转移和系统层面的集中是需要不同证据的不同问题。

一次潜在边缘故障后，董事会应要求什么

董事会资料包应从故障域地图开始，而不是机群规模。POP 数量、容量和对等宽度是有用的，但董事应该看到哪些控制是全局的，哪些是独立隔离的。地图应将软件版本、配置分发、租户边界、控制平面、DNS、证书、日志记录、状态通信、源站屏蔽和提供商恢复工具连接起来。

对于提供商，证据应回答具体问题：

• 哪类有效输入激活了缺陷，哪个不变量本应拒绝或包含它？
• 为什么生产前测试、生产金丝雀和 5 月 12 日的部署间隔未能揭示它？
• 在自动停止之前，一个配置或一个发布队列可以影响多少客户、POP 和请求？
• 金丝雀组在代码、控制平面、地理和流量上是否独立，或者它们共享被测试的机制？
• 平台能否在不依赖受影响的提供路径的情况下禁用一个触发租户配置？
• 运行时隔离是否将畸形状态或软件异常转变为租户范围的错误，而不是进程或机群故障？
• 什么证据表明永久修复和更广泛的类控制已部署到所有预期位置？
• 哪些恢复指标描述了客户体验、源站负载、缓存预热和残余错误，而不仅仅是节点健康？

对于客户，资料包应显示重要的用户旅程以及每个旅程所需的确切外部资源。它应命名一个所有者、影响容忍度、备用模式、决策阈值和上次演练日期。检测、决定、更改 DNS 或引导、提供有意义的流量和安全返回的时间应分别测量。一个在影响容忍度之后完成的故障转移是一个学习机制，还不是一个有效的控制。

NIST 的应急规划指南提供了一个持久的序列：业务影响分析、预防控制、恢复策略、计划、测试、培训、演练和维护。其联邦范围不应被误认为是普遍的法律授权，但操作原则具有很好的可转移性。恢复计划通过演练和维护变得可靠。

NIST 的供应链风险指南同样强调了对所获得技术如何开发、集成和部署的可见性降低。CDN 客户无法检查所有提供商内部情况。它仍然可以要求事件条款、实质性依赖披露、通知时钟、恢复证据、与关键性相称的审计权利、配置可移植性、数据导出和对经过测试的退出的支持。

指标应避免简单的绿色信号。“签约了两个 CDN”是薄弱的。“在上次未宣布的演练中，90%的关键旅程在八分钟内通过备用 CDN 提供”则更强。“全球网络恢复”对于一个源站过载的客户来说是薄弱的。“成功交易在 30 分钟内稳定在正常的错误预算内”则更强。“缺陷修复”没有回归类别、发布证据和关闭负责人则是薄弱的。

持久的教训是关于独立恢复

Fastly 6 月 8 日的中断是严重的、可见的且相对短暂的。这种组合可能鼓励错误的结论。一种自我满足：因为大多数服务在 49 分钟内恢复，该事件变成了一个令人印象深刻的恢复故事。另一种是宿命论：因为一个主要提供商可能会失败，中断是不可避免的，进一步的问责没有用。证据不支持两者。

快速恢复值得称赞。Fastly 承认它本应预见到触发条件也值得称赞。但该潜在缺陷从 5 月 12 日存活下来，一个有效的客户更改影响了大部分网络，而公开的修复记录仍然是薄弱的。预防、遏制、响应和保证是不同的控制。在响应方面的强劲表现并不能弥补其他三个方面。

对于客户来说，该事件表明，一个源站、第二份合同或 DNS 程序并不自动是一个独立的恢复路径。GOV.UK 准备的辅助 CDN 仍然涉及有意的等待、降级服务和 DNS 传播。GitLab 的普通更改路径触及了受相同事件影响的外部软件包依赖。这些不是反对应急计划的论点。它们是证据，证明只有当通过所有依赖项进行演练时，应急措施才变得真实。

对于网络风险，这次中断显示了为什么对等和传输分析必须向上堆叠。Fastly 地理分布、多重连接的边缘减少了许多物理风险。它并没有阻止共享软件将那个边缘变成一个逻辑故障域。相同的互联在提供非凡性能的同时，也可以以相同的覆盖范围分布一个共同的错误。

因此，最终的问责判断是具体的。Fastly 对提供商方的缺陷、其传播以及故障类别已被遏制的证据负责。客户对知道当 Fastly 失败时什么变得不可用，并选择一个与危害相称的备用方案负责。董事对测试提供商和客户的保证是否在一个实际可执行的恢复边界上相遇负责。在涉及关键行业的地方，监管机构对超越单个合同、看到单一公司无法看到的共同依赖负责。

在下一次边缘中断之后，相关的问题将不是网络是否分布。而是软件命运、操作权限和恢复能力是否也不独立分布。