# Meta 2021: Como um Comando de Manutenção Derrubou o Facebook por 6 Horas Em 4 de outubro de 2021, um comando de manutenção mal executado retirou todas as rotas BGP do backbone da Meta, tornando os servidores DNS autoritativos inalcançáveis pela internet. O efeito cascata derrubou Facebook, Instagram, WhatsApp e Oculus simultaneamente por aproximadamente seis horas, afetando bilhões de usuários e expondo fragilidades críticas em sistemas de controle de acesso e recuperação de emergência. - URL: https://fernando.moretes.com/studies/meta-bgp-2021 - Markdown: https://fernando.moretes.com/studies/meta-bgp-2021/study.md?lang=pt - Type: Post-mortem - Company: Meta - Domain: Rede - Date: 2021-10-04 - Tags: bgp, dns, postmortem, networking, meta, facebook, outage, infrastructure - Reading time: 11 min --- ## Ficha do Incidente - **Empresa / Sistema:** Meta (Facebook, Instagram, WhatsApp, Oculus) - **Data:** 4 de outubro de 2021 - **Duração:** ~6 horas (aproximadamente 15h51 UTC até ~21h45 UTC) - **Impacto em usuários:** ~3,5 bilhões de usuários sem acesso a todos os serviços Meta - **Impacto financeiro (estimado):** ~US$ 60–100 milhões em receita publicitária perdida (estimativa de mercado) - **Serviços afetados:** Facebook, Instagram, WhatsApp, Oculus, Workplace, sistemas internos da Meta - **Causa raiz:** Remoção acidental de rotas BGP do backbone durante auditoria de capacidade de rede - **Stack / Protocolos:** BGP (Border Gateway Protocol), DNS autoritativo interno, FBTUN (backbone proprietário), ferramentas internas de gerenciamento de rede - **Tipo de falha:** Erro humano amplificado por ausência de salvaguardas e acoplamento excessivo entre plano de controle e plano de dados No dia 4 de outubro de 2021, um engenheiro da Meta executou um comando de manutenção de rotina para auditar a capacidade da rede de backbone. O comando funcionou exatamente como programado — e foi exatamente isso o problema. Em questão de minutos, todas as rotas BGP que anunciavam os prefixos IP da Meta para a internet foram retiradas. Os servidores DNS autoritativos da empresa, que residem dentro dessa mesma infraestrutura, tornaram-se inalcançáveis. Facebook, Instagram, WhatsApp e Oculus desapareceram da internet simultaneamente. O que se seguiu foi uma das maiores interrupções de serviço da história da internet moderna — e uma aula magistral sobre como sistemas de controle mal projetados podem transformar uma tarefa trivial em uma catástrofe global. ## O que Aconteceu: Da Auditoria ao Colapso Para entender o incidente, é preciso primeiro entender como a Meta estrutura sua rede global. A empresa opera uma das maiores redes privadas do mundo, com pontos de presença (PoPs) em dezenas de países conectados por um backbone proprietário. Esse backbone é anunciado para a internet via BGP — o protocolo de roteamento entre sistemas autônomos que, em termos simples, diz ao resto da internet "esses prefixos IP pertencem à Meta, envie o tráfego para cá". Na manhã de 4 de outubro, uma equipe de engenharia estava realizando trabalhos de manutenção na infraestrutura de backbone com o objetivo de auditar a capacidade disponível. Para isso, utilizaram uma ferramenta interna de gerenciamento de rede que, entre outras funções, permite modificar configurações de roteadores ao longo da espinha dorsal da rede. O comando emitido tinha a intenção de fazer uma varredura de capacidade — mas, devido a um bug na ferramenta ou a uma configuração incorreta do comando (a Meta não especificou publicamente qual dos dois), o sistema interpretou a instrução como uma ordem para desativar as conexões BGP em todos os roteadores do backbone simultaneamente. O resultado foi imediato e total: todos os prefixos IP da Meta foram retirados do BGP global. Do ponto de vista da internet, a Meta simplesmente deixou de existir. Nenhum resolver DNS no mundo conseguia mais alcançar os servidores autoritativos da Meta para resolver `facebook.com`, `instagram.com` ou `whatsapp.com` — porque esses servidores estavam atrás da mesma infraestrutura que acabara de ser desconectada. O DNS não estava com defeito em si; ele estava simplesmente inalcançável. O que tornou a situação ainda mais crítica foi o efeito colateral sobre os próprios sistemas internos da Meta. Ferramentas de monitoramento, sistemas de acesso remoto, e até os crachás de acesso físico aos data centers dependiam de serviços que também ficaram offline. Engenheiros que tentavam diagnosticar o problema remotamente perderam acesso às ferramentas necessárias para corrigi-lo. A equipe precisou enviar técnicos fisicamente aos data centers — um processo que levou horas, especialmente porque os sistemas de controle de acesso físico também estavam parcialmente afetados. ## Linha do Tempo do Incidente 1. **~15h51 UTC — Comando de manutenção emitido** — Engenheiro executa ferramenta interna de gerenciamento de rede para auditoria de capacidade do backbone. O comando, por bug ou misconfiguration, instrui roteadores a desativar sessões BGP em toda a espinha dorsal. 2. **~15h51–15h53 UTC — Retirada em cascata das rotas BGP** — Em aproximadamente dois minutos, todos os prefixos IP da Meta são retirados do BGP global. Roteadores ao redor do mundo param de encaminhar tráfego para a infraestrutura da Meta. O TTL das entradas DNS começa a expirar nos resolvers recursivos. 3. **~15h53 UTC — DNS falha globalmente** — Resolvers DNS recursivos ao redor do mundo tentam consultar os servidores autoritativos da Meta (a.ns.facebook.com, b.ns.facebook.com etc.) e recebem timeouts. facebook.com, instagram.com e whatsapp.com tornam-se irresolvíveis. Usuários começam a reportar falhas. 4. **~16h00 UTC — Alertas internos disparam; acesso remoto comprometido** — Sistemas de monitoramento da Meta detectam a queda, mas as próprias ferramentas de resposta a incidentes dependem de serviços que também estão offline. Engenheiros remotos perdem acesso a ferramentas de diagnóstico e gerenciamento. Comunicação interna via sistemas baseados em internet também é afetada. 5. **~16h30–18h00 UTC — Acesso físico aos data centers** — Equipes são despachadas fisicamente para os data centers. O processo é lento: sistemas de controle de acesso físico (crachás) dependem parcialmente de serviços afetados. Técnicos precisam de autorizações manuais de emergência para entrar em algumas instalações. 6. **~18h00–20h00 UTC — Diagnóstico e início da recuperação** — Com acesso físico estabelecido, engenheiros identificam a causa raiz: sessões BGP desativadas nos roteadores de backbone. Iniciam o processo de reativação manual das sessões BGP. A recuperação é deliberadamente gradual para evitar uma sobrecarga súbita nos sistemas que voltam ao ar. 7. **~20h00–21h45 UTC — Restauração gradual dos serviços** — Rotas BGP são readicionadas progressivamente. Servidores DNS autoritativos voltam a ser alcançáveis. Resolvers recursivos ao redor do mundo começam a resolver os domínios da Meta novamente. Serviços são restaurados de forma escalonada para evitar thundering herd. 8. **~21h45 UTC — Serviços totalmente restaurados** — Todos os serviços da Meta reportam operação normal. Duração total do incidente: aproximadamente 6 horas. ## Fluxo de Falha: BGP, DNS e o Colapso em Cascata O diagrama reconstrói o fluxo de falha: como a retirada das rotas BGP do backbone tornou os servidores DNS autoritativos inalcançáveis, o que por sua vez tornou todos os serviços da Meta irresolvíveis para o mundo inteiro. ### 🌐 Internet / External World - End User Browser / App (user) - ISP Recursive DNS Resolver (network) - Global BGP Routing Table (network) ### 🏢 Meta Edge / PoPs - Edge Routers (BGP Peers) (network) - Backbone Routers (BGP Sessions DISABLED ❌) (network) ### 🔧 Meta Internal — Control Plane - Network Mgmt Tool (Maintenance Cmd ⚠️) (ci) - Engineer (Issued Command) (user) ### 📡 Meta Internal — Data Plane - Authoritative DNS (a/b.ns.facebook.com) 🔴 (network) - Facebook App Servers 🔴 (compute) - Instagram App Servers 🔴 (compute) - WhatsApp App Servers 🔴 (compute) - Internal Tools & Monitoring 🔴 (compute) ### Fluxos - engineer -> mgmt_tool: 1. Emite comando de auditoria - mgmt_tool -> backbone_router: 2. Desativa sessões BGP ❌ - backbone_router -> edge_router: 3. Rotas retiradas - edge_router -> bgp_internet: 4. Prefixos Meta removidos do BGP global - user -> isp_resolver: 5. Resolve facebook.com? - isp_resolver -> auth_dns: 6. Consulta NS autoritativo → TIMEOUT ❌ - bgp_internet -> auth_dns: Inalcançável (sem rota BGP) - auth_dns -> fb_app: Nunca alcançado - mgmt_tool -> internal_tools: Ferramentas internas também offline > **Causa Raiz: Acoplamento Fatal entre Plano de Controle e Plano de Dados:** A causa raiz não foi apenas o comando incorreto — foi uma falha de design sistêmica em três camadas sobrepostas: **1. Ausência de dry-run e validação com blast radius:** A ferramenta de gerenciamento de rede permitia emitir comandos que afetavam *todos* os roteadores do backbone sem nenhum mecanismo de simulação prévia, confirmação escalonada ou limite de escopo. Um comando que deveria ser cirúrgico podia ser — e foi — global. **2. DNS autoritativo dentro do perímetro afetado:** Os servidores de nomes autoritativos da Meta (`a.ns.facebook.com`, `b.ns.facebook.com`) eram anunciados via os mesmos prefixos BGP que foram retirados. Isso criou uma dependência circular fatal: para alcançar qualquer serviço da Meta, o mundo precisava resolver o DNS; para resolver o DNS, precisava alcançar os servidores autoritativos; para alcançar os servidores autoritativos, precisava das rotas BGP que acabavam de desaparecer. **3. Plano de controle de recuperação dependente do plano de dados comprometido:** As ferramentas que os engenheiros precisariam usar para diagnosticar e corrigir o problema — sistemas de monitoramento, acesso remoto, comunicação interna — dependiam da mesma infraestrutura que estava offline. O sistema de recuperação estava acoplado ao sistema que falhou. ## A Armadilha do DNS Autoritativo: Uma Dependência Circular Invisível Um dos aspectos mais tecnicamente interessantes deste incidente é o papel específico do DNS — e por que ele não pôde se recuperar automaticamente mesmo quando parte da infraestrutura poderia ter sido restaurada mais rapidamente. O DNS funciona em camadas. Quando um resolver recursivo (como o 8.8.8.8 do Google ou o resolver do seu ISP) precisa resolver `facebook.com`, ele primeiro consulta os root servers para descobrir quem é o servidor autoritativo para `.com`, depois consulta os servidores TLD para descobrir quem é o autoritativo para `facebook.com`, e finalmente consulta os servidores de nomes da Meta diretamente. Esses servidores de nomes (`a.ns.facebook.com`, `b.ns.facebook.com` etc.) são os que retornam os endereços IP reais dos servidores de aplicação. O problema é que esses servidores de nomes autoritativos da Meta são endereços IP dentro dos próprios prefixos da Meta — os mesmos que foram retirados do BGP. Quando um resolver tentava alcançá-los, os pacotes simplesmente não tinham rota. Não era uma falha de DNS no sentido de "o servidor respondeu com erro" — era uma falha de alcançabilidade de rede. O servidor estava lá, funcionando, mas nenhum pacote conseguia chegar até ele. Isso tem uma implicação importante para o TTL (Time To Live) das entradas DNS. Os registros DNS da Meta tinham TTLs relativamente curtos — na faixa de minutos. Isso significa que os resolvers recursivos ao redor do mundo rapidamente descartaram suas entradas em cache e tentaram revalidar. Cada tentativa de revalidação resultava em timeout. O resultado foi uma tempestade de consultas DNS falhando globalmente, com nenhuma possibilidade de fallback, porque não havia servidores autoritativos alternativos fora do perímetro afetado. Uma prática de resiliência que teria mitigado isso seria manter servidores DNS autoritativos em ASNs (Autonomous System Numbers) separados, com prefixos BGP independentes, anunciados por diferentes provedores de trânsito. Isso é exatamente o que grandes operadoras de DNS gerenciado (como Cloudflare, AWS Route 53, NS1) fazem por design — distribuem seus servidores autoritativos por múltiplos ASNs para que a falha de um não comprometa a resolubilidade do domínio. ## Remediação: Por que Levou 6 Horas para Corrigir um Comando A pergunta natural ao ouvir este incidente é: "se o problema foi um comando que desativou sessões BGP, por que não bastou reativar as sessões BGP?" A resposta revela a segunda camada de falha sistêmica: o plano de controle de recuperação estava dentro do perímetro comprometido. A Meta opera uma infraestrutura de escala extraordinária — dezenas de data centers, centenas de pontos de presença, milhares de roteadores. O gerenciamento dessa infraestrutura é feito por ferramentas internas sofisticadas, acessíveis via redes corporativas que, por sua vez, dependem dos mesmos sistemas de backbone que estavam offline. Quando o backbone caiu, os engenheiros remotos perderam acesso às ferramentas de gerenciamento de rede. Não era possível simplesmente abrir um terminal e reativar as sessões BGP — as ferramentas para fazer isso estavam inacessíveis. A solução foi enviar engenheiros fisicamente aos data centers. Isso introduziu atrasos significativos por várias razões: a logística de mobilizar pessoas para locais físicos leva tempo; alguns data centers estão em locais remotos ou com acesso controlado; e, ironicamente, os sistemas de controle de acesso físico (leitores de crachá, sistemas de autenticação de porta) também dependiam parcialmente de serviços que estavam offline, exigindo procedimentos de autorização de emergência manual. Uma vez com acesso físico, os engenheiros puderam conectar-se diretamente aos roteadores via console e reativar as sessões BGP manualmente. Mas mesmo nesse ponto, a recuperação precisou ser cuidadosamente escalonada. Quando os serviços da Meta voltaram a ser alcançáveis, bilhões de clientes (aplicativos móveis, browsers, sistemas de terceiros) tentaram reconectar-se simultaneamente. Uma restauração abrupta poderia gerar um thundering herd — uma avalanche de requisições que sobrecarregaria os sistemas ainda se recuperando. A equipe optou por uma restauração gradual, readicionando prefixos BGP progressivamente e monitorando a carga em cada etapa. Essa experiência levou a Meta a anunciar mudanças estruturais: separação mais clara entre o plano de controle de gerenciamento e a infraestrutura de produção, criação de canais de acesso de emergência out-of-band que não dependam dos serviços de produção, e revisão dos processos de validação de comandos de alto impacto na infraestrutura de rede. ## Lições Técnicas do Incidente - **Blast radius deve ser uma restrição de primeira classe em ferramentas de infraestrutura.** Qualquer ferramenta que possa afetar múltiplos sistemas simultaneamente deve ter mecanismos de escopo obrigatório, simulação (dry-run), e confirmação escalonada. O custo de implementar essas salvaguardas é trivial comparado ao custo de um incidente global. - **DNS autoritativo nunca deve ser o único ponto de falha e deve residir em ASNs independentes.** Hospedar servidores de nomes autoritativos dentro dos mesmos prefixos BGP que dependem deles cria uma dependência circular. A solução padrão da indústria é distribuir servidores autoritativos por múltiplos ASNs com diferentes provedores de trânsito. - **O plano de controle de recuperação deve ser independente do plano de dados de produção.** Se as ferramentas necessárias para recuperar um sistema dependem do próprio sistema, a recuperação se torna exponencialmente mais difícil. Canais de acesso out-of-band (redes de gerenciamento dedicadas, acesso serial/console, VPNs com uplinks independentes) são requisitos de resiliência, não luxos. - **Sistemas de controle de acesso físico são infraestrutura crítica e devem ter fallback offline.** Badge readers e sistemas de autenticação de porta que dependem de serviços de rede em nuvem criam um ponto de falha inesperado em cenários de outage total. Esses sistemas devem funcionar em modo degradado offline. - **TTLs curtos de DNS amplificam o impacto de outages de alcançabilidade.** TTLs curtos são bons para agilidade operacional (propagação rápida de mudanças), mas em um cenário de falha de alcançabilidade, eles garantem que os caches expirem rapidamente e que todos os resolvers do mundo comecem a fazer consultas que falharão. Deve haver uma política de TTL de emergência e procedimentos para aumentar - **Testes de recuperação de desastres devem incluir cenários de "ferramentas offline".** Runbooks de recuperação frequentemente assumem que as ferramentas de diagnóstico e remediação estão disponíveis. Simular cenários onde essas ferramentas também estão indisponíveis — e praticar recuperação via acesso físico ou out-of-band — é essencial para organizações de escala crítica. > **Perspectiva de Arquiteto: O que eu faria diferente:** Trabalhei com sistemas financeiros onde uma janela de manutenção mal executada pode ter consequências regulatórias e de reputação severas. O incidente da Meta ressoa porque o padrão de falha é universal: **ferramentas de infraestrutura que não têm o conceito de "escopo máximo de impacto" embutido como restrição de hardware, não apenas de software**. Se eu fosse redesenhar o sistema de gerenciamento de rede da Meta com base no que sabemos agora, priorizaria três mudanças estruturais: **Primeiro, separação obrigatória de plano de controle.** A rede de gerenciamento de infraestrutura deve ser fisicamente separada da rede de produção — não apenas logicamente separada via VLANs ou VRFs, mas com uplinks de trânsito independentes e ASNs distintos. Isso é padrão em operadoras de telecomunicações sérias e deveria ser padrão em qualquer empresa que opere backbone próprio. O custo é real, mas é uma fração do custo de um único incidente desse porte. **Segundo, DNS autoritativo em ASNs verdadeiramente independentes.** Não é suficiente ter servidores DNS em data centers diferentes se eles são todos anunciados pelo mesmo AS. A Meta deveria ter (e provavelmente tem agora) servidores autoritativos anunciados por ASNs separados com provedores de trânsito distintos — exatamente como o Cloudflare, AWS Route 53 e outros grandes operadores de DNS fazem. Isso não é paranoia; é engenharia de resiliência básica para um ativo tão crítico quanto o DNS. **Terceiro, e mais importante: blast radius como primitiva de primeira classe em tooling.** Toda ferramenta que pode emitir comandos para infraest ## Veredicto: Uma Falha de Design, Não de Operação O incidente da Meta em outubro de 2021 é frequentemente descrito como "erro humano" — e tecnicamente, um humano emitiu um comando que causou o problema. Mas essa descrição é incompleta e, na minha visão, perigosa, porque desvia a atenção das falhas sistêmicas que tornaram possível que um único comando derrubasse toda a empresa. A falha real foi de design em três níveis: (1) uma ferramenta de gerenciamento de rede sem restrições de blast radius; (2) servidores DNS autoritativos dentro do mesmo perímetro BGP que dependiam deles, criando uma dependência circular; e (3) um plano de controle de recuperação acoplado ao plano de dados que falhou. Qualquer uma dessas falhas individualmente seria gerenciável. As três juntas transformaram um erro operacional em uma catástrofe global de seis horas. A lição central para arquitetos e engenheiros sênior é esta: **em sistemas de escala crítica, a pergunta não é "podemos evitar todos os erros humanos?" — a resposta é sempre não. A pergunta é "quando um erro humano inevitável ocorrer, qual é o blast radius máximo possível, e estamos confortáveis com ele?"** Se a resposta for "pode derrubar tudo", o design precisa mudar. O incidente também serve ## Referências - [Meta Engineering — More details about the October 4 outage](https://engineering.fb.com/2021/10/05/networking-traffic/outage-details/) ## Fontes do caso - [Meta Engineering — More details about the October 4 outage](https://engineering.fb.com/2021/10/05/networking-traffic/outage-details/)