Fastly 的潜在缺陷与集中式 CDN 边缘的责任归属

摘要

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

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

2021 年 6 月 8 日 UTC 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 文档解释说，入网点被放置在密集的互联网交换位置附近，提供商多样性和网络邻近性是设计因素之一。DNS 和任播将用户引导至附近的 Fastly 容量。在物理局部故障中，这些特性可以绕过受损的链路、运营商、设施或 POP。

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

但它们没有解决 6 月 8 日的故障模式。如果许多 POP 运行相同的缺陷平台代码并接受一个通用配置模型，地理多样性可能复制而不是隔离缺陷。多个传输提供商可以可靠地将用户引导至可靠地返回错误的边缘节点。更多的对等互联会话可以改善可达性和路径选择，但服务应用程序仍然不可用。任播可以将请求移动到另一个 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 功能继续运行，显示了分离服务路径的价值。

在 UTC 10:18，GitLab 工程师准备了一个合并请求来替换用于静态资产的 CDN。他们无法通过正常的流水线应用它，因为该流水线中的一个镜像尝试从外部仓库安装一个包，该外部仓库也受到了 Fastly 中断的影响。一个预期的恢复机制通过一个不属于 CDN 设置的依赖项继承了相同的外部事件。

这是传递性集中的简洁例子。在架构图上，应用程序、配置流水线、容器镜像、包索引和 CDN 可能显示为不同的方框。在操作上，恢复动作依赖于执行它所需的每个方框。如果一个构建步骤到达一个不可用的外部服务，在需要它来移除另一个依赖项的时刻，该流水线就不可用。

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

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

恢复可能将缓存效率变为源站压力

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

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

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

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

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

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

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

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

一个可执行的多 CDN 设计至少具有八个严格的性质。

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

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

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

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

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

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

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

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

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

Fastly 的响应迅速，但公开保证有限

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

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

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

这并不能确定 Fastly 没有在内部执行这些行动。大型提供商通常根据保密条款向客户提供私人报告。这确立了公共信心的边界。外部人士可以相信观察到的恢复和所述的承诺；他们不能将简短的文章视为已完成补救的证明。

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

“由人为错误引起”的表述不如该公司的技术序列信息丰富。所有软件都是由人编写和操作的。治理问题是哪个系统允许一个普通的人为操作造成广泛的、相关的故障。个人错误的表述可能会掩盖设计和保证机制，而这些机制之所以存在，正是因为人和代码都是易出错的。

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

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

同一封信函报告第二季度收入为 8500 万美元，并将全年收入指引定为 3.4 亿至 3.5 亿美元，同时表示展望反映了中断、流量攀升时间和预期的续订。这些因素无法与公开数据干净地分开，因此将预期的全部变化归因于一个小时的停机是不合理的。站得住脚的结论更窄：中断产生了服务信用额度和客户流量决策，将其经济影响延伸到了技术事件之外。

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

该公司的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% 的关键旅程在 8 分钟内通过备用方案提供服务” 更强。“全球网络已恢复” 对于源站过载的客户来说是弱的。“成功交易在正常错误预算下稳定 30 分钟” 更强。“错误已修复” 在没有回归类别、推出证据和关闭负责人的情况下是弱的。

持久的教训在于独立恢复

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

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

对于客户，该事件表明，源站、第二份合同或 DNS 程序并不自动构成独立的恢复路径。GOV.UK 准备就绪的备用方案仍然涉及有意等待、服务降级和 DNS 传播。GitLab 的正常更改路径触碰了一个受到相同事件影响的外部包依赖。这些不是反对应急计划的论据。它们是证明，只有当通过所有依赖关系进行演练时，应急计划才成为现实。

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

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

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