Una política, cada región: Google Cloud y la responsabilidad de un plano de control global

Resumen

• El 12 de junio de 2025, campos en blanco no intencionados en una política de cuotas llegaron casi simultáneamente a los almacenes de datos regionales de Service Control de Google Cloud. Una ruta de código previamente implementada carecía tanto de un manejo de errores adecuado como de protección mediante feature flags; al procesar la política, los binarios de Service Control fallaron en todas las regiones. Muchas API de Google Cloud, Google Workspace y Google Security Operations devolvieron errores 503. Los recursos existentes de streaming e infraestructura como servicio pudieron seguir funcionando en gran medida, pero las rutas de gestión y API necesarias para inspeccionar, modificar, escalar o recuperar servicios quedaron ampliamente afectadas.
• El error inmediato fue limitado, pero el fallo de rendición de cuentas fue arquitectónico. Google tenía instancias de servicio distribuidas regionalmente y un despliegue binario por fases, pero la política desencadenante se replicó globalmente en segundos. El mecanismo de bloqueo, por lo tanto, evitó el aprendizaje regional que se suponía que proporcionaría el despliegue. La recuperación generó un efecto de rebaño contra Spanner en las regiones más grandes porque las tareas reiniciadas carecían de backoff exponencial aleatorio. La infraestructura pública de Cloud Service Health también dependía del entorno afectado, retrasando el primer aviso de Google durante aproximadamente una hora.
• Incidentes anteriores muestran causas diferentes pero preguntas recurrentes sobre la independencia lógica. En junio de 2019, la automatización de mantenimiento desprogramó clústeres del plano de control de red en varias ubicaciones físicas, se retiraron rutas BGP y las herramientas necesarias para el diagnóstico compitieron por la red congestionada. En febrero de 2021, un error latente desencadenado durante cambios de cuotas de peering bloqueó la programación global de red. En marzo de 2021, rutas inválidas expusieron un defecto conocido del proveedor y algunas ubicaciones de Cloud Interconnect carecían de suficiente diversidad de proveedores de routers. No se trata de un defecto de software recurrente; son pruebas repetidas de contención de causa común, autoridad de cambio, recuperación de red y visibilidad veraz.
• Google es responsable de validar los datos replicados globalmente, aislar las funciones del plano de control, preservar el comportamiento fail-static o fail-open cuando sea seguro, mantener las comunicaciones de incidentes independientes y demostrar que las remediaciones prometidas se han completado. Los clientes no pueden reparar esos controles de plataforma, pero siguen siendo responsables de identificar qué operaciones dependen de las API del plano de control, monitorear desde fuera del proveedor, probar modos degradados y comprar diversidad de rutas y proveedores en lugar de contar enlaces nominales. El despliegue en múltiples regiones reduce muchos riesgos; por sí solo, no escapa de un plano de políticas global ni de una red troncal compartida.

La interrupción fue una decisión de control tomada en todas partes a la vez

Una región de nube es fácil de imaginar. Tiene edificios, energía, refrigeración, fibra, máquinas y zonas destinadas a aislar fallos físicos. Un plano de control es más difícil de ver. Es la autoridad que decide si se pueden crear recursos, qué política se aplica, cómo se deben programar las rutas, si una solicitud de API está dentro de la cuota y hacia dónde debe ir el tráfico.

Las aplicaciones pueden continuar procesando trabajo existente cuando esa autoridad no está disponible brevemente, pero se vuelven frágiles cuando necesitan una nueva instancia, un cambio de configuración, una decisión de credenciales, una actualización de ruta o una conmutación por error que a su vez requiere el plano de control.

Esa distinción explica por qué el incidente del 12 de junio de 2025 fue simultáneamente menos que un apagón total de infraestructura y más que un problema de API ordinario. El informe completo del incidente de Service Control de Google dice que los recursos existentes de streaming e infraestructura como servicio no se vieron directamente afectados por el fallo principal.

Sin embargo, una larga lista de productos experimentó errores de API externos, incluidos Identity and Access Management, Cloud Storage, BigQuery, Cloud Run, Cloud DNS, Cloud Load Balancing, Hybrid Connectivity, Network Connectivity Center, Spanner, productos de monitoreo, la consola y múltiples servicios de IA. La capacidad de seguir sirviendo desde un estado ya programado sobrevivió mejor que la capacidad de pedirle a la plataforma que decidiera o cambiara algo.

El mecanismo fue inusualmente claro en el relato público de Google. El 29 de mayo, una nueva función de Service Control para comprobaciones adicionales de políticas de cuotas se lanzó región por región. El despliegue binario se completó sin exponer el fallo porque la ruta de código defectuosa requería un cambio de política posterior. La función no estaba protegida por un flag que permitiera habilitarla gradualmente para proyectos seleccionados, y su manejo de datos inválidos permitió que un valor nulo bloqueara el proceso. El 12 de junio, alrededor de las 10:45 a.m.

hora del Pacífico, una política de cuotas que contenía campos en blanco no intencionados se escribió en las tablas regionales de Spanner utilizadas por Service Control. Debido a que los metadatos de cuotas estaban diseñados para moverse globalmente con una consistencia casi inmediata, los datos aparecieron en todas las regiones en segundos. Cada despliegue regional de Service Control encontró entonces la misma entrada y entró en un bucle de fallos.

No fue un caso en el que la redundancia estuviera ausente. Existían instancias de servicio regionales y almacenes de datos regionales. Tampoco fue simplemente un caso de un ingeniero presionando el botón equivocado. Un sistema de producción aceptó datos de política estructuralmente inseguros, una ruta crítica carecía de manejo defensivo de errores, una función llegó a todas las regiones sin una ruta de activación controlada de forma independiente, y el sistema de propagación fue más rápido que el sistema de validación. La arquitectura convirtió un objeto lógico inválido en un evento global.

