Consultation

Ce que cette panne nous apprend · 29 octobre 2026 · 3 min

Ce que cette panne nous apprend — Octobre 2026 : une zone de Google Cloud à Londres, environ huit heures

Une panne d'alimentation dans une zone de Google Cloud a paralysé des services pendant des heures. Ce que l'on sait, ce que l'on ignore encore, et quoi vérifier lundi.

Quand
Impact dès 6 h 08 UTC le 20 octobre 2026 ; « atténué pour la plupart des clients » à 14 h 03 UTC
Où
europe-west2-b, l'une des trois zones de la région de Londres
Cause selon Google
« A power event caused an outage within europe-west2-b zone. »
Services cités
BigQuery Data Transfer Service, Cloud Filestore, Cloud Run, App Engine, NetApp Volumes, GKE, Managed Kafka (d'après The Register)
Pas encore public
L'analyse d'incident de Google, promise à la fin de son enquête interne

Ce que l'on sait

Aux premières heures du 20 octobre, un incident d'alimentation électrique a mis hors service une zone de la région londonienne de Google Cloud. L'impact pour les clients a commencé vers 6 h 08 UTC. À 11 h 58 UTC, Google prévoyait, sous réserve, une reprise complète pour 13 h 00 UTC ; à 14 h 03 UTC, il décrivait le problème comme atténué pour la plupart des clients, un très petit nombre restant touchés. Environ huit heures entre le premier impact et « surtout réglé ».

Plusieurs organisations britanniques connues ont été signalées comme touchées, dont Lloyds Bank, HSBC, Royal Mail, Rightmove, DPD, BT, Screwfix et Revolut. Ces signalements viennent de la presse et de sites de suivi des pannes. Dans les sources que nous avons lues, aucune de ces entreprises ne l'avait confirmé, et nous ne savons pas lesquelles dépendaient de la zone touchée.

Ce que l'on ignore encore

  • La cause au-delà de « incident d'alimentation » : Google a promis une analyse une fois son enquête interne terminée.
  • Pourquoi la perte d'une zone a été visible de tant de monde. Google ne parle que d'une zone ; un universitaire cité par The Register parle d'une panne « régionale, centrée sur europe-west2 ».
  • Si les clients touchés avaient une conception multi-zones qui n'a pas basculé, ou une conception à zone unique.

Ce que cela enseigne

Une zone est censée être l'unité que l'on peut perdre. La question utile n'est pas de savoir si Google a failli, mais lesquels de vos services s'en seraient aperçus.

  • La perte d'une zone est la défaillance que l'architecture infonuagique promet d'absorber, et la plus souvent non testée. Un service est multi-zones quand il a réellement basculé, pas quand le schéma le dit.
  • Les services gérés cachent leur zone. Le stockage, les files et les bases que vous n'avez pas placés vous-même sont peut-être à zone unique par défaut. Vérifiez, ne supposez pas.
  • Huit heures, c'est long face à une tolérance d'impact. Si vous avez écrit deux heures pour un service de paiement, une panne de zone comme celle-ci la dépasse, sauf si la bascule fonctionne.

À vérifier lundi matin

  1. Listez les services qui tournent dans une seule zone, y compris les services gérés que vous n'avez pas placés vous-même.
  2. Choisissez-en un et faites-le basculer, chronomètre en main. Si vous ne pouvez pas, écrivez pourquoi.
  3. Vérifiez que vos outils de surveillance, votre page d'état et vos alertes ne dépendent pas de la zone ou du fournisseur qu'ils surveillent.
  4. Comparez huit heures à la tolérance d'impact que vous avez écrite pour votre service le plus important.

Sources

Pour aller plus loin