Caída de Proton: lo que reveló un fallo de refrigeración

La caída de Proton el 27 de agosto de 2026 recuerda con claridad que la redundancia puede fallar de formas que el diseño de failover no contempla con limpieza. Un fallo total de refrigeración en su centro de datos de Fráncfort hizo subir la temperatura de la sala desde unos 21.8°C hasta 51.9°C en menos de media hora (30 minutos), fue apagando equipos componente a componente y obligó a los ingenieros a elegir entre recuperar el servicio o salvar el hardware.

Proton publicó un informe de incidente detallado al día siguiente, así que por una vez no hace falta conjeturar a partir de mensajes de usuarios. El cronograma aporta temperaturas concretas, modos de fallo, decisiones sobre bases de datos y datos de causa raíz, lo que enseña mucho más que una lección genérica sobre "tener redundancia".

¿Qué causó realmente la caída de Proton?

Proton indica que la causa raíz fue un fallo total del sistema de refrigeración en su centro de datos de Fráncfort. La investigación posterior atribuyó ese fallo a un cambio de filtros de aire realizado en ambos compresores de aire redundantes que alimentaban el sistema de refrigeración.

Según el informe del incidente, el operador del centro de datos ejecutó el mantenimiento durante la noche sin avisar previamente a Proton. Proton también señala que el operador no comunicó el fallo de refrigeración cuando ocurrió, lo que restó tiempo de respuesta al equipo de guardia.

La primera lección es que dos componentes redundantes pueden compartir un proceso de mantenimiento, un operador, un procedimiento o una decisión humana. Si se tocan ambos al mismo tiempo, el diseño puede ser redundante en lo eléctrico, pero no en la operación.

En nuestra sección de Centros de Datos y AIOps, este es el tipo de dependencia que importa más que un diagrama con dos cajas rotuladas A y B.

¿A qué velocidad se volvió peligrosa la sala?

La sala principal pasó de aproximadamente 21.8°C a 51.9°C en menos de media hora, y algunas sondas registraron temperaturas del aire de 60°C. Proton afirma que los servidores y los equipos de red empezaron a fallar uno a uno a medida que subía la temperatura.

La velocidad sorprendió incluso a una organización que había planificado la pérdida de un centro de datos. Proton afirma que la mayor densidad de potencia de los servidores ha cambiado los plazos térmicos: lo que antes podía tardar tres o cuatro horas en volverse crítico, en este incidente alcanzó un punto crítico en unos 20 minutos.

Eso supone un cambio operativo importante. Las CPU y GPU de alta densidad aportan más calor al mismo volumen de sala y rack, de modo que cuando desaparece la refrigeración activa, el margen térmico puede ser mucho más corto de lo que suponen los procedimientos antiguos. Un plan de failover que espera una hora de estabilidad del hardware tras perder la refrigeración puede estar estructuralmente equivocado si la ventana real se mide en minutos.

¿Por qué la redundancia no evitó la caída?

Proton contaba con sistemas redundantes y capacidad suficiente para sobrevivir a la caída completa de un centro de datos, pero el fallo real fue parcial, progresivo y caótico. Los componentes morían de forma dispersa según se calentaba la sala, lo que no encajaba con el estado binario de "sitio disponible o no disponible" que mejor gestiona la lógica automatizada de failover.

El impacto para los usuarios se agravó cuando fallaron tanto el switch de red primario como el secundario de un rack crítico. Ese rack contenía varias copias primarias de bases de datos.

La mayoría de los sistemas de Proton pueden conmutar por error automáticamente, pero las conmutaciones de bases de datos primarias requieren supervisión humana. Proton explica que esto busca reducir el riesgo de situaciones de split-brain, donde las copias divergen tras problemas de conectividad y se vuelven difíciles de conciliar con seguridad.

Esa decisión de diseño resulta razonable, y también implica que la velocidad de recuperación depende de que los ingenieros dispongan de tiempo suficiente y de información fiable para elegir la réplica correcta.

¿Por qué fue difícil la decisión entre Fráncfort y Zúrich?

El equipo tuvo que decidir si conmutaba las bases de datos a réplicas supervivientes en Fráncfort o a réplicas en Zúrich. Fráncfort ofrecería normalmente menor latencia y menos alteraciones, pero una réplica dentro del mismo edificio recalentado podía fallar instantes después.

