En la madrugada del 27 de agosto de 2026, Proton experimentó una interrupción generalizada que afectó a los servicios de varios usuarios. La causa principal fue un fallo total del sistema de refrigeración en nuestro centro de datos de Fráncfort. Aunque todos los sistemas de Proton son redundantes y disponemos de suficiente capacidad para soportar la caída completa de un centro de datos, existe un pequeño número de situaciones en las que la conmutación por error puede tardar más y provocar interrupciones que afecten a los usuarios.

A continuación, presentamos una cronología de lo sucedido, las decisiones que tomamos durante el incidente y por qué, y cómo se resolvió.

Cronología

Poco después de las 23:00 (hora central europea) del miércoles 26 de agosto, se produjo un fallo en el sistema de refrigeración de la sala principal de nuestro centro de datos de Fráncfort. Alrededor de las 23:15, la temperatura comenzó a subir desde aproximadamente 21,8 °C (temperatura nominal) hasta 51,9 °C en menos de media hora, y algunas sondas de medición registraron una temperatura ambiente de 60 °C en la sala. A medida que subía la temperatura, los servidores y los equipos de red de las instalaciones empezaron a fallar uno tras otro.

El incidente visible para los usuarios comenzó hacia la medianoche del 27 de agosto, cuando los fallos se agravaron hasta el punto de perderse la redundancia crítica. Esto ocurrió cuando fallaron tanto el switch de red principal como el de respaldo de un rack crítico, que desafortunadamente albergaba varias copias de bases de datos principales. Aunque casi todos los sistemas de Proton son redundantes y realizan la conmutación por error de forma automática e inmediata, las conmutaciones de bases de datos principales no se realizan de forma automática sin supervisión humana.

Mantenemos este control para evitar las denominadas situaciones de «split-brain» (cerebro dividido), en las que la falta temporal de disponibilidad de una base de datos principal hace que las réplicas se pierdan algunas actualizaciones y se desincronicen de formas que luego pueden ser difíciles de conciliar. Además, cuando se produce una conmutación por error de una base de datos principal, el procedimiento operativo estándar consiste en conmutar a una réplica en el mismo centro de datos por motivos de latencia y rendimiento. Sin embargo, la naturaleza específica del problema implicaba que esto podría ser desaconsejable, ya que potencialmente podríamos estar conmutando a algo que también caería.

Las decisiones

Llegados a este punto, los ingenieros de guardia de Proton tuvieron que tomar un par de decisiones de gran trascendencia mientras trabajaban bajo una presión extrema.

  • ¿Priorizar el restablecimiento del servicio en línea o dar prioridad a solucionar el problema de refrigeración y salvar el hardware del centro de datos?
  • ¿Deberíamos conmutar a réplicas dentro del mismo edificio en Fráncfort (más rápido y menos disruptivo, pero posiblemente una solución temporal si el calor no se pudiera controlar) o conmutar a Zúrich?
  • ¿Conmutamos todo o solo lo que está caído en ese momento? Contamos con planes de contingencia para la caída completa de un centro de datos en los que todo conmuta por completo y de forma prácticamente automática con bastante rapidez, pero una situación en la que servidores aleatorios van cayendo uno a uno no es gestionada de forma óptima por nuestra lógica de conmutación por error.

En última instancia, la velocidad a la que subían las temperaturas nos obligó a priorizar salvar el hardware en lugar de restablecer los servicios en línea. Esta no es una decisión que suela ser necesario tomar, ya que los sistemas de refrigeración suelen ser redundantes y la pérdida total de refrigeración es muy poco frecuente, lo que significa que suele haber bastante tiempo antes de que las temperaturas alcancen niveles críticos. El problema se ve agravado por el gran aumento de la densidad de potencia de los servidores en los últimos años debido a CPU y GPU más potentes para IA. Como resultado, lo que antes tardaba de 3 a 4 horas en volverse crítico alcanzó un nivel crítico en 20 minutos.

Por lo tanto, el equipo de guardia centró su atención en comunicarse con el equipo de operaciones presencial del centro de datos para restaurar la refrigeración, mientras apagaba tantos servidores como fuera posible para protegerlos. Debido a la escasez de equipos de servidores ligada al auge continuo de la IA, gran parte de este equipamiento —si se perdía— no se podría reemplazar en plazos cortos. Salvarlo tenía que ser una prioridad, incluso a costa de prolongar potencialmente el tiempo de inactividad.

