La redundancia no sobrevive al procedimiento

El 1 de septiembre, un ingeniero de Google desenchufó en un centro de datos, uno detrás de otro, el 100% de los caminos de fibra que daban servicio a una parte de la zona us-central1-b. Tardó trece minutos. Lo interesante del informe no es el error: es el párrafo que Google escribe justo antes, describiendo una arquitectura redundante impecable.

De la anterior caída de Google ya escribimos aquí: aquella fue de energía y refrigeración, un fallo de instalación en la sala. Esta no se le parece en nada, y por eso vale la pena. Aquí no se averió ninguna pieza. Todo el hierro estaba sano; lo que estaba desconectado, lo desconectó alguien, a mano, con una orden de trabajo aprobada.

Lo que estaba bien diseñado

Antes de contar el error, el informe preliminar dedica un párrafo a explicar cómo está montada la red de cada centro de datos. Merece leerse entero, porque es exactamente lo que cualquiera de nosotros pondría en una propuesta:

Todo eso es cierto y todo eso estaba puesto. Y no sirvió absolutamente de nada, porque la frase siguiente del informe dice que «un error de procedimiento hizo que la acción de mantenimiento físico desenchufara secuencialmente el 100% de los caminos de fibra en todos los dispositivos en trece minutos».

La redundancia es una máquina de enmascarar

Esto ya estaba explicado, y lleva explicado veintitrés años. En 2003, tres investigadores de Berkeley —David Oppenheimer, Archana Ganapathi y David Patterson— analizaron por qué se caen tres grandes servicios de internet y publicaron los resultados en USENIX. La conclusión que todo el mundo cita es que el error de operador era la mayor causa individual de caídas en dos de los tres servicios. La que casi nadie cita es la que de verdad explica lo del 1 de septiembre, y es un matiz que los propios autores se molestan en dejar por escrito:

Enmascarar. Esa es la palabra exacta de lo que hace la redundancia y de lo que no hace. Un disco que se muere, una fuente que se quema, un camino que se corta: son sucesos independientes, cada uno por su cuenta, y la redundancia existe justamente para taparlos antes de que nadie se entere. Por eso la garantía del párrafo de Google está escrita como está: resistente a cualquier fallo de un solo dispositivo, y a la mayoría de los dobles o triples. Son afirmaciones sobre coincidencias improbables. La separación física y la alimentación diversa sirven para que un charco, un incendio o un cuadro eléctrico no alcancen dos caminos a la vez.

Y hay un detalle del paper que encaja con este incidente mejor de lo que a nadie le gustaría. Los autores escriben que «los errores de operador surgían cuando los operadores estaban haciendo cambios en el sistema, por ejemplo escalando o reemplazando hardware, o desplegando o actualizando software», y añaden que la mayoría «surgieron durante mantenimiento normal». La tarea del 1 de septiembre, en palabras de Google, era «una actualización de capacidad programada». Escalar hardware. Mantenimiento normal. Veintitrés años después, en el mismo casillero.

Con una diferencia honesta que conviene decir: en aquellos tres servicios los errores de operador eran sobre todo de configuración —más del 50% en los tres casos— y no errores de procedimiento físico, que el propio paper sitúa en minoría. Este es de los raros. Lo que no cambia es el mecanismo: alguien haciendo un cambio previsto, en una ventana prevista, alcanza a la vez todo aquello que estaba separado para que no se alcanzara junto.

Tu lista es más corta de lo que crees

Aquí es donde esto deja de ser una anécdota de hiperescalar. Tu redundancia también lleva dentro un supuesto que nadie escribió: que nada toca todas las copias. Y en cualquier empresa hay una lista corta de cosas que sí las tocan todas, una detrás de otra, con credenciales y sin preguntar: el script de parcheo, el agente de copias, la herramienta de gestión remota, la actualización de firmware que se lanza por lotes, la orden de trabajo que dice «los dos switches». No son ataques ni averías. Son tareas rutinarias, aprobadas y bienintencionadas, y son las únicas capaces de recorrer tu redundancia de punta a punta. Esa lista cabe en media hoja y casi nadie la tiene escrita hasta que se la pides.

