Resumo

  • A Cloudflare informou interrupção no plano de controle e nos serviços de análise a partir de 2 de novembro de 2023, enquanto o tráfego principal da borda continuava [1].
  • O gatilho público foi uma cadeia de falha elétrica no PDX-04, instalação no Oregon que hospedava dependências críticas [1][3].
  • O incidente expôs dependências em Kafka, ClickHouse, identidade, ferramentas internas e sistemas necessários para recuperação [1].
  • Uma segunda falha elétrica na mesma instalação em 2024 testou a preparação Code Orange e reduziu o impacto no plano de controle [2].
  • Um encerramento confiável precisa provar configuração, análise, identidade, ferramentas internas e ações visíveis ao cliente durante perda completa de instalação.

O que aconteceu

A Cloudflare marcou o início às 11:43 UTC de 2 de novembro. A camada afetada foi o plano de controle e os serviços de análise [1]. Isso significa que clientes podiam ter dificuldade para mudar regras, consultar métricas ou usar funções administrativas, mesmo que o tráfego distribuído sem nova decisão de controle continuasse.

O ponto físico foi o PDX-04. A Cloudflare descreve um evento de manutenção não planejado da Portland General Electric afetando uma alimentação independente do prédio, seguido por baterias esgotadas, dificuldade de religar geradores, acesso ao prédio, troca de disjuntores e religamento controlado de servidores [1]. A Baxtel também vinculou a interrupção a uma falha elétrica em um data center da Flexential em Hillsboro, Oregon, citando a mesma explicação da Cloudflare [3].

A lição prática é que um serviço de nuvem pode continuar levando tráfego já configurado enquanto perde parte da superfície usada para mudar, diagnosticar ou confirmar o estado. Quando essa superfície depende de um local único, a continuidade do cliente depende de uma cadeia física e organizacional de recuperação.

A dependência oculta não era um servidor só

O postmortem não descreve uma máquina isolada. Ele cita componentes de plano de controle e análise, Kafka, ClickHouse, identidade e autorização, ferramentas internas e sistemas usados para reiniciar ou reconstruir serviços [1]. Algumas dependências eram conhecidas; outras só ficaram claras quando a instalação inteira falhou.

Esse é um caso de responsabilidade sobre infraestrutura de rede. O plano de controle é a superfície de autoridade operacional. Ali uma mudança vira configuração em execução, um alerta vira ação e o cliente entende se o serviço está saudável. Se essa superfície depende de uma instalação não testada sob perda total, o risco público não é apenas indisponibilidade; é perda de visibilidade e capacidade de mudança.

A Cloudflare também separa o que continuou do que falhou. Muito tráfego de borda permaneceu ativo [1]. Isso não torna o evento pequeno; mostra que resiliência precisa ser medida por camada. Um plano de dados saudável não prova um plano de controle recuperável.

Recuperação de desastre precisa rodar de verdade

A Cloudflare diz que tinha planos de recuperação, mas o evento mostrou que alguns serviços não estavam prontos para perda total da instalação e que certos procedimentos não tinham sido testados nas condições corretas [1]. Um plano pode nomear local alternativo. A prova real é replicação, filas, identidade, painéis e ferramentas internas funcionando durante a falha.

A volta também trouxe pressão de demanda. Quando serviços retornam, clientes e sistemas internos tentam de novo em massa. O postmortem descreve um efeito de multidão que pode transformar recuperação em segundo incidente se o plano de controle não absorver o backlog [1].

O relato de 2024 ajuda porque oferece comparação. Quatro meses depois houve outra falha elétrica importante na mesma instalação; a Cloudflare ativou Code Orange e disse que mudanças anteriores reduziram o impacto [2]. Isso não prova solução total, mas mostra o padrão certo: evento semelhante, preparação nova e resultado diferente.

A fronteira física continua importando

Planos de controle de nuvem parecem abstratos, mas o incidente envolveu energia, baterias, geradores, acesso físico, operador da instalação e ordem de reinício dos servidores [1][3]. Esses fatores ficam abaixo da API, mas governam o resultado visto pelo cliente.

Depender de data center de terceiro não é falha automática. A pergunta é o que o operador consegue provar: quem ativa o plano alternativo, quais funções do cliente continuam, qual degradação é intencional e quais registros mostram que o cenário foi exercitado.

A Baxtel acrescenta o contexto do operador do data center e uma resposta pública da Flexential sobre cenários de rede elétrica [3]. Isso não deve virar julgamento completo de causa. Mostra, porém, que a cadeia de recuperação cruzou fronteiras organizacionais.

Superfície Heng.lu: continuidade operacional

A superfície Heng.lu é continuidade do operador e identidade de hospedagem/rede. Um diretório ou página de status pode nomear operador e instalação; não prova que configuração, análise, identidade e ferramentas sobrevivem à perda de um prédio. A camada real é a evidência de recuperação em execução.

O teste público deve evitar teatro de culpa. A questão é qual dependência estava no caminho crítico, se a Cloudflare a conhecia antes e qual exercício agora prova que a mesma dependência não removerá novamente a autoridade de controle.

O que observar

O primeiro sinal é a separação contínua entre saúde do tráfego de borda e saúde do plano de controle e análise. Um estado global verde não basta se clientes não conseguem mudar ou observar configuração.

O segundo sinal é se Code Orange vira padrão repetível de evidência: perda completa de instalação, teste de failover, medição de backlog, identidade disponível, ações de cliente bem-sucedidas e comparação com o incidente anterior. A lição duradoura é que transportar tráfego não basta. O operador ainda precisa ver, mudar, reiniciar e explicar o serviço quando um prédio crítico apaga.

Fontes

  1. https://blog.cloudflare.com/post-mortem-on-cloudflare-control-plane-and-analytics-outage/
  2. https://blog.cloudflare.com/major-data-center-power-failure-again-cloudflare-code-orange-tested/
  3. https://baxtel.com/news/cloudflare-blames-flexential-dc-outage-for-its-service-disruption