O final do primeiro e o início do segundo mês do verão de 2019 acabou sendo difícil e foi marcado por várias quedas importantes nos serviços mundiais de TI. Dos notáveis: dois incidentes graves na infraestrutura CloudFlare (o primeiro - com mãos tortas e atitude descuidada em relação ao BGP por alguns ISPs dos EUA; o segundo - com a implantação distorcida dos próprios CFs, afetou todos os que usam CF e são muitos serviços notáveis) e operação instável da infraestrutura da CDN do Facebook (afetou todos os produtos do FB, incluindo Instagram e WhatsApp). Também tivemos que ficar de fora da distribuição, embora nossa interrupção fosse muito menos perceptível em um cenário global. Alguém já começou a arrastar helicópteros pretos e conspirações "soberanas"; portanto, estamos lançando um post mortem público de nosso incidente.
07/03/2019, 16:05Começamos a corrigir problemas de recursos, semelhantes a uma violação da conectividade de rede interna. Não tendo verificado tudo completamente, começaram a pecar na operacionalidade do canal externo na direção da Data Line, pois ficou claro que havia um problema com o acesso da rede interna à Internet (NAT), até o ponto em que colocavam a sessão BGP na direção da DataLine.
07/03/2019, 16:35Tornou-se óbvio que o equipamento que executava a tradução de endereços de rede e o acesso da rede local do site à Internet (NAT) falhou. Tentativas de reiniciar o equipamento não levaram a nada, a busca por opções alternativas para organizar a conectividade começou antes de receber uma resposta do suporte técnico, pois, por experiência, isso provavelmente não ajudaria.
O problema foi agravado pelo fato de que este equipamento também encerrou as conexões de entrada dos funcionários de VPN clientes, o trabalho de restauração remota ficou mais difícil de ser realizado.
07/03/2019, 16:40Tentamos reanimar um esquema de fallback NAT pré-existente que já havia trabalhado bastante antes. Mas ficou claro que vários reequipamentos da rede tornaram esse esquema quase completamente inoperante, pois sua restauração pode não funcionar no melhor dos casos e, no pior, quebrar o que já está funcionando.
Eles começaram a elaborar algumas idéias para transferir tráfego para um complexo de novos roteadores que atendiam o backbone, mas pareciam inoperantes devido às peculiaridades da distribuição de rotas na rede principal.
07/03/2019, 17:05Ao mesmo tempo, foi revelado um problema no mecanismo de resolução de nomes nos servidores de nomes, o que levou a erros na resolução de terminais em aplicativos; eles começaram a preencher rapidamente os arquivos do host com registros de serviços críticos.
07/03/2019, 17:27Restaurada funcionalidade limitada do Habr.
07/03/2019, 17:43Porém, no final, foi encontrada uma solução relativamente segura para organizar o tráfego que passava por apenas um dos roteadores de fronteira, que foi rapidamente arrancado. A conectividade com a Internet se recuperou.
Nos minutos seguintes, muitas notificações vieram de sistemas de monitoramento sobre a restauração da capacidade de trabalho dos agentes de monitoramento, mas alguns dos serviços se mostraram inoperantes, pois o mecanismo de resolução de nomes nos servidores de nomes (dns) foi violado.
07/03/2019, 17:52O NS foi reiniciado, o cache foi redefinido. Resolução recuperada.
07/03/2019, 17:55Ganhou todos os serviços, exceto MK, Freelansim e Toaster.
07/03/2019, 18:02Ganhou MK e Freelansim.
07/03/2019, 18:07Trouxe de volta uma inocente sessão de BGP com o DataLine.
07/03/2019, 18:25Eles começaram a consertar flanges nos recursos, isso foi associado a uma alteração no endereço externo do pool NAT e sua ausência no acl de vários serviços, rapidamente corrigidos. Imediatamente ganhou e Torradeira.
07/03/2019, 20:30Percebemos erros relacionados aos bots do Telegram. Eles esqueceram de registrar o endereço externo em um par de acl (servidores proxy), e rapidamente o corrigiram.
Conclusões
- O equipamento falhou, o que, mesmo antes disso, colocou em dúvida sua adequação. Havia planos de excluí-lo do trabalho, pois interferia no desenvolvimento da rede e apresentava problemas de compatibilidade, mas ao mesmo tempo desempenhava uma função crítica, motivo pelo qual qualquer substituição não era tecnicamente fácil sem a interrupção dos serviços. Agora você pode seguir em frente.
- Os problemas de DNS podem ser evitados movendo-os para mais perto da nova rede de backbone fora da rede NAT e ao mesmo tempo com conectividade total à rede cinza sem conversão (como foi planejado antes do incidente).
- Não use nomes de domínio ao montar clusters RDBMS, pois a conveniência de alterar transparentemente o endereço IP não é particularmente necessária, pois, mesmo assim, essas manipulações requerem remontagem de cluster. Essa decisão é ditada por razões históricas e, primeiro, pela obviedade dos terminais por nome nas configurações do RDBMS. Em geral, uma armadilha clássica.
- Em princípio, foram realizados exercícios comparáveis à “soberania de Runet”, há algo em que pensar do ponto de vista do fortalecimento das possibilidades de sobrevivência autônoma.