La caída de Google Cloud en Londres duró casi ocho horas y afectó servicios de la región

Google Cloud cerró el 20 de octubre una incidencia de 7 horas y 52 minutos en la región de Londres, europe-west2. El problema comenzó a las 06:08 UTC en la zona de disponibilidad europe-west2-b, donde un evento de alimentación dejó varios servicios indisponibles; otras cargas de la región registraron errores elevados e interrupciones de red. El incidente terminó formalmente a las 14:00 UTC, aunque los clientes pudieron empezar a recuperar servicios antes.

El panel de Google enumera decenas de productos afectados, desde Compute Engine y Cloud Storage hasta GKE, Cloud SQL, BigQuery, Pub/Sub y Cloud Run. Associated Press informó de interrupciones en Lloyds, Halifax, HSBC y Revolut, además de aplicaciones que dependen de infraestructura alojada en Londres. Google todavía no había publicado el análisis posterior del incidente: la causa inmediata está identificada como un evento eléctrico, pero el mecanismo detallado y las dependencias que extendieron el impacto no estaban explicados en el aviso público.

-InfraCrew dice: Una zona puede ser una frontera de fallo en el mapa y una dependencia compartida en el diagrama que nadie actualizó.-

Un fallo zonal con síntomas regionales

Google señaló que los servicios estaban indisponibles en europe-west2-b y que otras partes de europe-west2 podían sufrir errores e inestabilidad de red. La distinción importa: no significa que cada producto fallara en las tres zonas de Londres, ni que todas las aplicaciones alojadas allí quedaran fuera de servicio. Sí muestra que una avería localizada puede degradar servicios regionales cuando el plano de control, redes, réplicas o dependencias no se comportan como una copia aislada de la carga principal.

El proveedor recomendó, si era viable, mover las cargas afectadas a otra zona o región. Esa salida no es automática para todos los componentes. Una máquina virtual puede admitir recuperación en otra zona con una arquitectura preparada; una base de datos gestionada, una IP, un volumen persistente o una integración con servicios regionales tienen requisitos y límites propios. Migrar en plena incidencia también puede aumentar presión sobre capacidad, cuotas, enlaces y procedimientos de cambio.

AP registró el impacto visible en aplicaciones bancarias durante la mañana británica y señaló que Google esperaba publicar un análisis tras su investigación interna. El cierre del aviso a las 07:00 PDT no permite concluir que todas las cargas recuperaran al mismo tiempo: el propio historial distinguía la mitigación para la mayoría de clientes de la recuperación completa de cargas existentes. La restauración de una aplicación y la recuperación de la plataforma son hitos distintos, y conviene medir ambos.

-InfraCrew dice: «La región está verde» sirve de poco si tu balanceador, DNS o almacenamiento decidieron vivir en la misma zona que el problema.-

Qué revisar después de la caída

Para los equipos que usan europe-west2, la revisión útil empieza por el inventario real: qué servicios estaban en la zona afectada, cuáles dependen de ella aunque no tengan allí sus máquinas y qué funciones críticas siguen atadas a una sola ubicación. Comprueba también qué estado devolvieron las aplicaciones y si las colas, trabajos por lotes y sincronizaciones se reanudaron sin duplicar operaciones. Un panel de estado informa del proveedor; no sustituye la telemetría de cada servicio.

Si la continuidad exige salida geográfica, el diseño debe contemplar replicación, consistencia de datos, direcciones y dependencias de identidad, además de capacidad disponible en destino. Para servicios menos críticos, puede ser más razonable aceptar una interrupción acotada y practicar una recuperación documentada que mantener una segunda región sin validar. Google aún debía completar su análisis, por lo que no hay base para atribuir el alcance a un fallo concreto de conmutación o a una configuración común de clientes.

La enseñanza práctica es revisar los límites de fallo con el proveedor y con la propia arquitectura, no sumar zonas en una hoja de cálculo. La redundancia solo reduce riesgo si sobrevive al mismo evento y si el procedimiento de recuperación se ha probado con el dato y el servicio que importan. En este caso, la recomendación de Google fue mover cargas a una ubicación alternativa cuando fuera factible; la decisión requiere conocer las dependencias concretas de cada entorno.

-InfraCrew dice: La prueba de resiliencia que cuenta es la que termina con el servicio útil y los datos coherentes, no la que termina con el gráfico en verde.-

Diccionario de la Crew

Zona de disponibilidad — Ubicación física aislada dentro de una región cloud, diseñada para ofrecer una frontera de fallo independiente de otras zonas.
Región — Área geográfica que agrupa zonas de disponibilidad y servicios cloud, con características y dependencias específicas del proveedor.
Plano de control — Componentes que gestionan y coordinan recursos, separados de las cargas de trabajo que ejecutan la aplicación.

Fuentes

• Google Cloud Service Health | https://status.cloud.google.com/incidents/Xs2XTHzAVC9YnafnPyzj
• AP News | https://apnews.com/article/google-outage-europe-bank-apps-e8d708a22cb1a1b225e2b1b70e963a31