摘要
- 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分钟的管理与构建侧降级，而公司明确称缓存交付和其他边缘安全功能保持服务。