A las 00:45 CEST se había restablecido la refrigeración y las temperaturas estaban bajando. Proton decidió utilizar réplicas de Fráncfort donde aún seguían activas y de Zúrich donde no quedaba ninguna réplica en Fráncfort, en parte para evitar cambios mayores en los flujos de tráfico durante un incidente ya inestable.

Eso no recuperó todo de inmediato. Muchas tarjetas de red habían alcanzado los 105°C, frente a una temperatura normal de funcionamiento declarada de 45°C. Las tarjetas entraron en modo de protección térmica y requirieron un reinicio en frío del sistema.

Las restricciones de seguridad de Proton sobre la gestión fuera de banda también exigieron la intervención de más personal en la recuperación. Es otro compromiso que conviene anotar: un acceso administrativo más estricto reduce el riesgo de seguridad, pero ralentiza la recuperación de emergencia si la vía de acceso no está diseñada para un incidente del centro.

¿Perdió datos Proton?

Proton afirma que no se perdió ningún correo. La entrega de correo en ambas direcciones se retrasó, y algunos sistemas no críticos como las notificaciones push y el procesamiento de pagos tardaron más en recuperarse.

La mayoría de los servicios volvieron a estar disponibles para la mayoría de los usuarios hacia las 01:30 CEST, y algunos sistemas restantes se recuperaron sobre las 02:00 CEST. El trabajo continuó después de la caída visible, porque las bases de datos primarias estaban divididas entre Zúrich y Fráncfort y algunos sistemas operaban con menor redundancia o rendimiento.

Los informes de incidentes deben separar claramente esos dos estados. Una plataforma puede volver a atender a los usuarios mientras su infraestructura sigue en un estado anómalo y el equipo de ingeniería está a un solo fallo de otro incidente.

Las copias de seguridad funcionan del mismo modo. Una tarea de copia completada con éxito demuestra que los datos se escribieron, y solo una vía de recuperación probada demuestra que puedes recuperarlos. Nuestra guía de Proxmox Backup Server se centra en esa separación porque el estado de recuperación es lo que importa bajo presión.

¿Qué enseña esta caída sobre la redundancia de refrigeración?

La redundancia de refrigeración debe cubrir tanto el procedimiento de mantenimiento y operación como los equipos duplicados. Si dos compresores son redundantes pero ambos reciben la misma intervención de mantenimiento al mismo tiempo, el proceso de mantenimiento crea un dominio de fallo compartido.

Una revisión útil debería plantear quién puede dejar fuera de servicio ambas vías de refrigeración, qué alarmas llegan directamente al cliente, si la telemetría térmica se puede ver de forma independiente del operador de las instalaciones y qué acciones automáticas sobre las cargas de trabajo se activan cuando la temperatura supera umbrales definidos.

También conviene conocer el tiempo de supervivencia térmica con la densidad de hardware actual. No heredes una cifra de un diseño de centro de datos antiguo; mide o modela lo que ocurre con la potencia por rack de hoy.

Por último, define qué significa para la automatización una "caída completa del sitio". El centro de Proton fallaba de forma gradual, y la degradación progresiva puede ser más difícil que un corte limpio de energía porque cada decisión debe tener en cuenta componentes que funcionan ahora pero podrían dejar de hacerlo.

¿Qué probaría tras leer el postmortem de Proton?

Probaría un escenario de pérdida de refrigeración que asuma solo 20 minutos antes de que el equipo deje de ser fiable. Eso obliga al equipo a decidir qué se apaga, qué conmuta primero, qué bases de datos exigen aprobación humana y si el sitio remoto tiene realmente capacidad suficiente.

También revisaría las dependencias compartidas de mantenimiento. Pregunta si una sola empresa o una única orden de trabajo puede intervenir simultáneamente vías redundantes de alimentación, refrigeración, red o almacenamiento. Si es posible, la afirmación de redundancia necesita una salvedad operativa.

Luego probaría el acceso fuera de banda durante el mismo ejercicio. Los controles de seguridad deben mantenerse firmes, pero el acceso de emergencia no puede depender de despertar a una persona concreta que casualmente conoce el camino.

Confiar únicamente en el failover automático de todo el sitio solo es aceptable cuando la aplicación puede tratar de verdad un centro como un único dominio de fallo binario. El incidente de Proton muestra por qué la infraestructura de alta densidad suele fallar de una forma mucho menos conveniente.