No es la primera vez que damos con un supuesto de independencia que resulta falso. En agosto escribimos que redundancia no es diversidad de ruta: dos operadores distintos, dos contratos distintos y la misma zanja. Aquello era una correlación geográfica que nadie eligió. Esto es más incómodo, porque la correlación no es accidental: la introduce, cada vez, alguien de tu propio equipo haciendo su trabajo bien.

La red volvió a las 09:19. El incidente terminó a las 11:52

El informe da 4 horas y 11 minutos de duración, de 07:41 a 11:52 hora del Pacífico. Pero si sigues los avisos de estado que Google fue publicando durante la mañana, ese número se parte en dos mitades que no se parecen en nada. A las 09:19, hora y media después del primer cable, el aviso dice que «tras los esfuerzos de mitigación a nivel de red, la infraestructura de red subyacente se ha recuperado por completo» y que los equipos de producto «están validando el estado de recuperación de los servicios individuales». La fibra ya estaba puesta. Quedaban dos horas y media de incidente.

Esa segunda mitad es la parte que casi nunca se presupuesta. La detección, por cierto, fue instantánea: el informe dice que el problema «fue detectado inmediatamente por los sistemas automáticos de monitorización de pérdida de red, así como por sondas proactivas». Enterarse no costó nada. Volver a estar arriba costó todo lo demás, y la mayor parte de ese tiempo no fue enchufar fibra: fue esperar a que los servicios de encima se recompusieran. Es la misma diferencia que ya contamos en el plan de continuidad que nadie ha ensayado, donde el problema era que el papel decía «restaurar» sin que nadie hubiera cronometrado el verbo.

Lo que el proveedor puede mover por ti es tráfico, no estado

El desglose de impacto por servicio se lee bien junto a la cronología, y lo que sale de ahí no es lo que uno esperaría. Las máquinas virtuales de Compute Engine sufrieron «imposibilidad de acceder a ellas desde el exterior, e imposibilidad de que alcanzaran recursos remotos»: nadie las movió, se quedaron donde estaban hasta que alguien volvió a enchufar la fibra. Las bases de datos gestionadas —Cloud SQL, AlloyDB, Spanner, Bigtable, Filestore— tuvieron «acceso a datos y conectividad cortados para instancias localizadas estrictamente en la infraestructura afectada»: las que vivían en un solo sitio, cayeron. Y Kubernetes tuvo «clústeres y nodos inalcanzables dentro de la zona afectada, provocando tiempos de recuperación de clúster retardados»: capa alta, y aun así nadie lo evacuó.

Los únicos que se movieron solos fueron Cloud Run y App Engine: «picos de latencia temporales y cancelación de peticiones en cola mientras las cargas del backend se evacuaban automáticamente y se desplazaban a capacidad sana». Sin que nadie llamara a nadie. Y ahora la parte que descoloca: fueron también los últimos en volver. En el aviso de las 11:36, cuando el resto ya figura recuperado, los dos únicos productos que Google sigue nombrando son Cloud Run y App Engine; y el informe dice que su degradación duró «hasta las 11:52». Es decir, la hora de fin oficial del incidente es la suya, no la de la red.

La mitigación que publicaron era una decisión de hace meses

En plena caída, el aviso de estado publicó su apartado de workaround. Decía dos cosas. Una: «los clientes gravemente afectados que tengan servicios disponibles en zonas alternativas pueden conmutar a zonas alternativas». Y dos: «los clientes con reintentos en la capa de servicio pueden ver operaciones completadas con éxito, ya que solo una parte de la zona está afectada».

Las dos mitigaciones que tu proveedor te puede ofrecer en mitad de una caída de cuatro horas son cosas que o ya tenías montadas, o no existen para ti. Nadie compra una segunda zona a las 07:41 de la mañana con las máquinas mudas, ni le mete reintentos a una aplicación mientras se cae. Eso es literalmente lo que es un plan de recuperación: opciones compradas por adelantado. El día del incidente no se decide nada; el día del incidente solo se gasta lo que ya tenías.

Dos lecturas fáciles que no vamos a hacer

La primera es «por esto no nos fiamos de la nube». No. Google publicó un informe con la hora de inicio, la hora de fin, la causa raíz, una admisión explícita de que el error fue de procedimiento y el compromiso de decir después qué cambia. La pregunta incómoda no es para ellos, es para el resto: ¿tu última caída tiene un documento así? Con la hora exacta, qué se estaba tocando y quién lo aprobó. Si ese papel no existe, el mismo cambio volverá a pasar, y la segunda vez tampoco sabrás por qué.

