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 a los almacenes de datos regionales de Service Control de Google Cloud casi simultáneamente. Una ruta de código implementada previamente carecía tanto de un manejo de errores adecuado como de protección mediante indicadores de funcionalidad; el procesamiento de la política provocó que los binarios de Service Control fallaran en todas las regiones. Numerosas API de Google Cloud, Google Workspace y Google Security Operations devolvieron errores 503. Los recursos de streaming y de infraestructura como servicio existentes pudieron en su mayoría seguir funcionando, pero las rutas de administración y API necesarias para inspeccionar, modificar, escalar o recuperar servicios se vieron gravemente afectadas.
• El error inmediato fue puntual, pero el fallo de responsabilidad fue arquitectónico. Google tenía instancias de servicio distribuidas regionalmente y un despliegue binario por etapas, pero la política desencadenante se replicó globalmente en cuestión de segundos. El mecanismo de desactivación eludió así el aprendizaje regional que se suponía que el despliegue debía proporcionar. La recuperación generó entonces un efecto de manada contra Spanner en las regiones más grandes porque las tareas que se reiniciaban carecían de una retirada exponencial aleatorizada. La infraestructura pública de Cloud Service Health también dependía del entorno afectado, lo que retrasó la primera notificación 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 activado durante cambios en las cuotas de peering bloqueó la programación de red global. En marzo de 2021, rutas no válidas expusieron un defecto conocido de un proveedor y algunas ubicaciones de Cloud Interconnect carecían de suficiente diversidad de proveedores de enrutadores. Estos no son un único defecto de software recurrente; son pruebas repetidas de contención de modo 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 a prueba de fallos (fail-static o fail-open) cuando sea seguro, mantener las comunicaciones de incidentes independientes y demostrar que la corrección prometida se ha completado. Los clientes no pueden reparar esos controles de la plataforma, pero siguen siendo responsables de identificar qué operaciones dependen de las API del plano de control, monitorizar desde fuera del proveedor, probar modos degradados y adquirir diversidad de rutas y proveedores en lugar de contar enlaces nominales. El despliegue multirregional reduce muchos riesgos; pero no evade por sí mismo un plano de políticas global ni 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 diseñadas para 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 API está dentro de la cuota y hacia dónde debe ir el tráfico. Las aplicaciones pueden seguir procesando el 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 a la vez menos que un apagón total de infraestructura y más que un problema API ordinario. Elinforme completo del incidente de Service Controlde Google dice que los recursos de streaming y de infraestructura como servicio existentes no se vieron directamente afectados por el fallo principal. Sin embargo, una larga lista de productos experimentó errores de API externa, incluidos Identity and Access Management, Cloud Storage, BigQuery, Cloud Run, Cloud DNS, Cloud Load Balancing, Hybrid Connectivity, Network Connectivity Center, Spanner, productos de monitorización, la consola y múltiples servicios de IA. La capacidad de seguir sirviendo desde el estado ya programado sobrevivió mejor que la capacidad de pedir a la plataforma que decidiera o cambiara algo.

El mecanismo fue inusualmente claro en el informe público de Google. El 29 de mayo, se lanzó una nueva función de Service Control para verificaciones adicionales de políticas de cuotas región por región. El despliegue binario se completó sin exponer la falla porque la ruta de código que fallaba requería un cambio de política posterior. La función no estaba protegida por un indicador que pudiera habilitarla gradualmente para proyectos seleccionados, y su manejo de datos no válidos permitía que un valor nulo hiciera fallar el proceso. El 12 de junio alrededor de las 10:45 a.m. hora del Pacífico, se escribió una política de cuotas que contenía campos en blanco no intencionados en las tablas regionales de Spanner utilizadas por Service Control. Dado que los metadatos de cuotas se diseñaron para moverse globalmente con consistencia casi inmediata, los datos aparecieron en todas las regiones en cuestión de 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 faltara redundancia. Existían instancias de servicio regionales y almacenes de datos regionales. Tampoco fue simplemente un caso de que un ingeniero presionara el botón equivocado. Un sistema de producción aceptó datos de políticas estructuralmente inseguros, una ruta crítica carecía de manejo de errores defensivo, una función llegó a todas las regiones sin una ruta de activación controlada de forma independiente, y el sistema de propagación era más rápido que el sistema de validación. La arquitectura convirtió un objeto lógico no válido en un evento global.

