Fastly 的潜在漏洞与集中式 CDN 边缘的问责

摘要

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

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

2021 年 6 月 8 日 09:47 UTC，公共网络的很大一部分开始返回错误。新闻网站、商业服务、开发者平台、流媒体资产和英国中央政府网站均在可见的受灾之列。从外部看，事件像是许多无关组织同时发生故障。从基础设施角度看，它们确实相关：对这些服务的请求汇聚到了 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 的同期网络观察在 09:49 UTC 检测到事件开始，并测量到来自 Fastly 的流量下降约 75%，随后在 10:39 开始恢复。Cisco ThousandEyes 的逐层分析观察到在网络路径继续运行的情况下出现服务错误，并描述了随着流量在交付提供商之间转移的不同客户恢复模式。稍后的 ThousandEyes 产品分析直接说明了这一区别：在应用程序层出现 503 错误，而网络层看起来正常。

Fastly 自身的对等互连策略将 AS54113 标识为其与互联网服务提供商和内容网络交换流量的自治系统。其全球 POP 文档解释称，存在点放置在密集的互联网交换位置附近，提供商多样性和网络邻近性是其设计因素。DNS 和 Anycast 将用户引导至附近的 Fastly 容量。在物理本地化故障中，这些属性可以绕过受损的链路、运营商、设施或 POP。

在事件发生前，Fastly 描述了一个覆盖 26 个国家和六大洲的 68 个 POP 网络，通过混合传输、互联网交换、云对等互连和专用互连连接。其容量规划说明称其模拟了 POP 和连通性故障，并为溢出维护了区域性余量。这些是有意义的弹性形式。它们减少了对一条缆线、一家运营商、一栋建筑和一个都会站点的依赖。

它们没有解决 6 月 8 日的故障模式。如果许多 POP 运行相同的缺陷平台代码并接受公共配置模型，地理多样性可以复现而非隔离缺陷。多个传输提供商可以可靠地将用户带到可靠地返回错误的边缘节点。更多的对等会话可以改善可达性和路径选择，同时使服务应用程序不可用。Anycast 可以将请求移动到另一个 POP，但如果该 POP 遇到相同的软件状态，用户只是改变了位置而没有改变结果。

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

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

分布与集中可以共存

本次宕机产生了一个视觉悖论。受影响的设施遍布全球，然而一个单一的潜在条件导致了许多地方和组织的同步故障。分布描述资源的位置。集中描述在故障与广泛危害之间有多少独立决策、实现和恢复路径。一个系统可能在第一个方面得分很高，而在第二个方面得分很低。

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

这些测量是带有方法局限的快照。它们不应被转化为声称 62% 的网络依赖 Fastly 或所有测量的托管关系都是关键的。其相关性在于结构。流行服务通常依赖少数提供商，一个页面可能包含来自其中几个的资源。因此，集中可能出现在几个层面：

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

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

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

这并不意味着集中本质上是鲁莽的。集中的专业知识和基础设施可以比数千个薄弱的个人部署创造更好的安全性、性能和可靠性。问责问题是：从公共基础设施获得的效率是否由更强的共同模式控制、透明的事件证据和现实的退出或备用选项相匹配？集合越重要，视平台范围安全为普通产品质量问题就越难令人信服。

GOV.UK 有备份，但仍经历了宕机

政府数字服务关于GOV.UK 的公开事件报告是客户方决策的最清晰记录之一。GOV.UK 在开始后四分钟检测到自身影响，确立了事件和沟通负责人，确认主要 CDN 为源头，并找到了一个记录在案的故障转移到备用提供商的流程。

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

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

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

GOV.UK 的记录提供了几个问责测试。备用是否实际预热？是的。是否有记录在案的流程和指定权力？是的。降级是否被理解？是的。切换机制对于服务的影响容忍度是否足够快？观察到的时间线为决策者提供了回答的证据，而非理论保证。该报告还展示了为什么董事会应询问转移有意义用户流量的中值和最差时间，而不仅仅是是否签订了第二个 CDN 合同。

