El "Code Orange: Fail Small" está completo. El resultado es una red de Cloudflare más solida

Durante los últimos dos trimestres largos, hemos emprendido un esfuerzo intensivo de ingeniería, denominado internamente "Code Orange: Fail Small," centrado en hacer que la infraestructura de Cloudflare sea más resistente, segura y fiable para cada cliente.

A comienzos de este mes, el equipo de Cloudflare terminó este trabajo.

Aunque mejorar la resiliencia nunca será una tarea concluida y siempre será una prioridad en todo nuestro ciclo de vida del desarrollo, ya hemos terminado el trabajo que habría evitado las interrupciones globales del 18 de noviembre de 2025 y el 5 de diciembre de 2025.

Este trabajo se centró en varias áreas clave: cambios de configuración más seguros, reducción del impacto de los errores y revisión de nuestros procedimientos de “emergencia” y de gestión de incidentes. También implementamos medidas para evitar el incumplimiento y las regresiones a lo largo del tiempo, y fortalecimos la manera de comunicarnos con nuestros clientes durante una interrupción.

Aquí explicamos en detalle lo que ofrecemos y como te beneficia.

Beneficio: en la mayoría de los casos, los cambios internos en la configuración de Cloudflare ya no llegan a nuestra red de manera instantánea y, en su lugar, se implementan progresivamente con una supervisión del rendimiento en tiempo real. Esto permite que nuestras herramientas de observabilidad detecten los problemas y reviertan los errores antes de que afecten tu tráfico.

Para detectar implementaciones potencialmente peligrosas antes de que lleguen a producción, identificamos los proceso de configuración de alto riesgo y desarrollamos nuevas herramientas para gestionar mejor los cambios de configuración.

Para los productos que se ejecutan en nuestra red, procesan el tráfico de los clientes y reciben cambios de configuración, ya no implementamos estos cambios de forma inmediata en toda la red. Además, los equipos correspondientes adoptaron una metodología de "implementación mediada por estado" ("Health Mediated Deployment"), la misma que utilizamos para la publicación de software, en todas las implementaciones de configuración. Esto incluye, entre otros, a los equipos de productos que se vieron directamente afectados por los incidentes.

En el centro de esto se encuentra un nuevo componente interno que llamamos Snapstone, que creamos para llevar la implementación mediada por la salud a los cambios de configuración. Snapstone es un sistema que agrupa el cambio de configuración en un paquete, y luego permite la distribución gradual del cambio de configuración con principios de mediación de estado. Antes de Snapstone, aplicar esta metodología a la configuración era posible pero difícil. Se requería que cada equipo hiciera un esfuerzo significativo y no se aplicaba de manera sistemática en toda la red. Snapstone cierra esta brecha al proporcionar una forma unificada de incorporar, por defecto, el despliegue progresivo, la monitorización del estado en tiempo real y la reversión automatizada a las implementaciones de configuración.

El aspecto que hace que Snapstone sea particularmente poderoso es su flexibilidad. En lugar de proporcionar una solución para fallos anteriores específicos, Snapstone permite a los equipos definir de manera dinámica cualquier unidad de configuración que necesite una mediación de estado, ya sea un archivo de datos como el que originó la interrupción del 18 de noviembre o un indicador de control en nuestro sistema de configuración global como el involucrado en la interrupción del 5 de diciembre. Los equipos crean estas unidades de configuración bajo demanda, y Snapstone garantiza que se implementen de forma segura en cualquier lugar donde se utilicen.

Esto nos proporciona algo que antes no teníamos: cuando una revisión de riesgos o la experiencia operativa identifica un patrón de configuración peligroso, la solución es sencilla: basta con incorporarlo a Snapstone y el patrón de configuración hereda inmediatamente una implementación segura. 

Beneficio: en caso de que se observe un problema en nuestra red, nuestros sistemas ahora fallan de manera más estable. Esto reduce considerablemente el radio de impacto potencial, para garantizar que tu tráfico se entregue incluso en los peores escenarios posibles.

