Le 22 octobre, Google Cloud a publié sur sa page d'état un rapport d'incident préliminaire pour la région europe-west2 (Londres) : la perturbation a duré de 23:00 heure du Pacifique le 19 octobre (07:00 BST le 20 octobre) à 05:10 heure du Pacifique le 20 octobre (13:10 BST), soit 6 heures 10 minutes au total. Nos nœuds ne sont pas en Europe, mais le rapport met en lumière un point souvent négligé : ce que « plusieurs zones de disponibilité » au sein d'une même région peuvent et ne peuvent pas vous éviter.
Le déroulé : d'une coupure du réseau électrique à une zone entière privée de courant
- À 22:53 heure du Pacifique (06:53 BST), le site hébergeant la zone de disponibilité europe-west2-b a subi une coupure du réseau électrique. Comme prévu, la charge est passée sur les batteries des onduleurs (UPS) pendant que les groupes électrogènes diesel du site démarraient.
- Les deux systèmes d'automatisme PLC (automates programmables), principal et de secours, qui commandent les groupes électrogènes n'ont pas réussi à lancer le démarrage et le basculement automatiques, si bien que les groupes n'ont jamais repris la charge. À partir de 23:00, les batteries des UPS se sont épuisées, et les serveurs physiques, le réseau de commutation et le stockage local de la zone ont perdu l'alimentation.
- Une fois le réseau électrique rétabli, les ingénieurs sur place ont remis en service une alimentation secteur stable en moins d'une heure, puis ont réinitialisé et testé les automates de commande des groupes électrogènes ; Google a redémarré son infrastructure étape par étape et réadmis progressivement le trafic dans la zone b.
- La plupart des services ont été rétablis au cours des 5 premières heures 29 minutes (à 12:29 BST). Compute Engine a mis plus de temps : la création de nouvelles VM a repris à 12:46, et à 13:10 plus de 99 % des VM étaient de nouveau saines.
Pourquoi les zones a et c ont souffert sans perdre le courant
Le rapport cite deux causes. D'abord, les charges de travail de la zone b se sont reportées en masse sur les zones a et c et ont épuisé la capacité restante, provoquant des files d'attente, des basculements de bases de données plus lents et des erreurs 500 / 503 intermittentes. Ensuite, les plans de contrôle de certains services effectuaient des validations synchrones entre zones, et les composants dont dépendaient ces validations se trouvaient dans la zone b, privée de courant, si bien que les appels d'API ont expiré. Parmi les produits que le rapport cite comme touchés de manière inattendue figurent BigQuery, Looker, Compute Engine, GKE, Regional Persistent Disk et Cloud SQL. Les ressources hébergées uniquement dans la zone b étaient tout simplement inaccessibles. Le rapport final, avec les mesures préventives, n'a pas encore été publié.
Un détail encore : la toute première mise à jour de la page d'état cette nuit-là indiquait un début à 23:08 heure du Pacifique, ce qui correspondait en réalité au moment où la supervision de Google a déclenché l'alerte ; le rapport préliminaire retient 23:00. Quand vous lisez la page d'état d'un fournisseur cloud, attendez-vous à ce que les premières mises à jour soient corrigées par les rapports ultérieurs.
Les leçons pour un ou quelques VPS
- Gardez vos sauvegardes dans une autre région. Une sauvegarde située dans le même site ou la même région devient inaccessible en même temps que les données d'origine quand tout le site perd l'alimentation. Voir les stratégies de sauvegarde d'un VPS.
- Pour les services importants, prévoyez une machine dans une seconde région — une petite machine de secours à froid suffit — et gardez une TTL courte sur vos enregistrements DNS pour pouvoir basculer en cas de problème ; voir l'initiation au DNS et choisir un nœud de centre de données à faible latence.
- Cartographiez vos dépendances. Les zones a et c ont eu des problèmes parce que ce dont elles dépendaient se trouvait dans la zone b. Pour recenser ce dont dépendent vos propres services, voir le risque de dépendance, motif dominant des pannes du premier semestre 2026, et pour les deux incidents Azure de fin septembre, voir notre synthèse de leurs analyses.
Mise à jour du 7 novembre 2026 : Google Cloud a publié son rapport d'incident final le 4 novembre. Il chiffre l'impact principal à 6 heures 8 minutes et explique pourquoi les groupes électrogènes n'ont jamais démarré : le site fonctionnait sur une seule arrivée électrique pendant une maintenance, et la détection de sous-tension de l'automate se trouvait en amont du disjoncteur ouvert de l'autre arrivée, si bien qu'il voyait une source saine. Voir notre article de suivi.