Caída de Google Cloud en Londres: por qué falló el failover y qué aprender

22 de octubre de 2026 · Rafael Medina González

El 20 de octubre de 2026, un corte eléctrico en un centro de datos de Google Cloud en Londres dejó fuera de servicio la zona europe-west2-b durante algo más de seis horas. Fallaron dos failovers seguidos: los generadores de emergencia no arrancaron y, cuando el tráfico saltó a las otras zonas, estas se saturaron. Revolut, que se apoya en Google Cloud, se quedó horas sin pagos con tarjeta ni transferencias.

¿Qué pasó exactamente?

Según el informe preliminar de Google, a las 6:53 (hora de Londres, la misma que en Canarias) hubo una perturbación en la red eléctrica que alimenta el centro de datos de la zona europe-west2-b. El edificio pasó a funcionar con baterías (SAI) mientras debían arrancar los generadores diésel. No arrancaron: el autómata que controla esa transferencia falló, y también su autómata de respaldo. A las 7:00 se agotaron las baterías y se apagaron servidores, red y almacenamiento de la zona.

El incidente terminó a las 13:10. Google lo atribuye a ese "evento eléctrico" y ha anunciado un informe final con medidas preventivas.

Revolut confirmó la caída y aseguró que el dinero y los datos de sus clientes no se vieron comprometidos. La prensa británica e irlandesa recogió también problemas en otros servicios alojados en esa región.

¿Qué es un failover?

Un failover es el paso automático de un servicio a un sistema de reserva cuando el principal falla. Puede ser de energía (de la red a los generadores), de servidor (de una máquina a otra) o de ubicación (de un centro de datos a otro).

En la nube, la unidad básica es la zona: uno o varios edificios con energía y red propias. Varias zonas cercanas forman una región. La idea es que, si cae una zona, las otras de la misma región sigan atendiendo.

               Región europe-west2 (Londres)
  ┌───────────────┐  ┌───────────────┐  ┌───────────────┐
  │   Zona a      │  │   Zona b      │  │   Zona c      │
  │  servidores   │  │  servidores   │  │  servidores   │
  │  réplica BD   │  │  réplica BD   │  │  réplica BD   │
  └───────┬───────┘  └───────┬───────┘  └───────┬───────┘
          └──────────────────┼──────────────────┘
                     balanceador de carga
                             │
                         usuarios

¿Por qué falló esta vez?

Fallaron dos capas, una detrás de otra.

Primer fallo: la energía de reserva

 Red eléctrica ──✗ corte
        │
        ▼
 SAI (baterías) ── aguanta 7 minutos ──▶ se agota a las 7:00
        │
        ▼
 Generadores diésel ──✗ no arrancan
                      (fallan los dos autómatas de control)
        │
        ▼
 Zona b sin corriente

El respaldo existía, pero el mecanismo que lo pone en marcha no funcionó. Tener un generador no sirve de nada si nadie ha comprobado que arranca solo.

Segundo fallo: el salto a las otras zonas

Cuando la zona b cayó, el tráfico y las bases de datos se pasaron automáticamente a las zonas a y c. Pero todo llegó a la vez: las zonas supervivientes no tenían capacidad libre para absorber el trabajo de la caída, se formaron colas, los failovers de las bases de datos se retrasaron y aparecieron errores en toda la región.

 Antes:   a [███░░]   b [███░░]   c [███░░]
 Después: a [█████]▲  b [ caída]  c [█████]▲   → colas y errores

La lección es doble: el plan de reserva tiene que probarse de verdad, y lo que recibe la carga de reserva necesita margen para aguantarla.

¿Qué debe hacer una pyme?

No hace falta la arquitectura de un banco. Hace falta saber qué pasa si cae cada pieza y haberlo comprobado.

Haz la lista de lo crítico. Facturación, correo, ERP, la web de reservas. Para cada uno, anota cuánto tiempo puede estar parado (RTO) y cuántos datos te puedes permitir perder (RPO).
Comprueba el SAI. Si tienes servidor o NAS en la oficina, verifica que el SAI aguanta lo necesario y que apaga los equipos de forma ordenada antes de agotarse. Las baterías se degradan con los años.
Distribuye lo que sea crítico. En Azure, Google Cloud o AWS se puede desplegar en varias zonas de la misma región. Para lo imprescindible, valora además una segunda región.
Deja margen. Si cada nodo trabaja al límite, el failover trasladará el problema en vez de resolverlo.
Ensaya. Apaga a propósito un servidor o una zona en un horario tranquilo y mide cuánto tarda en recuperarse. Un plan que nunca se ha probado es una suposición.
Escribe el plan B manual. Qué hace el equipo si no hay sistema: cobrar en efectivo, avisar a clientes, a quién llamar. INCIBE lo recoge en su política de continuidad de negocio para pymes.

 ¿Cae una pieza?
   ├─ ¿Hay reserva automática? ── no ──▶ plan manual escrito
   │        │ sí
   │        ▼
   ├─ ¿Se ha probado este año? ── no ──▶ ensayo programado
   │        │ sí
   │        ▼
   └─ ¿La reserva tiene margen? ── no ──▶ redimensionar
            │ sí
            ▼
        servicio continúa

¿Cómo saber si te afectó?

Si usas servicios alojados en la región europe-west2 de Google Cloud, revisa el historial de incidentes en el panel de estado de tu proveedor y los registros de tus aplicaciones entre las 7:00 y las 13:10 del 20 de octubre. Si alguna operación quedó a medias en ese intervalo, como pagos, sincronizaciones o copias de seguridad, conviene verificarla.

Si quieres saber cómo respondería tu infraestructura a una caída así, la auditoría gratuita revisa copias, alimentación y puntos únicos de fallo.

Sigue leyendo

La regla 3-2-1 de copias de seguridad en una pyme