Une coupure de courant est devenue un compte à rebours de sept minutes
Vers 07h08 BST un mardi, une défaillance du réseau local a frappé la zone Google Cloud europe-west2-b à Londres. Les batteries UPS se sont immédiatement activées, une réponse exemplaire. Cependant, ni le contrôleur du générateur principal ni celui de secours n'ont démarré les générateurs diesel, laissant l'installation dépendante de l'alimentation par batterie.
Cette fenêtre de sept minutes s'est avérée critique. Le centre de données a fonctionné sur batteries pendant environ sept minutes avant que l'énergie ne s'épuise, plongeant toute la zone dans l'obscurité. Fait crucial, les batteries n'ont pas échoué ; ce sont les systèmes de démarrage des générateurs qui ont failli, créant une cascade de pannes inattendues.
Revolut, géant de la fintech au service de millions de personnes, a immédiatement ressenti l'impact. Les utilisateurs ont signalé des problèmes généralisés :
- Échecs de connexion
- Transferts d'argent bloqués
- Paiements par carte refusés
Revolut a d'abord évoqué une "perturbation de service" avant d'attribuer l'importante indisponibilité à Google Cloud. L'incident a rapidement souligné la fragilité de dépendre d'une infrastructure cloud, même la plus sophistiquée, lorsqu'un point de défaillance unique — comme un contrôleur de générateur — peut déclencher une telle perturbation.
Les deux zones saines n'étaient pas assez saines
Les régions multi-zones promettent de la résilience : si une zone tombe en panne, les charges de travail basculent vers les autres. La région europe-west2 de Google Cloud à Londres possède trois zones de ce type (a, b et c). Lorsque la zone b s'est éteinte, le système aurait dû basculer de manière transparente vers a et c, maintenant ainsi le service.
Au lieu de cela, la soudaine augmentation du trafic a surchargé l'infrastructure restante. Ce n'était pas un simple basculement ; c'était un problème de capacité et un cauchemar de coordination. Les dépendances inter-zones signifiaient que certains services dans les zones a et c restaient bloqués, attendant des composants ou des états toujours associés à la zone b hors ligne.
La leçon d'ingénierie est claire : la redondance n'est efficace que si les zones sont réellement indépendantes et possèdent suffisamment de marge pour absorber une tempête de basculement réaliste. Les limites de débit, la dégradation gracieuse et des plans de récupération rigoureusement testés sont essentiels pour empêcher un "effet troupeau" de faire tomber toute une région.
Google s'est rétabli avant Revolut
La récupération rapide de l'infrastructure de Google ne s'est pas traduite par un rétablissement immédiat du service pour ses clients. Google a rapporté que la plupart des clients étaient de nouveau en ligne environ six à huit heures après le début de l'incident, entre 13h00 et 15h00 BST. Revolut, cependant, n'a annoncé le rétablissement complet du service qu'à 18h40 BST, soit un retard significatif de plusieurs heures.
Cette disparité révèle une distinction critique : restaurer la capacité cloud ne résout pas instantanément l'arriéré opérationnel d'un client. Même avec des ressources de calcul et de stockage disponibles, une institution financière comme Revolut fait face à des défis complexes. Réconcilier les états des transactions, traiter les arriérés de paiement et normaliser chaque dépendance applicative — des paiements par carte aux services de connexion — prend du temps et nécessite un séquençage minutieux.
La panne a dépassé le cadre de Revolut. Des rapports ont indiqué des perturbations plus larges dans d'autres institutions et services britanniques, notamment :
- Lloyds
- Halifax
- Liens vidéo pour les audiences judiciaires à distance
Cet impact plus large souligne une vulnérabilité fondamentale de l'infrastructure cloud partagée. Une panne de zone unique dans europe-west2-b a entraîné un problème de service généralisé, démontrant comment des dépendances interconnectées peuvent transformer un événement électrique localisé en un casse-tête national. Pour plus de détails sur l'état de l'incident, consultez le Google Cloud Service Health Dashboard. Fait intéressant, les régulateurs ont pris note, la Bank of England et la FCA ayant reçu des demandes concernant le calendrier de notification de l'incident.
Cet article vous plaît ? Recevez-en un comme celui-ci chaque matin.
un e-mail par jour · désinscription en deux clics · aucun traqueur tiers
Une panne cloud est désormais un risque bancaire
La désignation de Google Cloud en tant que critical third party pour le système financier britannique en juillet change fondamentalement la donne. Après la panne, le président du Treasury Committee a immédiatement demandé des réponses à la Bank of England et à la FCA concernant les délais de notification. Il ne s'agit pas seulement d'un problème technique ; c'est un risque systémique.
Les entreprises financières sont désormais confrontées à une question cruciale : quel niveau de résilience est suffisant ? Lorsqu'un fournisseur cloud, une région entière ou même l'architecture d'une application devient un point de concentration, les entreprises doivent examiner leur exposition. Les conceptions multi-régions offrent une voie vers une réduction des risques, mais introduisent des compromis importants en termes de coûts, de latence et de gestion complexe des données.
Pour les clients et les développeurs, des leçons pratiques émergent. Pendant les incidents, consultez systématiquement le service health dashboard de Google Cloud ; il offre les informations les plus récentes. Les équipes d'ingénierie doivent aller au-delà des suppositions ; testez la perte de zone, validez la capacité de basculement et simulez des modes de fonctionnement dégradés. Le déploiement multi-zones ne garantit pas à lui seul la continuité.
Questions fréquemment posées
Pourquoi Revolut a-t-il été hors ligne pendant la panne de Google Cloud ?
Un centre de données londonien a perdu l'alimentation après la défaillance des contrôleurs des générateurs principaux et de secours. Le trafic a été transféré vers les zones restantes, qui ont également été affectées par une surcharge et des dépendances vis-à-vis de la zone hors ligne.
Combien de temps a duré la panne de Google Cloud à Londres ?
Google a déclaré que la plupart des clients touchés avaient retrouvé un service normal environ six à huit heures après le début de l'incident. Revolut a indiqué que ses services étaient de retour plus tard, vers 18h40 BST.
Pourquoi les autres zones londoniennes de Google Cloud n'ont-elles pas empêché la perturbation ?
Les zones restantes ont fait face à une augmentation soudaine du trafic de basculement, tandis que certains services dépendaient encore de composants liés à la zone défaillante.
Que signifie cette panne pour les services financiers britanniques ?
Elle souligne comment une perturbation chez un fournisseur cloud majeur peut affecter les services financiers et pourquoi les régulateurs examinent de près les fournisseurs tiers critiques.