Los equipos de producto han revisado minuciosamente, tanto de forma manual como programática, sus posibles modos de fallo para los productos que son cruciales para gestionar el tráfico de los clientes. Los equipos han eliminado las dependencias en tiempo de ejecución no esenciales e implementaron mejores modos de falla. Ahora usaremos la última configuración eficiente conocida donde sea posible (\"fail stale”), y si no es posible, hemos revisado cada caso de fallo y hemos implementado \"fail open\" o \"fail close\" dependiendo de si es preferible brindar servicio el tráfico con funcionalidad reducida a no atenderlo en absoluto.

Veamos un ejemplo de cómo funciona esto. Nuestra interrupción de noviembre de 2025 fue consecuencia de una falla en la implementación de nuestro clasificador de aprendizaje automático de detección de gestión de bots. Con nuestros nuevos procedimientos se rechazaría el uso de la configuración actualizada si hubiera datos que el sistema no pudiera leer; en su lugar, utilizaría la configuración anterior. Si la configuración anterior no estaba disponible por algún motivo, se abriría en caso de fallo para garantizar que se siga atendiendo el tráfico de producción de los clientes, lo cual es un resultado mucho mejor que el tiempo de inactividad.

En consecuencia, si el mismo cambio de gestión de bots que causó la falla en noviembre se implementara ahora, el sistema detectaría la falla en una etapa temprana de la implementación, antes de que hubiera afectado algo más que un pequeño porcentaje del tráfico.

También hemos comenzado a segmentar aún más nuestro sistema para que las copias independientes de los servicios se ejecutan para diferentes grupos de tráfico. Cloudflare ya aprovecha hoy estos grupos de clientes para la mitigación del radio de acción mediante técnicas de gestión del tráfico, y este trabajo adicional de segmentación de procesos nos proporciona una poderosa capacidad de fiabilidad.  

Por ejemplo, el sistema de ejecución de Workers está segmentado en múltiples servicios independientes que gestionan diferentes conjuntos de tráfico. Uno de estos servicios gestiona sólo el tráfico para nuestros clientes de productos gratuitos. Los cambios se despliegan en esos segmentos en función de grupos de clientes, comenzando por los clientes gratuitos. También enviamos actualizaciones más rápido y con mayor frecuencia a los segmentos menos críticos y más lento a los más críticos.

Como resultado, si se activara un cambio en el sistema de tiempo de ejecución de Workers y este rompiera el tráfico, se afectaría solo a un pequeño porcentaje de nuestros clientes gratuitos, antes de ser detectado y revertido automáticamente.

Volviendo al sistema de tiempo de ejecución de Workers como ejemplo, en un período de siete días a principios de este mes, el proceso de implementación se activó más de 50 veces. Aquí pueden observarse cómo cada uno ocurre en “ondas”, a medida que el cambio se propaga hasta el perímetro, muchas veces en paralelo con las versiones siguientes y las anteriores:

Gracias a los procesos mencionados, planeamos extender este patrón de implementación a muchos más de nuestros sistemas en el futuro.

Beneficio: si ocurre un incidente, tenemos las herramientas y los equipos para comunicar con más claridad y resolverlo con mayor rapidez, minimizando el tiempo de inactividad.

Cloudflare opera en la infraestructura de Cloudflare. Usamos nuestros propios productos Zero Trust para proteger nuestra infraestructura, pero esto genera una dependencia: si un corte de energía a nivel de red afecta estas herramientas, se pierde la misma conexión que necesitamos para corregirlas. Antes de esta iniciativa Code Orange, nuestras métodos de "romper el cristal" estaban restringidas a unas pocas personas y ofrecían un acceso limitado a las herramientas. Necesitábamos que estas herramientas y caminos estuvieran más disponibles durante una interrupción.

Para resolverlo, realizamos una auditoría exhaustiva de las herramientas esenciales para la visibilidad del sistema, la depuración y los cambios en producción. Finalmente, desarrollamos rutas de autorización de respaldo para 18 servicios clave, con el respaldo de nuevos scripts de emergencia y proxies.

En todo el programa Code Orange, pasamos de la teoría a la práctica. Después de una prueba en equipos pequeños, el 7 de abril de 2026 realizamos un ejercicio destinado a todo el equipo de ingeniería que contó con más de 200 integrantes. Si bien la automatización mantiene estos caminos funcionales, estos ejercicios aseguran que nuestros ingenieros tengan memoria muscular para usarlos bajo presión.

Este esfuerzo también se centró en el flujo de información. Cuando nuestra visibilidad interna se ve afectada, nuestra respuesta a incidentes disminuye y nuestra capacidad para comunicarnos con el mundo exterior empeora. Históricamente, las observaciones técnicas sobre la marcha no siempre se traducían en actualizaciones claras para nuestros clientes.

Para salvar esta brecha, hemos establecido un equipo de comunicación dedicado que trabaja de forma coordinada con los que responden a incidentes en situaciones importantes. Así como nuestros ingenieros practicaron sus procedimientos de "romper el cristal", este equipo utilizó el programa Code Orange para realizar un simulacro sobre la optimización de la cadencia y la claridad de las actualizaciones para los clientes. En la medida que aseguramos disponer de las herramientas necesarias para poder ver, así como de la estructura adecuada para poder hablar, somos capaces de resolver más rápidamente los incidentes y mantener a nuestros clientes mejor informados.

Beneficio: utilizaremos los aprendizajes de nuestros incidentes y además hemos codificado las resoluciones. Nuestra red se volverá cada vez más resistente.

Para evitar que se genere divergencia y para reintroducir las regresiones en el trabajo realizado como parte de Code Orange con el tiempo, el equipo ha creado un Codex interno que solidifica todas nuestras instrucciones en reglas claras y concisas.

El Codex ahora es obligatorio para todos los equipos de ingeniería y producto y se ha convertido en una parte central de los procedimientos internos de Cloudflare. Sus reglas se imponen mediante revisiones de código con IA que destacan automáticamente cualquier instancia que pueda desviarse de las directrices, lo que requiere realizar revisiones manuales adicionales. Eso se aplica sin excepción a todo nuestro código base. El objetivo es simple: desarrollar una memoria institucional que se mantenga sola.

La interrupción de noviembre y diciembre contaron con un modo de fallo común: se trataba de código que partía de la premisa de que las entradas serían siempre válidas, y no tenía un modo de degradación gradual si esta premisa fallaba. Un servicio de Rust llamo a .unwrap() en vez de gestionar un error; el código Lua indexó un objeto que no existía. Ambos patrones se pueden prever si se capturan y se respetan las lecciones.

El Codex forma parte de nuestra respuesta. Se trata de un repositorio vivo de normas de ingeniería redactadas por expertos a través de nuestro proceso de "solicitud de comentarios (RFC)", que después se trasladan a un lenguaje normativo y esquemático. Las mejores prácticas, que antes tenían los ingenieros sénior en su cabeza, o que se detectaban solo después de un incidente, ahora se han convertido en conocimientos compartidos accesibles para todos. Cada regla sigue un formato sencillo: "Si necesita X, use Y", con un vínculo al RFC que explica por qué.

Por ejemplo, una versión más reciente de una RFC dice:"No utilizar .unwrap() fuera de las pruebas y de build.rs." Otro ejemplo presenta un principio más amplio: "Los servicios DEBEN validar que las dependencias ascendentes se encuentren en el estado esperado antes de su procesamiento".

Si estas reglas se hubieran aplicado antes, las interrupciones de noviembre y diciembre habrían sido solicitudes de fusión rechazadas en lugar de incidentes globales.

Las reglas que no se aplican son meras recomendaciones. El Codex se integra con agentes impulsados por la IA en cada etapa del ciclo de vida del desarrollo de software, desde la revisión de diseño hasta el despliegue y análisis de incidentes. Esto desplaza la aplicación de la normativa hacia la izquierda, pasando de "interrupción global" a "solicitud de fusión rechazada". El radio de una violación pasa de millones de solicitudes afectadas a un solo desarrollador que recibe comentarios prácticos antes de que su código llegue a la producción.

El Codex es un documento en constante evolución y se mejorará de manera continua con el tiempo. Los expertos en dominios escriben documentos RFC para codificar las prácticas recomendadas. Los incidentes muestran las brechas que se convierten en nuevas RFC. Cada RFC aprobado genera reglas de Codex. Estas reglas alimentan a los agentes que revisan la siguiente solicitud de fusión. Es un círculo virtuoso: los conocimientos generan normas, las normas generan aplicaciones, las aplicaciones generan requisitos mínimos para todos.

Beneficio: la transparencia es importante para nosotros. Si algo falla, nos comprometemos a mantenerte informado en cada paso del camino para que puedas concentrarte en lo que realmente importa.

Las interrupciones globales nos han hecho revisar los principales procesos y enfoques culturales más allá de la ingeniería y el desarrollo de productos. Como parte de las iniciativas más amplias de Code Orange, hemos introducido objetivos de nivel de servicio (SLO, por sus siglas en inglés) adicionales para todos nuestros servicios. Se ha aplicado un registro de cambios global, incorporado a todos los equipos en nuestro sistema de coordinación de mantenimiento, y mejoramos la transparencia en toda la empresa sobre nuestros incidentes que "previenen" la acumulación de tickets. 

También hemos reforzado la forma en que nos comunicamos con nuestros clientes durante una interrupción. Nuestro objetivo es alertarte sobre un problema en el momento en que lo confirmamos, antes de que notes el problema. Para cuando notes una latencia o un error, nuestro objetivo es que la actualización ya esté esperando en tus notificaciones.

Durante un incidente activo, ahora proporcionamos actualizaciones en intervalos predecibles (por ejemplo, cada 30 o 60 minutos), incluso si la actualización es simplemente, "Seguimos probando la solución; aún no hay cambios" Esto te permite planear tu día en vez de actualizar constantemente una página de estado.

Nuestro trabajo no acaba cuando la situación vuelve a la normalidad. Proporcionamos informes exhaustivos que explican cómo ocurrió la interrupción, por qué ocurrió y qué cambios estructurales estamos haciendo para asegurarnos de que no vuelva a ocurrir.

Nos tomamos los incidentes muy en serio y adoptamos una responsabilidad compartida de toda la organización Cloudflare preguntándonos en cada equipo: ¿qué podría haberse hecho mejor? Esto guió el trabajo que realizamos durante los dos últimos trimestres.

Si bien este trabajo nunca se completa en su totalidad, estamos seguros de que estamos en una posición mucho mejor y Cloudflare ahora es mucho más fuerte gracias a ello.