Proton法兰克福机房冷却故障复盘：比“全死”更危险的是“半死”

概述

2026年8月27日凌晨，瑞士隐私服务商Proton（ProtonMail母公司）托管于德国法兰克福的机房发生冷却系统全面失效，机房温度约20分钟内从30°C飙升至60°C，ProtonMail、ProtonVPN等服务中断数小时，恢复时间超出SLA承诺，CEO Andy Yen公开承认“我们搞砸了”。本文按时间线复盘这起事故：为什么机房“只死了一半”反而导致自动切换失灵？20分钟涨30°C背后的热物理是什么？“故障模式已知却未做缓解”暴露了怎样的风险管理漏洞？对常年跟机房空调、割接、双活集群打交道的通信运维人，这是一份难得的活教材。

一、事故经过：一条“关键冷却故障”公告

事情的开端是一条深夜公告。据数据中心行业媒体DCD报道，Proton在美中部时间8月27日午夜过后对外发布声明：

“我们已确认某数据中心发生关键冷却故障，正在将流量切换至备用站点。”

受影响的是Proton位于德国法兰克福的机房。这里要先交代一下背景：Proton是瑞士公司，最早的基础设施放在日内瓦和苏黎世，其中一部分当年还托管在阿廷豪森（Attinghausen）一处前K7军事地堡里——藏在1000米厚的花岗岩之下。2021年前后，Proton通过社区投票选定德国作为新节点，在紧邻DE-CIX（欧洲最大互联网交换中心）的位置落了地，选这里的原因很直接：要带宽，法兰克福的对等互联成本最低。之后社区投票又选了挪威，节点现已投运。

也就是说，出事的法兰克福机房不是“主力机房之一”，而是为了带宽质量特意加上的关键节点——日内瓦和苏黎世在故障期间确实还在运行，但相当一部分用户流量锚定在法兰克福。

事故的大致时间线如下（各家报道时区表述略有出入，以欧洲中部时间为轴整理）：

用时间轴看更直观：

timeline
    title Proton法兰克福机房冷却故障时间线（2026-08-27）
    26日夜间 : 冷却系统全面失效<br/>机房温度开始爬升
    约20分钟内 : 温度30°C → 60°C<br/>逼近服务器过热保护阈值
    27日凌晨 : 发布"关键冷却故障"公告<br/>宣布切换流量至备份站点
    故障持续期 : 机房"部分存活"<br/>自动切换未触发，人工抢救冷却设备
    凌晨2时CEST : 服务恢复<br/>全程中断数小时、超出SLA
    事后 : CEO公开认错<br/>承诺落地整改措施

受影响的是Proton全系列在线服务——Mail、VPN等均出现不可用。Proton官方未公布受影响账户的精确数量（该公司2024年曾宣布用户规模突破1亿），但从“全服务、数小时、跨时区”三个维度看，这是一次典型的S级事故。

二、根因分析：为什么“半死”比“全死”更可怕

这起事故最有技术含量的部分，是CEO Yen解释的这段话：

“这次切换花了比平时更长的时间，因为机房只死了一半——自动切换没有被触发，而团队一开始忙着抢救冷却系统，赶在服务器被永久损坏之前。”

这句话值得所有做高可用设计的人逐字读三遍。故障处置的核心矛盾在这里：

flowchart TD
    subgraph S1 [场景A：机房“全死”]
        A1[供电/服务完全中断] --> A2[心跳全部丢失<br/>健康检查失败]
        A2 --> A3[自动切换立即触发<br/>分钟级完成流量倒换]
    end
    subgraph S2 [场景B：机房“半死”——本次事故]
        B1[冷却失效<br/>但服务器仍在运行] --> B2[服务仍有响应<br/>存活探针全部通过]
        B2 --> B3[自动切换不触发<br/>流量继续锚定故障机房]
        B1 --> B4[温度持续爬升<br/>逼近硬件损伤阈值]
        B4 --> B5[人工介入<br/>优先救硬件而非切流量]
        B5 --> B6[恢复窗口被大幅压缩]
    end

全死是自动化的朋友，半死是自动化的敌人。 主流高可用架构的切换判据是“服务是否可达”——心跳、TCP探活、HTTP 200。机房冷却全停后，只要服务器还没热到关机，所有探针都是绿的。监控体系探测的是“死活”，而事故的真正信号是“温度”——这个维度根本不在切换判据里。等温度高到服务开始劣化，手动切换又和硬件抢救抢资源，MTTR自然爆表。

这个模式在通信网里有一堆孪生兄弟：

• 核心网NF“假死”：K8s里Pod还在、进程还在，但业务逻辑卡死，liveness探针配的是TCP检查就永远不重启；
• SCTP/链路半开：对端协议栈还在回包，但上层业务处理已经挂了，七号信令链路的LSSU/POC类故障同理；
• 双平面单平面劣化：流量按哈希走，50%用户已经完全无法受理，但整体成功率只掉一半，还没跌破网管的大阈值；
• 割接“部分成功”：3000个网元割了2999个，最后1个卡住——系统整体“基本可用”，最考验预案的恰恰是这种状态。

三、热物理：20分钟，30°C，你的全部恢复窗口

Yen事后贴出了温度曲线，并写道：

“高功率数据中心在冷却全停后温度涨得多快，真的令人恐惧。基线是30°C，峰值60°C——20分钟涨了30°C。”