Llamar al incidente una interrupción por política mal formada es preciso pero incompleto. La política fue el desencadenante. Las causas mayores fueron la cantidad de autoridad adjunta a ella y la ausencia de contención entre aceptación, replicación, interpretación y servicio. La pregunta responsable no es meramente por qué existió un campo en blanco. Es por qué cualquier política individual pudo convertirse en un estado de fallo ejecutable en todas partes antes de que una región, un cohorte de proyectos o un validador sombra tuviera tiempo de rechazarla.

Un desencadenante corto produjo una recuperación larga y desigual

La cronología de Google contiene dos historias muy diferentes. La detección y el diagnóstico fueron rápidos. La recuperación completa no lo fue.

El camino más lento en us-central1 es central para el análisis de riesgos. A medida que las tareas de Service Control se reiniciaban, colocaban una demanda concentrada en la tabla de Spanner subyacente. Las tareas carecían del backoff exponencial aleatorio necesario para evitar reintentos sincronizados. Google tuvo que limitar la creación de tareas y redirigir el tráfico a bases de datos multirregión. En otras palabras, el primer fallo fue la interpretación insegura de datos globales; el segundo fue un comportamiento de recuperación que sobrecargó una dependencia compartida.

La propia literatura de SRE de Google ha descrito durante mucho tiempo este peligro. Su capítulo sobre cómo abordar fallos en cascada explica cómo los reintentos y reinicios pueden mantener un backend sobrecargado y cómo el backoff exponencial aleatorio, la degradación gradual y la reducción controlada de carga pueden evitar que un problema de capacidad local se convierta en una cascada. El informe de 2025 se compromete explícitamente a auditar los sistemas para ese backoff. La importancia no es que Google no haya seguido una oración en un libro.

Es que una clase conocida de peligro en sistemas distribuidos permaneció en un servicio crítico cuya población de reinicio era regional y cuyos datos subyacentes eran globales.

Por lo tanto, los planes de recuperación deben evaluarse como arquitecturas de producción, no como párrafos de manuales. Un sistema que puede desactivarse de forma segura necesita un mecanismo de bloqueo cuyas propias dependencias se entiendan. Una flota que puede fallar junta necesita un gobernador de reinicio, control de admisión, jitter y una tasa de recuperación máxima probada. Un almacén de datos que se espera que absorba la recuperación de la flota necesita capacidad reservada o una ruta de lectura degradada.

Si los ingenieros deben enrutar a una base de datos multirregión durante el evento, esa ruta debe ensayarse y ser observable antes del incidente, con evidencia de que no moverá la sobrecarga a otro lugar.

La cola larga también importa para la comunicación con el cliente. El informe preliminar de Google describió un evento global de tres horas, mientras que la página del incidente continuó listando la recuperación del producto hasta las 6:18 p.m. Algunos productos tenían trabajo atrasado después de que el servicio de API regresara. Un cliente cuya solicitud falló durante la ventana principal puede haber tenido reintentos, trabajos en cola, flujos de trabajo parciales, cachés obsoletas o un servicio de terceros que tardó más en recuperarse.

El estado verde del proveedor es el inicio de la reconciliación del cliente, no la prueba de que cada proceso de negocio esté completo.

El despliegue regional no creó aprendizaje regional

Se supone que la entrega progresiva convierte la distancia en evidencia. Un cambio llega a una población pequeña; los operadores observan su comportamiento; solo entonces avanza más. Google utilizó un despliegue binario región por región para el nuevo código de Service Control, pero el despliegue nunca ejerció la ruta de código que luego falló. La política activadora siguió un mecanismo de distribución diferente, uno optimizado para hacer que el estado de las cuotas sea global en segundos. El código fue gradual; el significado del código no lo fue.

Este es un fallo de control de cambios sutil pero trascendental. Los equipos a menudo revisan binarios, configuración, esquemas, políticas y datos como objetos separados. Sin embargo, el comportamiento de producción proviene de su combinación. Una función inactiva puede pasar todas las puertas regionales hasta que un valor de configuración la active en todas partes. Un esquema puede ser válido para el escritor pero inválido para un lector más antiguo. Una política replicada globalmente puede hacer que los canarios regionales sean irrelevantes. Un botón de emergencia puede existir pero aún depender del plano de control roto para surtir efecto.

La guía de infraestructura actual de Google reconoce este riesgo. La guía de componentes básicos de confiabilidad dice que los recursos globales son resistentes a incidentes de infraestructura zonales y regionales, pero pueden convertirse en puntos únicos de fallo cuando un error crítico de configuración tiene alcance global. Recomienda un control cuidadoso de los cambios y, para cargas de trabajo excepcionalmente exigentes, respaldos regionales de defensa en profundidad. La guía complementaria de gestión y monitoreo aconseja un despliegue progresivo y un escrutinio adicional para los recursos globales.

El incidente de 2025 aplica la misma lógica dentro del proveedor: el alcance global es un beneficio de confiabilidad contra fallos físicos y un peligro de radio de explosión para mal estado lógico.

Una remediación completa necesita un modelo de lanzamiento unificado. El binario, el esquema de política, los valores de política, la replicación del almacén de datos, las versiones del lector, el comportamiento de respaldo y los controles de emergencia deben tratarse como una superficie de cambio. Los nuevos lectores deben aceptar de forma segura valores antiguos, nuevos, faltantes y corruptos. La nueva política debe leerse en modo sombra antes de ser autoritativa. La activación debe comenzar con proyectos internos o una región acotada y detenerse automáticamente en umbrales de fallo, latencia o error.

La replicación debe ser lo suficientemente incremental como para preservar un intervalo de detección, incluso si el estado comercial final debe volverse globalmente consistente.

Eso no significa que cada política global deba volverse lentamente inconsistente. Las decisiones de cuota y autorización pueden requerir un estado oportuno y coherente. La cuestión de diseño es si la validación puede separarse de la autoridad. Una política candidata puede replicarse como datos inertes, analizarse y evaluarse contra tráfico similar al de producción, y volverse efectiva solo después de que las comprobaciones tengan éxito. Las regiones pueden retener una política de último valor conocido cuando un nuevo objeto es inválido. Los lectores pueden distinguir la corrupción de una denegación legítima.