La segunda lectura fácil es reírse del ingeniero, que es la que han hecho casi todos los titulares de la semana. Es la peor de las dos. La frase más importante de todo el informe es la que va inmediatamente después de la causa raíz: «la naturaleza del error, combinada con la velocidad de la acción, impidió que los avisos de acción incorrecta llegaran al ingeniero antes de la desconexión completa». Había avisos. No llegaron a tiempo.

Y que Google leyó el incidente así lo dice su propia acción inmediata, en el último aviso de aquel día: «se ha detenido el mantenimiento en la región mientras se llevan a cabo auditorías proactivas». No pararon un equipo ni una versión. Pararon el procedimiento, en toda la región, hasta revisarlo. Cuando lo que falla es la forma de hacer las cosas, la primera mitigación seria es dejar de hacerlas.

Qué se puede hacer el lunes, y cuándo no hace falta hacer nada

Lo primero es la lista de antes: qué procedimientos tuyos pueden tocar más de un elemento redundante. Escritos, no de memoria. Lo segundo es un número que casi nadie tiene medido, el de cuánto tarda el deshacer —no el detectar—; y si la respuesta incluye «alguien tiene que ir», hay que sumar el viaje, y sumarlo un domingo. Nuestro último simulacro de recuperación completa, cronómetro en mano, fueron 14 minutos: es un dato interno y una prueba, no una promesa contractual, y lo que importa no es nuestro número sino que tú tengas uno medido en vez de uno estimado. Lo tercero es mirar los dos workarounds de Google y preguntarte cuál de los dos tendrías hoy montado.

Y en el hierro, lo más barato de todo: que el trabajo sobre un camino y el trabajo sobre el otro no se firmen para la misma noche. Es lo primero que pedimos por escrito cuando se toca físicamente un equipo de un cliente en una sala de colocation, y no por desconfianza: porque separar las ventanas es lo único que convierte un error de manos en un incidente de un solo camino. No cuesta dinero. Cuesta escribirlo en la orden de trabajo.

Ahora la parte que nos vende menos y que hay que decir igual: si tu empresa aguanta cuatro horas parada una vez cada dos años sin que se note en la caja, no montes multi-zona. Te va a costar más el remedio que la enfermedad. Para una tienda con pedidos online, cuatro horas de un martes de septiembre son dinero contante y sonante; para una gestoría, son una mañana rara en la que se trabaja en local y se refunfuña. Son dos decisiones distintas y las dos son legítimas. La única postura que no lo es consiste en no haber hecho nunca la cuenta y descubrir la cifra el día que pasa.

Lo que no afirmamos

La redundancia enmascara lo que pasa por casualidad. No enmascara lo que pasa a propósito, ordenadamente y con la lista delante. Si nadie ha mirado nunca qué procedimientos de tu casa pueden recorrer todos tus caminos, tu arquitectura de alta disponibilidad tiene un supuesto sin verificar en la base — y esos supuestos se comprueban una sola vez, solos, y a la hora que ellos eligen. El fallo es inevitable. La avería, otra vez, es una decisión de diseño.

Fuentes (verificadas el 7-sep-2026): incidente J5ia5t9p3g9Q5Wi7r8Ev de Google Cloud —informe preliminar publicado el 3-sep con fechas, duración de 4 h 11 min, párrafo de arquitectura de red, causa raíz («sequentially unplugged 100% of fiber paths across all devices within 13 minutes»), la frase sobre los avisos que no llegaron al ingeniero, la detección inmediata y el desglose de impacto por servicio; y los avisos de estado del propio 1-sep, de los que salen la recuperación de la red a las 09:19, el estado de Cloud Run y App Engine a las 11:36, los dos workarounds, «the remaining zones in the region are unaffected» y la parada del mantenimiento en la región—: status.cloud.google.com. Enmascaramiento del error de operador, cambios durante «scaling or replacing hardware» y proporción de errores de configuración: Oppenheimer, Ganapathi y Patterson, «Why Do Internet Services Fail, and What Can Be Done About It?», USENIX USITS 2003 (citas del texto completo). Los 14 minutos del simulacro son un dato interno de everyWAN: una medición propia, no un compromiso de servicio. Las traducciones de las citas son nuestras; los originales están en inglés.