这个速度可以用最粗的量级估算验证一下。冷却全停后，机房IT负载的全部电功率都变成了热，蓄在室内空气、服务器和建材里。以1MW IT负载、1000立方米机房空间做最保守的“只加热空气”估算：空气比热约1.0 kJ/(kg·K)，1000m³约合1.2吨空气，1MW持续加热下理论温升速率高达每分钟数十度——现实中大部分热量被服务器机壳、机架、墙体吸收，温升被大幅摊薄，但即便如此，每分钟1.5°C的实测曲线完全在物理量级之内。

这对运维的 directly 推论有三条：

1. 多数服务器的过热保护大约在进风45–50°C触发（厂商阈值不一），从30°C基线出发，你的处置窗口只有约10分钟量级，不是半小时；
2. ASHRAE对A1级机房允许的短时进风上限是32°C量级，60°C意味着绝大多数设备要么降频、要么已批量保护性关机——即使此刻切走流量，故障机房也要面对大面积重启的二次故障；
3. 密度越高，窗口越短。AI时代单机柜功率密度从10kW向50kW+演进，热时间常数在缩短，冷却类故障的“容错时间”正在从小时级压缩到分钟级。这不是Proton一家的处境，是所有高密度机房（包括运营商的汇聚局所、BBU池机房）共同的趋势。

行业背景也印证了这一点：Uptime Institute历年的宕机成因调查里，供电与制冷相关原因常年位居数据中心宕机前列。冷却系统平时最安静、最不被“看见”，出事时却最致命。

四、最扎心的一句：“这个故障模式我们本来就知道”

整份复盘里最值得贴在机房墙上的，是Yen承认的另一段话：

“这个故障模式我们其实早就知道，但缓解措施没有被排上优先级——因为当时判断这个场景极不可能发生。我们现在正在落地改造，确保同类事故不再发生。”

这是教科书级的FMEA（失效模式与影响分析）败局。按照经典的RPN打分法（RPN=发生度×严重度×检出度），“冷却全停”通常被打成：发生度低（有多重冗余）、严重度高、检出度低。低发生度乘上任何东西，RPN都排不进整改队列——于是“已知、致命、未处理”的风险长期裸奔，直到那一天到来。

问题出在两个认知偏差上：

• 发生度被系统性低估。冗余设计针对的是单点故障，而现实中的冷却故障常常是共因失效（同一路冷媒、同一套控制系统、同一次误操作）。叠加共因之后，“极不可能”的先验概率远比拍脑袋估计的高；
• 整改成本被高估。针对这个场景的缓解措施其实并不贵：把温度、温升速率、冷媒压力纳入切换触发条件（多信号判决）、预制“断冷预案”剧本、每年做一次断冷演练——都是人力周级别的工作。

对照通信运维的日常，同样的台词你一定不陌生：“这个异常场景评估过，概率太低，没排进版本。”然后它就在下一次重大保障前夕准时出现。割接回退预案里写了断链路、断电源的场景，但很少有人写过“网元半起半不来”的场景——而后者才是割接失败最高频的形态。

五、处置与整改：一份可以抄的作业

平心而论，Proton这次的事后处置有不少可取之处，值得运营商和ISV借鉴：

1. 快速、诚实、有细节的对外沟通。 CEO本人出面，认错不绕弯（原话相当直白），并主动披露温度曲线、故障机理、决策过程。对照业内常见的“部分用户可能出现体验波动”式公关，透明沟通在技术社区的口碑收益极高。

2. 明确整改方向。 官方表态包括：确保“部分失效”场景下自动切换能够触发（多信号健康判据）、把已知的低概率故障模式重新纳入缓解清单。这两条恰好对应本文第三、四节的分析。

3. 架构层面的反思空间。 Proton在瑞士之外扩展节点时，把带宽质量（DE-CIX互联）放在了第一位，这是产品驱动决策的合理性；但这次事故提示，多站点布局除了带宽维度，还需要回答“任一站点以何种速度、何种 completeness 降级”的问题——日内瓦、苏黎世、挪威都在运行，但用户切换体验仍有数小时延迟，说明流量调度粒度和预案颗粒度都还有提升空间。

给出一份把这次事故翻译成机房/网络运维语言的整改清单：

六、写在最后：给通信运维人的三个提醒

这起事故没有DDoS、没有黑客、没有光缆被挖断，根因朴素到近乎无聊——空调坏了。但它把三件老生常谈的事变成了活案例：

第一，监控“活着”不如监控“健康”。 从核心网到数据中心，切换判据里如果没有业务级探针和动力环境信号，你的高可用架构在“半死”面前形同虚设。

第二，恢复窗口比你以为的短。 高密度化是全行业的确定性趋势，散热类故障的容错时间正在向分钟级收敛。基站空调告警为什么值得当重要告警治理？因为物理规律对1MW机房和对2kW的BBU池一视同仁，只是比例不同。

第三，对“极不可能”保持敬畏。 每一份“已评估、概率低、不处理”的风险清单条目，都是未来某天复盘报告里的第一句引文。区别只在于：你是把它写在事故前，还是事故后。

Proton这次用数小时的服务中断和一次公开认错，替全行业交了一份学费。学费已经付了，作业就摆在上面——抄不抄，各家的机房自己说了算。

参考来源

1. Privacy-focused email service Proton goes down after cooling failure in Frankfurt data center — DCD对本次事故的主报道，含CEO Andy Yen原文引述与温度数据
2. Data Center Dynamics News — DCD新闻频道，本次事故信息的首发追踪源
3. Syria provides Internet through alternative routes after 'sabotage' of subsea cable — DCD关联报道：基础设施单点脆弱性的又一案例
4. Canada's CityWest to construct new fiber route along Highway 37 in effort to boost network resiliency — DCD关联报道：为提升网络韧性而新增物理路由

本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。

[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。