La consistencia global no es incompatible con la seguridad por fases; simplemente requiere más que una replicación rápida.

Fail open es una decisión comercial y de seguridad, no un eslogan

Google se comprometió a modularizar Service Control para que una función de política afectada pudiera aislarse y fallar abiertamente (fail open), permitiendo que las solicitudes de API continúen si la comprobación correspondiente fallaba. Esa es una corrección significativa, pero la frase "fail open" necesita límites. Una comprobación de cuota, una decisión de autenticación, un control de facturación y un control de prevención de abusos no tienen la misma consecuencia cuando no están disponibles.

Para una comprobación de cuota de bajo riesgo, un servicio permisivo temporal puede ser más seguro que rechazar cada solicitud de API del cliente. El proveedor puede conciliar el uso más tarde, limitar la exposición por proyecto y preservar la disponibilidad central. Para una comprobación de autorización, permitir solicitudes a ciegas podría crear un incidente de seguridad peor que el tiempo de inactividad. Para la creación de recursos, una caché local limitada de la política reciente puede ser más segura que una denegación universal o un permiso universal.

El comportamiento degradado correcto depende del propósito del control, la frescura del estado confiable, la reversibilidad de las acciones y el potencial de fraude, pérdida de datos o gasto descontrolado.

La arquitectura de infraestructura de servicio de Google separa los planos de gestión, control y datos, al tiempo que muestra cuán amplias son las funciones de la plataforma: autenticación, autorización, cuota, limitación de velocidad, auditoría, facturación, registro y monitoreo. Esa amplitud es precisamente por qué el comportamiento de fallo modular es importante. Un analizador o ruta de política no debería poder convertir cada tipo de decisión en la misma respuesta 503.

Un diseño responsable publicaría principios en lugar de detalles de implementación sensibles. ¿Qué clases de comprobación utilizan datos del último valor conocido? ¿Cuáles pueden fallar abiertamente temporalmente? ¿Cuáles fallan cerrados porque la consecuencia de seguridad domina? ¿Qué límites estrictos permanecen durante el servicio degradado? ¿Cómo se reconcilia el uso excepcional? ¿Pueden los clientes elegir un comportamiento más estricto para cargas de trabajo reguladas? ¿Cómo distingue la plataforma una política de proveedor inválida de una denegación legítima de cuota del cliente?

Esto también cambia las pruebas. No es suficiente confirmar que una política correcta devuelve la respuesta adecuada. Las pruebas deben inyectar campos en blanco, campos desconocidos, versiones obsoletas, replicación parcial, objetos corruptos, almacenes de datos no disponibles, lecturas lentas y políticas conflictivas. Deben demostrar que un módulo puede omitirse sin eludir salvaguardas no relacionadas. Deben medir el comportamiento visible para el cliente durante la operación degradada y verificar que la recuperación no reproduzca cambios rechazados o duplicados de manera impredecible.

El sistema de estado compartió la interrupción que debía describir

Durante aproximadamente la primera hora, los clientes no recibieron un informe público de incidente de Cloud Service Health porque esa infraestructura también estaba caída. Algunos clientes también ejecutaban monitoreo en Google Cloud, por lo que tanto el servicio como su evidencia del servicio fallaron juntos. La interrupción afectó no solo la producción sino también el control epistémico: la capacidad de saber lo que estaba sucediendo, decidir si conmutar por error y explicar la situación a los usuarios.

Esto no fue sin precedentes. Durante la interrupción global de autenticación de Google el 14 de diciembre de 2020, el informe de incidente dice que las herramientas internas de Cloud Support se vieron afectadas, los clientes no pudieron crear o ver casos de soporte en la consola y la comunicación del tablero se retrasó hasta después de que terminara el impacto principal. Ese evento provino de la gestión automatizada de cuotas que redujo la capacidad del sistema de identidad central.

Las configuraciones existentes del plano de datos de red permanecieron operativas, pero los servicios autenticados, el acceso a la API, las consolas y muchas herramientas internas no. El mecanismo difiere del de 2025; la preocupación recurrente es que la identidad, el soporte, el monitoreo y la comunicación pueden compartir un destino con los servicios que se supone que deben diagnosticar.

Google ha documentado desde entonces un modelo de comunicación más explícito. Su guía de comunicación de incidentes distingue entre Personalized Service Health, que utiliza el contexto del proyecto y puede integrarse con alertas y API, y el tablero público de Cloud Service Health. La misma guía reconoce que Personalized Service Health depende de servicios como IAM y recomienda un respaldo al tablero público y al feed RSS cuando los sistemas personalizados no están disponibles. Ese es un buen consejo, pero junio de 2025 muestra que el canal público también necesita independencia operativa.

La obligación del proveedor es mantener una ruta de publicación externamente accesible, con energía y administración independientes, con plantillas de incidentes preautorizadas y entradas fuera de banda desde el comando de incidentes. No debería requerir la consola normal, el plano de identidad del cliente, la pila de monitoreo primaria ni el servicio de control bajo investigación. El primer aviso no necesita contener una causa raíz.

Debe indicar los síntomas observados, el alcance conocido, la hora de inicio, si las operaciones del plano de control o las cargas de trabajo existentes están afectadas, los workarounds disponibles y la hora de la próxima actualización.

Los clientes tienen una obligación paralela. La guía de integración para Personalized Service Health dice explícitamente que el servicio no puede saber si cada producto es crítico para una aplicación particular o si la aplicación continúa cuando una dependencia falla. Los operadores necesitan sus propias comprobaciones de recorrido de usuario, métricas de aplicación, telemetría de red y alarmas de procesos de negocio. Al menos una ruta debe ejecutarse fuera de Google Cloud y entregarse a un canal de incidentes que no dependa de la identidad de Google. El estado del proveedor es una corroboración, no el primer y único detector.

