Por Qué Esto Importa

En noviembre y diciembre de 2025, Cloudflare sufrió dos caídas globales que afectaron a millones de usuarios. Las causas: un rollout de clasificador ML en Bot Management y una flag de control en el sistema global de configuración. Ambas compartían un patrón mortal: código que asumía que los inputs siempre serían válidos, sin degradación gradual.

La respuesta fue la iniciativa “Code Orange: Fail Small” — un esfuerzo intensivo de dos trimestres que reconstruyó cómo se despliegan los cambios de configuración, cómo se absorben las fallas, y cómo se captura y aplica el conocimiento institucional.

Referencia: El post oficial completo está en el Blog de Cloudflare.

Cloudflare server rack with health monitoring dashboard overlay showing progressive deployment status Programming Illustration

Pilar 1: Despliegue de Configuración con Medición de Salud

El Problema

Antes de Code Orange, los cambios de configuración llegaban instantáneamente a la red. No había rollout gradual, monitoreo en tiempo real ni rollback automático. Un solo archivo de config malo podía tumbar toda la red.

La Solución: Snapstone

Cloudflare construyó Snapstone, un componente interno que empaqueta cambios de configuración y los libera gradualmente aplicando los mismos principios de health mediation que en los despliegues de software.

# Flujo conceptual de despliegue de Snapstone (simplificado)
etapas:
  - nombre: canary
    porcentaje: 2
    health_checks:
      - latencia_p99 < 200ms
      - tasa_error < 0.1%
    rollback_en_fallo: true
  - nombre: regional
    porcentaje: 25
    health_checks:
      - latencia_p99 < 250ms
      - tasa_error < 0.5%
    rollback_en_fallo: true
  - nombre: global
    porcentaje: 100
    health_checks:
      - latencia_p99 < 300ms
      - tasa_error < 1.0%
    rollback_en_fallo: true

Características clave:

  • Unidades flexibles: Los equipos definen cualquier unidad de config (archivo de datos, flag de control, etc.) que necesite mediación.
  • Rollback automático: Si los health checks fallan en cualquier etapa, el despliegue se revierte antes de afectar producción.
  • Enfoque unificado: Antes cada equipo creaba su propio canary. Ahora hay un sistema reutilizable.

Relacionado: Para una visión más amplia de patrones de rollout progresivo en orquestación de agentes de IA, checa el Vercel Chat SDK Adapter Directory — usa principios similares de despliegue en oleadas.

Abstract cloud network diagram with segmented traffic cohorts and fail-open pathways Software Concept Art

Pilar 2: Reduciendo el Impacto de las Fallas

El Principio: Falla con Gracia

Los equipos de Cloudflare revisaron todos los servicios críticos e implementaron tres estrategias:

  1. Fail stale: Usar la última config buena conocida cuando los nuevos datos no se pueden leer.
  2. Fail open: Si no hay config antigua, servir tráfico con funcionalidad reducida en lugar de tirarlo.
  3. Fail close: Solo bloquear tráfico si servir datos degradados causa daños peores.

Ejemplo: Clasificador ML de Bot Management

Si el escenario de noviembre de 2025 se repitiera hoy:

  • El sistema detectaría datos ilegibles en la etapa canary (2% del tráfico).
  • Rechazaría la nueva config y caería a la antigua.
  • Si la antigua tampoco estuviera disponible, haría fail open — sirviendo tráfico sin el modelo ML más reciente — en lugar de tirar peticiones.

Segmentación de Procesos para Reducir el Radio de Impacto

Cloudflare comenzó a segmentar servicios en copias independientes para diferentes cohortes de clientes. Por ejemplo, el runtime de Workers ahora corre instancias separadas para clientes free y de pago. Los cambios se despliegan primero en el segmento free. En un período de siete días, el proceso de despliegue de Workers se disparó más de 50 veces, cada uno en oleadas que se propagan al edge.

También te puede interesar: El enfoque de Spotify para dashboards de release y automatización ofrece insights complementarios sobre frecuencia de despliegue y radio de impacto. Lee más en Inside Spotify’s Release Engine Dashboard Design & Automation Insights.

AI code review agent scanning a pull request with Codex rules enforcement highlighted Development Concept Image

Pilar 3: El Codex — Estándares de Ingeniería Aplicados por IA

De Incidentes a Memoria Institucional

Las caídas de noviembre y diciembre fueron causadas por dos errores simples de código:

  • Un servicio Rust llamó .unwrap() en lugar de manejar un error.
  • Código Lua indexó un objeto que no existía.

Para evitar que estos patrones se repitan, Cloudflare construyó el Codex — un repositorio vivo de estándares de ingeniería escritos mediante un proceso de RFC y aplicados por agentes de revisión de código con IA.

Cómo Funciona el Codex

  1. Expertos escriben RFCs para codificar buenas prácticas (ej.: “No uses .unwrap() fuera de tests y build.rs.”)
  2. RFCs aprobadas generan reglas del Codex con formato simple: “Si necesitas X, usa Y” + link a la RFC.
  3. Agentes de IA aplican las reglas en cada etapa del SDLC: design review, code review, despliegue y análisis de incidentes.
  4. Incidentes revelan brechas que se convierten en nuevas RFCs, creando un volante de mejora continua.

Impacto Práctico

Antes de Code Orange, un merge request peligroso podía escapar de la revisión y causar una caída global. Ahora, la misma violación se detecta en la etapa de PR — el radio de impacto se reduce de millones de peticiones a un solo desarrollador recibiendo feedback accionable inmediato.

Limitaciones y Precauciones

Aunque Code Orange es un gran avance, no es una bala de plata:

  • Complejidad: Snapstone y la segmentación de procesos añaden overhead operativo. Equipos pequeños pueden encontrar las herramientas pesadas.
  • Falsos positivos: Los agentes de IA pueden marcar patrones seguros como violaciones, requiriendo revisión manual extra.
  • Factores humanos: Los drills y la memoria muscular son tan buenos como su frecuencia. El drill de abril de 2026 involucró a 200+ ingenieros, pero mantener esa práctica en todos los equipos es un reto.

Próximos Pasos

Si eres responsable de confiabilidad en tu organización, considera:

  • Auditar tu pipeline de despliegue de configuración: ¿Estás desplegando configs instantáneamente o progresivamente?
  • Implementar rollouts con medición de salud: Incluso un canary simple con health checks manuales es mejor que ningún staging.
  • Codificar tus aprendizajes de incidentes: Empieza un “Codex” ligero para tu equipo — un documento vivo de reglas aplicadas por linters o gates de CI.

El trabajo de Cloudflare es un caso de estudio poderoso de cómo la cultura de ingeniería, las herramientas y los procesos pueden converger para prevenir fallas catastróficas. El trabajo nunca termina, pero la dirección es clara: falla pequeño, aprende rápido, y codifica tu conocimiento para que nunca tenga que ser redescubierto a través de una caída.

Este contenido fue redactado con la asistencia de herramientas de IA, basándose en fuentes confiables, y fue revisado por nuestro equipo editorial antes de su publicación. No reemplaza el asesoramiento de un profesional especializado.