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.

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.

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:
- Fail stale: Usar la última config buena conocida cuando los nuevos datos no se pueden leer.
- Fail open: Si no hay config antigua, servir tráfico con funcionalidad reducida en lugar de tirarlo.
- 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.

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
- Expertos escriben RFCs para codificar buenas prácticas (ej.: “No uses
.unwrap()fuera de tests ybuild.rs.”) - RFCs aprobadas generan reglas del Codex con formato simple: “Si necesitas X, usa Y” + link a la RFC.
- Agentes de IA aplican las reglas en cada etapa del SDLC: design review, code review, despliegue y análisis de incidentes.
- 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.