O "Code Orange: Fail Small" está concluído. O resultado é uma rede da Cloudflare mais forte

Nos últimos dois trimestres e pouco, realizamos um intenso esforço de engenharia, internamente conhecido como “Code Orange: Fail Small”, focado em tornar a infraestrutura da Cloudflare mais resiliente, segura e confiável para todos os nossos clientes.

No início deste mês, a equipe da Cloudflare concluiu este trabalho.

Embora aprimorar a resiliência nunca será um "trabalho concluído" e sempre será uma prioridade máxima em todo nosso ciclo de desenvolvimento, agora finalizamos o trabalho que teria evitado as interrupções globais de 18 de novembro de 2025 e 5 de dezembro de 2025.

Este trabalho se concentrou em diversas áreas-chave: alterações de configuração mais seguras, redução do impacto de falhas e revisão de nossos procedimentos de emergência e gerenciamento de incidentes. Também introduzimos medidas para impedir desvios e regressões ao longo do tempo e fortalecemos a maneira como nos comunicamos com nossos clientes durante uma interrupção.

Aqui, explicamos detalhadamente o que lançamos e o que isso significa para você.

O que isso significa para você: na maioria dos casos, as mudanças internas de configuração da Cloudflare não chegam mais à nossa rede instantaneamente, em vez disso, são implementadas de forma progressiva, com monitoramento da integridade em tempo real. Isso permite que nossas ferramentas de observabilidade detectem problemas e revertam erros antes que eles afetem seu tráfego.

Para detectar implantações possivelmente perigosas antes que cheguem à produção, identificamos pipelines de configuração de alto risco e criamos novas ferramentas para gerenciar melhor as alterações de configuração.

Para produtos que são executados em nossa rede, processando tráfego de clientes e recebendo alterações de configuração, não implantamos mais essas alterações instantaneamente em toda a rede. Em vez disso, as equipes relevantes adotaram uma metodologia de "implantação mediada por integridade", a mesma que usamos quando lançamos software, para todas as implantações de configuração. Isso inclui, entre outros, as equipes de produto que foram diretamente afetadas pelos incidentes.

No centro disso está um novo componente interno que chamamos de Snapstone, que criamos para trazer implantação mediada por integridade para alterações de configuração. O Snapstone é um sistema que agrupa alterações de configuração em um pacote e então permite a liberação gradual da alteração de configuração com princípios de mediação de integridade. Antes do Snapstone, aplicar essa metodologia à configuração era possível, mas difícil. Exigia um esforço significativo de cada equipe e não era aplicada de forma consistente em toda a rede. O Snapstone preenche essa lacuna, oferecendo uma forma unificada de implementar por padrão implantação progressiva, monitoramento de integridade em tempo real e reversão automática para implantações de configuração.

O que torna o Snapstone extremamente poderoso é sua flexibilidade. Em vez de ser uma correção para falhas passadas específicas, o Snapstone permite que as equipes definam dinamicamente qualquer unidade de configuração que precisa de mediação de integridade, seja um arquivo de dados, como o que causou a interrupção de 18 de novembro, ou um indicador de controle em nosso sistema de configuração global como o envolvido na interrupção de 5 de dezembro. As equipes criam essas unidades de configuração sob demanda, e o Snapstone garante a implantação segura em todos os lugares onde são usadas.

Isso nos proporciona algo que não tínhamos antes: quando uma análise de risco ou experiência operacional identifica um padrão de configuração perigoso, a correção é simples: trazê-lo para o Snapstone, e o padrão de configuração herda imediatamente a implantação segura. 

O que isso significa para você: caso um problema seja detectado em nossa rede, nossos sistemas agora falham de forma mais controlada. Isso reduz drasticamente o raio de impacto em potencial, garantindo que seu tráfego seja entregue mesmo nos piores cenários.

As equipes de produtos revisaram cuidadosamente, de forma manual e por meio de programação, os modos de falha em potencial para produtos críticos para o atendimento do tráfego de clientes. As equipes removeram dependências de tempo de execução não essenciais e implementaram modos de falha melhores. Agora, usaremos a última configuração válida conhecida, sempre que possível ("falha obsoleta"), e, caso isso não seja possível, revisamos cada caso de falha e implementamos "falha aberta" ou "falha fechada", dependendo se o atendimento do tráfego com funcionalidade reduzida é preferível ao não atendimento.

