Las baterías que sostienen una de las tres zonas de Google Cloud en Londres están pensadas para aguantar unos cinco minutos, lo justo para que arranquen los generadores. El 20 de octubre los generadores nunca recibieron la orden de arrancar. A las siete de la mañana se apagaron las máquinas y, durante buena parte del día, en Reino Unido hubo gente que no podía pagar con tarjeta, sacar dinero del cajero ni entrar en la app de su banco.
Una semana antes, una prueba que no salió bien
El edificio estaba preparado para casi todo. Según el informe del incidente que Google publicó el 4 de noviembre, la instalación tiene dos acometidas eléctricas independientes, llamémoslas A y B, un banco de generadores diésel, baterías que dan unos cinco minutos de margen y un autómata industrial, un PLC, que decide cuándo arrancan los generadores. De ese autómata hay dos ejemplares: uno principal y otro de respaldo.
El 14 de octubre, durante la prueba trimestral de carga de los generadores, apareció un problema en el camino de la acometida B. Para repararlo, el equipo abrió su interruptor. El edificio pasó a funcionar con una sola pierna, algo habitual en mantenimiento.
El martes 20, a las 06:53 hora británica, falló un cable subterráneo de la compañía eléctrica, fuera del recinto. La acometida A se quedó sin tensión. Era el momento exacto para el que existen los generadores.
El autómata que veía corriente donde no la había
Antes de arrancar los generadores, el PLC comprueba si sigue llegando electricidad de la red. El problema estaba en dónde lo comprobaba: sus sensores medían antes del interruptor de la acometida B, no después. Y la línea B seguía con tensión hasta ese interruptor, que estaba abierto.
Es como comprobar si llega agua a casa mirando la tubería de la calle con la llave de paso cerrada. La tubería está llena; el grifo, seco. El autómata concluyó que había una red sana disponible y no dio la orden. El de respaldo tenía exactamente la misma lógica, así que repitió exactamente el mismo error. Un respaldo que copia el fallo no es un respaldo. Es un eco.
El equipo intentó transferir la carga en remoto y el propio sistema lo bloqueó, por la misma lectura falsa. Con las baterías vaciándose, pasó la instalación a mano a una línea eléctrica de reserva. La luz volvió a las salas a las 08:20. Para entonces, los servidores llevaban más de una hora apagados.
Por qué la luz volvió a las ocho y el servicio a mediodía
Un disco que se apaga de golpe tiene que revisarse antes de que alguien vuelva a confiar en él, y en esa zona se habían apagado de golpe muchísimos. Los ingenieros decidieron esperar en lugar de levantar servicios que podían empeorar la recuperación de los datos. Es la decisión correcta y también la más lenta: Google da por resuelto el grueso del impacto tras 6 horas y 8 minutos.
El golpe tampoco se quedó dentro del edificio. Las cargas que huyeron de la zona caída aterrizaron a la vez en las dos zonas vecinas y las saturaron. Y en Apigee X, el servicio de Google para gestionar APIs, aparece el detalle más humano del informe: estaba diseñado con tres copias de sus datos en tres zonas distintas, pero un error de planificación había colocado dos de ellas en la zona que se apagó. Tres copias, dos en el mismo cajón. Ese servicio estuvo devolviendo errores durante 7 horas y 19 minutos.
| Pieza | Cómo estaba pensada | Qué pasó el 20 de octubre |
|---|---|---|
| Acometidas eléctricas | Dos independientes (A y B) | B abierta por reparación; A cayó por una avería externa |
| Generadores diésel | Arranque automático ordenado por el PLC | No recibieron la orden |
| PLC de control | Principal y respaldo | Misma lógica, mismo error en los dos |
| Baterías SAI | Unos 5 minutos de margen | Se agotaron hacia las 07:00 |
| Zonas de la región | Tres, para absorber la caída de una | Las dos vecinas se saturaron |
| Réplicas de Apigee X | Tres, en tres zonas | Dos estaban en la zona caída |
Elaboración propia a partir del informe de incidente de Google.
Lo que se notó en la calle
Revolut, Lloyds, HSBC, Royal Mail, DPD y Rightmove informaron de problemas. Solo con Revolut se registraron más de 1.500 avisos de usuarios poco después de las ocho de la mañana. También cayó la plataforma de vídeo que usan los juzgados para las vistas a distancia.
Después llegaron las preguntas. Según Reuters, la Autoridad Bancaria Europea pidió información a Google, el regulador financiero británico se puso en contacto con la compañía y la comisión del Tesoro del Parlamento escribió al Banco de Inglaterra y a la FCA. Es la primera prueba seria de las reglas europeas que vigilan a los proveedores tecnológicos de los que depende la banca, las que nacieron con el reglamento DORA.
No es la primera vez que la electricidad tumba a Google en Londres. En agosto de 2024, una avería en una subestación dejó sin sus dos alimentaciones a un nodo de red de la misma región, y el informe de entonces ya anunciaba que se investigaría por qué la energía de emergencia no había asumido la carga. En julio de 2026 le tocó a una zona en Países Bajos, por una avería en la red eléctrica que alimentaba el centro de datos.
Para una organización española, la lección no está en Londres. El ENS tiene una medida para esto, la op.cont.3, «Pruebas periódicas», en el Real Decreto 311/2022. La pregunta útil no es si tu proveedor tiene generadores. Es cuándo fue la última vez que alguien desenchufó algo para comprobar que arrancan.
Ensaya el apagón un martes cualquiera
Google ha corregido el autómata, revisa los de otros centros con el mismo diseño y ha congelado mantenimientos parecidos. Pero el cambio más revelador es otro: el equipo del edificio ensaya ahora el procedimiento de emergencia dos veces por turno. La redundancia que no se ensaya es una hipótesis.