Introducción
El 20 de octubre de 2026, a primera hora de la mañana, las aplicaciones bancarias de miles de clientes británicos comenzaron a fallar en cascada. Revolut dejó de procesar pagos y reintegros en cajeros automáticos. Los portales de Lloyds y HSBC mostraban errores. Las audiencias judiciales por videoconferencia de los tribunales civiles ingleses quedaron interrumpidas. La causa no fue un bug ni un ciberataque: fue un cable subterráneo roto y dos autómatas programables mal configurados.
Cuando la red de seguridad falla
A las 06:00 UTC, el suministro eléctrico externo del centro de datos que aloja la zona europe-west2-b de Google Cloud en Londres se cortó por la rotura de un cable subterráneo. El escenario estaba previsto: los sistemas de alimentación ininterrumpida (UPS) debían tomar el relevo y, a continuación, los grupos electrógenos de respaldo tenían que arrancar automáticamente. No lo hicieron.
El informe post-incidente publicado el 4 de noviembre detalla la causa: los dos controladores lógicos programables (PLC), principal y de respaldo, presentaban un fallo en su lógica de detección de tensión. El autómata reportaba que había una fuente eléctrica operativa disponible, aun cuando ambas alimentaciones del centro de datos estaban fuera de servicio. Los generadores nunca recibieron la señal de arranque. Las baterías UPS se agotaron en cinco minutos. Servidores, almacenamiento y equipos de red se apagaron.
La caída total duró siete horas y cincuenta y dos minutos. Más de cincuenta productos de Google Cloud resultaron afectados: Compute Engine, Cloud SQL, Cloud Storage, BigQuery, GKE, Cloud Run, toda la pila de una zona completa.
Doce servicios en cascada
El impacto no se limitó a las instalaciones de Google. Doce servicios de terceros que dependían de esa zona también se vieron arrastrados. Los sistemas de Revolut perdieron sucesivamente conectividad, transferencias y operaciones en cajeros. Lloyds, HSBC y Royal Mail también fueron impactados. Cuatro horas después de la resolución oficial del incidente, seis de los veintisiete servicios de Revolut permanecían aún degradados.
Lo que este incidente pone de manifiesto es la diferencia estructural entre resiliencia lógica y resiliencia física. Las arquitecturas multi-zona protegen frente a fallos aplicativos y deficiencias de software. Pero no compensan un defecto de ingeniería en los sistemas de control industrial de un centro de datos, sistemas a los que ni los clientes ni sus auditores tienen acceso directo.
Infraestructura crítica: una designación, y luego una caída
El contexto regulatorio añade una dimensión especialmente reveladora. En julio de 2026, el Tesoro británico designó oficialmente a Google Cloud EMEA Limited, junto a AWS, Microsoft Azure y Oracle, como "tercero crítico" del sistema financiero del Reino Unido. Primera designación de este tipo en Europa, reconocía la dependencia sistémica de las instituciones financieras respecto al cloud público. Tres meses después, uno de esos proveedores ya regulados registraba el incidente cloud más mediático del año en el Reino Unido.
Para las organizaciones sujetas a DORA, el reglamento europeo sobre resiliencia operativa digital, en vigor desde enero de 2025, este incidente es una demostración práctica e incómoda: los planes de continuidad deben contemplar escenarios de fallo en los proveedores cloud críticos, no solo interrupciones internas.
Lo que los equipos TI deben aprender
Google reprogramó los PLC defectuosos y se comprometió a reforzar sus protocolos de prueba de infraestructura física. Pero estas medidas correctivas no responden a las preguntas que cualquier CIO debería hacerse hoy.
¿Sus planes de continuidad contemplan y prueban realmente un escenario de caída completa de una zona cloud durante varias horas, con conmutación efectiva y verificada a una región alternativa? ¿Su arquitectura asume que una zona está disponible mientras el proveedor no declare un incidente? Este centro de datos londinense perdió el suministro eléctrico seis minutos antes de que Google detectara los primeros errores en sus aplicaciones.
Y para las organizaciones del sector financiero: ¿están planificados y documentados para 2027 los tests de resiliencia con terceros críticos que exige DORA?
La resiliencia cloud no se lee solo en los SLA, se pone a prueba en la sala de generadores.