Vejamos um exemplo de como isso funciona. A nossa interrupção de novembro de 2025 foi causada por uma falha na implementação do nosso classificador de aprendizado de máquina para detecção do Bot Management. De acordo com nossos novos procedimentos, se fossem gerados novamente dados que nosso sistema não pudesse ler, ele se recusaria a usar a configuração atualizada e, em vez disso, usaria a configuração antiga. Se a configuração antiga não estivesse disponível por algum motivo, ele entraria em "falha aberta" para garantir a continuidade do tráfego de produção dos clientes, o que é um resultado muito melhor do que tempo de inatividade.

Como resultado, se a mesma alteração no Bot Management, que causou a falha em novembro, fosse implementada agora, o sistema detectaria a falha em um estágio inicial da implantação, antes que ela afetasse mais do que uma pequena porcentagem do tráfego.

Também começamos a segmentar ainda mais nosso sistema, para que cópias independentes dos serviços sejam executadas para diferentes grupos de tráfego. A Cloudflare já utiliza esses grupos de clientes para mitigar o raio de impacto com técnicas de gerenciamento de tráfego e esse trabalho adicional de segmentação de processos oferece um poderoso recurso de confiabilidade para nós no futuro.  

Por exemplo, o sistema de tempo de execução do Workers é segmentado em vários serviços independentes que lidam com diferentes grupos de tráfego, com um deles lidando apenas com o tráfego de nossos clientes gratuitos. As alterações são implantadas nesses segmentos com base nos grupos de clientes, começando pelos clientes gratuitos. Também estamos enviando atualizações com mais rapidez e frequência para os segmentos menos críticos e em um ritmo mais lento para os segmentos mais críticos.

Como resultado, se uma alteração fosse implementada no sistema de tempo de execução do Workers e interrompesse o tráfego, agora, ela afetaria apenas uma pequena porcentagem de nossos clientes gratuitos antes de ser detectada e revertida automaticamente.

Continuando com o exemplo do sistema de tempo de execução do Workers, em um período de sete dias no início deste mês, o processo de implementação foi acionado mais de cinquenta vezes. É possível observar como cada um deles acontece em "ondas", à medida que a alteração se propaga para a borda, frequentemente em paralelo com as versões subsequentes e anteriores:

Estamos trabalhando para estender esse padrão de implantação para muitos dos nossos sistemas no futuro.

O que isso significa para você?: se ocorrer um incidente, temos as ferramentas e equipes necessárias para nos comunicar com mais clareza e resolvê-lo rapidamente, minimizando o tempo de inatividade.

A Cloudflare é executada na Cloudflare. Usamos nossos próprios produtos Zero Trust para proteger nossa infraestrutura, mas isso cria uma dependência: se uma interrupção em toda a rede afetar essas ferramentas, perdemos os próprios caminhos necessários para corrigi-las. Antes da iniciativa Code Orange, nossos caminhos de emergência eram restritos a um pequeno grupo de pessoas e ofereciam acesso limitado às ferramentas. Precisávamos que essas ferramentas e caminhos ficassem disponíveis de forma mais ampla durante uma interrupção.

Para resolver isso, realizamos uma auditoria abrangente das ferramentas essenciais para a visibilidade do sistema, depuração e alterações na produção. Por fim, desenvolvemos caminhos de autorização de backup para 18 serviços principais, compatíveis com novos scripts de emergência e novos proxies.

Durante o programa Code Orange, passamos da teoria à prática. Após exercícios em equipes pequenas, realizamos um simulado com toda a equipe de engenharia em 7 de abril de 2026, envolvendo mais de 200 membros da equipe. Embora a automação mantenha esses caminhos funcionais, treinamentos como esses garantem que nossos engenheiros tenham a memória muscular necessária para usá-los sob pressão.

Esse esforço também concentra-se no fluxo de informações. Quando a visibilidade interna é interrompida, nossa resposta a incidentes fica mais lenta e nossa capacidade de comunicação com o mundo externo é prejudicada. Historicamente, observações técnicas feitas no calor do momento nem sempre se traduziram em atualizações claras para nossos clientes.

Para superar essa lacuna, criamos uma equipe de comunicação dedicada para trabalhar em conjunto com os responsáveis pela resposta a incidentes durante eventos críticos. Enquanto nossos engenheiros praticavam seus procedimentos de emergência, essa equipe usou o programa Code Orange para aprimorar a frequência e a clareza das atualizações para os clientes. Ao garantir que temos tanto as ferramentas para visualizar quanto a estrutura para comunicar, podemos resolver incidentes mais rapidamente e manter nossos clientes melhor informados.

O que isso significa para você: lembramos dos aprendizados com nossos incidentes e codificamos as soluções. Nossa rede se tornará cada vez mais resiliente.

Para evitar desvios e a reintrodução de regressões ao trabalho realizado como parte do Code Orange ao longo do tempo, a equipe criou um Codex interno que solidifica todas as nossas diretrizes em regras claras e concisas.

