Análise da maior falha na história da Cloudflare: não foi um ataque, foi uma alteração na configuração que causou o problema.

No dia 18 de novembro, a Cloudflare caiu, e isso causou bastante alvoroço – CDN, serviços de segurança, Workers KV, Turnstile, Access, uma série de produtos ficaram todos fora do ar, e eles mesmos disseram que foi a pior queda desde 2019.

No início, a equipe achou que estava sob um ataque DDoS, mas após uma longa investigação, descobriram que o problema tinha sido causado por alguém da própria equipe: as permissões do banco de dados foram alteradas, o que resultou num bug no arquivo de configuração gerado, que derrubou diretamente o sistema de proxy central. No final, conseguiram reverter para a configuração antiga para resolver a situação, e só conseguiram uma recuperação completa às 1h06 do dia 19, hora de Pequim.

O relatório de retrospectiva do blog oficial foi escrito de forma bastante sincera, admitindo diretamente que é “inaceitável” e afirmando que precisa acelerar a transformação da resiliência do sistema. Para nós, que usamos os serviços deles para executar projetos, esse nível de falha na infraestrutura realmente deve ser lembrado — mesmo os fornecedores mais competentes podem falhar devido a erros operacionais internos, e a implantação em nuvem e planos de emergência devem ser preparados com antecedência.