Hay una razón de gobernanza para esta separación. Una página de estado retrasada cambia el comportamiento del cliente. Los equipos pueden perder tiempo buscando en sus propias implementaciones, realizar reversiones arriesgadas, escalar hacia un plano de control roto o posponer una conmutación por error mientras esperan confirmación. El silencio del soporte también puede llevar a los proveedores posteriores a publicar especulaciones. La disponibilidad de la comunicación es, por lo tanto, un control de riesgo con objetivos medibles de detección y publicación, no una cortesía agregada después de que comienza el trabajo de ingeniería.

Las cargas de trabajo existentes sobrevivieron mejor que las acciones destinadas a salvarlas

La declaración del informe de 2025 de que los recursos existentes de streaming e infraestructura como servicio no se vieron afectados debe leerse con cuidado. Demuestra una separación útil entre partes del plano de datos y la ruta de gestión. No significa que una aplicación estuviera segura simplemente porque sus máquinas virtuales en ejecución permanecieron activas.

Los sistemas en la nube son dinámicos. Los autoscaling crean instancias. Los orquestadores reemplazan nodos no saludables. Los sistemas de despliegue obtienen artefactos y realizan llamadas API. Las bases de datos conmutan por error. Los certificados y tokens rotan. Los servicios serverless invocan rutas de control del proveedor detrás de una solicitud aparentemente simple. Los respondedores de incidentes cambian reglas de firewall, balanceadores de carga, DNS, rutas, cuotas y permisos. Un plano de datos estático puede seguir reenviando mientras el proceso de negocio a su alrededor pierde la capacidad de adaptarse.

La interrupción de red de febrero de 2021 hace concreto ese límite. El informe de incidente sobre fallo de programación de red de Google dice que se desencadenó un error latente cuando el plano de control de red global reprocesó operaciones asociadas con cambios de cuotas de peering. Las VM y puntos finales de red nuevos, actualizados, eliminados o migrados no pudieron programarse correctamente, mientras que muchas instancias sin cambios continuaron operando. Google pausó las migraciones en vivo a nivel mundial; alrededor de 1000 clústeres de GKE se vieron afectados por la incapacidad de aprovisionar nodos o clústeres;

algunas creaciones de instancias y actualizaciones de balanceadores de carga fallaron con tasas muy altas. Un servidor existente saludable no ayudó a un grupo de autoscaling que necesitaba un nuevo servidor en red.

Esta es la paradoja del plano de control en la recuperación ante desastres. Las acciones en el plan de recuperación a menudo son menos probadas y más dependientes del plano de control que el servicio ordinario. Un manual puede decir "crear capacidad en la segunda región" o "cambiar el balanceador de carga", pero esas son operaciones de API. Si la interrupción inicial afecta la creación de recursos o las actualizaciones del balanceador de carga global, el paso de recuperación no está disponible precisamente cuando se necesita.

La guía de arquitectura de recuperación ante desastres de Google distingue las acciones del plano de datos de las actualizaciones del plano de control y explica la resiliencia específica del servicio. Su guía de diseño de infraestructura confiable recomienda evitar o minimizar las dependencias de acciones que no sean del plano de datos durante fallos, como crear un nuevo balanceador de carga. La lección práctica es preaprovisionar la ruta de recuperación. La capacidad puede estar caliente en lugar de hipotética. Los puntos finales regionales pueden existir antes de que el frontend global falle.

Los registros DNS, credenciales, rutas, imágenes y manuales pueden estar disponibles sin una operación administrativa de último minuto.

Para cada paso de recuperación, un operador debería poder nombrar la API, el proveedor de identidad, la ruta de red, el resolvedor de DNS, el almacén de artefactos, el secreto y la aprobación humana que requiere. Luego, el ejercicio debería eliminar esas dependencias una por una. Un plan que solo tiene éxito mientras la consola, IAM, Service Control, la programación de red global y la región primaria están saludables es un procedimiento de expansión, no de recuperación ante desastres.

La interrupción de 2019 mostró que la separación física puede compartir un límite de automatización

El 2 de junio de 2019, los proyectos de Google Cloud en varias regiones de EE. UU. experimentaron una pérdida elevada de paquetes durante más de tres horas. Algunos servicios de Google no pudieron redirigir completamente a los usuarios a regiones no afectadas. El informe de incidente de red describió múltiples fallos que se combinaron en una interrupción importante: los trabajos del plano de control de red se configuraron para detenerse para un evento de mantenimiento; varias instancias de gestión de clústeres eran elegibles para el mismo tipo de evento raro;

y un error de software permitió que la automatización desprogramara clústeres de software independientes incluso cuando estaban en diferentes ubicaciones físicas.

La red inicialmente continuó en modo "fail static" sin su plano de control. Varios minutos después, se retiraron las rutas BGP entre las ubicaciones afectadas, lo que redujo la capacidad de la red y volvió inaccesibles algunas regiones. El fallo de las herramientas de diagnóstico en la red congestionada ralentizó la investigación. Cuando los ingenieros restauraron las instancias del plano de control, la configuración tuvo que reconstruirse y redistribuirse, extendiendo la recuperación.

Hay una sorprendente similitud estructural con 2025. En 2019, existían ubicaciones físicas y múltiples gestores de clústeres, pero una abstracción de mantenimiento los seleccionó juntos. En 2025, existían instancias regionales de Service Control, pero una política global las alcanzó juntas. Ambos incidentes involucraron un período de seguridad que resultó demasiado corto o demasiado dependiente: el enrutamiento fail-static en 2019 y una derivación de botón de emergencia en 2025. Ambos afectaron las herramientas utilizadas para comprender o comunicar la interrupción.

Ambas rutas de recuperación tuvieron que reconstruir o redistribuir el estado de control en condiciones degradadas.

