Por que tentar de novo não trazia o Facebook de volta

Resumo

• Os serviços ficaram difíceis de alcançar depois que uma ordem de manutenção desconectou a rede central e levou à retirada de rotas DNS.
• Reconectar a rede não significava recuperar todos os aplicativos naquele instante. A retomada também exigia acesso aos equipamentos e cuidado com a carga.

Fechar, abrir de novo, tentar outro aplicativo. São gestos que dão ao usuário alguma coisa para fazer quando a conexão falha. Em 4 de outubro de 2021, porém, trocar Facebook por Instagram ou WhatsApp não contornava a queda: os três serviços foram atingidos. Para quem usava esses aplicativos para conversar, o problema continuava depois da troca de tela.

As novas tentativas não podiam executar o trabalho necessário dentro da empresa. E esse trabalho tinha um obstáculo incomum: os engenheiros também haviam perdido meios de entrar em seus próprios sistemas. Antes de devolver o acesso ao público, precisavam recuperar acesso para consertar a rede.

Por isso, não era uma espera que pudesse terminar simplesmente porque alguém insistiu mais uma vez. Havia conexões a restabelecer, equipes enviadas aos locais e, depois, serviços a reiniciar sem sobrecarregar tudo de uma vez. As máquinas, para complicar a explicação, nem sempre tinham parado.

As máquinas não tinham desligado

DNS é o sistema usado para encontrar o endereço de um serviço a partir do nome. Segundo o relato técnico do Facebook, seus servidores DNS estavam operacionais. O problema era chegar até eles.

A origem foi uma manutenção da rede central que interligava os centros de dados. Um comando deveria avaliar a capacidade disponível, mas acabou desconectando os enlaces. Uma falha no programa de auditoria impediu que a verificação prevista barrasse a operação.

Sem alcançar os centros de dados pela rede central, os servidores DNS retiraram seus anúncios BGP, conforme a lógica do sistema. Esses anúncios informam a outras redes por onde alcançar certos destinos. Sem as rotas, o fato de um servidor continuar ligado e trabalhando não garantia que uma consulta pudesse chegar.

Por fora, Cloudflare percebeu um aumento acentuado de mudanças de roteamento por volta de 15h40 UTC e a retirada das rotas dos prefixos DNS às 15h58. Outros prefixos do Facebook continuavam com rotas. O registro confirma sintomas visíveis, não cada etapa interna narrada pela empresa.

Quem conserta também precisa de acesso

O Facebook informou que perdeu tanto o acesso normal à rede quanto o acesso de gerenciamento fora de banda, pensado como uma via separada. A perda do DNS também prejudicou ferramentas internas de investigação. O relato não demonstra que a falha do DNS tenha causado especificamente a perda da via fora de banda; são problemas documentados cuja ligação exata não deve ser inventada.

Engenheiros foram enviados aos locais para recuperar o acesso. As barreiras de segurança física e dos sistemas dificultaram a entrada e as alterações nos equipamentos. Isso explica parte do esforço de recuperação, mas não permite transformar toda a queda em uma viagem de carro nem atribuir a tarefa a um único técnico.

Depois de religar as conexões centrais, ainda havia risco na volta. Reativar tudo de uma vez poderia provocar saltos de tráfego e de demanda elétrica. A empresa descreveu uma retomada cuidadosa, ajudada por exercícios anteriores de falhas. A perda completa da rede central mundial, porém, não tinha sido ensaiada.

A rota voltou antes de a história acabar

Cloudflare viu atividade BGP reaparecer perto das 21h UTC, com pico às 21h17. Às 21h28, a reconexão global e a resolução DNS pareciam restauradas. Os aplicativos podiam precisar de mais tempo.

Entre 15h58 e 21h28 há 330 minutos. O número mede o intervalo entre dois registros externos. Não mede a experiência exata de cada usuário nem o tempo gasto pelos engenheiros no deslocamento. Da mesma forma, os dezoito minutos entre as primeiras observações não provam qual foi a janela interna de detecção.

Para quem estava tentando abrir um aplicativo, pouco importava qual etapa faltava. Para entender por que o retorno demorou, importa bastante: alcançar equipamentos, restabelecer conexões e recuperar o serviço não eram uma única ação.

Havia ainda o trabalho criado pelas tentativas repetidas. Aplicativos e resolvedores insistiam nas consultas DNS, sem poder recriar as rotas ausentes. Cloudflare relatou maior demora nas respostas mais lentas de seu resolvedor 1.1.1.1, mas a maioria das consultas ainda terminava em menos de dez milissegundos. A carga extra chegou a outros sistemas; não derrubou toda a internet.

Os dois relatos de 2021 permitem acompanhar essa dificuldade. Não permitem certificar a arquitetura atual de Meta Platforms ou afirmar que as melhorias posteriores foram, ou deixaram de ser, implementadas. A parte mais esclarecedora do episódio não exige essa extrapolação: até uma máquina funcionando depende de caminhos que podem falhar, inclusive o caminho de quem vai repará-los.

Correção em 21 de outubro de 2026: foram separados os problemas de acesso de gerenciamento e das ferramentas dependentes de DNS. O intervalo observado não é tratado como tempo de viagem nem como duração universal da queda. Também foram retiradas conclusões sobre a arquitetura atual sem apoio nesses relatos de 2021.