摘要
- 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 的帖子中独立确定永久修复是只移除了触发因素，修复了根本缺陷，还是更改了允许如此广泛爆炸半径的架构。
这一差距应塑造结论。记录支持一个潜在漏洞、一个有效触发因素、全局错误行为、快速检测和相对快速的缓解。它不支持有关错误代码或个别工程师行为的详细理论。问责分析应保持在控制层面：测试设计、配置隔离、部署安全、全局故障遏制、可观察性、事件权限以及向客户和董事提供的证据。
时间线区分休眠风险与主动中断
对于许多用户，事件持续不到一小时，但相关控制窗口几乎在四周前就开始了。缺陷可能在操作上存在而不产生可见症状。这就是潜在故障难... (truncated, same as contentHtml)