Código Laranja: Falhe Pequeno — nosso plano de resiliência após os incidentes recentes

Em 18 de novembro de 2025, a rede da Cloudflare apresentou falhas significativas no fornecimento de tráfego de rede por aproximadamente duas horas e dez minutos. Quase três semanas depois, em 5 de dezembro de 2025, houve uma nova falha em fornecer tráfego para 28% dos aplicativos em nossa rede por cerca de 25 minutos

Publicamos posts de blog detalhados sobre os dois incidentes após a ocorrência, mas sabemos que precisamos nos esforçar mais para reconquistar a confiança de vocês. Hoje, estamos compartilhando detalhes sobre o trabalho em andamento na Cloudflare para evitar que interrupções como essas voltem a acontecer.

Nosso plano se chama “Código Laranja: Falhe Pequeno” e reflete nosso objetivo de tornar a rede mais resiliente a erros ou falhas que possam levar a uma grande interrupção. Um "Código Laranja" significa que o trabalho nesse projeto tem prioridade. Para fins de contexto, declaramos um “Código Laranja” na Cloudflare uma vez, após outro grande incidente que exigiu prioridade máxima de todos na empresa. Entendemos que os eventos recentes exigem a mesma atenção.  O Código Laranja é a nossa forma de possibilitar que isso aconteça, permitindo que as equipes trabalhem de forma multifuncional conforme necessário para realizar o trabalho, enquanto pausam outras atividades.

O trabalho do Código Laranja está organizado em três áreas principais:

• Exigir implementações controladas para qualquer alteração de configuração propagada na rede, da mesma forma que fazemos atualmente para lançamentos de binários de software.

• Revisar, aprimorar e testar os modos de falha de todos os sistemas que lidam com o tráfego de rede para garantir que apresentem um comportamento bem definido em todas as condições, incluindo estados de erro inesperados.

• Alterar nossos procedimentos internos de emergência* e remover dependências circulares para que nós e nossos clientes possamos agir rapidamente e acessar todos os sistemas sem problemas durante um incidente.

Esses projetos proporcionarão melhorias iterativas à medida que avançam, em vez de uma mudança radical ao final. Cada atualização individual contribuirá para maior resiliência na Cloudflare. Ao final, esperamos que a rede da Cloudflare seja muito mais resiliente, inclusive para problemas como aqueles que desencadearam os incidentes globais que tivemos nos últimos dois meses.

Entendemos que esses incidentes são problemáticos para nossos clientes e para a internet como um todo. Estamos profundamente constrangidos. É por isso que este trabalho é a prioridade número um para todos aqui na Cloudflare.

^{* Os procedimentos de emergência na Cloudflare permitem que certos indivíduos elevem seus privilégios, sob certas circunstâncias, para realizar ações urgentes e resolver cenários de alta gravidade.}

No primeiro incidente, usuários que visitavam o site de um cliente na Cloudflare visualizaram páginas de erro que indicavam que a Cloudflare não podia fornecer uma resposta à solicitação deles. No segundo caso, viram páginas em branco.

Ambas as interrupções seguiram um padrão semelhante. Nos momentos que antecederam cada incidente, uma alteração de configuração foi implantada instantaneamente em nossos data centers em centenas de cidades ao redor do mundo.

A alteração de novembro foi uma atualização automática do nosso classificador Bot Management. Executamos diversos modelos de inteligência artificial que aprendem com o tráfego que flui em nossa rede para criar detecções que identificam bots. Atualizamos constantemente esses sistemas para nos mantermos à frente de agentes mal-intencionados que tentam burlar nossa proteção de segurança e alcançar os sites dos clientes.

Durante o incidente de dezembro, enquanto tentávamos proteger nossos clientes de uma vulnerabilidade na popular estrutura de código aberto React, implementamos uma alteração em uma ferramenta de segurança utilizada por nossos analistas de segurança para aprimorar as assinaturas. Assim como a urgência das novas atualizações de gerenciamento de bots, precisávamos nos antecipar aos invasores que queriam explorar a vulnerabilidade. Essa alteração desencadeou o início do incidente.

