摘要
2026 年 8 月 26 日夜至 9 月 1 日，Proton 法兰克福数据中心的冷却系统两次故障，导致 Mail、Drive、Calendar、Pass 等核心服务大范围中断。第一次（08-26 约 23:00 CEST）因数据中心运营商在无事先通知下对两台冗余制冷压缩机的空气滤网同时更换，冷却全失效，机房温度 30 分钟内从 21.8°C 飙至 51.9°C，网卡过热自我保护宕机，主备双交换机同机架失效并拖累多个主库副本；因主库故障转移需人工监督（防 split-brain）拉长恢复。第二次（09-01 14:37–20:49 CEST）为首次过热造成的残余硬件故障，同一批服务再断。Proton 已发官方事后报告，确认无用户数据丢失。归为外部类（物理设施冷却失效），严重度 p1。
时间线
2026-08-26 23:00 CEST法兰克福 DC 冷却系统失效（运营商无通知下对两台冗余压缩机空气滤网同时更换）
2026-08-26 23:15–23:45 CEST机房温度 21.8→51.9°C（峰值约 60°C）；网卡达 105°C（正常约 45°C）自我保护宕机；主备双交换机同机架失效
2026-08-27 00:00 CEST用户面中断，Mail/Drive/Calendar/认证受影响；主库故障转移需人工监督，恢复被拉长
2026-08-27 00:45 CEST冷却恢复，温度回落；01:30 大部分服务恢复，02:00 推送/支付等次要组件恢复
2026-08-27 全天DB 团队恢复全冗余（部分主库在 Zurich、部分在 Frankfurt，期间降冗余/降性能运行）
2026-09-01 14:37–20:49 CEST残余硬件故障（首次过热损伤所致，Proton 9/1 更新自述关联）致 Mail/Pass/Drive/Calendar 再次中断
根因
直接根因：数据中心运营商在**无事先通知**的情况下，对两台冗余制冷压缩机的空气滤网同时执行更换，导致冷却能力在维护窗口内归零；且运营商未在冷却失效发生时及时通报 Proton，压缩了响应时间。物理链：冷却失效 → 高功率密度机房温度骤升（现代 CPU/GPU 与 AI 负载使临界温度从历史上 3–4 小时缩短至约 20 分钟可达）→ 网络设备与服务器过热自我保护宕机 → 承载多个主库副本的机架主备交换机同失效 → 主库无法自动故障转移（Proton 为防 split-brain 要求人工监督）→ 恢复延长至数小时并跨多日补冗余。第二次中断是首次过热对硬件造成**永久性损伤**后的残余故障，非独立新因。
放大因素
- 主备交换机共置同一机架、且机架载主库副本，使「纸面冗余」在单点物理失效时未真正生效。
- 主库故障转移须人工审批，数据安全优先于可用性，但代价是中断时长显著拉长（CEO Andy Yen 公开承认 failover 过慢「we fucked up」）。
- 现代机房功率密度攀升，冷却失效到临界温度的窗口从小时级缩至分钟级，传统「诊断—降载—迁移」流程来不及。
- 苏黎世备用站点容量与自动化当时尚未建成（目标 2026 年底），单站点依赖放大了冲击。
- 与同周 Microsoft 365 认证配置故障无关，但二者共同暴露「单点物理失效 + 冗余未真正覆盖」这一共性。
缓解措施
- 08-27 00:45 冷却恢复后逐步恢复服务，当日补齐全冗余；明确无邮件/用户数据丢失。
- 09-01 残余硬件故障于 20:49 CEST 前修复。
- Proton 表示正建设附加数据库韧性与基础设施容量，降低单站点依赖；苏黎世二站点容量与自动化目标 2026 年底完成。
经验教训
- 物理设施冗余须验证「真正独立」：主备网络/电源不得共置单机架，主库副本分布须跨故障域。
- 冷却系统等基础设施维护须走变更通知与双方确认，禁止对冗余组件同时操作（同停=无冗余）。
- 高功率密度机房须有分钟级冷却失效应急（快速降载、工作负载迁移），不能依赖小时级人工流程。
- 主库 failover 的安全/速度权衡须明确书面的 RTO 预期，并对关键路径配置带外远程复位能力。
- 「数据驻留/主权」不等于「高可用」，采购方应直接追问厂商 failover 是否自动、跨哪些站点。
检查清单
- 主备网络/电源/交换机是否跨机架、跨故障域部署，杜绝共置单点
- 主库副本是否分布在不同故障域，单机架失效不拖累多数副本
- 制冷/电力等设施维护是否走变更通知、禁止冗余组件同时操作
- 高功率密度机房是否具备分钟级冷却失效应急（快速降载+负载迁移）
- 主库 failover 的安全/速度权衡是否有书面 RTO，关键路径是否带外可远程复位
- 是否订阅 status.proton.me 并核查厂商二站点 failover 实际覆盖（非仅合规声明）