O final do primeiro e início do segundo mês do verão de 2019 revelou-se difícil e foi marcado por várias quedas importantes nos serviços globais de TI. Entre os mais notáveis: dois incidentes graves na infraestrutura CloudFlare (o primeiro - com mãos tortas e atitude negligente em relação ao BGP por parte de alguns ISPs dos EUA; o segundo - com uma implantação desonesta dos próprios CF, que afetou todos que usam CF , e esses são muitos serviços notáveis) e operação instável da infraestrutura CDN do Facebook (afetou todos os produtos do FB, incluindo Instagram e WhatsApp). Também tivemos que nos envolver na distribuição, embora a nossa interrupção tenha sido muito menos perceptível no contexto global. Alguém já começou a trazer helicópteros negros e conspirações “soberanas”, por isso estamos divulgando uma autópsia pública do nosso incidente.
03.07.2019, 16: 05
Começaram a ser registrados problemas com recursos, semelhantes a uma quebra na conectividade da rede interna. Não tendo verificado tudo completamente, começaram a criticar o desempenho do canal externo em direção ao DataLine, pois ficou claro que o problema era com o acesso da rede interna à Internet (NAT), a ponto de colocar a sessão BGP em direção ao DataLine.
03.07.2019, 16: 35
Tornou-se óbvio que o equipamento que fornecia tradução de endereços de rede e acesso da rede local do site à Internet (NAT) havia falhado. As tentativas de reiniciar o equipamento não deram em nada, a busca por opções alternativas para organizar a conectividade começou antes de receber uma resposta do suporte técnico, pois pela experiência isso provavelmente não teria ajudado.
O problema foi um pouco agravado pelo facto de este equipamento também encerrar ligações de entrada de funcionários clientes VPN, e o trabalho de recuperação remota tornou-se mais difícil de realizar.
03.07.2019, 16: 40
Tentamos reviver um esquema NAT de backup existente anteriormente que funcionava bem antes. Mas tornou-se claro que uma série de remodelações de rede tornaram este esquema quase completamente inoperante, uma vez que a sua restauração poderia, na melhor das hipóteses, não funcionar ou, na pior das hipóteses, quebrar o que já estava a funcionar.
Começamos a trabalhar em algumas ideias para transferir tráfego para um conjunto de novos roteadores que atendem ao backbone, mas elas pareciam inviáveis devido às peculiaridades da distribuição de rotas na rede principal.
03.07.2019, 17: 05
Ao mesmo tempo, foi identificado um problema no mecanismo de resolução de nomes nos servidores de nomes, o que levou a erros na resolução de endpoints em aplicativos, e eles começaram a preencher rapidamente os arquivos hosts com registros de serviços críticos.
03.07.2019, 17: 27
A funcionalidade limitada do Habr foi restaurada.
03.07.2019, 17: 43
Mas no final foi encontrada uma solução relativamente segura para organizar o tráfego através de um dos roteadores de fronteira, que foi rapidamente instalado. A conectividade com a Internet foi restaurada.
Nos minutos seguintes, muitas notificações vieram dos sistemas de monitoramento sobre a restauração da funcionalidade dos agentes de monitoramento, mas alguns dos serviços ficaram inoperantes porque o mecanismo de resolução de nomes nos servidores de nomes (DNS) estava quebrado.
03.07.2019, 17: 52
O NS foi reiniciado e o cache foi limpo. A resolução foi restaurada.
03.07.2019, 17: 55
Todos os serviços começaram a funcionar exceto MK, Freelansim e Toaster.
03.07.2019, 18: 02
MK e Freelansim começaram a trabalhar.
03.07.2019, 18: 07
Traga de volta uma sessão BGP inocente com DataLine.
03.07.2019, 18: 25
Começaram a registar problemas de recursos, o que se deveu a uma alteração do endereço externo do pool NAT e à sua ausência na acl de vários serviços, o que foi prontamente corrigido. A torradeira começou a funcionar imediatamente.
03.07.2019, 20: 30
Notamos erros relacionados aos bots do Telegram. Acontece que eles esqueceram de registrar o endereço externo em alguns acl (servidores proxy), o que foi prontamente corrigido.
Descobertas
- O equipamento, que anteriormente suscitava dúvidas sobre a sua idoneidade, falhou. Havia planos para eliminá-lo do trabalho, pois interferia no desenvolvimento da rede e apresentava problemas de compatibilidade, mas ao mesmo tempo desempenhava uma função crítica, razão pela qual qualquer substituição era tecnicamente difícil sem interromper os serviços. Agora você pode seguir em frente.
- O problema do DNS pode ser evitado aproximando-os da nova rede backbone fora da rede NAT e ainda tendo conectividade total com a rede cinza sem tradução (que era o plano antes do incidente).
- Você não deve usar nomes de domínio ao montar clusters RDBMS, pois a conveniência de alterar o endereço IP de forma transparente não é particularmente necessária, uma vez que tais manipulações ainda exigem a reconstrução do cluster. Esta decisão foi ditada por razões históricas e, em primeiro lugar, pela obviedade dos endpoints por nome nas configurações do RDBMS. Em geral, uma armadilha clássica.
- Em princípio, foram realizados exercícios comparáveis à “soberania do Runet”, há algo em que pensar em termos de fortalecimento das capacidades de sobrevivência autônoma.
Fonte: habr.com