Una falla eléctrica en Google Cloud Londres afectó a Revolut y a servicios bancarios del Reino Unido

Una falla eléctrica en Google Cloud Londres afectó a Revolut y a servicios bancarios del Reino Unido
0 0 votos
Valora la Publicación

Un evento eléctrico en la zona europe-west2-b de Google Cloud, en Londres, provocó desde las 06:08 UTC del 20 de octubre (03:08 en Argentina) errores y fallas de red en la región europe-west2.

Google llegó a listar 38 productos afectados. En paralelo, Revolut reportó problemas en varios de sus servicios y hubo reportes masivos de fallas en bancos británicos como Lloyds, HSBC y Bank of Scotland.

Qué informó Google

El panel de estado de Google Cloud registró el incidente como «múltiples servicios con problemas en la región europe-west2», con inicio a las 23:08 hora del Pacífico del 19 de octubre.

La descripción inicial hablaba de errores elevados y fallas intermitentes de red. Luego Google atribuyó el problema a un evento eléctrico en una de las tres zonas de la región.

Entre los productos afectados figuran, según Google y lo reportado por The Register y The Stack:

  • Google Kubernetes Engine (GKE), Cloud Run y App Engine.
  • Compute Engine, Cloud Filestore y Google Cloud NetApp Volumes.
  • BigQuery Data Transfer Service, AlloyDB for PostgreSQL y Apigee.
  • Managed Service for Apache Kafka.

Durante varias horas no hubo un tiempo estimado de recuperación. Como alternativa, Google sugirió a los clientes afectados que, si era posible, migraran sus cargas a otra zona o región.

Pasado el mediodía de Londres, Google informó que el evento eléctrico estaba mitigado, que la infraestructura base se recuperaría parcialmente en unos 30 minutos y que el resto de los servicios lo haría después.

Bancos y servicios afectados

Revolut informó una «interrupción que afecta a varios servicios». Según Cybernews, los problemas alcanzaron el inicio de sesión, los pagos, las transferencias y las extracciones en cajeros.

La empresa aseguró que el dinero y los datos de sus clientes están a salvo. No nombró a Google como causa, aunque figura como caso de cliente de Google Cloud.

Downdetector registró además reportes de fallas en Lloyds, HSBC, Bank of Scotland, Royal Mail, Rightmove, DPD, BT y Screwfix. Ni Google ni esas empresas confirmaron hasta el momento la relación con el incidente.

Zonas, regiones y por qué una falla local puede escalar

En la nube de Google, una región es una ubicación geográfica (en este caso, Londres) y cada región tiene varias zonas: datacenters con energía, refrigeración y red independientes.

Desplegar en varias zonas protege ante la caída de una sola. Pero algunos servicios administrados y planos de control (los componentes que crean, escalan y configuran recursos) funcionan a nivel regional, por lo que una falla zonal puede afectar a cargas que estaban repartidas.

La región europe-west2 ya tuvo un antecedente. En julio de 2022, durante una ola de calor, la zona europe-west2-a perdió la refrigeración y Google apagó parte del datacenter. En su informe, la empresa reconoció que desvió por error tráfico interno para evitar las tres zonas de la región, y no solo la afectada.

El contexto regulatorio

El 10 de julio de 2026, el Tesoro británico designó a cuatro proveedores como «terceros críticos» del sistema financiero: Google Cloud EMEA, Amazon Web Services EMEA, Microsoft Ireland Operations y Oracle Corporation UK.

Desde el 13 de julio, el Banco de Inglaterra, la PRA y la FCA los supervisan en conjunto, con requisitos como pruebas de escenarios y reporte de incidentes sobre los servicios que prestan al sector financiero.

El incidente ocurrió además un año después de la caída de AWS en us-east-1 del 20 de octubre de 2025, cuando una falla en la gestión de DNS de DynamoDB generó efectos en cadena durante unas 15 horas.

Qué revisar en arquitecturas propias

Las guías de arquitectura de los principales proveedores coinciden en algunos puntos para reducir el impacto de una falla zonal o regional:

  • Probar la pérdida de una zona con simulacros planificados, no solo declararla en el diseño.
  • Identificar qué servicios son zonales, regionales o globales y qué dependencias compartidas existen.
  • Definir modos degradados para que las funciones críticas sigan disponibles aunque falle una parte.
  • Evaluar despliegues multi-región para los flujos que no pueden interrumpirse, con su costo explícito.

¿Probaron alguna vez apagar una zona?

¿Sus equipos tienen medido qué pasa si se cae una zona o una región completa? Te leemos en los comentarios.

Fuentes

Escrito por

Pablo Ariel Di Loreto

Profesor. Informático. Fanático del helado de dulce de leche. Director de Ingeniería en MODO, y Secretario del Microsoft Users Group Asociación Civil. Además, soy owner de iniciativas como ConoSurTech y Aprender IT.

Ver todas las entradas de Pablo Ariel Di Loreto →
Suscribirse
Notificarme de
guest

0 Comentarios
Viejos
Nuevos Más votados
Scroll al inicio
0
Nos encantaría conocer tu opinión: ¡comenta!x