Facebook fala sobre o incidente de 4 de outubro

Agora que nossas plataformas estão funcionando normalmente após a interrupção de 4 de outubro achei que valeria a pena compartilhar mais detalhes sobre o que aconteceu e por quê – e o mais importante, como estamos aprendendo com isso. 

Por Santosh Janardhan

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 centros de dados.

Esses data centers vêm em diferentes formas. Alguns são prédios enormes que abrigam milhões de máquinas que armazenam dados e executam as pesadas cargas computacionais 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 nossa rede de backbone para um data center maior. 

É aí que as informações necessárias para o seu aplicativo são recuperadas e processadas e enviadas de volta pela rede para o seu telefone.

O tráfego de dados entre todas essas instalações de computação é gerenciado por roteadores, que descobrem para onde enviar todos os dados de entrada e saída. 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.

Esta foi a fonte da interrupção do dia 4 de outubro de 2021.

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 em todo o mundo. 

Nossos sistemas são projetados para auditar comandos como esses para evitar erros como esse, mas um bug na ferramenta de auditoria a impediu de interromper o comando corretamente. 

Essa mudança causou uma desconexão completa de nossas conexões de servidor entre nossos centros de dados 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.

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 protocolo de gateway de fronteira (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 centros de dados, 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 do BGP. 

O resultado final foi que nossos servidores DNS ficaram 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 por quê, 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. 

Nosso acesso à rede principal e fora de banda estava desativado, então enviamos engenheiros no local aos data centers para que depurem o problema e reiniciem os sistemas. 

Mas isso levou tempo, porque essas instalações foram projetadas com altos níveis de segurança física e do sistema em mente. 

Eles são 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ê tiver 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 restaurada em todas as regiões de nosso data center, 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 um exercício de tempestade, 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 off-line, certamente estaremos procurando maneiras de simular eventos como esse daqui para frente.  

Cada falha como essa é uma oportunidade de aprender e melhorar, e há muito para aprendermos com ela. 

Depois de 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 extenso 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 cometido por nós mesmos. 

Acredito que uma troca como essa vale a pena – segurança diária muito aumentada versus uma recuperação mais lenta 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.

Fonte: Facebook