Las causas no son intercambiables. El incidente de 2019 fue un fallo de control de red y automatización de mantenimiento; el incidente de 2025 fue un fallo de datos de política y control de API. La rendición de cuentas no debería aplanarlos en "Google tuvo otra interrupción". El valor de la comparación es probar si la organización descubre repetidamente que componentes nominalmente independientes aún comparten un dominio administrativo, un mecanismo de propagación, una herramienta de emergencia o una dependencia de recuperación.

Los compromisos de Google de 2019 incluyeron rechazar las solicitudes de mantenimiento implicadas, persistir la configuración local del plano de control, extender la duración de la operación de red fail-static, endurecer las herramientas de emergencia y expandir las pruebas de recuperación ante desastres. La pregunta actual de rendición de cuentas no es si esas acciones habrían prevenido el puntero nulo no relacionado de 2025.

Es si el método de gobernanza detrás de ellas se convirtió en estándar: mapear la autoridad común, persistir el estado seguro, mantener los controles de emergencia fuera del dominio de fallo primario y probar el fallo correlacionado catastrófico. Un programa de remediación tiene valor institucional solo cuando su patrón de control viaja más allá del equipo que escribió la autopsia.

La diversidad de peering y tránsito se trata del destino, no del número de circuitos

La disponibilidad de la nube llega a los clientes a través de redes. Una carga de trabajo puede estar saludable dentro de una región mientras los usuarios no pueden alcanzarla porque un borde, una ruta troncal, una sesión de peering, un proveedor de tránsito, una ruta de DNS o un interconexión híbrida ha fallado. Por el contrario, dos circuitos de acceso pueden parecer diversos en una orden de compra mientras convergen en una misma metrópoli, un mismo proveedor, un mismo modelo de router, un mismo borde de Google o un mismo sistema de control.

El informe de incidente de red troncal del 17 de marzo de 2021 de Google ilustra esa diferencia. La conexión de nuevos routers cambió qué rutas recibían ciertos roles de router. Esas rutas expusieron un defecto conocido en un modelo de router específico, lo que provocó que los procesos de enrutamiento fallaran. La redirección automática redujo el riesgo de una cascada más amplia, pero produjo pérdida de paquetes durante la convergencia. Una mitigación manual causó otro período de congestión, y algunas ubicaciones de Cloud Interconnect tuvieron un impacto extendido porque la redundancia de proveedores de routers era insuficiente.

El tráfico de IP privada interregional, el tráfico de IP pública, los balanceadores de carga, los túneles VPN y la conectividad externa se vieron afectados en diferentes proporciones.

Por eso, una revisión de resiliencia debe ir más allá de "tenemos dos enlaces". La revisión debe preguntar quién posee cada ruta de fibra, qué edificio y dominio de disponibilidad de borde utiliza, qué proveedor de router y tren de software lo termina, qué Cloud Router controla sus sesiones BGP, cómo convergen las rutas, si la capacidad de conmutación por error puede soportar toda la carga y si ambos caminos dependen del mismo plano de control del proveedor. Debe observar los cambios de ruta reales y ejecutar retiros planificados, no aceptar un diagrama de topología como prueba.

La visión general de Cloud Interconnect de Google ofrece configuraciones de 99.9 y 99.99 por ciento y explica que una sola conexión no tiene SLA de tiempo de actividad. La guía de Partner Interconnect requiere cuatro adjuntos VLAN en dos metrópolis y dominios de disponibilidad de borde para su topología recomendada de 99.99 por ciento; también señala que el segmento del proveedor fuera de la red de Google necesita su propia garantía. El uso de múltiples proveedores de servicios puede mejorar la disponibilidad, pero solo si sus rutas subyacentes están realmente separadas y tienen suficiente capacidad durante la conmutación por error.

El peering dentro de la nube no es tránsito por defecto. La documentación de VPC Network Peering de Google establece que el peering es no transitivo: si la red A está emparejada con B y A también está emparejada con C, B no obtiene conectividad con C. Esa restricción puede ser un límite de contención útil, pero sorprende a los equipos que asumen que una VPC central actúa automáticamente como un concentrador de tránsito. Durante una interrupción, una ruta de recuperación improvisada puede fallar porque la topología anunciada nunca fue compatible.

Cuando se requiere tránsito, debe diseñarse explícitamente, con intercambio de rutas, política, capacidad, inspección de seguridad y comportamiento de fallo probados de punta a punta.

El tránsito de Internet merece la misma precisión. El acceso público a través de dos ISP puede seguir entrando a la red de Google a través de una ubicación de peering común. Un interconexión privada y una VPN de Internet pueden ofrecer mejor diversidad administrativa, pero ambos pueden seguir dependiendo de la red troncal de Google o de la misma identidad de cliente y DNS. Una segunda nube puede reducir la concentración de proveedores solo si la aplicación, los datos, la identidad, las herramientas de despliegue, la observabilidad y la conmutación por error de DNS pueden operar de forma independiente allí.

Un recuento de logotipos no es una arquitectura.

La multirregión es una fuerte protección contra la clase equivocada de fallo

El diseño multirregión sigue siendo valioso. Puede proteger contra un evento de energía, una pérdida de capacidad local, un fallo de hardware zonal y muchos problemas de software regionales. El error no es usar múltiples regiones; es tratar la frase como una declaración completa de independencia.

El evento de red de 2019 afectó a varias regiones porque un límite de automatización del plano de control cruzó ubicaciones físicas. El incidente de cuotas de peering de 2021 afectó la programación de red a nivel global porque el controlador relevante y los recursos de VPC tenían alcance global. El evento de Service Control de 2025 afectó a todas las regiones porque el plano de políticas era global. En cada caso, más réplicas de aplicación dentro del dominio administrativo afectado no pudieron eliminar la causa común.

La documentación de confiabilidad de Google hace una distinción útil entre el alcance de la ubicación y la confiabilidad de la aplicación. Los recursos globales pueden ser altamente resistentes a una interrupción de infraestructura regional mientras siguen siendo puntos únicos de fallo a través de la configuración. Los recursos multirregión pueden sobrevivir a la pérdida de una región pero seguir dependiendo de la identidad global, la gestión de API, el control de red o un frontend global. Los clientes necesitan un grafo de dependencias que marque tanto la geografía como la autoridad.

