Un corte de energía se convirtió en una cuenta regresiva de siete minutos
Alrededor de las 07:08 BST de un martes, un fallo en la red local afectó a la zona europe-west2-b de Google Cloud en Londres. Las baterías UPS se activaron de inmediato, una respuesta de libro de texto. Sin embargo, ni el controlador del generador principal ni el de respaldo iniciaron los generadores diésel, dejando a la instalación dependiendo de la energía de las baterías.
Esa ventana de siete minutos resultó crítica. El centro de datos funcionó con baterías durante aproximadamente siete minutos antes de que se agotara la energía, sumiendo a toda la zona en la oscuridad. Fundamentalmente, las baterías no fallaron; los sistemas de arranque de los generadores sí lo hicieron, creando una cascada de interrupciones inesperadas.
Revolut, un gigante fintech que atiende a millones de usuarios, sintió el impacto de inmediato. Los usuarios reportaron problemas generalizados:
- Fallos en el inicio de sesión
- Transferencias de dinero bloqueadas
- Pagos con tarjeta rechazados
Revolut citó inicialmente una "interrupción del servicio" antes de atribuir el extenso tiempo de inactividad a Google Cloud. El incidente subrayó rápidamente la fragilidad de depender incluso de la infraestructura en la nube más sofisticada cuando un único punto de fallo, como un controlador de generador, puede provocar una interrupción tan significativa.
Las dos zonas saludables no fueron lo suficientemente saludables
Las regiones multizona prometen resiliencia: si una zona falla, las cargas de trabajo se trasladan a las otras. La región europe-west2 de Google Cloud en Londres tiene tres zonas de este tipo (a, b y c). Cuando la zona b se quedó sin energía, el sistema debería haber realizado una conmutación por error sin problemas a las zonas a y c, manteniendo el servicio.
En cambio, el aumento repentino de tráfico sobrecargó la infraestructura restante. No fue un simple cambio; fue un problema de capacidad y una pesadilla de coordinación. Las dependencias entre zonas significaron que algunos servicios en las zonas a y c permanecieron bloqueados, esperando componentes o estados aún asociados con la zona b fuera de línea.
La lección de ingeniería es clara: la redundancia solo es efectiva si las zonas son verdaderamente independientes y poseen suficiente margen para absorber una tormenta de conmutación por error realista. Los límites de tasa, la degradación gradual y los planes de recuperación rigurosamente probados son fundamentales para evitar que una "estampida" derribe toda una región.
Google se recuperó antes que Revolut
La rápida recuperación de la infraestructura de Google no se tradujo en una restauración inmediata del servicio para sus clientes. Google informó que la mayoría de los clientes volvieron a estar en línea entre seis y ocho horas después de que comenzara el incidente, entre las 13:00 y las 15:00 BST. Revolut, sin embargo, no anunció la restauración completa del servicio hasta las 18:40 BST, un retraso significativo de varias horas.
Esta disparidad revela una distinción crítica: restaurar la capacidad de la nube no elimina instantáneamente el retraso operativo de un cliente. Incluso con computación y almacenamiento disponibles, una institución financiera como Revolut enfrenta desafíos complejos. Conciliar los estados de las transacciones, eliminar los retrasos en los pagos y normalizar cada dependencia de la aplicación, desde los pagos con tarjeta hasta los servicios de inicio de sesión, requiere tiempo y una secuencia cuidadosa.
La interrupción se extendió más allá de Revolut. Los informes indicaron una interrupción más amplia en otras instituciones y servicios del Reino Unido, incluyendo:
- Lloyds
- Halifax
- Enlaces de video para audiencias judiciales remotas
Este impacto más amplio subraya una vulnerabilidad fundamental de la infraestructura de nube compartida. Un fallo de zona única en europe-west2-b se convirtió en un problema de servicio generalizado, demostrando cómo las dependencias interconectadas pueden convertir un evento de energía localizado en un dolor de cabeza nacional. Para obtener más detalles sobre el estado del incidente, consulte el Google Cloud Service Health Dashboard. Curiosamente, los reguladores han tomado nota, y el Bank of England y la FCA han recibido consultas sobre el cronograma de notificación del incidente.
¿Te está gustando? Recibe uno así en tu bandeja cada mañana.
un correo al día · date de baja en dos clics · sin rastreadores de terceros
Una interrupción en la nube es ahora un riesgo bancario
La designación de Google Cloud como critical third party para el sistema financiero del Reino Unido en julio cambia fundamentalmente lo que está en juego. Tras la interrupción, el presidente del Treasury Committee buscó inmediatamente respuestas del Bank of England y la FCA con respecto a los cronogramas de notificación. Esto no es solo un fallo técnico; es un riesgo sistémico.
Las empresas financieras ahora enfrentan una pregunta cruda: ¿cuánta resiliencia es suficiente? Cuando un proveedor de nube, una región completa o incluso la propia arquitectura de una aplicación se convierte en un punto de concentración, las empresas deben examinar su exposición. Los diseños multirregión ofrecen un camino para reducir el riesgo, pero introducen compensaciones significativas en costo, latencia y gestión compleja de datos.
Para clientes y desarrolladores, surgen lecciones prácticas. Durante los incidentes, consulte constantemente el service health dashboard de Google Cloud; ofrece la información más actualizada. Los equipos de ingeniería deben ir más allá de las suposiciones; prueben la pérdida de zona, validen la capacidad de conmutación por error (failover) y simulen modos de operación degradados. El despliegue multizona por sí solo no garantiza la continuidad.
Preguntas frecuentes
¿Por qué se cayó Revolut durante la interrupción de Google Cloud?
Un centro de datos en Londres perdió energía después de que fallaran los controladores de los generadores primarios y de respaldo. El tráfico se trasladó a las zonas restantes, que también se vieron afectadas por la sobrecarga y las dependencias de la zona fuera de línea.
¿Cuánto duró la interrupción de Google Cloud en Londres?
Google dijo que la mayoría de los clientes afectados se habían recuperado entre seis y ocho horas después de que comenzara el incidente. Revolut dijo que sus servicios volvieron más tarde, aproximadamente a las 18:40 BST.
¿Por qué las otras zonas de Google Cloud en Londres no evitaron la interrupción?
Las zonas restantes enfrentaron un aumento repentino de tráfico de conmutación por error, mientras que algunos servicios aún dependían de componentes vinculados a la zona fallida.
¿Qué significa la interrupción para los servicios financieros del Reino Unido?
Destaca cómo la interrupción en un importante proveedor de nube puede afectar a los servicios financieros y por qué los reguladores están examinando a los proveedores externos críticos.