Agora que nossas plataformas estão funcionando normalmente após a interrupção de ontem, compartilho detalhes adicionais sobre o que aconteceu e por quê – e, o mais importante, como estamos aprendendo com isso.
Essa interrupção foi provocada pelo sistema que gerencia nossa capacidade de rede de backbone global. O backbone é a rede que o Facebook construiu para conectar todas as nossas instalações de computação, que consiste em dezenas de milhares de quilômetros de cabos de fibra óptica cruzando o globo e conectando todos os nossos data centers.
Esses data centers possuem diferentes formas. Alguns são prédios enormes que abrigam milhões de máquinas que armazenam dados e executam cargas computacionais pesadas que mantêm nossas plataformas funcionando, e outros são instalações menores que conectam nossa rede de backbone à internet mais ampla e às pessoas que usam nossas plataformas.
Quando você abre um de nossos aplicativos e carrega seu feed ou mensagens, a solicitação de dados do aplicativo viaja de seu dispositivo para a instalação mais próxima, que então se comunica diretamente por meio de nossa rede de backbone para um data center maior. É aí que as informações necessárias para seu aplicativo são recuperadas, processadas e enviadas de volta da rede para o seu dispositivo.
O tráfego de dados entre todas essas instalações de computação é gerenciado por roteadores, que descobrem para onde enviar todos os dados entrando e saindo. E no extenso trabalho diário de manutenção dessa infraestrutura, nossos engenheiros geralmente precisam fazer parte do backbone offline para manutenção – talvez consertando uma linha de fibra, adicionando mais capacidade ou atualizando o software no próprio roteador.
Isso foi a origem da interrupção de ontem. Durante um desses trabalhos de manutenção de rotina, um comando foi emitido com a intenção de avaliar a disponibilidade da capacidade do backbone global, que involuntariamente derrubou todas as conexões em nossa rede de backbone, desconectando efetivamente os data centers do Facebook globalmente. Nossos sistemas são projetados para auditar comandos como esses, a fim de evitar erros como esse, mas um bug nessa ferramenta de auditoria não interrompeu o comando corretamente.
Essa mudança causou uma desconexão completa de nossas conexões de servidor entre nossos data centers e a internet. E essa perda total de conexão causou um segundo problema que piorou as coisas.
Um dos trabalhos realizados por nossas instalações menores é responder a consultas de DNS (Domain Name System). DNS é o catálogo de endereços da internet, permitindo que os nomes simples da Web que digitamos nos navegadores sejam traduzidos em endereços IP de servidor específicos. Essas consultas de tradução são respondidas por nossos servidores de nomes autorizados que ocupam endereços IP bem conhecidos, que por sua vez são anunciados para o resto da internet por meio de outro protocolo chamado Border Gateway Protocol (BGP).
Para garantir uma operação confiável, nossos servidores DNS desativam esses anúncios BGP se eles próprios não puderem falar com nossos data centers, uma vez que isso é uma indicação de uma conexão de rede não íntegra. Na recente interrupção, todo o backbone foi retirado de operação, fazendo com que esses locais se declarassem insalubres e retirassem os anúncios BGP. O resultado final foi que nossos servidores DNS tornaram-se inacessíveis, embora ainda estivessem operacionais. Isso impossibilitou que o restante da internet encontrasse nossos servidores.
Tudo isso aconteceu muito rápido. E enquanto nossos engenheiros trabalhavam para descobrir o que estava acontecendo e o motivo, eles enfrentaram dois grandes obstáculos: primeiro, não foi possível acessar nossos data centers por nossos meios normais porque suas redes estavam desligadas e, segundo, a perda total de DNS quebrou muitas das ferramentas internas que normalmente usamos para investigar e resolver interrupções como esta.
Nossos acessos à rede principal e à rede fora de banda estavam desativados, então enviamos engenheiros aos data centers para que resolvessem o problema e reiniciassem os sistemas. Mas isso levou tempo, porque essas instalações foram projetadas com altos níveis de segurança física e de sistema. São instalações difíceis de entrar e, uma vez dentro, o hardware e os roteadores são projetados para serem difíceis de modificar, mesmo quando você tem acesso físico a eles. Portanto, demorou mais para ativar os protocolos de acesso seguro necessários para colocar as pessoas no local e poder trabalhar nos servidores. Só então poderíamos confirmar o problema e colocar nosso backbone online novamente.
Depois que nossa conectividade de rede de backbone foi restabelecida em todas as regiões de nossos data centers, tudo voltou com ela. Mas o problema não acabou – sabíamos que reativar nossos serviços de uma só vez poderia causar uma nova rodada de acidentes devido a um aumento no tráfego. Os data centers individuais relatavam quedas no uso de energia na faixa de dezenas de megawatts e, repentinamente, reverter essa queda no consumo de energia poderia colocar em risco tudo, desde sistemas elétricos a caches.
Felizmente, este é um evento para o qual estamos bem preparados graças aos “exercícios de tempestade” que temos executado há muito tempo. Em exercícios como esse, simulamos uma grande falha do sistema colocando um serviço, data center ou região inteira offline, testando toda a infraestrutura e software envolvidos. A experiência com esses exercícios nos deu a confiança e a experiência para colocar as coisas novamente online e gerenciar cuidadosamente as cargas crescentes. No final, nossos serviços voltaram a funcionar com relativa rapidez, sem mais falhas em todo o sistema. E embora nunca tenhamos enfrentado uma tempestade que simulasse nosso backbone global sendo colocado offline, certamente vamos procurar maneiras de simular eventos como este daqui para frente.
Cada falha como essa é uma oportunidade de aprender e melhorar, e há muito para aprendermos com ela. Após cada problema, pequeno e grande, fazemos um amplo processo de revisão para entender como podemos tornar nossos sistemas mais resilientes. Esse processo já está em andamento.
Fizemos um amplo trabalho de proteção de nossos sistemas para impedir o acesso não autorizado, e foi interessante ver como essa proteção nos deixou mais lentos enquanto tentávamos nos recuperar de uma interrupção causada não por atividade maliciosa, mas por um erro de nossa autoria. Acredito que um tradeoff assim vale a pena – segurança diária muito elevada versus uma recuperação mais lenta no caso de um evento raro como este. De agora em diante, nosso trabalho é fortalecer nossos testes, exercícios e resiliência geral para garantir que eventos como esse aconteçam o menos possível.