El plan "Code Orange: Fail Small" de Cloudflare: Un post-mortem de las caídas globales y la ruta hacia la resiliencia
La iniciativa "Code Orange: Fail Small" de Cloudflare no es solo un nombre bonito; significa un cambio de paradigma hacia prácticas de despliegue más cautelosas y, sobre todo, una asunción más realista de que fallar es inevitable. Al contener los problemas antes de que hagan metástasis y se conviertan en caídas globales, Cloudflare busca recuperar no solo la confianza, sino la estabilidad misma del ecosistema de internet. Porque, la verdad... nadie quiere tener que explicarle al jefe por qué el sitio está abajo solo porque a un CDN o al DNS se les ocurrió tirarse desde la ventana.

Las caídas recientes y su impacto
El 2025 resultó ser un año bastante "movidito" para la red de Cloudflare, marcado por dos incidentes de proporciones que dejaron la grande en el ecosistema digital.
- 18 de noviembre de 2025: El primer condoro, detallado por InfoQ, interrumpió el tráfico por unas dos horas y diez minutos. Para muchos, fueron 130 minutos de quedarse mirando el spinner de carga, preguntándose si el internet finalmente había tirado la toalla.
- 5 de diciembre de 2025: La segunda caída, documentada en el propio post-mortem de Cloudflare, afectó a cerca del 28% de las aplicaciones detrás de su red por unos 25 minutos. Un corte más corto, quizás, pero igual de brígido como para sacarles un gruñido colectivo a los desarrolladores y usuarios.
Ambos incidentes fueron gatillados por cambios de configuración globales casi instantáneos que, irónicamente, buscaban mejorar la seguridad o la detección de bots. Estos cambios provocaron una propagación ultra rápida de settings erróneos en cientos de data centers, transformando un error de configuración menor en una catástrofe digital global.
Los pilares del plan Code Orange: Fail Small
Entonces, ¿qué trae este nuevo "remedio" para la resiliencia? El plan "Code Orange: Fail Small" se apoya en tres pilares fundamentales, diseñados para inyectarle una buena dosis de cautela y robustez a sus operaciones globales.
Rollouts controlados y cambios de configuración
El plan exige que los cambios de configuración —los mismos culpables de las últimas caídas— se implementen de forma controlada y por fases. Este enfoque ahora imita el proceso de Health Mediated Deployment (HMD) de Cloudflare, que ya estaba más que probado pero que antes se reservaba solo para lanzamientos de software. Imagínalo como el hermano mayor cuático del software que ahora se queda cuidando los cambios de configuración. El proceso HMD incluye validaciones por etapas y mecanismos de rollback automático, asegurando que la cosa esté estable antes de mandarse el despliegue masivo.
Históricamente, las actualizaciones de configuración críticas —ya fueran registros DNS o reglas de seguridad— se disparaban a toda la red global de Cloudflare en segundos, gracias a su sistema interno Quicksilver. Un sistema diseñado para la velocidad que, como ya vimos, también puede ser un demonio para desatar desastres. La nueva política dicta que estas actualizaciones ahora pasarán por una serie de "puertas" de monitoreo y despliegues graduales. ¿El objetivo? Pillar esa config maliciosa antes de que decida botar la mitad del internet, data center por data center.
Mejorando los modos de falla (Failure Modes)
Cloudflare está revisando con lupa y mejorando todos los modos de falla dentro de los sistemas que manejan el tráfico de red. La idea es asegurar que cada componente se comporte de forma predecible cuando las papas queman, evitando que un solo punto de falla gatille un efecto dominó catastrófico. Esto implica validar rigurosamente los contratos de interfaz entre productos críticos y, lo más importante, establecer valores por defecto (defaults) con sentido común. La lógica es que si un subsistema dependiente decide fallar, el tráfico debería seguir fluyendo, aunque sea "cojeando". Porque, seamos realistas, al internet no le gusta para nada el stop total.
Overhaul a los procedimientos "Break-Glass"
La compañía también le está pegando una buena renovada a sus procedimientos "break-glass" —esos protocolos de emergencia para cuando "queda la escoba" de verdad—. El fin es desenredar las dependencias circulares en el acceso a herramientas internas que, históricamente, han convertido la respuesta rápida a incidentes en un ballet en cámara lenta. Con mejor capacitación y protocolos de acceso de emergencia simplificados, buscan empoderar a los ingenieros para que reaccionen con la velocidad de un SRE con sobredosis de cafeína, pero sin comprometer las mismas salvaguardas de seguridad que están tratando de proteger.
Ejecución incremental y mirada al futuro
Cloudflare no solo está vendiendo humo; están aplicando la receta paso a paso. Para fines del primer trimestre de 2026, esperan que todos los sistemas de producción estén operando bajo el proceso de configuración HMD mejorado, con modos de falla mejor definidos y testeados, y ojalá, con un acceso de respuesta a emergencias que no requiera un mapa del tesoro y un saludo secreto. Este mismo despliegue por fases es un testimonio de la filosofía "fail small".
Contexto y reacción de la comunidad
Estos esfuerzos proactivos llegan justo cuando están bajo el foco, después de una serie de caídas que dejaron a sitios gigantes como LinkedIn, Zoom y Shopify temporalmente en la edad de piedra digital. Estos incidentes, con justa razón, reavivaron el eterno debate sobre los riesgos de depender tanto de una infraestructura de internet centralizada. Es como si poner todos los huevos en la misma canasta no fuera siempre la mejor estrategia, aunque esa canasta sea Cloudflare.
Si bien se sintió una dosis saludable de frustración en los foros y redes, muchos usuarios valoraron que Cloudflare reconociera sus errores de frente y se comprometiera con mejoras estructurales. Al final, la transparencia, incluso después de un condoro digital, igual suma puntos.
Fuente

Más contenido:
Grave brecha de Trivy en Github Actions amenaza tus secretos, tokens, credenciales e incluso tus artefactos, qué debes hacer y saber
la ironía de la seguridad: las github actions de trivy secuestradas (otra vez) En un giro del destino que haría que cualquier SRE se sirviera un trago fuerte, Trivy —el escáner de vulnerabilidades estándar de la industria mantenido por Aqua Security— ha sido comprometido por segunda vez en un mes.
Leer más →
Los mitos y credos respecto a turnos (o "estar de guardia")
Llevo más de una década haciendo turnos de guardia. Cuando los computadores que administro tienen un problema, le avisan a mi equipo 24/7 para que los ayude. Uso estos credos para que estar de turno sea lo más tranquilo posible. Descúbrelo antes que el cliente Ya sea que el

