2 月 6 日，Cloudflare 旗下 R2 对象存储发生 59 分钟的全面宕机，导致所有 R2 相关操作（包括文件上传、下载和元数据管理）完全失效。与此同时，依赖 R2 的多个 Cloudflare 服务，如 Stream、Images、Cache Reserve、Vectorize 和 Log Delivery 也受到严重影响。
事件起因
本次事故由 人为错误 和 滥用处理系统的控制缺陷 共同导致。Cloudflare 在处理一份关于 钓鱼站点 的滥用报告时，错误地 禁用了整个 R2 网关服务，而非针对具体存储桶采取行动。这直接导致 R2 API 瘫痪，并影响了多个依赖 R2 的核心业务。
影响范围
R2 存储：100% 操作失败，无数据丢失。
Stream（视频流服务）：上传和播放全部失败。
Images（图像存储）：上传和下载失败，但部分缓存仍可用，影响较小。
Cache Reserve（缓存存储）：所有缓存请求失败，导致回源服务器负载增加。
Log Delivery（日志交付）：日志交付延迟，部分日志丢失（R2 相关日志丢失率高达 13.6%）。
Durable Objects（持久存储）：北美地区短暂出现 0.09% 失败率。
Vectorize（向量存储）：75% 查询失败，100% 插入、更新、删除操作失败。
Workers & Pages：少量部署失败，仅影响依赖 R2 绑定的项目。
恢复过程
事故发生后，Cloudflare 工程团队 花费近 1 小时 排查问题，并最终通过手动重新部署 R2 网关恢复服务。
08:14 UTC 影响开始，09:13 UTC 恢复，10:29 UTC 完全恢复。
时间线
08:12 - 处理滥用报告时，R2 网关服务被错误禁用。
08:14 - 影响开始，所有 R2 API 请求失败。
08:15 - R2 监控指标显示异常。
08:17 - 关键告警触发，R2 无法通过健康检查。
08:18 - R2 值班工程师开始排查日志和监控数据。
08:23 - 售前工程师反馈客户遇到 HTTP 500 错误。
08:25 - 内部正式宣布事件。
08:33 - R2 工程团队无法找到根因，升级给高级值班工程师。
08:42 - 确认问题源于滥用处理系统导致 R2 生产环境被禁用。
08:46 - 工程师尝试使用管理工具恢复 R2 网关，但因工具本身依赖 R2，无法执行恢复。
08:49 - 工程师向运维团队求助，他们拥有更低级别的系统访问权限。
08:57 - 运维团队开始重新启用 R2 网关服务。
09:09 - R2 团队触发 R2 网关重新部署。
09:10 - R2 开始恢复，客户端逐步重新连接。
09:13 - 主要影响结束，R2 恢复至服务级别目标（SLO）。
09:36 - Durable Objects 负载恢复正常。
10:29 - 事件结束，所有指标恢复正常。
为防止类似事故重演，Cloudflare 已实施或正在推进 以下改进措施：
1. 增强滥用处理系统的安全机制，防止误禁用生产服务。
2. 对内部账户增加标记，避免生产环境遭误操作。
3. 加强访问权限控制，限制高风险操作的执行权限。
4. 引入“双人审批”机制，高级操作需二次确认。
5. 优化内部账户管理架构，减少误操作的可能性。
Cloudflare 承认此次事故对客户造成了重大影响，并表示深感抱歉。公司承诺将继续优化安全控制，减少人为操作带来的潜在风险，以确保未来不会再发生类似事件。
相关链接: Cloudflare Blog / 蓝点网
