Cloudflare 控制面板服务中断的事故分析

[gam2046]

建议有阅读能力的朋友，直接阅读原文地址： https://blog.cloudflare.com/post-mortem-on-cloudflare-control-plane-and-analytics-outage/

由于各种原因，可能对于原文解读存在错误，如有出入，请以原文为准

---

省流版本

因当地的供电团队进行计划外的电力维护，致使 PDX-DC04 核心数据中心意外断电，Cloudflare 团队尝试将该数据中心的业务切换到欧洲地区的高可用集群，但是失败了，原因是业务设计中存在部分依赖项目不在高可用集群中。最后在当地电力团队恢复供电后，才逐步恢复服务。

完整版本

(以下所有时间，均为 UTC 时间)

2023 年 11 月 2 日，互联网安全和性能提供商 Cloudflare 的控制平面和分析服务发生了一次持续近两天的中断事件。该事件的主要原因是其位于美国俄勒冈州的最大数据中心 PDX-04 在当地电力公司进行非计划维修时遭遇了两次电力故障，导致数据中心的发电机和电池备用电源均失效。该数据中心由 Flexential 运营，但 Flexential 在事件发生和恢复过程中没有及时通知 Cloudflare ，也没有按照最佳实践处理电力问题。

Cloudflare 的控制面板和分析服务主要运行在俄勒冈州的三个数据中心，其中 PDX-04 占据了最大的比例。这三个数据中心之间通过高可用性集群实现数据同步和服务冗余，以应对任何一个数据中心的故障。然而，Cloudflare 在事件中发现，有一些服务虽然在高可用性集群上运行，但却依赖于 PDX-04 中的一些服务，例如 Kafka 和 ClickHouse 。这些依赖导致了一些服务的故障，影响了客户对 Cloudflare 网站和 API 的访问和修改。此外，Cloudflare 的日志处理和分析报告服务也因为 PDX-04 的停电而无法正常工作。

Cloudflare 在事件发生后，迅速派出了本地团队前往数据中心，并决定将一些服务切换到欧洲的灾备站点。在切换过程中，Cloudflare 也遇到了一些问题，例如请求量过大、部分产品没有灾备方案等。Cloudflare 在 11 月 2 日的 17:57 恢复了大部分服务的稳定性，但仍有一些服务，主要是日志处理和一些定制的 API ，直到 PDX-04 恢复后才能正常工作。Flexential 在 22:48 恢复了 Cloudflare 的电力供应，并确认了电力的质量。Cloudflare 在第二天开始恢复 PDX-04 的服务，包括重启网络设备、重建数千台服务器和恢复服务的状态。Cloudflare 在 11 月 4 日的 04:25 完成了所有服务的恢复。

Cloudflare 表示对此次事件感到抱歉和尴尬，并承诺将采取一系列措施来提高控制平面的可靠性和弹性。这些措施包括：

• 移除对核心数据中心的依赖，尽可能地将控制面板的配置转移到分布式的网络上
• 确保在核心数据中心全部离线的情况下，分布式的网络上的控制平面仍能正常运行
• 要求所有正式发布的产品和功能必须依赖高可用性集群，而不是特定的数据中心
• 要求所有正式发布的产品和功能必须有可靠的灾备计划，并进行测试
• 测试系统故障的影响范围，并尽量减少受到影响的服务数量
• 实施更严格的混沌测试，包括完全关闭每个核心数据中心的测试
• 对所有核心数据中心进行彻底的审计，并制定重审计划，以确保符合我们的标准
• 实施日志和分析的灾备计划，确保在所有核心数据中心故障的情况下，不会丢失任何日志数据

[szdosar]

“PDX-DC04”或“PDX-04”，位于俄勒冈州希尔斯伯勒的一个由 Flexential 运营的数据中心（具体地址是 4915 NE Starr Blvd, Hillsboro, OR, USA ）设施，Cloudflare 在这里部署了其大部分分析集群和高可用性集群。
一个危险的鸡蛋放在同一个篮子的案例。