2026 年八月 27 日凌晨，Proton 发生了大范围服务中断，影响了众多用户的服务。根本原因是法兰克福数据中心的冷却系统完全失效。虽然 Proton 的所有系统均具备冗余设计，且我们拥有足够的容量来承受整个数据中心完全瘫痪的情况，但在少数场景下，故障转移可能耗时更长，并导致用户端服务中断。

以下是事件发生的时间线，包括事件期间我们做出的选择及其原因，以及问题最终如何解决。

时间线

八月 26 日星期三，欧洲中部时间晚上 11 点刚过，我们法兰克福数据中心主机房的冷却系统发生故障。晚上 11 点 15 分左右，温度在不到半小时内从约 21.8°C（标称温度）升至 51.9°C，部分测量探头显示机房内气温达 60°C。随着温度不断上升，机房内的服务器和网络设备开始逐一瘫痪。

用户端服务中断始于八月 27 日午夜前后，当时故障升级到关键冗余丢失的程度。原因是关键机架上的主要网络交换机和备份网络交换机同时发生故障，而该机架不幸包含多个主要数据库副本。虽然 Proton 几乎所有系统都具备冗余并会自动/立即进行故障转移，但主要数据库的故障转移在没有人工监督的情况下不会自动执行。

我们保留这种人工控制，是为了避免所谓的“脑裂”情况，即主要数据库暂时不可用导致副本错过部分更新，进而以日后难以调和的方式失去同步。此外，当主要数据库发生故障转移时，出于延迟和性能方面的考虑，标准操作流程是转移到同一数据中心内的副本。然而，此次问题的特殊性意味着这种做法可能并不明智，因为我们可能会转移到同样会宕机的设备上。

相关决策

此时，Proton 的值班工程师需要在极大压力下做出几项影响重大的决策。

  • 是优先让服务恢复在线，还是优先解决冷却问题并保住数据中心内的硬件？
  • 是故障转移到法兰克福同一栋楼内的副本（速度更快、影响更小，但如果高温无法得到控制，可能只是权宜之计），还是故障转移到苏黎世？
  • 是将所有系统进行故障转移，还是仅转移当时已宕机的系统？我们有应对整个数据中心完全瘫痪的应急预案，在这种情况下系统会全面且大多自动地快速完成故障转移，但服务器随机逐一宕机的情况却难以被我们的故障转移逻辑妥善处理。

最终，温度上升的速度迫使我们优先抢救硬件，而非让服务恢复在线。这通常不是需要做出的抉择，因为冷却系统通常也有冗余，冷却系统完全失效的情况相当罕见，这意味着温度达到临界点之前通常还有相当多的时间。近年来，随着用于 AI 的高功耗 CPU 和 GPU 的出现，服务器功率密度大幅提升，使这一问题更加严重。因此，过去需要 3-4 小时才会达到临界温度的情况，如今 20 分钟就达到了临界点。

因此，值班团队将注意力集中在与现场数据中心运营团队沟通以恢复冷却，同时尽可能关闭更多服务器以保护设备。由于 AI 热潮导致服务器设备短缺，其中许多设备一旦损失将无法在短期内更换。保护这些设备必须成为首要任务，即使这可能以延长停机时间为代价。

到 中欧夏令时间 00:45，我们得以恢复冷却，设施温度开始下降，值班团队随即转入服务恢复工作。此时，我们决定将主要数据库进行故障转移——如果法兰克福仍有存活的副本，则转移到法兰克福；如果法兰克福没有存活的副本，则转移到苏黎世——以避免过多改变我们的流量流向，从而可能造成新的不稳定。之所以选择这一方案，是因为我们假设既然冷却已得到控制，让法兰克福恢复在线应该相对容易，且比切换到苏黎世更快。

遗憾的是，事实并非如此。事件期间，法兰克福基础设施中的许多网卡温度达到 105°C（正常工作温度为 45°C），这会触发特殊的温度保护模式，导致网卡被停用，直到进行冷系统重置后才会恢复。我们的安全策略限制了访问系统带外控制器的能力，这需要我们叫醒更多员工协助恢复工作。

到 中欧夏令时间 01:30，大多数用户的大部分服务已恢复在线。不过，推送通知或支付处理等不太关键的系统直到中欧夏令时间 02:00 左右才恢复。

正如我们在最初的事件报告中所说，没有电子邮件丢失，但事件期间电子邮件的双向投递均出现延迟。

虽然面向用户的服务已完全恢复，但对我们的工程师——尤其是数据库团队——来说，这一夜还没有结束。我们的基础设施处于极不正常的状态：一些主要数据库位于苏黎世，另一些位于法兰克福，且其中多个数据库的冗余和/或性能有所降低。我们的团队通宵工作解决了最紧迫的问题，并在八月 27 日全天继续工作，以恢复完整的冗余。

虽然我们挽救了几乎全部基础设施，但不幸的是，一些服务器因高温而损坏，且我们尚不清楚此次高温事件是否会影响幸存设备的使用寿命。

根本原因与后续措施

八月 27 日的后续调查查明，冷却系统故障的根本原因是为冷却系统供电的两台冗余空气压缩机的空气滤芯更换操作。遗憾的是，数据中心运营商在深夜进行此项操作且未提前通知，冷却故障发生时也未及时沟通，这大大缩短了我们的响应时间。我们正在与运营商密切合作，防止此类事件再次发生。

不过，我们当前数据库基础设施的一个已知局限是，此类中断可能导致恢复时间长于正常情况。导致此次事件的一系列事件极不可能发生——但它们确实发生了。

解决这一故障模式所需的数据库弹性工作已在进行中，仍计划于年底前完成。此外，包括新数据中心空间在内的额外基础设施容量目前正在部署中，预计将在未来几周内投入使用，这将进一步降低我们对单一站点的依赖。

遗憾的是，此次事件发生在这些改进完全到位之前。我们目前正在评估在哪些方面可以安全地加快剩余工作，同时对关键数据库基础设施的变更保持所需的谨慎。

我们深知用户期望 Proton 提供极高的可靠性，此次事件也更加凸显了完成这项工作并持续提高弹性标准的重要性。我们再次向所有受影响的用户致以诚挚歉意，毫无保留。