Hacia las 00:45 CEST, logramos restaurar la refrigeración y las temperaturas de las instalaciones comenzaron a bajar, por lo que el equipo de guardia pasó a centrarse en la recuperación del servicio. En ese momento, tomamos la decisión de conmutar las bases de datos principales a Fráncfort si alguna réplica seguía activa, y a Zúrich en los casos en que no quedaran réplicas activas en Fráncfort, para evitar alterar demasiado nuestros flujos de tráfico y provocar posiblemente una nueva inestabilidad. Se seleccionó esta opción porque asumimos que, una vez controlada la refrigeración, sería relativamente fácil volver a poner Fráncfort en línea y más rápido que cambiar a Zúrich.

Desafortunadamente, no fue así. Durante el incidente, muchas tarjetas de red de la infraestructura de Fráncfort alcanzaron una temperatura de 105 °C (la temperatura normal de funcionamiento es de 45 °C), lo que activa un modo especial de protección térmica y hace que las tarjetas de red queden desactivadas hasta que se restablezca el sistema en frío. Nuestra postura de seguridad limita la capacidad de acceder al controlador fuera de banda de nuestros sistemas, lo que nos obligó a despertar a personal adicional para que ayudara con la recuperación.

Hacia la 01:30 CEST, pudimos restablecer la mayoría de los servicios en línea para la mayoría de los usuarios. Sin embargo, algunos sistemas menos críticos, como las notificaciones push o el procesamiento de pagos, no se recuperaron hasta cerca de las 02:00 CEST.

Como informamos en el informe inicial del incidente, no se perdió ningún correo electrónico, pero la entrega de correos electrónicos en ambas direcciones sufrió retrasos durante el incidente.

Aunque los servicios de cara a los usuarios se restauraron por completo, la noche no terminó ahí para nuestros ingenieros, en particular para el equipo de bases de datos. Nuestra infraestructura quedó en un estado altamente anómalo, con algunas bases de datos principales en Zúrich y otras en Fráncfort, y varias de ellas funcionando con redundancia y/o rendimiento reducidos. Nuestro equipo trabajó durante toda la noche para resolver los problemas más urgentes, y el trabajo continuó durante todo el día 27 de agosto para restaurar la redundancia total.

Aunque pudimos salvar casi toda la infraestructura, desafortunadamente algunos servidores quedaron inutilizados por el calor y todavía no sabemos si el sobrecalentamiento afectará a la vida útil de los equipos que sobrevivieron.

Causa principal y próximos pasos

Una investigación posterior el 27 de agosto determinó que la causa principal del fallo de refrigeración fue el reemplazo de los filtros de aire en los dos compresores de aire redundantes que alimentan el sistema de refrigeración. Desafortunadamente, el operador del centro de datos realizó esta operación en mitad de la noche, sin previo aviso, y tampoco comunicó el fallo de refrigeración cuando ocurrió, lo que redujo drásticamente el tiempo del que disponíamos para responder. Estamos trabajando estrechamente con el operador para evitar que se repita este incidente.

Sin embargo, también es una limitación conocida de nuestra infraestructura de base de datos actual que una interrupción de este tipo pueda dar lugar a un proceso de recuperación más largo de lo normal. La serie de eventos que condujo a este incidente es altamente improbable y, sin embargo, ocurrió.

El trabajo de resiliencia de la base de datos necesario para abordar este modo de fallo ya está en marcha y sigue estando previsto completarlo para finales de año. Además, actualmente se está habilitando capacidad de infraestructura adicional, incluido nuevo espacio en centros de datos, y se espera que esté disponible en las próximas semanas, lo que reducirá aún más nuestra dependencia de una única ubicación.

Desafortunadamente, este incidente ocurrió antes de que esas mejoras estuvieran completamente implementadas. Ahora estamos revisando cómo podemos acelerar de forma segura el trabajo restante, manteniendo al mismo tiempo el nivel de cuidado necesario para realizar cambios en una infraestructura de base de datos crítica.

Reconocemos que nuestros usuarios esperan un nivel de fiabilidad muy alto de Proton, y este incidente refuerza la importancia de completar este trabajo y continuar elevando nuestros estándares de resiliencia. Pedimos disculpas de nuevo, sin reservas, a todos los usuarios afectados.