Llamar al incidente una interrupción por política malformada es preciso pero incompleto. La política fue el desencadenante. Las causas más amplias fueron la cantidad de autoridad asociada a ella y la ausencia de contención entre la aceptación, replicación, interpretación y servicio. La pregunta responsable no es simplemente por qué existía un campo en blanco. Es por qué una sola política pudo convertirse en un estado de fallo ejecutable en todas partes antes de que una región, una cohorte de proyecto o un validador sombra tuviera tiempo de rechazarla.

Un desencadenante breve 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.

La recuperación más lenta en us-central1 es central para el análisis de riesgos. A medida que las tareas de Service Control se reiniciaban, ejercían una demanda concentrada sobre la tabla de Spanner subyacente. Las tareas carecían de la retirada exponencial aleatorizada necesaria para evitar reintentos sincronizados. Google tuvo que limitar la creación de tareas y enrutar 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. El capítulo sobreabordar los fallos en cascadaexplica cómo los reintentos y reinicios pueden mantener un backend sobrecargado y cómo la retirada exponencial aleatorizada, la degradación elegante y el desprendimiento de carga controlado 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 esa retirada. La importancia no es que Google no haya seguido una frase de un libro. Es que una clase conocida de riesgos de sistemas distribuidos permanecía en un servicio crítico cuya población de reinicio era regional y cuyos datos de respaldo eran globales.

Por lo tanto, los planes de recuperación deben evaluarse como arquitecturas de producción, no como párrafos de un manual. Un sistema que puede desactivarse de manera segura necesita un mecanismo de apagado cuyas propias dependencias se comprendan. Una flota que puede fallar junta necesita un gobernador de reinicio, control de admisión, fluctuación (jitter) y una tasa de recuperación máxima probada. Un almacén de datos del 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 observarse antes del incidente, con evidencia de que no trasladará la sobrecarga a otro lugar.

La cola larga también importa para la comunicación con los clientes. El informe preliminar de Google describió un evento global de tres horas, mientras que la página de incidentes continuó enumerando la recuperación de productos hasta las 6:18 p.m. Algunos productos tenían trabajos atrasados después de que el servicio API volviera. 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 comienzo de la conciliación del cliente, no la prueba de que cada proceso empresarial esté íntegro.

El despliegue regional no generó 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 de activación siguió un mecanismo de distribución diferente, optimizado para hacer que el estado de las cuotas fuera 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 consecuente. Los equipos a menudo revisan los binarios, la configuración, el esquema, la política y los datos como objetos separados. Sin embargo, el comportamiento en producción surge de su combinación. Una función inactiva puede pasar todas las puertas regionales hasta que un valor de configuración la activa en todas partes. Un esquema puede ser válido para el escritor pero no para un lector más antiguo. Una política replicada globalmente puede hacer que los canarios regionales sean irrelevantes. Un botón rojo puede existir pero aún depender del plano de control averiado para surtir efecto.

La guía de infraestructura actual de Google reconoce este riesgo. Laguía de bloques de construcción de fiabilidaddice que los recursos globales son resistentes a incidentes de infraestructura zonales y regionales, pero pueden convertirse en puntos únicos de fallo cuando un error de configuración crítico tiene alcance global. Recomienda un control cuidadoso de los cambios y, para cargas de trabajo excepcionalmente exigentes, retrocesos regionales de defensa en profundidad. Laguía de gestión y monitorizacióncomplementaria aconseja el 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 fiabilidad contra el fallo físico y un riesgo de radio de explosión para un estado lógico incorrecto.

Una corrección completa necesita un modelo de publicación 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 retroceso y los controles de emergencia deben tratarse como una sola superficie de cambio. Los nuevos lectores deben aceptar de forma segura valores antiguos, nuevos, faltantes y corruptos. Las nuevas políticas deben leerse en modo sombra antes de ser autoritativas. La activación debe comenzar con proyectos internos o una región delimitada y detenerse automáticamente ante umbrales de fallos, latencia o errores. La replicación debe ser lo suficientemente incremental como para preservar un intervalo de detección, incluso si el estado empresarial final debe ser globalmente consistente.