O padrão expôs uma lacuna grave na forma como implantamos as alterações de configuração na Cloudflare, em comparação com a forma como lançamos as atualizações de software. Quando lançamos atualizações de versão de software, fazemos isso de forma controlada e monitorada. Para cada nova versão binária, a implantação deve concluir várias etapas com sucesso antes de poder atender ao tráfego mundial. Inicialmente, a implementação é feita no tráfego de funcionários, antes de implementarmos gradualmente a alteração para porcentagens crescentes de clientes em todo o mundo, começando com usuários gratuitos. Se detectarmos uma anomalia em qualquer fase, poderemos reverter a versão sem qualquer intervenção humana.

Essa metodologia não foi aplicada a alterações de configuração. Ao contrário do lançamento do software principal que alimenta nossa rede, quando fazemos alterações de configuração, estamos modificando os valores de como esse software se comporta. Podemos fazer isso instantaneamente. Também concedemos esse poder aos nossos clientes: se você fizer uma alteração em uma configuração na Cloudflare, ela se propagará globalmente em segundos.

Embora essa velocidade traga vantagens, ela também acarreta riscos que precisamos mitigar. Os dois últimos incidentes demonstraram que precisamos tratar qualquer alteração aplicada à forma como servimos o tráfego em nossa rede com o mesmo nível de cautela testada que aplicamos às alterações no próprio software.

Nossa capacidade de implementar alterações de configuração globalmente em segundos foi o ponto fundamental em comum entre os dois incidentes. Em ambos os eventos, uma configuração incorreta derrubou a rede em segundos.

A introdução de implementações controladas da nossa configuração, assim como já fazemos para as versões de software, é o fluxo de trabalho mais importante do nosso plano Código Laranja.

As alterações de configuração na Cloudflare se propagam para a rede muito rapidamente. Quando um usuário cria um novo registro de DNS ou cria uma nova regra de segurança, ele atinge 90% dos servidores na rede em segundos. Isso é alimentado por um componente de software que chamamos internamente de Quicksilver.

O Quicksilver também é utilizado para qualquer alteração de configuração solicitada pelas nossas próprias equipes. A velocidade é um recurso: podemos reagir e atualizar globalmente o comportamento da nossa rede com muita rapidez. No entanto, em ambos os incidentes, isso causou uma alteração radical que se propagou para toda a rede em segundos, em vez de passar por gateways para testá-la.

Embora a capacidade de implementar alterações em nossa rede de forma quase instantânea seja útil em muitos casos, ela raramente é necessária. Estamos trabalhando para tratar a configuração da mesma forma que tratamos o código: introduzindo implementações controladas no Quicksilver para qualquer alteração de configuração.

Lançamos atualizações de software em nossa rede várias vezes ao dia por meio do que chamamos de sistema de Implantação Mediada por Saúde (HMD). Nessa estrutura, cada equipe da Cloudflare que possui um serviço (um componente de software implementado em nossa rede) deve definir as métricas que indicam se uma implementação foi bem-sucedida ou falhou, o plano de implementação e as medidas a serem tomadas caso não tenha havido sucesso.

Serviços diferentes terão variáveis ligeiramente diferentes. Alguns podem precisar de tempos de espera maiores antes de prosseguir para mais data centers, enquanto outros podem ter tolerâncias menores para taxas de erro, mesmo que isso cause sinais de falsos positivos.

Após a implantação, nosso kit de ferramentas HMD começa a progredir cuidadosamente de acordo com o plano, monitorando cada etapa antes de prosseguir. Se alguma etapa falhar, a reversão será iniciada automaticamente e a equipe poderá ser notificada, se necessário.

Ao final do Código Laranja, as atualizações de configuração seguirão o mesmo processo. Esperamos que isso nos permita detectar rapidamente os tipos de problemas que ocorreram nestes dois últimos incidentes, muito antes que se tornem problemas generalizados.

Embora estejamos otimistas de que um melhor controle sobre as alterações de configuração detectará mais problemas antes que se tornem incidentes, sabemos que erros podem e vão ocorrer. Nos dois incidentes, erros em uma parte da nossa rede tornaram-se problemas na maior parte da nossa pilha de tecnologia, incluindo o plano de controle que os clientes utilizam para configurar a forma como usam a Cloudflare.

Precisamos pensar em implementações cuidadosas e graduais, não apenas em termos de progressão geográfica (expandindo para mais dos nossos data centers) ou em termos de progressão da população (expandindo para funcionários e tipos de clientes). Também precisamos planejar implantações mais seguras que contenham falhas de progressão de serviço (que se propagam de um produto, como nosso serviço Bot Management, para um não relacionado, como nosso painel).

