摘要
- Cloudflare 于 11:51:07 UTC 创建事件 pgcdxsjxkl0q，影响等级为轻微，状态为调查中。
- 在本轮 11:53:12 UTC 固定截止点，Analytics 处于性能下降，尚无恢复更新。
- 首份通知称 Dashboard 及相关 API 请求可能失败或显示错误。
- Cloudflare 明确排除 CDN 缓存文件交付和其他边缘安全功能受到影响。
- 后续更新把 API、Dashboard、Pages 及 Worker 构建纳入范围，12:43:57 进入监控。
- 事件于 13:01:59 解决，但未说明根因、受影响客户数或地区分布。
固定窗口看见的是事件开端
从 11:51:07 开始到 11:53:12 截止，只有 2 分 05 秒。此时官方记录只足以确认 Analytics 降级和 Cloudflare 正在调查。
修复、监控和解决都发生在窗口之后。它们应按原始时间补充，而不能改写截止时的认知状态。
把“当时知道什么”与“后来发生什么”分开，是滚动新闻准确性的基本条件。
公开访问与管理能力可以同时呈现不同状态
Cloudflare 称缓存文件继续通过 CDN 交付，其他 Edge 安全功能也未受影响；但客户可能无法稳定使用 Dashboard 或相关 API。
因此，用户能打开网页，并不等于运营团队能查看分析数据、修改配置或发布新版本。
这也不能被概括为 DNS、CDN 和所有安全能力全面中断。故障边界位于控制和构建侧。
影响范围是分步确认的
12:25:44 的更新继续调查，并把 API 和 Dashboard 标记为降级。12:37:35，Cloudflare 再确认 Pages 与 Worker 构建受影响。
最终记录没有把后两项的开始时间追溯到 11:51。能够确认的是披露时间，不是它们此前已经故障的确切时长。
用各更新自己的时间戳，能避免把逐步扩大的范围写成从起点就完全一致。
构建失败影响的是下一次变更
已经部署的 Pages 或 Worker 版本可能继续运行，但新的构建无法完成，会阻碍功能上线、紧急修复和回滚。
对静态运行的站点，外部影响可能很小；对正处理漏洞或事故的团队，同样时长会更关键。
Cloudflare 没有公布失败请求率、构建失败数量和客户类型，无法估计总体业务损失。
解决状态没有给出技术原因
12:43:57，Cloudflare 称已实施修复并进入监控；12:46:20 再次表示持续观察；13:01:59 事件解决。
Analytics、API、Dashboard、Pages 和 Workers 随后全部恢复为 operational。最终通知只说明状态恢复，没有根因或客户补救步骤。
“已解决”能够结束告警，不能替代事后分析。
连续性预案需要单独覆盖控制面
客户可把配置纳入版本控制，在 Dashboard 之外保存必要指标，并预先区分哪些变更必须立即执行、哪些可以等待。
应急手册还应分别判断边缘交付故障和管理面故障。看到监控工具失灵就转移仍然健康的流量，反而可能扩大问题。
业务方还应记录故障窗口内被推迟的配置、构建和回滚，在控制面恢复后逐项重放并核对结果。恢复访问并不意味着积压操作已经安全完成。
后续最有价值的证据是根因、错误率、失败构建数以及延迟分析数据是否补齐。现有记录支持的结论较窄：Cloudflare 经历了约 70 分钟的管理与构建侧降级，而公司明确称缓存交付和其他边缘安全功能保持服务。