Ese grafo debería incluir al menos cinco capas. Primero, la ejecución: dónde se ejecutan realmente los procesos y los datos. Segundo, el control: qué API crean, enrutan, autorizan, escalan y conmutan por error esos recursos. Tercero, el acceso: qué DNS, peering, tránsito, interconexión, VPN y rutas troncales conectan a usuarios y operadores. Cuarto, la observación: dónde residen los registros, métricas, feeds de estado, paginación y soporte. Quinto, la recuperación: qué repositorios, credenciales, humanos y servicios externos se necesitan para restaurar la operación.

Una dependencia es independiente solo si el mismo evento creíble no puede deshabilitarla junto con la primaria. Dos regiones controladas por una política global inválida no son independientes para ese evento. Dos pilas de monitoreo entregadas a través del mismo sistema de identidad no son independientes para una interrupción de autenticación. Dos circuitos en el mismo software de router no son independientes para el defecto de proveedor relevante. Un servicio en caliente en otra nube no es independiente si el único control de DNS, repositorio de artefactos o inicio de sesión del operador vive en Google Cloud.

Este análisis no debería convertirse en una demanda costosa de que cada carga de trabajo pequeña opere a través de tres proveedores. Los controles deben ser proporcionales. Un sitio de información pública puede aceptar unas pocas horas de inactividad y mantener una página de estado externa. Un servicio de autorización de pagos puede necesitar capacidad preaprovisionada, tránsito independiente, monitoreo externo y un proveedor secundario probado. El acto responsable es saber qué dependencias siguen siendo comunes, valorar la consecuencia y obtener la aceptación explícita del dueño del negocio.

Cloudflare convirtió un incidente de un proveedor en una lección de dependencia para otro

El evento de junio de 2025 cruzó un límite corporativo de una manera particularmente instructiva. El propio informe de interrupción de Cloudflare dice que Workers KV dependía en parte de un proveedor de nube externo. Cuando esa dependencia falló, Workers KV dejó de estar disponible y un amplio conjunto de productos de Cloudflare que lo usaban se vieron afectados, incluidos Access, Gateway, WARP, Turnstile, Images, Stream, partes del tablero y otros servicios.

Los servicios principales de CDN y seguridad de Cloudflare no estaban uniformemente caídos, pero la dependencia hizo visible un fallo del plano de control de Google Cloud a través de productos vendidos bajo el nombre de otro proveedor.

Esto no es evidencia de que la subcontratación sea inherentemente irresponsable. Los proveedores compran servicios entre sí de manera sensata. Es evidencia de que la distancia comercial de una dependencia no reduce su consecuencia operativa. Un cliente puede creer que se ha diversificado al comprar Google Cloud para infraestructura y Cloudflare para seguridad perimetral, pero un servicio de control de Cloudflare puede depender de Google Cloud. La cadena resultante puede ser Google Cloud a Workers KV a Access al inicio de sesión del operador de un cliente.

Sin divulgación y pruebas, el cliente no puede ver que el control secundario comparte el dominio de fallo primario.

Cloudflare aceptó su parte de la responsabilidad. Su informe describió qué servicios dependían de Workers KV, señaló que el servicio principal no conmutó por error inicialmente desde la ruta de almacenamiento de terceros y esbozó el trabajo para reducir o eliminar las dependencias para productos críticos. Google sigue siendo responsable del fallo de la plataforma upstream; Cloudflare sigue siendo responsable de decidir que un servicio interno crítico pudiera depender de él sin una continuidad adecuada; el cliente final sigue siendo responsable de evaluar si el acceso a sus propios sistemas tiene una ruta de escape.

Estos deberes son concurrentes, no mutuamente excluyentes.

El reportaje contemporáneo de la Associated Press registró una interrupción visible en servicios en línea populares y decenas de miles de informes de usuarios. Dicho reportaje es útil para demostrar el alcance público, pero los recuentos de informes de interrupción no son un censo de personas afectadas, solicitudes o pérdidas financieras. La evidencia más sólida proviene de los informes técnicos de los proveedores y de los datos de transacciones de los clientes.

La rendición de cuentas debe resistir tanto la subestimación como el espectáculo: una cascada de dependencias amplia importa incluso cuando no hay un total de pérdida global preciso disponible.

Por lo tanto, los contratos y las revisiones de arquitectura deben pedir a los proveedores que identifiquen dependencias materiales de cuarto nivel para el control, la identidad, la configuración, el estado y las funciones de recuperación. Deben especificar los deberes de notificación cuando un evento upstream es responsable, conservar los registros que permitan a los clientes conciliar el impacto y definir si el proveedor tiene una alternativa probada.

El cliente puede no recibir un mapa completo de proveedores por razones de seguridad y comerciales, pero debe recibir suficiente seguridad para comprender la concentración por nube, plataforma de identidad, operador de red y plano de control geográfico.

Un crédito de SLA no demuestra que la dependencia sea aceptable

Los acuerdos de nivel de servicio son útiles porque definen un compromiso medible y un remedio. No son una evaluación de riesgos completa. Un porcentaje de tiempo de actividad mensual promedia el tiempo y a menudo se aplica a un producto específico o topología configurada. Puede excluir la configuración del cliente, segmentos de terceros, cuotas, funciones de vista previa o fallos fuera del servicio cubierto. El remedio suele ser un crédito contra gastos futuros, no una compensación por ingresos perdidos, mano de obra de emergencia, exposición regulatoria o daño a los usuarios del cliente.

El SLA de Cloud Interconnect actual, por ejemplo, diferencia las topologías de nivel de producción de las conexiones individuales y requiere evidencia del cliente para las reclamaciones. Ese marco puede fomentar una topología sólida, pero no puede decirle a un consejo directivo si una pérdida de cuatro horas de acceso híbrido es tolerable. Tampoco un SLA específico del producto describe el fallo correlacionado entre la API utilizada para cambiar un servicio, el monitoreo utilizado para observarlo y el canal de soporte utilizado para reportarlo.