Eso no significa que todas las políticas globales deban volverse lentamente inconsistentes. 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 frente al tráfico similar al de producción, y volverse efectiva solo después de que las comprobaciones tengan éxito. Las regiones pueden conservar una política conocida como buena cuando un nuevo objeto no es válido. Los lectores pueden distinguir la corrupción de una denegación legítima. La consistencia global no es incompatible con la seguridad escalonada; simplemente requiere más que una replicación rápida.

El fallo abierto (fail open) es una decisión empresarial 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, permitiendo que las solicitudes API continuaran 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 temporalmente permisivo puede ser más seguro que rechazar cada solicitud API del cliente. El proveedor puede conciliar el uso más tarde, limitar la exposición por proyecto y preservar la disponibilidad principal. 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 delimitada de políticas recientes podría ser más segura que la denegación universal o el permiso universal. El comportamiento degradado correcto depende del propósito del control, la frescura del estado de confianza, la reversibilidad de las acciones y el potencial de fraude, pérdida de datos o gasto descontrolado.

Laarquitectura de Service Infrastructurede Google separa los planos de gestión, control y datos, mostrando la amplitud de las funciones de la plataforma: autenticación, autorización, cuotas, limitación de velocidad, auditoría, facturación, registro y monitorización. Esa amplitud es precisamente la razón por la que importa el comportamiento modular ante fallos. Un solo 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 estado bueno conocido? ¿Cuáles pueden fallar temporalmente de forma abierta? ¿Cuáles fallan cerradas porque la consecuencia de seguridad es dominante? ¿Qué límites estrictos permanecen durante el servicio degradado? ¿Cómo se concilia 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 no válida de una denegación de cuota legítima del cliente?

Esto también cambia las pruebas. No basta con confirmar que una política buena devuelve la respuesta correcta. 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 ser omitido sin omitir 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 estaba caída. Algunos clientes también ejecutaban la monitorización en Google Cloud, por lo que tanto el servicio como su evidencia del servicio fallaron juntos. La interrupción afectó no solo a la producción sino al 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 carecía de precedentes. Durante la interrupción global de autenticación de Google el 14 de diciembre de 2020, elinforme del incidentedice que las herramientas internas de Cloud Support se vieron afectadas, los clientes no podían crear ni ver casos de soporte en la consola y la comunicación del panel se retrasó hasta después de que terminara el impacto principal. Ese evento se originó por la gestión automatizada de cuotas que redujo la capacidad del sistema de identidad central. Las configuraciones del plano de datos de red existentes 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, la monitorización y la comunicación pueden compartir el destino de los servicios que se supone que deben diagnosticar.

Google ha documentado desde entonces un modelo de comunicación más explícito. Suguía de comunicación de incidentesdistingue Personalized Service Health, que utiliza el contexto del proyecto y puede integrarse con alertas y API, del panel público de Cloud Service Health. La misma guía reconoce que Personalized Service Health depende de servicios como IAM y recomienda un retroceso al panel público y a la fuente RSS cuando los sistemas personalizados no estén disponibles. Ese es un consejo sensato, 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 accesible externamente, alimentada y administrada de forma independiente, 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 monitorización principal ni el servicio de control bajo investigación. El primer aviso no necesita contener la 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 se ven afectadas, las soluciones disponibles y la hora de la próxima actualización.

Los clientes tienen una obligación paralela. Laguía de integración de Personalized Service Healthde Google dice explícitamente que el servicio no puede saber si cada producto es crítico para una aplicación en particular o si la aplicación continúa cuando falla una dependencia. Los operadores necesitan sus propias comprobaciones de recorrido del usuario, métricas de aplicación, telemetría de red y alarmas de procesos empresariales. 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 propios despliegues, realizar retrocesos arriesgados, escalar en 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 descendentes a publicar especulaciones. Por lo tanto, la disponibilidad de la comunicación es un control de riesgos con objetivos medibles de detección y publicación, no una cortesía añadida después de que comience el trabajo de ingeniería.

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

La afirmación del informe de 2025 de que los recursos de streaming y de infraestructura como servicio existentes no se vieron afectados debe leerse con atención. 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 permanecieran activas.

