Resumo
- O que desconectou os data centers do Facebook no mundo inteiro foi um comando rotineiro de manutenção. O sistema de auditoria criado para barrar comandos desse tipo não barrou, porque tinha um bug.
- Quando o backbone sumiu, os servidores de DNS retiraram seus anúncios BGP exatamente como foram projetados para fazer. O fail-safe funcionou; por funcionar, converteu a ruptura interna em inacessibilidade externa.
- O acesso primário e o out-of-band caíram juntos, e a recuperação começou com engenheiros fisicamente dentro dos prédios. O que a auditoria virou depois, e quem aprovou seu desenho, não aparece no material público que esta leitura alcançou.
A Meta descreveu o episódio com uma franqueza incomum no próprio blog de engenharia. De “More details about the October 4 outage”:
"During one of these routine maintenance jobs, a command was issued with the intention to assess the availability of global backbone capacity, which unintentionally took down all the connections in our backbone network, effectively disconnecting Facebook data centers globally."
A intenção era medir. O resultado foi cortar tudo. Até aí, é a descrição de um acidente. O caso vira uma história sobre controle na frase seguinte:
"Our systems are designed to audit commands like these to prevent mistakes like this, but a bug in that audit tool prevented it from properly stopping the command."
O controle que a organização acreditava ter não era o controle que ela de fato tinha. Uma ferramenta de auditoria é software, e software carrega defeitos; a diferença é que ninguém a trata como algo que precisa de garantia própria. O registro interno do comando — o que ele atingia, até onde ia, quem o autorizou — não está entre os materiais que esta leitura conseguiu acessar. Por isso não há aqui suposição sobre a sintaxe do comando nem sobre quem o aprovou.
O segundo controle foi mais fiel ao projeto. Os servidores de DNS do Facebook retiram seus próprios anúncios BGP quando não conseguem falar com os data centers. Nas palavras da Meta:
"To ensure reliable operation, our DNS servers disable those BGP advertisements if they themselves can not speak to our data centers, since this is an indication of an unhealthy network connection. In the recent outage the entire backbone was removed from operation, making these locations declare themselves unhealthy and withdraw those BGP advertisements."
Não foi efeito colateral imprevisto. Foi comportamento projetado executando na condição para a qual foi projetado. Como o backbone inteiro desapareceu, todas as localidades se declararam doentes ao mesmo tempo e recolheram seus anúncios em uníssono. A ruptura interna virou inacessibilidade externa sem nenhum passo intermediário. Um fail-safe que compartilha o destino daquilo que protege amplia o dano na medida exata de sua correção.
A janela observada de fora é da Cloudflare. Em “Understanding how Facebook disappeared from the Internet”, a empresa registra que a resolução do nome facebook.com no resolver 1.1.1.1 parou por volta das 15:50 UTC e voltou às 21:20 UTC.
"It stopped being available at around 15:50 UTC and returned at 21:20 UTC."
A Cloudflare relata também que o Facebook interrompeu o anúncio de seus prefixos de DNS via BGP por volta das 15:58 UTC, e que a disrupção durou aproximadamente cinco horas e meia a seis horas. Essa duração é a moldura publicada pela Cloudflare, não um número declarado pela Meta. A mesma medição mostra atividade BGP retomada por volta das 21:00 UTC, com pico às 21:17 UTC.
A recuperação não começou por acesso remoto. A Meta descreve o limite físico daquele momento:
"Our primary and out-of-band network access was down, so we sent engineers onsite to the data centers to have them debug the issue and restart the systems. But this took time, because these facilities are designed with high levels of physical and system security in mind. They're hard to get into, and once you're inside, the hardware and routers are designed to be difficult to modify even when you have physical access to them."
Prédios difíceis de invadir são a decisão certa em tempos normais. Quando o acesso primário e o out-of-band caem ao mesmo tempo, a mesma solidez vira o fator que estica a recuperação de minutos para horas. A velocidade do runbook sempre para uma vez na porta.
A pergunta é uma só: quem audita o auditor? Uma ferramenta de auditoria só é controle quando seu próprio comportamento é testado e sua própria falha é visível. Nenhum dos dois testes aparece no registro público. O que mudaria a classificação do caso é concreto: um registro de que a ferramenta de auditoria tem testes de regressão próprios e de que esses testes são verificados por alguém independente de quem os escreveu; uma revisão periódica da política de fail-safe de DNS tendo o destino compartilhado como critério; e um exercício de recuperação executado sob a premissa de que o acesso primário e o out-of-band se perdem juntos.
Com esses três registros legíveis, o caso sai de “controle não verificado” e entra em “falha de um controle verificado”.
O que esta leitura efetivamente percorreu foram dois documentos: a publicação de engenharia da Meta e a análise de medição da Cloudflare. Plano de remediação, status de implementação, evidência de durabilidade, relatório de defeito da ferramenta de auditoria e rastro de autorização do comando não estavam legíveis. Também não havia análise independente de rotas além da Cloudflare, que é a única observação de terceiro em que este texto se apoia. O perfil corporativo da Facebook, Inc. está na entrada do diretório.
Briefing para membros
Contexto aprofundado da tendência
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Círculo Estratégico
Um briefing diário no seu idioma, construído a partir de mudanças que verificamos.
Assine por USD 20/mêsCancele quando quiser.
Candidate-se à Leadership Alliance
A reportagem pública continua gratuita. A pesquisa para membros, o briefing diário e o fórum exigem uma assinatura.