El cliente necesita un objetivo de nivel de servicio para su propio recorrido de usuario. Ese objetivo debe incluir los productos en la nube, las rutas de red, los servicios internos y los proveedores necesarios para completar el recorrido. Debe medir tanto el servicio en estado estable como las acciones de recuperación. Un flujo de pago que se mantiene activo pero no puede agregar capacidad puede estar saludable ahora y en riesgo inmediato. Una base de datos que sirve lecturas pero no puede promover una réplica puede tener capacidad de recuperación degradada incluso antes de que los usuarios vean errores.

Los términos de responsabilidad y crédito de Google son asignaciones legales, no evidencia de ingeniería. Por el contrario, una disculpa pública de un proveedor no es prueba de negligencia ni una admisión legal. Este artículo asigna responsabilidad operativa y de gobernanza basada en el control: quién diseñó la ruta de propagación, quién aceptó la dependencia, quién pudo probarla y quién debe verificar la remediación. La responsabilidad legal depende del contrato, la jurisdicción, los hechos y la adjudicación fuera del alcance de un informe técnico de incidente.

Por lo tanto, los consejos directivos deben solicitar una exposición cuantificada más allá del tiempo de actividad del proveedor. ¿Cuántos ingresos o servicios públicos dependen de una operación del plano de control? ¿Cuánto tiempo pueden servir los recursos ya en ejecución sin escalar o sin credenciales? ¿Cuál es el tiempo para mover a los usuarios a través de una ruta de tránsito alternativa? ¿Qué recuperaciones requieren el proveedor fallido? ¿Qué evidencia existe del último ejercicio? Un crédito de servicio pertenece al registro financiero; nunca debe confundirse con la continuidad.

La lista de remediación de Google es creíble solo cuando se convierte en evidencia

El informe de incidente de 2025 contiene un conjunto sólido de compromisos. Google congeló los cambios de Service Control y los envíos manuales de políticas después de la recuperación.

Dijo que modularizaría el servicio y fail open cuando corresponda, auditaría los sistemas que consumen datos replicados globalmente, propagaría dichos datos de forma incremental con tiempo de validación, requeriría que los binarios críticos estén protegidos por feature flags deshabilitados por defecto, mejoraría el análisis estático y las pruebas de datos inválidos, auditaría el backoff exponencial aleatorio, mejoraría las comunicaciones externas y mantendría el monitoreo y la comunicación disponibles cuando Google Cloud esté inactivo.

Esas acciones coinciden con la cadena de fallo observada de manera inusualmente precisa. El problema restante es la garantía. Una promesa puede cerrar una acción de autopsia en un sistema de seguimiento sin demostrar que el riesgo ha disminuido en producción. Google debería publicar el estado de finalización, el método de validación y los límites residuales para las acciones de mayor impacto, incluso si la arquitectura detallada permanece confidencial.

Para la seguridad de políticas globales, la evidencia podría incluir el porcentaje de consumidores críticos de políticas detrás de una activación por fases; tasas de rechazo automatizadas para datos candidatos malformados; intervalos mínimos de observación antes de la autoridad global; y ejercicios exitosos en los que un objeto malo se detiene en un cohorte. Para el aislamiento de fallos, podría incluir pruebas que muestren que un módulo de cuota puede fallar mientras las comprobaciones de API no relacionadas continúan y que las decisiones sensibles a la seguridad mantienen su límite previsto.

Para la recuperación, Google debería mostrar límites de reinicio de flota, conformidad de backoff, capacidad reservada del almacén de datos y resultados de pruebas de carga para la recuperación regional simultánea. Para la comunicación, debería publicar el tiempo desde el primer impacto al cliente hasta la detección interna, el primer aviso público, la primera declaración de impacto acotado y la disponibilidad de la ruta de estado independiente durante los ejercicios. Para el aprendizaje institucional, debería informar si se encontraron y remediaron consumidores globales similares fuera de Service Control.

Incidentes anteriores agudizan la necesidad de este seguimiento. Después de 2019, Google prometió una operación de red fail-static más larga, configuración de control persistente, herramientas de emergencia robustas y pruebas de catástrofe ampliadas. Después de febrero de 2021, prometió una mayor regionalización de los componentes globales del plano de control de red, pausas automáticas para migraciones y una mejor resiliencia del plano de datos cuando los controladores no respondían. Después de marzo de 2021, prometió dominios funcionales para la aplicación de políticas de rutas y mejores pruebas de compilación de routers.

Cada compromiso puede haberse completado dentro de su propio programa; el registro público no proporciona una vista de garantía continua que muestre cómo ha cambiado el riesgo de modo común de la plataforma a lo largo del tiempo.

El libro de SRE de Google describe las autopsias como un sistema de aprendizaje, con elementos de acción vinculados a las causas y sin reducir los incidentes complejos a la culpa individual. El mismo principio respalda la rendición de cuentas externa. El propósito de publicar evidencia no es exponer a un empleado o invitar a los clientes a ejecutar la red de Google. Es permitir que los clientes distingan una solución temporal de un control duradero, vean lo que queda abierto y decidan si su propio tratamiento de riesgos es adecuado.

Una revisión independiente agregaría valor para los controles más globales. Podría muestrear documentos de diseño, registros de despliegue, resultados de inyección de fallos, independencia del botón de emergencia y cierre de acciones. El resultado público podría declarar el alcance, las excepciones y las conclusiones sin revelar internos explotables. La autoevaluación proporciona profundidad técnica; la garantía independiente proporciona confianza de que los criterios de cierre no fueron definidos únicamente por el equipo responsable de la entrega.

Qué deben probar los clientes antes del próximo incidente global