Los sistemas en la nube son dinámicos. Los autoescaladores 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 se rotan. Los servicios sin servidor 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 empresarial que lo rodea pierde la capacidad de adaptarse.

La interrupción de red de febrero de 2021 hace concreto ese límite. Elinforme de incidente sobre el fallo de programación de redde Google dice que se activó un error latente cuando el plano de control de red global reprocesó operaciones asociadas con cambios en las cuotas de peering. Las máquinas virtuales y los puntos finales de red nuevos, actualizados, eliminados o migrados no pudieron programarse correctamente, mientras que muchas instancias no modificadas continuaron funcionando. Google pausó las migraciones en vivo a nivel global; alrededor de 1.000 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 a tasas muy altas. Un servidor existente saludable no ayudó a un grupo de autoescalado que necesitaba un nuevo servidor en red.

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

Laguía de arquitectura de recuperación ante desastresde Google distingue las acciones del plano de datos de las actualizaciones del plano de control y explica la resistencia específica del servicio. Suguía de diseño de infraestructura fiablerecomienda evitar o minimizar las dependencias de acciones no pertenecientes al plano de datos durante los fallos, como la creación de un nuevo balanceador de carga. La lección práctica es aprovisionar previamente la ruta de recuperación. La capacidad puede estar caliente en lugar de ser hipotética. Los puntos finales regionales pueden existir antes de que falle el frontend global. 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 debe poder nombrar la API, el proveedor de identidad, la ruta de red, el resolvedor DNS, el almacén de artefactos, el secreto y la aprobación humana que requiere. Luego, el ejercicio debe eliminar esas dependencias una a una. Un plan que solo tiene éxito mientras la consola, IAM, Service Control, la programación de red global y la región principal están todos en buen estado 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 mismo 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. Elinforme de incidente de reddescribió múltiples fallos que se combinaron en una interrupción importante: los trabajos del plano de control de red se configuraron para detenerse por 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 continuó inicialmente en modo "fail static" sin su plano de control. Varios minutos después, se retiraron las rutas BGP entre las ubicaciones afectadas, reduciendo la capacidad de la red y haciendo que algunas regiones fueran inaccesibles. 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, prolongando 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 implicaron un período de seguridad que resultó demasiado corto o demasiado dependiente: enrutamiento fail-static en 2019 y una omisión de botón rojo 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íticas y control de API. La responsabilidad no debe reducirlos a "Google tuvo otra interrupción". El valor de la comparación es comprobar si la organización descubre repetidamente que componentes nominalmente independientes todavía comparten un dominio administrativo, un mecanismo de propagación, una herramienta de emergencia o una dependencia de recuperación.

Los compromisos de Google en 2019 incluyeron rechazar las solicitudes de mantenimiento implicadas, conservar la configuración del plano de control local, extender la duración de la operación de red en modo fail-static, reforzar las herramientas de emergencia y ampliar las pruebas de recuperación ante desastres. La cuestión de responsabilidad actual no es si esas acciones habrían evitado 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, conservar el estado seguro, mantener los controles de emergencia fuera del dominio de fallo principal y probar fallos catastróficos correlacionados. Un programa de corrección solo tiene valor institucional cuando su patrón de control viaja más allá del equipo que redactó el análisis post mortem.

La diversidad de peering y tránsito se trata del destino, no del recuento de circuitos

La disponibilidad de la nube llega a los clientes a través de las redes. Una carga de trabajo puede estar en buen estado dentro de una región mientras los usuarios no pueden acceder a ella porque un borde, una ruta troncal, una sesión de peering, un proveedor de tránsito, una ruta de DNS o una interconexión híbrida ha fallado. A la inversa, dos circuitos de acceso pueden parecer diversos en una orden de compra mientras convergen en una misma área metropolitana, un mismo proveedor, un modelo de enrutador, un mismo borde de Google o un sistema de control.

Elinforme de incidente de la red troncaldel 17 de marzo de 2021 de Google ilustra esa diferencia. La conexión de nuevos enrutadores cambió qué rutas recibían ciertos roles de enrutador. Esas rutas expusieron un defecto conocido en un modelo de enrutador específico, provocando 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 prolongado porque la redundancia de proveedores de enrutadores era insuficiente. El tráfico IP privado interregional, el tráfico IP público, los balanceadores de carga, los túneles VPN y la conectividad externa se vieron afectados en diferentes proporciones.

