Ayer por la mañana, a las 06:08 UTC, se cayó una zona. Una sola: europe-west2-b, una de las tres de la región de Londres de Google Cloud. La causa que publicó el panel de estado no fue un despliegue mal hecho, ni un certificado caducado, ni un cambio de configuración un viernes: fue un «evento eléctrico». Ocho horas más tarde, la frase que más se repitió para explicar por qué unos cayeron y otros no —«estamos repartidos en dos zonas»— había resultado ser una frase sobre etiquetas, no sobre sitios.
Lo que dijo Google, palabra por palabra
La nota del panel de estado, con su corte marcado: «A power event caused an outage within europe-west2-b zone. The power event is mitigated. We are seeing the recovery of services and are prioritizing the recovery of existing workloads. […] Customers may not be able to yet create new workloads». Traducido: un evento eléctrico provocó una caída dentro de la zona europe-west2-b; el evento está mitigado; se están recuperando los servicios y se prioriza recuperar las cargas de trabajo existentes; puede que todavía no se puedan crear cargas nuevas. Esa última frase vale más de lo que parece, y volvemos a ella en el checklist.
The Register recogió siete productos afectados: BigQuery Data Transfer Service, Cloud Filestore, Cloud Run, App Engine, Google Cloud NetApp Volumes, Google Kubernetes Engine y el servicio gestionado de Apache Kafka. El panel de estado acabó listando bastantes más, y entre ellos productos regionales como Cloud Storage y Compute Engine. Ese detalle importa y volvemos a él al final. Por el lado de quien lo sufrió fuera: Lloyds, HSBC, Revolut, Royal Mail, Rightmove, DPD, BT y Screwfix, entre otros; pagos, transferencias, reparto, portales inmobiliarios y parte de las vistas judiciales por vídeo en Inglaterra y Gales. Google avisó a las 11:58 UTC de que la recuperación completa llegaría «tentativamente» a las 13:00, y marcó servicio normal para la mayoría a las 14:03 UTC.
A la hora de escribir esto no hay informe de incidente publicado. Google dice que lo habrá: «We will publish an analysis of this incident once we have completed our internal investigation». Hasta entonces, qué falló exactamente —acometida, cuadro, conmutación a grupo electrógeno, baterías— no lo sabemos, y quien lo esté afirmando en una red social tampoco. Lo que sí tenemos es la etiqueta de la causa y el alcance.
En ese diagnóstico no hay software. Hay electricidad. Y la electricidad no sale en ningún diagrama de arquitectura que nos hayan enseñado nunca en una reunión.
«Estamos repartidos en dos zonas» no es una respuesta
La documentación de Google lo dice sin adornos: «Zones and regions are logical abstractions of underlying physical resources» —zonas y regiones son abstracciones lógicas de los recursos físicos subyacentes— y «A zone is a deployment area within a region», una zona es un área de despliegue dentro de una región. Abstracción lógica. Área de despliegue. Ni una palabra sobre salas, cuadros, acometidas o grupos.
La documentación de AWS lo lleva más lejos. Texto literal: «the us-east-1a for your AWS account might not be the same physical location as the us-east-1a for another AWS account». Es decir: mi zona «a» y tu zona «a» pueden no ser el mismo edificio. No es un error: fue una decisión deliberada para repartir la carga, porque si no todo el mundo elige la primera de la lista. Para poder coordinarse entre cuentas existen los AZ ID, identificadores estables del tipo use1-az1, que sí señalan —cita textual— «the same physical location in every AWS account».
Ese reparto independiente ya no es general. Todas las regiones posteriores a noviembre de 2012 usan un mapeo uniforme, y desde noviembre de 2025 las cuentas nuevas también lo tienen en las antiguas. Pero sigue vivo para las cuentas creadas antes de esa fecha en nueve regiones, y la lista incluye tres que salen mucho en arquitecturas españolas: Irlanda, Norte de Virginia y Oregón, además de Norte de California, Singapur, Sídney, Tokio, São Paulo y GovCloud Oeste. Y conviene no confundir proveedores: esto es AWS, no Google; Google no documenta ninguna aleatorización por proyecto, y no vamos a insinuar que la haya.
Lo que comparten los dos proveedores es lo que importa: el nombre de una zona es una etiqueta de reparto. No te dice en qué sala está, de qué cuadro cuelga, si comparte acometida con la zona de al lado ni a cuántos metros está de ella. Lo que compras es un compromiso de independencia, que es una cosa seria y normalmente se cumple. Lo que no compras es un plano. Que una zona no es un edificio ya lo escribimos en julio, cuando a Google se le fue europe-west4-a por tensión y refrigeración (lo contamos en julio con europe-west4-a); hoy el ángulo es el siguiente paso: qué puedes auditar tú. Y desde el otro extremo, cuando lo que se cayó fue una región entera: tu nube aguanta perder una zona, no una región.
El dominio de fallo más viejo es el que menos se dibuja
La redundancia se piensa por capas, y casi todo el mundo se queda en las dos primeras. Capa disco: espejo. Capa máquina: doble fuente, porque la máquina entera casca —memoria corrupta, cuelgue—. Capa sala: un centro de datos fuera por corte eléctrico, incendio o inundación. La corriente está por debajo de las tres, y es la que peor se dibuja por una razón de fondo: no es un componente, es la condición para que existan los componentes. En un diagrama lógico nada está enchufado a nada.
La nube pública añade una trampa propia. Los recursos se clasifican en zonales, regionales y globales, y esa clasificación la pone el proveedor producto a producto, no tu intuición. Un disco persistente zonal, un clúster de Kubernetes de una sola zona o un volumen de ficheros vive en una zona, aunque tu consola diga europe-west2 y aunque la palabra «región» aparezca tres veces en la presentación que aprobó el presupuesto. La arquitectura parece regional. El recurso no lo es.
Ceph le puso nombre a esto hace años, y se llama «pdu»
Para quien tiene hierro propio esto tiene nombre desde hace años. La jerarquía por defecto de CRUSH —el algoritmo con el que Ceph decide dónde va cada copia de cada objeto— tiene esta lista de tipos de cubo, y lleva ahí desde hace muchas versiones: osd, host, chassis, rack, row, pdu, pod, room, datacenter, zone, region, root.
Entre row (fila de armarios) y pod hay un tipo de cubo que se llama unidad de distribución eléctrica. Está ahí porque quien diseñó esto sabía exactamente lo que pasó ayer en Londres: que la corriente es un dominio de fallo de pleno derecho, que no coincide con el armario ni con la fila, y que dos máquinas separadas por veinte metros pueden morir juntas si cuelgan de la misma regleta. La documentación lo dice sin rodeos: «By reflecting the underlying physical organization of the installation, CRUSH can model (and thereby address) the potential for correlated device failures» —al reflejar la organización física real de la instalación, CRUSH puede modelar, y por tanto tratar, el potencial de fallos correlacionados de dispositivos—.
El dominio de fallo que Ceph usa por defecto es host: tres réplicas en tres máquinas distintas. Eso protege de que se muera una máquina, que es el fallo más frecuente, y está bien elegido como valor por defecto. Pero si esas tres máquinas están en el mismo armario, y ese armario cuelga de un cuadro, frente a un evento eléctrico tienes tres copias y un solo dominio de fallo: a efectos del cuadro, una copia. Ceph te dirá HEALTH_OK todo el tiempo, porque está cumpliendo con exactitud la regla que le escribiste. El sistema no miente; es que nadie le preguntó por la corriente.
La diferencia entre una zona de nube y un cubo de CRUSH no es tecnológica: uno se puede imprimir y el otro no. Un ceph osd tree te saca el árbol entero —qué disco cuelga de qué máquina, de qué armario, de qué fila— en una pantalla, y lo puedes poner al lado del esquema eléctrico de tu sala y discutirlo con el electricista. La «zona b» de Londres no se puede imprimir. No porque te la escondan, sino porque para ti no es un sitio: es una etiqueta con un compromiso detrás. Eso no hace mala a la nube; hace que la pregunta sea otra. Lo contamos entero cuando hablamos de cómo un Ceph de tres nodos no se cura solo: aguanta.
Cuándo NO subir el dominio de fallo
La reacción natural es decir «pues lo subo a rack y listo», y es lo que más hemos visto romperse. Si tu pool tiene tres copias y le pides al algoritmo un armario distinto por copia, necesitas tres armarios con sitio y con discos. Con dos, CRUSH no encuentra dónde poner la tercera: los grupos de colocación se quedan infrarreplicados (undersized) y, según el min_size que tengas, el pool deja de aceptar escrituras en cuanto algo más se tuerza.
Lo que has hecho ahí es cambiar un riesgo de durabilidad por un problema de disponibilidad. Y el segundo llega antes: el cuadro eléctrico te puede fallar una vez cada muchos años, pero un clúster que no acepta escrituras te lo encuentras el martes que viene. Declarar room cuando tienes una sala no es resiliencia, es un clúster parado con muy buena intención. En un clúster de tres nodos el dominio razonable casi siempre sigue siendo host.
El cuadro eléctrico no se arregla con un comando. Se arregla con trabajo de electricista y de inventario —dos acometidas, dos cuadros, un SAI probado con carga de verdad— y de eso escribimos entero el día que tocaba: los dos cables de tu servidor van a la misma regleta. Lo que aporta Ceph es que, una vez hecho ese trabajo, puedes decírselo al sistema y el sistema lo respeta.
El plano que falta: una fila por réplica
Este plano lo rellenamos de pie delante del armario, con una linterna, siguiendo cada manguera hasta su cuadro. No desde el inventario, no desde la hoja de cálculo de la última auditoría, no desde la memoria del compañero que montó aquello. Una fila por copia de tus datos.
Si dos filas comparten cuadro, tienes dos copias y no tres. Si las tres comparten SAI, tienes una. Da igual lo que diga el panel. La cuenta no la hace el sistema de almacenamiento, la hace el electricista.
Si lo tuyo está en la nube el plano es otro, pero el ejercicio es el mismo y se contesta en una tarde:
- Apunta el identificador, no el nombre. En AWS,
aws ec2 describe-availability-zones --query "AvailabilityZones[].{Name:ZoneName,ID:ZoneId}" --output tablete da las dos columnas. Si repartes entre cuentas u organizaciones, la que vale es la del ID. - Marca qué recursos son zonales. Uno a uno, mirando la ficha del producto y no el nombre de la carpeta. El disco, el clúster, el volumen de ficheros, la cola. El que esté en una sola zona, subrayado.
- Pregunta por el plano de control. No sólo «¿sobrevive mi aplicación a perder una zona?», sino «¿puedo arrancar cosas nuevas mientras esa zona está caída?». Son dos preguntas distintas y la segunda es la que decide cuánto dura el mal rato.
- Ponle fecha a la prueba. Apagar a propósito lo que vive en una zona, en horario de oficina, con todo el mundo delante. Si la respuesta a «¿podemos hacerlo el jueves a las once?» es «ni de broma», ya tienes el resultado del experimento sin haber apagado nada.
La factura que deja Londres
De las 06:08 a las 14:03 van siete horas y cincuenta y cinco minutos. Un compromiso de disponibilidad del 99,9% da derecho a 8 horas y 46 minutos de caída en todo el año. Es decir: el incidente de ayer, él solo, se comió el 90% del presupuesto anual de un 99,9%. Y estamos en octubre.
Conviene además no confundir el compromiso del proveedor con el tuyo: lo que tú firmaste con tus clientes y lo que el proveedor te compensa con créditos de servicio son dos cosas distintas, y los créditos no pagan el día que el almacén no sacó pedidos. Sobre esa confusión escribimos entero hace unos días: el 99,9% no te dice cuánto dura la caída.
Queda una cosa que no encaja, y es la que más nos ha hecho pensar: el aislamiento de zonas no aguantó del todo. Google acotó la causa a europe-west2-b, pero el resumen de su propio panel dice que «some services in europe-west2 region might experienced elevated errors and intermittent network issues», y entre los productos listados hay regionales. Es decir: ayer no bastaba con estar repartido. El límite de la zona no cayó donde el diagrama decía que caía, que es —otra vez— el argumento de este post. Dicho lo cual, la región siguió en pie: Google perdió una de tres zonas y no perdió Londres.
De qué cuadro cuelga la segunda copia
Esa es la pregunta, y no admite «estamos replicados» por respuesta. Si nadie en la sala sabe contestarla, lo que hay no son dos copias: son dos sitios donde está la misma. Nosotros montamos almacenamiento distribuido con Ceph precisamente cuando el reparto tiene que ser algo que puedas señalar con el dedo, y el resto de la infraestructura con el esquema eléctrico encima de la mesa desde el primer día. Si quieres que miremos el tuyo, la primera conversación es rellenar esa tabla: escríbenos.
Fuentes. Nota del panel de estado de Google Cloud sobre el evento eléctrico en europe-west2-b y cronología del 20 de octubre de 2026, recogidas por The Register; lista de organizaciones afectadas según la misma cobertura y la de la prensa británica. Documentación de Google Cloud, «Regions and zones» (zonas y regiones como abstracciones lógicas; zona como área de despliegue). Documentación de AWS, «AZ IDs» (mapeo independiente por cuenta, identificadores use1-az1, regiones afectadas y cambio de noviembre de 2025). Documentación de Ceph, «CRUSH Maps» (tipos de cubo de la jerarquía por defecto, fallos correlacionados, ceph osd tree) y perfiles de código de borrado (crush-failure-domain por defecto host). Resumen y cronología del incidente en el panel de estado público de Google Cloud, consultado el 21-10-2026. El cálculo de los nueves es aritmética nuestra. A fecha de publicación no hay informe de incidente público del proveedor; Google ha dicho que lo publicará cuando termine su investigación interna.
Microsoft 365
ES 
CAT 
EN