Aux premières heures du 27 août 2026, Proton a subi une panne généralisée qui a affecté les services pour un certain nombre d’utilisateurs. La cause première était une défaillance totale du système de refroidissement dans notre centre de données de Francfort. Bien que tous les systèmes de Proton soient redondants et que nous disposions d’une capacité suffisante pour supporter une panne complète d’un centre de données, il existe un petit nombre de scénarios dans lesquels le basculement peut prendre plus de temps et entraîner des perturbations visibles pour les utilisateurs.

Voici la chronologie des événements, les choix que nous avons faits pendant l’incident et pourquoi, ainsi que la manière dont il a été résolu.

Chronologie

Peu après 23 h (heure d’Europe centrale) le mercredi 26 août, une panne du système de refroidissement est survenue dans la salle principale de notre centre de données de Francfort. Vers 23 h 15, la température a commencé à grimper, passant d’environ 21,8 °C (température nominale) à 51,9 °C en moins d’une demi-heure, certaines sondes de mesure signalant une température de l’air de 60 °C dans la salle. À mesure que les températures augmentaient, les serveurs et les équipements réseau du site ont commencé à s’arrêter un par un.

L’incident visible pour les utilisateurs a commencé vers minuit le 27 août, lorsque les pannes se sont aggravées au point d’entraîner la perte d’une redondance critique. Cela s’est produit lorsque le commutateur réseau principal et le commutateur de secours d’une baie critique sont tombés en panne, et cette baie contenait malheureusement plusieurs copies de bases de données principales. Bien que la quasi-totalité des systèmes Proton soient redondants et basculent automatiquement et immédiatement, les basculements de bases de données principales ne sont pas effectués automatiquement sans supervision humaine.

Nous conservons ce contrôle afin d’éviter les situations dites de « split-brain », dans lesquelles l’indisponibilité temporaire d’une base de données principale fait que les répliques manquent certaines mises à jour et se désynchronisent de manière difficile à réconcilier ultérieurement. De plus, lorsqu’un basculement de base de données principale se produit, la procédure opérationnelle standard consiste à basculer vers une réplique située dans le même centre de données pour des raisons de latence et de performances. Cependant, la nature spécifique du problème rendait cette option risquée, car nous risquions de basculer vers un équipement qui allait lui aussi tomber en panne.

Les décisions

À ce stade, les ingénieurs d’astreinte de Proton ont dû prendre plusieurs décisions lourdes de conséquences, tout en intervenant sous une pression extrême.

  • Devaient-ils donner la priorité à la remise en ligne du service ou au traitement du problème de refroidissement pour préserver le matériel à l’intérieur du centre de données ?
  • Devions-nous basculer vers des répliques dans le même bâtiment à Francfort (plus rapide et moins perturbateur, mais potentiellement temporaire si la chaleur ne pouvait pas être maîtrisée) ou basculer vers Zurich ?
  • Devions-nous tout basculer ou uniquement ce qui était en panne à ce moment-là ? Nous disposons de plans d’urgence en cas de panne totale d’un centre de données, où le basculement se fait de manière complète et en grande partie automatique assez rapidement, mais une situation où des serveurs tombent en panne les uns après les autres de manière aléatoire n’est pas bien gérée par notre logique de basculement.

En fin de compte, la vitesse à laquelle les températures augmentaient nous a contraints à privilégier la préservation du matériel plutôt que la remise en ligne des services. C’est un choix qui n’a généralement pas lieu d’être fait, car les systèmes de refroidissement sont habituellement redondants et une perte totale de refroidissement est très rare, ce qui laisse généralement un certain délai avant que les températures ne deviennent critiques. Le problème est accentué par la forte augmentation de la densité de puissance des serveurs ces dernières années, avec des processeurs et cartes graphiques plus puissants pour l’IA. Par conséquent, ce qui prenait autrefois 3 à 4 heures pour atteindre un seuil critique l’est devenu en 20 minutes.

L’équipe d’astreinte a donc concentré ses efforts sur la communication avec l’équipe d’exploitation sur place du centre de données pour rétablir le refroidissement, tout en éteignant autant de serveurs que possible pour les protéger. En raison d’une pénurie d’équipements de serveurs liée à l’essor actuel de l’IA, une grande partie de ce matériel — s’il était perdu — n’aurait pas pu être remplacée dans des délais courts. Le préserver devait être une priorité, même au prix d’un éventuel allongement de la durée d’indisponibilité.