Es por esto que una revisión de resiliencia debe ir más allá del "tenemos dos enlaces". La revisión debe preguntar quién es propietario de cada ruta de fibra, qué edificio y dominio de disponibilidad de borde utiliza, qué proveedor de enrutador y tren de software lo termina, qué Cloud Router controla sus sesiones BGP, cómo reconvergen las rutas, si la capacidad de conmutación por error puede soportar toda la carga y si ambas rutas dependen del mismo plano de control del proveedor. Debe observar los cambios de ruta reales y realizar retiradas planificadas, no aceptar un diagrama de topología como prueba.

Ladescripción general de Cloud Interconnectde Google ofrece configuraciones del 99,9% y 99,99% y explica que una sola conexión no tiene SLA de tiempo de actividad. Laguía de Partner Interconnectrequiere cuatro conexiones VLAN en dos áreas metropolitanas y dominios de disponibilidad de borde para su topología recomendada del 99,99%; 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. Ladocumentación de VPC Network Peeringde Google establece que el peering no es transitivo: si la red A se empareja con B y A también se empareja con C, B no obtiene por ello 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íticas, capacidad, inspección de seguridad y comportamiento de fallos probado de extremo a extremo.

El tránsito de internet merece la misma precisión. El acceso público a través de dos ISP puede seguir entrando en la red de Google a través de una ubicación de peering común. Una interconexión privada y una VPN de internet pueden ofrecer una mejor diversidad administrativa, pero ambas pueden seguir dependiendo de la red troncal de Google o de la misma identidad de cliente y DNS. Una segunda nube solo puede reducir la concentración del proveedor si la aplicación, los datos, la identidad, las herramientas de despliegue, la observabilidad y la conmutación por error de DNS pueden funcionar allí de forma independiente. 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 utilizar 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 globalmente 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 aplicaciones dentro del dominio administrativo afectado no pudieron eliminar la causa común.

La documentación de fiabilidad de Google hace una distinción útil entre el alcance de la ubicación y la fiabilidad de la aplicación. Los recursos globales pueden ser altamente resistentes a una interrupción de infraestructura regional y, al mismo tiempo, convertirse en 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 siguen dependiendo de la identidad global, la gestión de API, el control de red o un frontend global. Los clientes necesitan un gráfico de dependencias que marque tanto la geografía como la autoridad.

Ese gráfico debe incluir al menos cinco capas. La primera es la ejecución: dónde se ejecutan realmente los procesos y los datos. La segunda es el control: qué API crean, enrutan, autorizan, escalan y conmutan por error esos recursos. La tercera es el acceso: qué rutas de DNS, peering, tránsito, interconexión, VPN y red troncal conectan a los usuarios y operadores. La cuarta es la observación: dónde residen los registros, métricas, fuentes de estado, paginación y soporte. La quinta es 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 no válida no son independientes para ese evento. Dos pilas de monitorización 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 enrutador no son independientes para el defecto del proveedor correspondiente. Un servicio caliente en otra nube no es independiente si el único control de DNS, repositorio de artefactos o inicio de sesión del operador reside en Google Cloud.

Este análisis no debe convertirse en una exigencia costosa de que cada pequeña carga de trabajo opere a través de tres proveedores. Los controles deben ser proporcionados. 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 aprovisionada previamente, tránsito independiente, monitorización externa 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 propietario 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. Elinforme de la propia interrupción de Cloudflaredice 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 utilizaban se vieron afectados, incluidos Access, Gateway, WARP, Turnstile, Images, Stream, partes del panel de control y otros servicios. Los servicios principales de CDN y seguridad de Cloudflare no cayeron uniformemente, pero la dependencia hizo que un fallo del plano de control de Google Cloud fuera visible a través de productos vendidos bajo el nombre de otro proveedor.

Esto no es evidencia de que la externalización sea inherentemente irresponsable. Los proveedores compran servicios unos a otros con sensatez. Es evidencia de que la distancia comercial de una dependencia no reduce su consecuencia operativa. Un cliente puede creer que se ha diversificado comprando 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 → Workers KV → Access → inicio de sesión del operador del cliente. Sin divulgación y pruebas, el cliente no puede ver que el control secundario comparte el dominio de fallo principal.

