摘要

  • Fastly 的服务版本机制允许重新激活旧配置，但 API 所示的 active 状态属于控制面事实，并非每个服务请求的节点都已收敛的证明。
  • 回滚验收应按 POP 记录最后一次旧版本响应、恢复版本、针对有害行为的探针，以及另行管理的 purge 或缓存 generation 状态。

中央屏幕显示回滚成功，旧版本已经重新成为 active，整体错误率也在下降。但一个远端 POP 的请求仍在执行刚被撤回的规则。这是一个假设的验收场景，不是 Fastly 已报告的事故。它要区分的是“命令被接受”和“结果已完成”。

Fastly 把服务版本定义为一组明确配置。版本可以克隆、锁定、激活和停用；同一服务只有一个 active 版本，旧的 inactive 版本也可以再次激活。这让恢复有了清晰对象，也很容易让团队把 API 返回时间当作结束时间。

Fastly 自己的入门教程说明，配置变更可能需要几分钟才能传播。分布式系统需要时间并不等于缺陷，却说明中央状态和全球请求行为是两个不同观察。

POP 是执行群体，不只是地图上的点

Fastly 将 POP 描述为一组缓存服务器。启用 clustering 和 shielding 后，一次请求可能经过多个站点或 POP。VCL 的 server.datacenter 和 Compute 的 FASTLY_POP 可以标识服务位置，边缘环境也能暴露服务版本。这样才能回答：哪一个版本，在什么地点、什么时间，对哪项测试作出了决定？

普通健康检查不够。探针必须真正经过被撤回的路径重写、权限规则、源站选择、header 策略、缓存键、Compute 分支或安全决策。无关端点返回绿色，只能证明网络还能回答。

第一个时间点是中央激活回执；决定性的时间点，是最后一条仍受旧版本或旧规则支配的响应。两者之间才是回滚收敛区间。应看所有已观察 POP 的最大值，而不是平均值。

日志能证明出现，未必能证明不存在

Fastly 提供近实时流式日志，也允许记录服务请求的数据中心。一条显示旧版本在期限后仍被执行的日志，是强阳性证据。Fastly 同时明确，日志投递是 best effort，不能保证完整；分布式系统为了稳定和性能可能丢弃记录。

因此，日志中没有旧版本，并不能单独证明全球不存在。需要结合主动探测、请求级 POP/版本标记、真实流量、平台证据和未观察群体清单。Anycast 也使客户难以随意指定每个 POP，正确做法是报告实际覆盖率，而不是假装全覆盖。

配置与缓存不是同一个回滚面

Fastly 的 purge 文档给出了多种传播时钟：purge-all 最长可需两分钟；URL 或 surrogate-key purge 约以 150 毫秒传播；边缘代码发出的 cache-key purge 默认只作用于本地 POP，除非显式选择 global；soft purge 还可能保留可作为 stale 使用的旧对象。

Fastly 也记录过一种竞态：shield 在 purge 后把旧内容返回给 edge，使其继续缓存。对 purge-all，平台通过 VCL 和 Compute 暴露缓存 generation，文档还给出比较 shield 与 edge generation 的思路。因此，恢复配置版本不等于缓存对象、缓存键、动态数据或源站状态都已恢复。若必须 purge，还要防止重新填充时压垮源站。

2021 年事故可以说明什么

Fastly 称，2021 年 6 月 8 日的全球中断源于一个未发现的软件缺陷，被一次有效的客户配置变更触发。时间线显示 09:47 UTC 开始，10:27 确认触发配置，10:36 开始恢复，11:00 大多数服务恢复，12:35 完成缓解。

该事故证明，有效配置可以与平台软件产生全球性影响，恢复也有多个阶段。公开说明并未称某个 POP 继续执行已撤回规则，因此不能把本文场景强加给该事故。合理结论只是：回滚时长和完成证据应成为单独的验收对象。

回滚台账应联合记录服务、撤回和恢复版本、中央请求/回执、按请求观察到的版本和 POP、准确的有害探针、trace、缓存 generation、最后旧响应、第一条恢复响应、覆盖范围、日志缺口，以及有权宣布结束的人。

来源