Google Cloud publicó el reporte preliminar del incidente que dejó ciega una zona completa de us-central1-b el pasado 1 de septiembre. La causa no fue un BGP mal propagado, ni un despliegue de software, ni un corte de energía: un ingeniero que hacía un upgrade de capacidad rutinario fue desconectando cables de fibra óptica hasta que se quedó sin ninguno. Cuatro horas y once minutos de caída para VMs, GKE, Cloud SQL, Spanner, BigQuery y una lista larga de servicios más.
Qué pasó
El ingeniero estaba ejecutando un upgrade de capacidad programado sobre los routers de datacenter que sostienen una fracción de la zona us-central1-b. La arquitectura de red de cada datacenter de Google está diseñada con redundancia entre varios dispositivos de routing, con rutas de fibra físicamente separadas y fuentes de energía distintas. Según el propio reporte, el diseño tolera cualquier falla de un solo dispositivo o ruta, y la mayoría de las fallas dobles o triples no llegan a afectar tráfico de clientes.
El problema es que la redundancia no protege contra que alguien desenchufe todo. Un error de procedimiento hizo que la acción de mantenimiento desconectara secuencialmente el 100% de las rutas de fibra de todos los dispositivos en 13 minutos. Y ahí está el detalle que más duele: la velocidad de la secuencia impidió que las alertas de acción incorrecta alcanzaran al ingeniero antes de que terminara de desconectar. Los avisos existían; llegaron tarde.
El resultado fue capacidad de cómputo aislada de la red. Las VMs seguían encendidas y podían hablar entre ellas dentro de la zona, pero nadie de fuera podía alcanzarlas, y ellas no podían salir. Cómputo vivo, incomunicado.
Por qué importa
Este incidente es un recordatorio incómodo de algo que en las arquitecturas de alta disponibilidad se firma en el papel y se olvida en la práctica: la redundancia protege contra fallas aleatorias e independientes, no contra un operador que actúa de forma sistemática sobre todas las rutas a la vez. Toda la separación física, la diversidad de energía y el multi-path se anulan cuando la misma mano recorre los mismos racks con el mismo procedimiento equivocado. El modo de falla se vuelve correlacionado, y el diseño nunca lo contempló.
Para quien diseña o audita infraestructura, la lectura práctica es doble. Primero: la lista de servicios golpeados muestra por qué "zonal" no significa "irrelevante". Compute Engine perdió acceso externo a VMs; GKE dejó clusters y nodos inalcanzables con recuperación lenta; Cloud Run y App Engine sufrieron picos de latencia y abortos de cola mientras evacuaban carga; Cloud SQL, AlloyDB, Spanner, Bigtable y Filestore perdieron conectividad para instancias que vivían estrictamente en la infraestructura afectada. Y en la capa de red: VPC, Cloud NAT, Apigee, BigQuery, Dataflow, Looker, Cloud Interconnect e incluso Google SecOps SOAR con pérdida de paquetes y timeouts de API.
Ese último punto merece un párrafo aparte para cualquiera que trabaje en un SOC: la plataforma de respuesta a incidentes también estaba en la lista de afectados. Si tu tooling de detección y automatización vive en la misma zona que tu carga productiva, el día que se caiga la zona pierdes las dos cosas al mismo tiempo, justo cuando más necesitas ver.
Segundo: si tenías recursos anclados a una sola zona sin réplica, este incidente los apagó durante cuatro horas por una razón que ningún SLA de software habría anticipado.
El detalle técnico
La detección funcionó bien. El monitoreo automático de pérdida de red y las sondas proactivas levantaron la alarma de inmediato y engancharon a los equipos de ingeniería de red y respuesta a incidentes. La mitigación fue en dos frentes en paralelo: por software, mover tráfico lejos de la infraestructura impactada, desplazando automáticamente las cargas compatibles a capacidad sana en otra parte de la región; por hardware, técnicos en sitio identificando los enlaces ópticos desconectados y reasentando físicamente las fibras. Cuando los enlaces volvieron, el tráfico se normalizó y la capacidad regresó a servicio.
Vale la pena notar el contraste: la parte automatizada de la respuesta —detección y desvío de tráfico— hizo su trabajo. Lo que marcó el reloj de las cuatro horas fue la parte física, la que requiere que alguien camine hasta el rack y vuelva a meter cada fibra en su puerto correcto. En el mundo del cloud, donde todo se siente como una API, el piso del datacenter sigue siendo el camino crítico.
Google califica la causa como preliminar y promete un reporte final con acciones preventivas. Lo interesante será qué controles añaden: lo natural sería un gate que bloquee la operación cuando un procedimiento de mantenimiento está a punto de bajar la última ruta redundante de un dispositivo, en lugar de depender de una alerta que compite en velocidad contra las manos del técnico.
Qué hacer
- Revisa qué tienes anclado a una sola zona. Discos zonales, instancias de Cloud SQL sin HA, clusters GKE zonales y Filestore son los sospechosos de siempre. Multi-zona cuesta más; una caída de cuatro horas también.
- Saca tu tooling de respuesta de la zona que vas a defender. SIEM, SOAR, bastiones, jump hosts y runbooks deben estar en un dominio de falla distinto al de la carga productiva.
- Audita tus propios procedimientos de mantenimiento físico y de cambios en red. La pregunta correcta no es "¿tengo redundancia?", sino "¿puede un solo operador siguiendo un procedimiento tumbar todas mis rutas?". Si la respuesta es sí, no tienes redundancia: tienes copias.
- Exige gates, no alertas. Un aviso que llega después de la acción no es un control. Donde puedas, convierte las advertencias en bloqueos que requieran confirmación explícita o segunda persona.
- Prueba la evacuación de zona. El desvío automático de Google funcionó; el de tu aplicación solo lo sabrás el día que lo ensayes.