Para isso, estamos revisando os contratos de interface entre todos os produtos e serviços críticos que compõem nossa rede para garantir que vamos: a) presumir que ocorrerão falhas entre cada interface e b) lidar com essas falhas da maneira mais razoável possível. 

Voltando à falha do nosso serviço Bot Management, havia pelo menos duas interfaces importantes onde, se tivéssemos presumido que a falha iria acontecer, poderíamos ter lidado com ela de maneira adequada, de tal forma que seria improvável que qualquer cliente fosse impactado. A primeira era a interface que leu o arquivo de configuração corrompido Em vez de entrarmos em pânico, deveria haver um conjunto sensato de padrões validados que teriam permitido que o tráfego passasse pela nossa rede, enquanto teríamos, na pior das hipóteses, perdido o ajuste fino em tempo real que alimenta nossos modelos de aprendizado de máquina para detecção de bots. A segunda interface era entre o software principal que executa nossa rede e o próprio módulo do Bot Management. No caso de falha do nosso módulo do Bot Management (como ocorreu), não deveríamos ter descartado o tráfego por padrão. Em vez disso, poderíamos ter proposto, mais uma vez, um padrão mais sensato que permitisse a passagem do tráfego com uma classificação aceitável.

Durante os incidentes, levamos muito tempo para resolver o problema. Em ambos os casos, a situação foi agravada pelos nossos sistemas de segurança, que impediram os membros da equipe de acessar as ferramentas necessárias para solucionar o problema. Além disso, em alguns casos, as dependências circulares nos atrasaram, pois alguns sistemas internos também ficaram indisponíveis.

Como uma empresa de segurança, todas as nossas ferramentas estão protegidas por camadas de autenticação com controles de acesso granulares para garantir a segurança dos dados de clientes e impedir o acesso não autorizado. Essa é a atitude correta, mas, ao mesmo tempo, nossos processos e sistemas atuais nos atrasaram quando a velocidade era uma prioridade máxima

As dependências circulares também afetaram a experiência do cliente. Por exemplo, durante o incidente de 18 de novembro, o Turnstile, nossa solução de bot sem CAPTCHA, ficou indisponível. Como usamos o Turnstile no fluxo de login do painel da Cloudflare, os clientes que não tinham sessões ativas ou tokens de serviço de API não conseguiram iniciar sessão na Cloudflare no momento em que mais precisavam para fazer alterações críticas.

Nossa equipe vai revisar e aprimorar todos os procedimentos e a tecnologia de emergência para garantir que, quando necessário, possamos acessar as ferramentas certas o mais rápido possível, mantendo nossos requisitos de segurança. Isso inclui revisar e remover dependências circulares, ou ser capaz de "contorná-las" rapidamente caso haja um incidente. Também aumentaremos a frequência dos nossos exercícios de treinamento para que os processos sejam bem compreendidos por todas as equipes antes de qualquer possível cenário de desastre no futuro. 

Embora não tenhamos abordado neste artigo todo o trabalho que está sendo realizado internamente, os fluxos de trabalho detalhados acima descrevem as principais prioridades nas quais as equipes devem se concentrar. Cada um desses fluxos de trabalho corresponde a um plano detalhado que atinge quase todas as equipes de produto e engenharia da Cloudflare. Temos muito trabalho a fazer.

Até o final do 1º trimestre, e em grande parte antes disso, nós vamos:

• Garantir que todos os sistemas de produção sejam cobertos por Implantações Mediadas por Saúde (HMD) para gerenciamento de configuração.

• Atualizar nossos sistemas para aderir aos modos de falha adequados para cada conjunto de produtos.

• Garantir que tenhamos processos implementados para que as pessoas certas tenham o acesso certo para fornecer a remediação adequada durante uma emergência.

Alguns desses objetivos serão contínuos. Sempre precisaremos lidar melhor com as dependências circulares à medida que lançamos novos softwares. Nossos procedimentos de emergência precisarão ser atualizados para refletir como nossa tecnologia de segurança muda ao longo do tempo.

Falhamos com nossos usuários e com a internet como um todo nestes dois últimos incidentes. Temos trabalho a fazer para corrigir isso. Planejamos compartilhar atualizações conforme esse trabalho avança e agradecemos as perguntas e o feedback que recebemos dos nossos clientes e parceiros