Ningún cliente puede feature-flag el binario interno de Service Control de Google o cambiar cómo se replican sus tablas de políticas. Los consejos que simplemente dicen a los clientes que "arquitecten mejor" después de una interrupción generalizada del proveedor transfieren la responsabilidad de manera injusta. Aún así, los clientes toman decisiones trascendentales sobre cuánta autoridad tiene una interrupción del proveedor sobre su negocio.

Comience con la ruta de servicio. Identifique qué transacciones de usuario continúan si todas las API de gestión de Google Cloud no están disponibles durante tres horas. Pruebe con nuevos despliegues pausados, autoscaling congelado, cambios de IAM no disponibles, modificaciones de balanceador de carga bloqueadas y soporte inaccesible. Mida cuándo la capacidad, las credenciales, los certificados, las colas o los trabajos programados se convierten en el factor limitante.

El resultado a menudo será una curva en lugar de una respuesta binaria: el servicio continúa con la carga actual durante un período, luego se degrada a medida que se acumulan las acciones de control rutinarias.

A continuación, pruebe el acceso del operador. Mantenga credenciales de escape cuya recuperación y verificación no requieran la ruta de identidad de la nube primaria. Mantenga un espacio de trabajo de incidentes mínimo, una lista de contactos, manuales, diagramas de arquitectura y un publicador de estado fuera de Google Cloud. Asegúrese de que el equipo pueda llegar a los operadores de red y proveedores críticos sin la suite de colaboración corporativa si esa suite comparte la identidad de Google. Audite cada herramienta de emergencia en busca de dependencias ocultas de DNS, correo electrónico, inicio de sesión único y secretos.

Luego pruebe las rutas de red. Retire cada sesión BGP y adjunto de interconexión durante un ejercicio controlado. Confirme que el tráfico se mueve a través de la metrópoli y el proveedor previstos, mida la pérdida de convergencia y verifique que la alternativa tenga capacidad de carga completa. Verifique que el respaldo de Internet público no esté bloqueado por firewalls, enrutamiento o suposiciones de direcciones de origen. Para VPC peering, demuestre las rutas importadas y exportadas exactas y no asuma transitividad. Para tránsito multinube, pruebe la consistencia de datos y la identidad, así como los paquetes.

Preaprovisione lo que no se pueda crear durante una interrupción del plano de control. Esto puede incluir balanceadores de carga regionales, registros DNS, clústeres secundarios, bases de datos en espera, cuotas, cuentas de servicio, artefactos y túneles de red. Mantenga los cambios lo suficientemente pequeños como para que una configuración de último valor conocido siga siendo utilizable. Practique un modo degradado que elimine características no esenciales en lugar de emitir una ráfaga de reintentos o solicitudes de escalado a un proveedor afectado.

Finalmente, concilie después del ejercicio. Determine qué transacciones fallaron, cuáles se reintentaron, cuáles se duplicaron, cuáles permanecieron en cola y qué clientes necesitan aviso. La restauración del proveedor no garantiza la corrección de la aplicación. Los objetivos de recuperación deben incluir la limpieza del trabajo atrasado y la validación de datos, no solo una verificación de salud HTTP.

Para organizaciones más pequeñas, la versión proporcional puede ser modesta: una verificación de tiempo de actividad externa, una página de estado en otro proveedor, detalles de contacto exportados y manuales, copias de seguridad probadas, procedimientos manuales conocidos y una decisión documentada sobre si el costo multinube está justificado. La rendición de cuentas no es sinónimo de arquitectura máxima. Es la capacidad de demostrar que una decisión de riesgo consciente reemplazó una dependencia accidental.

Una tarjeta de puntuación para la rendición de cuentas del plano de control y la red

Un consejo directivo, regulador o cliente importante no necesita código fuente propietario para hacer preguntas precisas. Necesita evidencia que se corresponda con los modos de fallo observados.

La tarjeta de puntuación debe leerse en todas las filas. Un feature flag sin estado independiente no es suficiente. Cuatro adjuntos de interconexión sin diversidad de proveedor y router pueden no ser suficientes. Una aplicación multirregión sin recuperación preaprovisionada puede seguir dependiendo del controlador global. La confiabilidad proviene de la composición de controles y de la evidencia de que la composición funciona bajo fallo.

La señal perdurable es la velocidad de la autoridad compartida

Las plataformas en la nube crean valor al centralizar decisiones. Una política puede gobernar miles de proyectos. Una red puede transportar tráfico entre continentes. Una API puede crear infraestructura en segundos. El mismo apalancamiento determina el radio de explosión del error.

Por lo tanto, la interrupción de junio de 2025 no se recuerda mejor como un puntero nulo. Los punteros nulos son defectos de software ordinarios. Lo que hizo que este fuera globalmente trascendental fue que el código inactivo, la política inválida, la replicación rápida, los lectores regionales, el reinicio sincronizado, el monitoreo compartido y los proveedores posteriores formaron una cadena. El sistema estaba distribuido, pero la autoridad no estaba suficientemente particionada.

La respuesta de Google identificó los temas correctos: propagación incremental, feature flags, fallo modular, backoff y comunicación independiente. Los clientes deben esperar pruebas de que esos cambios funcionan, siendo honestos sobre los riesgos que aún poseen. Una carga de trabajo puede estar distribuida en regiones y seguir dependiendo de una decisión global. Un negocio puede comprar dos redes y seguir usando una ruta hacia el destino. Una página de estado puede ser pública y seguir viviendo dentro del incidente.

El estándar de rendición de cuentas adecuado no es que una nube global nunca deba fallar. Es que la autoridad global no debe moverse más rápido que los controles que la validan; que los sistemas regionales deben poder rechazar o sobrevivir a un estado común inseguro; que las rutas de red y recuperación deben ser independientes en la operación, no solo en los nombres; y que los clientes deben poder ver el fallo mientras aún hay tiempo para actuar. En un plano de control de nube, la velocidad es poder. La resiliencia comienza por poner límites a dónde puede viajar ese poder.