Dès 00 h 45 CEST, nous avons pu rétablir le refroidissement et les températures dans l’installation ont commencé à baisser, permettant à l’équipe d’astreinte de se concentrer sur le rétablissement des services. À ce moment-là, nous avons pris la décision de basculer les bases de données principales vers Francfort si une réplique était toujours active, et vers Zurich s’il n’y avait plus de réplique active à Francfort, afin d’éviter de trop modifier nos flux de trafic et de risquer de créer une nouvelle instabilité. Cette option a été sélectionnée parce que nous pensions que, le refroidissement étant désormais maîtrisé, il serait relativement facile de remettre Francfort en ligne et plus rapide que de tout basculer vers Zurich.

Malheureusement, cela ne s’est pas passé comme prévu. Pendant l’incident, de nombreuses cartes réseau de l’infrastructure de Francfort ont atteint une température de 105 °C (la température normale de fonctionnement étant de 45 °C), ce qui déclenche un mode de protection thermique spécial et entraîne la désactivation des cartes réseau jusqu’à une réinitialisation matérielle à froid du système. Notre politique de sécurité limitant l’accès au contrôleur hors bande de nos systèmes, nous avons dû mobiliser du personnel supplémentaire pour participer à la récupération.

Dès 01 h 30 CEST, nous avons pu remettre en ligne la plupart des services pour la majorité des utilisateurs. Toutefois, certains systèmes moins critiques, tels que les notifications push ou le traitement des paiements, n’ont été rétablis que vers 02 h 00 CEST.

Comme nous l’avions indiqué dans le rapport d’incident initial, aucun message n’a été perdu, mais la distribution des e-mails dans les deux sens a été retardée pendant l’incident.

Bien que les services destinés aux utilisateurs aient été entièrement restaurés, la nuit n’était pas terminée pour nos ingénieurs, en particulier l’équipe en charge des bases de données. Notre infrastructure se trouvait dans un état particulièrement anormal, avec certaines bases de données principales à Zurich et d’autres à Francfort, plusieurs d’entre elles fonctionnant avec une redondance réduite et/ou des performances dégradées. Notre équipe a travaillé toute la nuit pour résoudre les problèmes les plus urgents, et les efforts se sont poursuivis tout au long de la journée du 27 août pour restaurer une redondance complète.

Bien que nous ayons pu sauver la quasi-totalité de l’infrastructure, certains serveurs ont malheureusement succombé à la surchauffe, et nous ne savons pas encore si cet épisode de surchauffe aura un impact sur la durée de vie du matériel survivant.

Cause première et prochaines étapes

Une enquête ultérieure menée le 27 août a permis d’attribuer la cause première de la panne de refroidissement au remplacement d’un filtre à air sur les deux compresseurs d’air redondants alimentant le système de refroidissement. Malheureusement, l’opérateur du centre de données a effectué cette opération en pleine nuit, sans préavis, et n’a pas non plus communiqué la défaillance du refroidissement lorsqu’elle s’est produite, ce qui a considérablement réduit notre temps de réaction. Nous travaillons en étroite collaboration avec l’opérateur pour éviter que cet incident ne se reproduise.

Cependant, c’est aussi une limite connue de notre infrastructure de bases de données actuelle qu’une panne de ce type puisse entraîner un processus de récupération plus long que d’habitude. L’enchaînement d’événements qui a conduit à cet incident était hautement improbable, mais il s’est pourtant produit.

Les travaux sur la résilience des bases de données nécessaires pour faire face à ce mode de défaillance sont déjà en cours et leur finalisation reste prévue d’ici la fin de l’année. Des capacités d’infrastructure supplémentaires, notamment un nouvel espace de centre de données, sont également en cours de mise en service et devraient être disponibles dans les prochaines semaines, ce qui réduira encore davantage notre dépendance à un site unique.

Malheureusement, cet incident s’est produit avant que ces améliorations ne soient pleinement en place. Nous examinons actuellement les moyens d’accélérer en toute sécurité les travaux restants, tout en maintenant le niveau de rigueur exigé pour les modifications apportées à l’infrastructure critique de bases de données.

Nous savons que nos utilisateurs attendent de Proton un niveau de fiabilité très élevé, et cet incident renforce l’importance de mener à bien ces travaux et de continuer à élever nos exigences en matière de résilience. Nous présentons à nouveau nos excuses les plus sincères à chaque utilisateur touché.