O comando que tirou WhatsApp, Instagram e Facebook do ar

Em 4 de outubro de 2021, WhatsApp, Instagram e Facebook ficaram indisponíveis por quase seis horas. A duração é aproximada: a volta de uma rota, de uma resposta DNS e de um aplicativo são sinais diferentes de recuperação. As medições externas da Kentik ajudam a acompanhar esse retorno sem inventar um segundo único em que tudo voltou para todos. Fonte 4

Naquela data, o nome corporativo ainda era Facebook. A marca Meta seria anunciada em 28 de outubro. A mudança posterior de nome não explica a interrupção. Fonte 5

O efeito de uma manutenção

Segundo a engenharia do Facebook, um comando destinado a avaliar a capacidade disponível da rede principal interrompeu suas conexões. Uma falha na ferramenta de auditoria impediu o bloqueio da operação. A rede que ligava centros de dados ficou desconectada. Fonte 1

Esse é o relato interno da empresa sobre o mecanismo. Não identifica, para esta análise, uma intenção de provocar o apagão. As medições de outras organizações mostram o desaparecimento dos caminhos de acesso, mas não revelam a motivação de quem executou o comando.

O endereço existia, mas o caminho desapareceu

DNS associa nomes como facebook.com a endereços usados pelos computadores. BGP permite anunciar por quais caminhos redes podem ser alcançadas. A Cloudflare observou mudanças nos anúncios de rotas e falhas nas consultas de nomes durante a interrupção. Fonte 3

Segundo o Facebook, seus servidores DNS retiravam anúncios BGP quando não conseguiam se comunicar com os centros de dados. Com a rede principal interrompida, esse mecanismo tornou os servidores de nomes inacessíveis, embora continuassem operando. Fonte 1

Portanto, o DNS não precisou ser apagado para deixar de responder aos usuários. Um serviço pode estar ligado e, ainda assim, não existir um caminho utilizável até ele. Trocar uma configuração no celular não restauraria as conexões internas da empresa.

Quem precisava consertar também perdeu acesso

O comunicado inicial reconheceu o impacto nas ferramentas internas usadas na recuperação. A explicação posterior descreveu a necessidade de intervenção local e dificuldades de acesso aos centros de dados. Fontes 1 e 2

A correção dependia de chegar a equipamentos e ferramentas que a própria falha havia tornado difíceis de alcançar. Essa dependência ajuda a explicar por que identificar a mudança problemática não significava revertê-la imediatamente.

Nossa leitura editorial é que um caminho de recuperação precisa ser avaliado junto com o serviço. Quando ambos dependem da mesma infraestrutura, uma única interrupção pode retirar a operação e dificultar o conserto ao mesmo tempo.

Voltar também exige cuidado

Os gráficos da Kentik registraram a queda brusca de tráfego e sinais de retorno horas depois. A Cloudflare acompanhou a reaparição de rotas e a retomada de respostas DNS. Esses registros descrevem partes da recuperação, não a experiência simultânea de cada usuário. Fontes 3 e 4

O caso mostra como aplicativos aparentemente separados compartilham dependências capazes de derrubá-los em conjunto. Não é necessário atribuir um prejuízo financeiro sem fonte ou supor um ataque para compreender a escala do episódio.

Na investigação da CrowdStrike, a dificuldade era levar a correção às máquinas que já não inicializavam normalmente. Aqui, era recuperar o acesso à infraestrutura que sustentava os próprios meios de reparo. Em ambos, a forma de recuperação faz parte da explicação da duração.