#!/intro
No dia 4 de outubro, durante quase seis horas, o Facebook, o Instagram e o WhatsApp desapareceram da Internet.
A indisponibilidade começou por parecer uma falha de DNS. Os servidores autoritativos deixaram de estar acessíveis e os prefixos usados pelo serviço deixaram de ser anunciados através de BGP. Para o resto da Internet, era como se a infraestrutura do Facebook tivesse deixado de existir.
Mas o DNS não esteve na origem do incidente.
A causa foi uma alteração interna que retirou de serviço as ligações do backbone global. A partir desse momento, vários mecanismos automáticos reagiram como previsto, mas fizeram-no perante uma situação para a qual não tinham sido concebidos.
O resultado não foi apenas a perda dos serviços públicos. A mesma falha atingiu os acessos e as ferramentas necessárias para diagnosticar o incidente e recuperar a infraestrutura.
> sintomas
Os primeiros sinais apontavam para uma falha generalizada de DNS. Os servidores autoritativos dos domínios do Facebook deixaram de responder e os nomes associados ao Facebook, Instagram e WhatsApp deixaram de ser resolvidos.
A observação das tabelas globais de encaminhamento revelou depois que os prefixos usados pela infraestrutura de DNS tinham deixado de ser anunciados através de BGP. Sem esses anúncios, os restantes sistemas autónomos deixaram de dispor de rotas para alcançar os servidores autoritativos.
A falha de DNS era apenas o primeiro sintoma. A retirada dos anúncios BGP fazia com que toda a infraestrutura responsável por esses domínios deixasse de ser alcançável.
Para a Internet, o Facebook tinha deixado de existir. Os seus domínios não podiam ser resolvidos e os prefixos que permitiam chegar à sua infraestrutura já não constavam das tabelas de encaminhamento.
Faltava determinar o que tinha provocado a retirada simultânea dos anúncios BGP.
> origem
A origem do incidente esteve numa operação corrente de manutenção da rede.
Os técnicos pretendiam avaliar a capacidade disponível no backbone global. O comando executado para esse efeito acabou por retirar de serviço todas as suas ligações, interrompendo a comunicação entre os centros de dados e as instalações que asseguravam a ligação à Internet.
Existia uma ferramenta destinada a auditar este tipo de comandos. Deveria ter identificado o risco e impedido a execução. Não o fez porque continha uma falha.
Classificar o incidente apenas como erro humano seria tecnicamente redutor. Os erros são inevitáveis em qualquer operação complexa. O problema não foi apenas a execução de um comando incorreto. Foi a possibilidade de esse comando produzir um efeito global antes de qualquer mecanismo independente conseguir limitar as consequências.
Quando uma única alteração consegue retirar de serviço todo o backbone, a validação prévia não pode constituir a única barreira entre a intenção e o resultado.
Uma ferramenta de controlo também é software. Pode conter falhas, interpretar incorretamente o estado da infraestrutura ou não reconhecer uma combinação de condições que nunca foi prevista. Quando toda a proteção da operação depende dessa ferramenta, a falha do controlo devolve à alteração todo o seu potencial destrutivo.
Alterações com este alcance devem ser aplicadas progressivamente, começando por domínios de falha limitados. A progressão deve depender da observação do comportamento real da rede e de critérios explícitos de interrupção, não apenas da aprovação inicial do comando.
Não basta validar aquilo que se pretende executar. É necessário limitar aquilo que a execução consegue afetar.
> propagacao
A perda do backbone interrompeu a comunicação entre os centros de dados e as instalações onde se encontravam os servidores DNS autoritativos.
Essas instalações verificavam continuamente se conseguiam comunicar com a infraestrutura interna. Quando essa comunicação falhava, os servidores DNS retiravam os respetivos anúncios BGP.
A lógica era válida.
Uma instalação sem ligação aos centros de dados poderia deixar de conseguir responder corretamente aos pedidos recebidos. Ao retirar os anúncios BGP, o tráfego deixaria de ser encaminhado para essa localização e poderia seguir para outra instalação considerada operacional.
O mecanismo tinha sido concebido para conter uma falha localizada.
Quando todo o backbone foi retirado de serviço, todas as instalações perderam simultaneamente a comunicação com os centros de dados. Todas observaram a mesma condição e todas retiraram os respetivos anúncios.
Os servidores DNS continuavam operacionais, mas os seus prefixos tinham deixado de ser anunciados. Sem uma rota para os servidores autoritativos, os servidores DNS recursivos deixaram de conseguir obter os endereços dos serviços do Facebook.
Não foi o DNS que desligou a infraestrutura. Foi a perda do backbone que levou os servidores DNS a retirar os anúncios através dos quais podiam ser alcançados. Cada mecanismo executou o comportamento para o qual tinha sido concebido. O backbone deixou de transportar tráfego. Os mecanismos de verificação detetaram a perda de conectividade. Os servidores DNS retiraram os anúncios. O BGP propagou essa decisão à Internet.
Individualmente, cada reação era defensável. Em conjunto, tornaram toda a infraestrutura inacessível.
A redundância geográfica foi anulada porque todas as localizações dependiam da conectividade ao mesmo backbone e do respetivo plano de gestão. A distribuição física dos serviços não eliminava, por isso, o ponto único de falha existente no controlo da infraestrutura.
Replicar componentes não é suficiente quando todas as réplicas partilham a mesma dependência, observam o mesmo indicador e falham da mesma forma.
> recuperacao
A retirada dos anúncios BGP tornou os serviços inacessíveis a partir da Internet. O problema agravou-se quando os técnicos tentaram recuperar a infraestrutura.
Os meios habituais de acesso remoto aos centros de dados estavam indisponíveis. Os acessos fora de banda também tinham deixado de funcionar. A perda do DNS afetou ainda várias ferramentas internas utilizadas para diagnosticar e resolver incidentes.
Os técnicos sabiam que existia uma indisponibilidade global, mas tinham perdido parte dos meios necessários para determinar a sua origem e intervir nos equipamentos afetados. Foi necessário enviar equipas para os centros de dados e obter acesso físico à infraestrutura.
Os centros de dados estavam protegidos por controlos físicos rigorosos. Mesmo depois de autorizada a entrada, os equipamentos de encaminhamento tinham sido deliberadamente configurados para dificultar alterações através de acesso local.
Uma organização com a dimensão do Facebook deve impedir que a simples presença física junto de um equipamento permita alterar componentes críticos. O problema estava na inexistência, naquele cenário, de um caminho de recuperação suficientemente independente da infraestrutura afetada.
Um acesso fora de banda não é apenas um segundo endereço, uma interface adicional ou outra ligação para o mesmo sistema de administração. Tem de continuar disponível quando o encaminhamento interno falha. Não pode depender do mesmo DNS, dos mesmos serviços de diretório e identidade, nem dos mesmos caminhos de rede que pretende recuperar. As credenciais, os procedimentos e os canais de comunicação necessários também têm de permanecer acessíveis. Caso contrário, existe uma alternativa documentada, mas não existe independência operacional.
A recuperação também não pode depender dos componentes que estão a ser alterados. Um mecanismo de reversão que utiliza a mesma infraestrutura afetada deixa de ser um mecanismo de recuperação quando essa infraestrutura desaparece.
O incidente expôs uma dependência particularmente perigosa: a organização precisava da rede para reparar a própria rede.
O restabelecimento dos serviços também teve de ser controlado. Depois de várias horas de indisponibilidade, a reativação simultânea de toda a infraestrutura poderia provocar aumentos súbitos de carga nos sistemas internos, nas bases de dados e nos serviços de autenticação.
Recuperar a conectividade não significava que todos os serviços pudessem regressar imediatamente. A reposição teve de ser gradual para evitar que a recuperação desencadeasse uma nova falha.
> conclusao
O incidente expôs uma fragilidade arquitectural recorrente: a concentração da produção, da gestão e da recuperação no mesmo domínio de falha.
Nestas condições, a replicação de componentes preserva capacidade instalada, mas não garante continuidade operacional. Quando as várias instâncias dependem dos mesmos sinais, dos mesmos serviços de suporte e dos mesmos caminhos de administração, uma falha comum neutraliza toda a redundância disponível.
A arquitetura deve impedir que uma alteração isolada se propague a toda a infraestrutura. Isso exige segmentação por domínios de falha, aplicação progressiva de alterações, critérios automáticos de interrupção e mecanismos de reversão independentes dos componentes alterados. A validação prévia reduz o risco, mas não substitui a contenção do impacto.
A mesma independência é necessária no plano de gestão. Os acessos administrativos, a monitorização, os serviços de identidade, os canais de comunicação e os procedimentos de emergência não podem depender integralmente da infraestrutura de produção. Um acesso designado como fora de banda só o é quando permanece operacional perante a falha total dos caminhos normais.
O incidente demonstra também os limites da automatização baseada em pressupostos locais. Um mecanismo pode executar corretamente a sua função e, ainda assim, agravar uma falha global. A automatização deve considerar falhas correlacionadas, estados incoerentes e cenários em que todas as localizações observam simultaneamente a mesma condição.
A gestão de alterações em infraestruturas críticas não pode limitar-se à autorização, revisão e auditoria. Deve controlar tecnicamente o âmbito de impacto e garantir que nenhuma operação dispõe, por omissão, de capacidade para comprometer toda a infraestrutura.
A recuperação tem ainda de ser tratada como uma capacidade autónoma. Não basta documentar procedimentos ou manter componentes alternativos. É necessário testar se continuam acessíveis e operacionais quando os sistemas principais, as ferramentas internas e os serviços de suporte deixam de estar disponíveis.
O Facebook não ficou indisponível por falta de redundância. Ficou sem capacidade de recuperação porque a operação, a gestão e a resposta pertenciam ao mesmo domínio de falha.
Quando os meios de recuperação dependem da infraestrutura que falhou, não são meios de recuperação.
São parte da falha.
> status: offline> exit 0