对于公共服务，这一区别尤其重要。表示层面的宕机可以使税收指南、福利信息、健康材料、监管指示和紧急更新无法访问，即使底层部门系统保持健康。当它是公共入口点时，这个层面并非装饰。业务影响映射应视交付丧失为对用户实际可达服务的丧失。

GitLab 发现了恢复路径内的依赖

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

10:18 UTC，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 TTL 值可以缩短某些过渡，但解析器和客户端并非都在理想时刻刷新。根部记录、CNAME 链、Anycast 地址和证书验证施加了约束。一个引导层本身可能成为一个集中的依赖。组织需要来自真实故障转移练习的测量传播数据。

第三，源站必须接受两个交付提供商。网络允许列表、双向 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 月因软件更新中未发现漏洞导致的另一次平台中断，该中断引发了服务级别索赔。这两次事件未被描述为拥有相同的技术原因。然而，它们的共存确实使软件发布弹性成为董事会持续关注而非一次性操作异常的合理主题。

该公司在 6 月年会前提交的2021 年委托书表示，董事会负责风险知情监督和监控战略风险敞口，而高管日常管理重大风险。它指派信息安全风险监督给审计委员会。文件未透露董事会在宕机前对平台范围可用性风险了解多少，或事后审查了什么。它建立了治理架构，而非董事会实际调查的质量。

对于产品是共享运营基础设施的提供商，可用性属于战略监督，即使审计委员会的规定职权强调信息安全。一小时的缺陷改变了客户路由决策、服务信用敞口、收入预期和信任。这是从工程控制到企业价值的直接桥梁。董事无需调试边缘软件，但他们需要证据表明管理层能够界定软件发布、隔离租户配置、安全恢复和验证补救。

责任是共享的，但并非模糊

共享责任在云事件后常被引用，仿佛它广泛分散了责任，以至于任何一方都不保持明确问责。更好的方法是通过控制能力来分配责任。

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

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

对等互连合作伙伴和传输运营商往返于 Fastly 之间传输流量，但公开记录并未将它们识别为原因。它们的多样性可能有助于在应用程序失败时保持网络可达。将责任归咎于“互联网”或 BGP 将抹去分层证据。

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

双方董事会控制了风险偏好和证据要求。Fastly 的董事会可以询问平台发布是否有独立的爆炸半径控制，以及租户操作是否可以跨越服务边界。客户董事会可以询问哪些重要服务是单归属的，以及切换时间是否保持在业务影响容忍度内。没有一个董事会可以将问题外包给另一个。

监管机构在通用提供商支持关键部门时拥有更窄但重要的作用。金融稳定委员会的第三方风险工具包区分了公司层面的第三方管理与当局识别系统性依赖的需要。英格兰银行的关于外包和第三方风险的 SS2/21期望受监管公司管理集中度和运营弹性。欧盟的数字运营弹性法案后来正式化了对 ICT 第三方集中度和受覆盖金融机构管理机构责任的关注。

这些框架并未创建对 Fastly 的追溯性裁决，它们也不等同地适用于每个 CDN 客户。它们显示了政策方向：关键服务用户仍对其依赖负责，同时监管机构也需要对常见提供商的可见性，因为其故障可能同时影响许多公司。公司级故障转移和系统级集中是独立的问题，需要不同的证据。

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

董事会文件应以故障域图开始，而非舰队规模。POP 数量、容量和对等互连广度是有用的，但董事应看到哪些控制是全局的，哪些是独立隔离的。该图应连接软件版本、配置分布、租户边界、控制平面、DNS、证书、日志记录、状态通信、源站屏蔽和提供商恢复工具。

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

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

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

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

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

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

持久教训是关于独立恢复

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

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

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

对于网络风险，宕机展示了为什么对等互连和传输分析必须向上层堆栈推进。Fastly 地理上分布、多重连接的边缘减少了许多物理风险。它没有阻止共享软件将该边缘转变为一个逻辑故障域。相同的互连提供了非凡的性能，同时可以以同等范围传递一个共同错误。

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

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