En la madrugada del 27 de agosto de 2026, Proton experimentó una interrupción generalizada del servicio que afectó a varios usuarios. La causa principal fue una falla total del sistema de refrigeración en nuestro centro de datos de Fráncfort. Si bien todos los sistemas en Proton son redundantes y contamos con suficiente capacidad para soportar la falla completa de un centro de datos, existen pocos escenarios en los que la conmutación por error puede tardar más y ocasionar interrupciones a los usuarios.

A continuación, presentamos un cronograma de lo ocurrido, las decisiones que tomamos durante el incidente y por qué, así como la manera en que se resolvió.

Cronología

Poco después de las 23:00 (hora central europea) del miércoles 26 de agosto, ocurrió una falla en el sistema de refrigeración en la sala principal de nuestro centro de datos de Fráncfort. Hacia 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 llegaron a registrar una temperatura ambiente de 60 °C en la sala. A medida que las temperaturas aumentaban, los servidores y los equipos de red de las instalaciones comenzaron a apagarse uno a uno.

El incidente que afectó a los usuarios comenzó alrededor de la medianoche del 27 de agosto, cuando las fallas escalaron hasta el punto de perderse la redundancia crítica. Esto ocurrió cuando fallaron tanto el switch de red principal como el de copia de seguridad en un rack crítico, y desafortunadamente este rack contenía varias copias de bases de datos principales. Si bien 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 automáticamente sin supervisión humana.

Mantenemos este control con el fin de evitar las llamadas situaciones de “cerebro dividido” (split brain), donde la indisponibilidad temporal de una base de datos principal provoca que las réplicas pierdan algunas actualizaciones y se desincronicen de formas que pueden ser difíciles de conciliar después. Además, cuando ocurre 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 se caería.

Las decisiones

En ese momento, los ingenieros de guardia de Proton tuvieron que tomar un par de decisiones cruciales bajo una presión extrema.

  • ¿Priorizan volver a poner el servicio en línea o priorizan solucionar el problema de refrigeración y salvar el hardware dentro del centro de datos?
  • ¿Deberíamos realizar la conmutación por error a las réplicas dentro del mismo edificio en Fráncfort (más rápido y menos disruptivo, pero posiblemente una solución temporal si no se lograba controlar el calor) o conmutar a Zúrich?
  • ¿Conmutamos todo o solo lo que está caído en ese momento? Contamos con planes de contingencia para la falla total de un centro de datos, donde los sistemas conmutan por completo y de forma casi automática con bastante rapidez, pero una situación en la que servidores aleatorios van fallando uno tras otro 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 frente a 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 en la densidad de potencia de los servidores en los últimos años debido a CPU y GPU de mayor potencia para IA. Como resultado, lo que antes tardaba de 3 a 4 horas en volverse crítico, alcanzó un punto crítico en 20 minutos.

Por lo tanto, el equipo de guardia centró su atención en comunicarse con el equipo de operaciones en el centro de datos para restaurar la refrigeración, mientras apagaba la mayor cantidad posible de servidores para protegerlos. Debido a la escasez de equipos de servidores vinculada al auge actual de la IA, gran parte de este equipamiento —de perderse— no habría podido reemplazarse a corto plazo. Salvarlo tenía que ser una prioridad, aun a costa de prolongar potencialmente el tiempo de inactividad.

Hacia las 00:45 CEST, logramos restaurar la refrigeración y las temperaturas en las instalaciones comenzaron a descender, por lo que el equipo de guardia pasó a enfocarse 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 hubiera ninguna réplica activa en Fráncfort, para evitar alterar demasiado nuestros flujos de tráfico y la posible generación de nueva inestabilidad. Se seleccionó esta opción porque supusimos que, al tener la refrigeración bajo control, sería relativamente fácil volver a poner a Fráncfort en línea y más rápido que transferir todo a Zúrich.

Desafortunadamente, este no fue el caso. 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 realice un reinicio en frío del sistema. 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 ayudar con la recuperación.

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

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

Aunque los servicios para los usuarios quedaron totalmente restaurados, la noche no terminó ahí para nuestros ingenieros, en particular para el equipo de bases de datos. Nuestra infraestructura quedó en un estado sumamente anormal, con algunas bases de datos principales en Zúrich y otras en Fráncfort, y varias de ellas funcionando con redundancia reducida o menor rendimiento. Nuestro equipo trabajó durante toda la noche para resolver los problemas más urgentes, y las labores continuaron a lo largo del día 27 de agosto para restaurar la redundancia total.

Si bien pudimos salvar casi toda la infraestructura, desafortunadamente algunos servidores sufrieron daños irreparables por calor, y aún no sabemos si el sobrecalentamiento afectará la vida útil del equipo que sobrevivió.

Causa principal y próximos pasos

Una investigación posterior realizada el 27 de agosto determinó que la causa principal de la falla de refrigeración fue el reemplazo de los filtros de aire en ambos compresores de aire redundantes que alimentan el sistema de refrigeración. Desafortunadamente, el operador del centro de datos realizó esta operación en plena noche, sin previo aviso, y tampoco comunicó la falla de refrigeración cuando ocurrió, lo que redujo drásticamente el tiempo que tení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 actual de bases de datos que una interrupción de este tipo pueda derivar en un proceso de recuperación más largo de lo normal. La serie de eventos que provocó este incidente es altamente improbable, pero aun así ocurrió.

El trabajo de resiliencia en las bases de datos necesario para abordar este modo de falla ya está en marcha y sigue previsto para completarse a finales de año. Además, actualmente se está habilitando capacidad adicional de infraestructura, incluido nuevo espacio en centros de datos, que se espera esté disponible en las próximas semanas, lo que reducirá aún más nuestra dependencia de un solo sitio.

Desafortunadamente, este incidente ocurrió antes de que esas mejoras estuvieran implementadas por completo. Ahora estamos evaluando dónde podemos acelerar de forma segura el trabajo restante, manteniendo al mismo tiempo el nivel de cuidado necesario para realizar cambios en una infraestructura crítica de bases de datos.

Reconocemos que nuestros usuarios esperan un nivel muy alto de confiabilidad por parte de Proton, y este incidente refuerza la importancia de completar este trabajo y seguir elevando nuestros estándares de resiliencia. Pedimos disculpas de nuevo, sin reservas, a cada usuario que se haya visto afectado.