一个客户改了一次设置，Reddit、纽约时报同时打不开：Fastly 潜伏三周的 bug
目录
配图：AI 生成的概念示意图，非论文原图、真实现场或实验数据。
TL;DR：2021 年 6 月 8 日，CDN 服务商 Fastly 的全球网络约 85% 返回错误，大量知名网站同时无法访问。Fastly 事后说明，原因是 5 月 12 日起部署的软件里藏着一个未被发现的 bug，被某位客户一次“合法”的配置变更触发。这不是黑客攻击，也不是该客户的错；约 49 分钟内 95% 的网络恢复正常。
这是一件 2021 年的旧事，这里当作案例回顾，不是今天的新闻。
发生了什么
2021 年 6 月 8 日 UTC 09:47，Fastly 的网络开始出现全球性故障。据当时的新闻报道，纽约时报、卫报、Twitch、Reddit 以及英国政府主页等网站一度无法连接。
Fastly 的监控大约一分钟后就发现了异常，09:58 发布状态通告。10:27 工程师定位到触发问题的客户配置，随即将其禁用。10:36 起服务开始恢复，约 11:00 大部分已恢复，12:35 事件被判定为已缓解。
潜伏三周的 bug
根据 Fastly 的复盘，问题的种子在 5 月 12 日就埋下了：那天开始的一次软件部署引入了一个 bug，只有在特定客户配置、特定情形同时满足时才会触发。它顺利通过了质量保证和测试，在线上安静地躺了近四周。
6 月 8 日凌晨，一位客户推送了一次有效的配置变更，恰好满足这些条件，bug 被引爆。Fastly 强调这是一次合法操作，客户并没有做错什么。
为什么值得记住
第一，这是 CDN 集中化的代价。很多互不相关的网站，背后共用同一家边缘网络，一处出问题就是一大片一起掉线。
第二，“合法输入触发潜伏 bug”很难靠常规测试防住。系统每天处理海量配置，任何一个组合都可能是没人试过的角落。
第三，影响面极大但恢复很快：发现仅用约一分钟，95% 的网络在 49 分钟内恢复。快的原因是定位到了触发配置并直接关掉它，而永久性修复要晚得多，17:25 UTC 才开始部署。
后续
Fastly 的工程高级副总裁 Nick Rockwell 公开表示，公司应当预见到这类情况。承诺的后续动作包括：尽快安全地在全网部署修复、对流程和实践做完整复盘、查明测试为何没发现、缩短故障修复时间；长期则计划借助 WebAssembly 与 Compute@Edge 的隔离机制，提高平台韧性。