Cloudflare aceptó su parte de 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 dependencias para productos críticos. Google sigue siendo responsable del fallo de la plataforma ascendente; Cloudflare sigue siendo responsable de decidir que un servicio interno crítico pudiera depender de ella sin una continuidad adecuada; el cliente final sigue siendo responsable de evaluar si el acceso a sus propios sistemas tiene una ruta de acceso de emergencia. Estos deberes son concurrentes, no mutuamente excluyentes.

Lacobertura de Associated Presscontemporánea registró interrupciones visibles en los servicios en línea populares y decenas de miles de informes de usuarios. Dichos informes son útiles 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 responsabilidad debe resistir tanto la subestimación como el espectáculo: una cascada de dependencia amplia importa incluso cuando no se dispone de un total preciso de pérdidas globales.

Por lo tanto, los contratos y las revisiones de arquitectura deben pedir a los proveedores que identifiquen las dependencias materiales de cuartos para las funciones de control, identidad, configuración, estado y recuperación. Deben especificar los deberes de notificación cuando un evento ascendente es responsable, conservar registros que permitan a los clientes conciliar el impacto y definir si el proveedor tiene una alternativa probada. Es posible que el cliente no reciba un mapa completo de proveedores por razones de seguridad y comerciales, pero debe recibir la garantía suficiente 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 prueba que la dependencia sea aceptable

Los acuerdos de nivel de servicio (SLA) 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 a una topología configurada. Puede excluir la configuración del cliente, segmentos de terceros, cuotas, funciones en 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 actualSLA de Cloud Interconnect, por ejemplo, diferencia las topologías de nivel de producción de las conexiones únicas y requiere evidencia del cliente para las reclamaciones. Ese marco puede fomentar una topología sólida, pero no puede decirle a una junta directiva 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, la monitorización utilizada para observarlo y el canal de soporte utilizado para informarlo.

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 en buen estado ahora y en riesgo inmediato. Una base de datos que sirve lecturas pero no puede promover una réplica puede tener una 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 podría probarlo y quién debe verificar la correcció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 incidentes.

Por lo tanto, las juntas directivas deben solicitar una exposición cuantificada más allá del tiempo de actividad del proveedor. ¿Cuántos ingresos o servicio público dependen de una operación del plano de control? ¿Cuánto tiempo pueden servir los recursos ya en ejecución sin escalado ni credenciales? ¿Cuál es el tiempo para mover a los usuarios a través de una ruta de tránsito alternativa? ¿Qué recuperaciones requieren al 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 corrección de Google solo es creíble cuando se convierte en evidencia

El informe del incidente de 2025 contiene un sólido conjunto 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 fallaría abiertamente cuando fuera apropiado, auditaría los sistemas que consumen datos replicados globalmente, propagaría dichos datos de forma incremental con tiempo de validación, exigiría que los binarios críticos estuvieran protegidos por indicadores de funcionalidad desactivados por defecto, mejoraría el análisis estático y las pruebas de datos no válidos, auditaría la retirada exponencial aleatorizada, mejoraría las comunicaciones externas y mantendría la monitorización y la comunicación disponibles cuando Google Cloud esté caído.

Esas acciones coinciden inusualmente bien con la cadena de fallos observada. El problema restante es la garantía. Una promesa puede cerrar una acción post mortem 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 sigue siendo confidencial.

Para la seguridad de las políticas globales, la evidencia podría incluir el porcentaje de consumidores de políticas críticas detrás de la activación escalonada; 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 incorrecto se detiene en una cohorte. Para el aislamiento de fallos, podría incluir pruebas que muestren que un módulo de cuota puede fallar mientras continúan las comprobaciones de API no relacionadas y que las decisiones sensibles a la seguridad conservan su límite previsto.

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

