从 1531 UTC 开始一直持续到 1952 UTC，我们两个核心数据中心中有一个发生多路冗余光纤连接中断，导致 Cloudflare 仪表板和 API 无法使用。
这次中断不是由 DDoS 攻击造成的，也与 COVID-19 危机引起的流量增长没有关系。其原因也不是任何软件或硬件故障，或任何配置不当。
究竟发生了什么
作为在我们核心数据中心之一进行的维护计划的一部分，我们指示技术人员拆除某一个机柜中的所有设备。这个机柜里面有我们计划淘汰的非在用的旧设备，而且里面的任何服务器上都没有活跃的流量或数据。这个机柜里还有一个配线架（线缆接线板），提供与其他Cloudflare 数据中心的所有外部连接。在三分钟时间内，技术人员停用了我们未在使用的硬件，也断开了此配线架中的线缆。
这一数据中心承载着 Cloudflare 的主控制平面和数据库，因此，当我们断开连接后，仪表板和 API 的服务立即停止。Cloudflare 网络本身继续正常运作，代理的客户网站和应用程序也继续运行。Magic Transit、Cloudflare Access 和 Cloudflare Spectrum 同样如此。所有安全服务，例如我们的 Web Application Firewall，也继续照常运行。
但是，以下操作无法进行：
- 登录仪表板
- 使用相关 API
- 进行任何配置更改（例如更改DNS记录）
- 清除缓存
- 运行自动负载平衡运行状况检查
- 创建或维护 Argo Tunnel 连接
- 创建或更新Cloudflare Workers
- 将域名转移到Cloudflare Registrar
- 访问 Cloudflare 日志和分析
- 在 Cloudflare Stream 上编码视频
- 记录来自边缘服务的日志信息（客户将在日志数据中看到空缺）
此次中断没有导致配置数据丢失。我们客户的配置数据会同时进行备份和异地复制，但这次没有备份或副本需求。所有配置数据均保持就位。
我们是如何响应的
在中断期间，我们设法立即切换到灾难恢复核心数据中心并恢复连接。
数十名工程师在两个虚拟作战室奋战，因为 COVID-19 疫情导致Cloudflare 的大部分人都在远程工作。一个作战室专门用来恢复连接，另一个则专门进行灾难恢复故障转移。
我们很快对内部监控系统进行了故障转移，从而能监控整个 Cloudflare 网络。这样，我们就能统揽全局，找到 200 多个城市中任何网络位置的问题。切换之后，Cloudflare 的边缘服务可以继续正常运行，并且 SRE 团队可以应对该服务日常运行中出现的任何问题。
在处理这一事故期间，我们每 20 分钟就是否将仪表板和 API 故障转移到灾难恢复中心或继续尝试恢复连接做出决定。如果数据中心受到了物理损坏（例如，倘若发生了自然灾害），那么切换决定便很容易做出；但由于我们对故障转移进行过测试，我们知道从灾难恢复中心回复将非常复杂。因此，我们根据事态发展权衡利弊，得出最佳的行动计划。
到 1944 UTC，从该数据中心到互联网的第一条链路恢复上线。这是一条具有 10Gbps 容量的备用链路。
到 1951 UTC，我们恢复了连接互联网的四大链路里的第一条。
到 1952 UTC，Cloudflare 仪表板和 API 恢复服务。
到 2016 UTC，四条链路里的第二条恢复正常。
到 2019 UTC，四条链路里的第三条恢复正常。
到 2031 UTC，所有冗余连接全部恢复。
展望未来
我们非常严肃地对待这一事故，并认识到它所产生的影响。我们已经确定了几项措施，以应对日后再度出现此类问题的风险，并且我们计划立即着手处理：
- 设计：虽然外部连接使用了多样的提供商，形成了多样的数据中心，但我们的所有连接都只通过一个配线架，造成了单一物理故障点。这应该要分散到我们设施的多个部分。
- 文档：从配线架上拔下线缆后，我们在为数据中心技术人员确定要恢复的外部连接关键线缆时浪费了宝贵的时间。我们应该采取措施，确保各种线缆和面板都贴上标签，以便任何解决问题的人员能够快速识别。这应当能提升我们访问所需文档的能力。
- 流程：在向技术人员发送淘汰硬件的指示时，我们应明确标注不应触碰的线缆。
我们将在内部进行全面的事后调查，确保找到并解决本次事故的根本原因。
我们对这次中断感到非常抱歉。