O Codex agora é obrigatório para todas as equipes de engenharia e produto e se tornou parte central dos procedimentos internos da Cloudflare. Suas regras são aplicadas por meio de revisões de código com IA que destacam automaticamente qualquer instância que possa divergir das diretrizes, exigindo revisões manuais adicionais. Isso é aplicado sem exceção a toda a nossa base de código. O objetivo é simples: criar uma memória institucional que se auto impõe.

As interrupções de novembro e dezembro compartilharam um modo de falha comum: código que supunha que as entradas seriam sempre válidas, sem degradação gradual quando essa suposição falhava. Um serviço Rust chamou .unwrap() em vez de resolver um erro. O código Lua indexou um objeto que não existia. Ambos os padrões podem ser evitados se as lições forem aprendidas e aplicadas.

O Codex faz parte da nossa resposta. É um repositório vivo de padrões de engenharia escritos por especialistas em domínios por meio do nosso processo Request For Comments (RFC), que são depois usados para criar regras práticas. As práticas recomendadas que antes existiam apenas na mente de engenheiros seniores, ou eram descobertas somente após um incidente, agora se tornam conhecimento compartilhado e acessível a todos. Cada regra segue um formato simples: "Se precisar de X, use Y", com um link para o RFC que explica o motivo.

Por exemplo, um RFC agora afirma: "Não use .unwrap()" fora de testes e build.rs." Outro captura um princípio mais amplo: "Os serviços DEVEM validar se as dependências upstream estão em um estado esperado antes do processamento."

Se essas regras tivessem sido aplicadas antes, as interrupções de novembro e dezembro teriam sido solicitações de mesclagem rejeitadas em vez de incidentes globais.

Regras sem aplicação são sugestões. O Codex se integra a agentes com tecnologia de IA em todas as etapas do ciclo de vida do desenvolvimento de software, desde a revisão do projeto até a implantação e a análise de incidentes. Isso desloca a aplicação para a esquerda, de "interrupção global" para "solicitação de mesclagem rejeitada". O raio de impacto de uma violação diminui de milhões de solicitações afetadas para um único desenvolvedor recebendo feedback acionável antes mesmo de seu código chegar à produção.

O Codex é um documento vivo e será continuamente aprimorado ao longo do tempo. Especialistas da área escrevem RFCs para codificar as melhores práticas. Os incidentes revelam lacunas que se tornam novos RFCs. Cada RFC aprovado gera regras para o Codex. Essas regras alimentam os agentes que analisam a próxima solicitação de mesclagem. É um ciclo virtuoso: a expertise se transforma em padrões, os padrões se transformam em aplicação e a aplicação eleva o padrão para todos.

O que isso significa para você: a transparência é importante para nós. Se algo der errado, nos comprometemos a informar você em todas as etapas, para que possa se concentrar no que é importante.

As interrupções globais nos fizeram revisar nossos principais processos e abordagens culturais, indo além da engenharia e do desenvolvimento de produtos. Como parte das iniciativas mais amplas do Code Orange, introduzimos objetivos de nível de serviço (SLOs) adicionais para todos os nossos serviços, implementamos um registro de alterações global, integramos todas as equipes ao nosso sistema de coordenação de manutenção e aprimoramos a transparência em toda a empresa sobre a lista de pendências de tickets de "prevenção" de incidentes.

Também fortalecemos a maneira como nos comunicamos com nossos clientes durante uma interrupção. Nosso objetivo é alertar você sobre um problema no momento em que o confirmamos, antes mesmo que você perceba. Quando você notar uma lentidão ou um erro, nosso objetivo é que já haja uma atualização disponível em suas notificações.

Durante um incidente ativo, agora fornecemos atualizações em intervalos previsíveis (por exemplo, a cada 30 ou 60 minutos), mesmo que a atualização seja simplesmente "Ainda estamos testando a correção. Nenhuma alteração nova ainda." Isso permite que você planeje seu dia em vez de ficar atualizando constantemente uma página de status.

Nosso trabalho não acaba quando o status volta ao normal. Fornecemos relatórios pós-incidente detalhados explicando o que aconteceu, por que aconteceu e as mudanças estruturais específicas que estamos implementando para garantir que isso não se repita.

Levamos os incidentes muito a sério e adotamos uma responsabilidade compartilhada em toda a organização Cloudflare, perguntando a cada equipe: O que poderia ter sido feito melhor? Isso orientou o trabalho que realizamos nos últimos dois trimestres.

Embora esse trabalho nunca termine de fato, estamos confiantes de que estamos em uma posição muito melhor e que a Cloudflare está muito mais forte por causa disso.