Los incidentes anteriores agudizan la necesidad de este seguimiento. Después de 2019, Google prometió una operación de red en modo fail-static más prolongada, configuración de control persistente, herramientas de emergencia robustas y pruebas de catástrofes ampliadas. Después de febrero de 2021, prometió una mayor regionalización de los componentes de control de red global, pausas automáticas para las 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 ruta y pruebas mejoradas de compilación de enrutadores. Es posible que cada compromiso se haya completado dentro de su propio programa; el registro público no proporciona una vista continua de garantía que muestre cómo cambió el riesgo de modo común de la plataforma con el tiempo.

El libro SRE de Google describelos análisis post mortem 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 responsabilidad 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 rojo y cierre de acciones. El resultado público podría indicar el alcance, las excepciones y las conclusiones sin revelar elementos internos explotables. La autoevaluación proporciona profundidad técnica; la garantía independiente proporciona confianza en que los criterios de cierre no fueron definidos únicamente por el equipo responsable de la entrega.

Lo que los clientes deberían probar antes del próximo incidente global

Ningún cliente puede activar por indicador el binario interno de Service Control de Google o cambiar la forma en que se replican sus tablas de políticas. El consejo que simplemente dice a los clientes que "diseñen mejor" después de un fallo generalizado del proveedor transfiere la responsabilidad de manera injusta. Aun así, los clientes toman decisiones consecuentes sobre cuánta autoridad tiene una interrupción del proveedor sobre su negocio.

Comience por la ruta de servicio. Identifique qué transacciones de usuario continúan si todas las API de administración de Google Cloud no están disponibles durante tres horas. Pruebe con nuevos despliegues en pausa, el autoescalado congelado, los cambios de IAM no disponibles, las modificaciones del balanceador de carga bloqueadas y el 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 y luego se degrada a medida que se acumulan las acciones de control rutinarias.

A continuación, pruebe el acceso del operador. Mantenga credenciales de emergencia cuya recuperación y verificación no requieran la ruta de identidad principal de la nube. Mantenga un espacio de trabajo mínimo para incidentes, una lista de contactos, manuales, diagramas de arquitectura y un publicador de estado fuera de Google Cloud. Asegúrese de que el equipo pueda comunicarse con los operadores de red y los 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 conexión de interconexión durante un ejercicio controlado. Confirme que el tráfico se mueve a través del área metropolitana y el proveedor previstos, mida la pérdida de convergencia y verifique que la alternativa tenga capacidad de carga completa. Compruebe que el retroceso a internet pública no esté bloqueado por suposiciones de firewall, enrutamiento o dirección de origen. Para el peering de VPC, demuestre las rutas importadas y exportadas exactas y no asuma transitividad. Para el tránsito multinube, pruebe la consistencia de los datos y la identidad, así como los paquetes.

Aprovisione previamente 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 última configuración buena conocida siga siendo utilizable. Practique un modo degradado que descarte las 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 quedaron en cola y qué clientes necesitan notificación. La restauración del proveedor no garantiza la corrección de la aplicación. Los objetivos de recuperación deben incluir la eliminación del trabajo atrasado y la validación de datos, no solo una comprobación de estado HTTP.

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

Un cuadro de mando para la responsabilidad del plano de control y la red

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

El cuadro de mando debe leerse en todas las filas. Un indicador de funcionalidad sin estado independiente no es suficiente. Cuatro conexiones de interconexión sin diversidad de proveedor y enrutador pueden no ser suficientes. Una aplicación multirregión sin recuperación aprovisionada previamente aún puede depender del controlador global. La fiabilidad proviene de la composición de los controles y de la evidencia de que la composición funciona bajo fallos.

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

Las plataformas en la nube crean valor al centralizar las 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 consecuente fue que el código inactivo, la política no válida, la replicación rápida, los lectores regionales, el reinicio sincronizado, la monitorización compartida y los proveedores descendentes formaron una sola cadena. El sistema estaba distribuido, pero la autoridad no estaba suficientemente particionada.

La respuesta de Google identificó los temas correctos: propagación incremental, indicadores de funcionalidad, fallo modular, retirada 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 extenderse por regiones y aún depender de una decisión global. Una empresa puede comprar dos redes y aún usar una ruta hacia el destino. Una página de estado puede ser pública y aún vivir dentro del incidente.

El estándar de responsabilidad 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 la nube, la velocidad es poder. La resiliencia comienza poniendo límites a donde ese poder puede viajar.