Suporte Técnico
Documentação
Entrar
Entre em contato conosco
Vá direto para um resumo gerado por IA desta postagem do blog 
Em um cenário tecnológico em constante evolução, lidar com ambientes complexos está longe de ser moleza. Desde equipes de operações maiores e mais caras até uma padronização mais rigorosa de hardware e software, muitas estratégias foram postas à prova. A automação e as palavras-chave do momento já tiveram seu momento de destaque.
Estamos, e já há algum tempo, adotando o paradigma da “infraestrutura como código” (IaC). Essa abordagem se adapta bem à escalabilidade, exige menos recursos, integra-se perfeitamente a outras ferramentas e processos, como controle de código-fonte e rastreamento de alterações, e é uma maneira mais eficiente de gerenciar as demandas cada vez maiores do mundo digital atual.
No entanto, como tudo na vida, a IaC não está isenta de falhas. Temos décadas de experiência no gerenciamento da infraestrutura, mas é na parte do “código” da IaC que surgem os problemas. Se o número de bugs, patches, vulnerabilidades, programas de recompensa por bugs e outras atividades relacionadas servir de indicação, fica claro que temos espaço para melhorar nossas habilidades de programação.
Quando, de forma anedótica, diferentes pacotes de software são comparados não por seu desempenho ou confiabilidade, mas pelo fato de serem tão cheios de bugs quanto outros pacotes ou versões, tratar a infraestrutura como código inevitavelmente introduz esses mesmos bugs e problemas na própria infraestrutura. Um exemplo disso é o recente incidente no Azure.
A interrupção do Azure: um estudo de caso sobre IaC
Há alguns dias, um contratempo no Azure afetou clientes na região sul do Brasil. Como um dos principais provedores de nuvem, o Azure adota o lema “tudo é código”, permitindo que a configuração de serviços, servidores, bancos de dados, endpoints, backups e muito mais seja tratada como código. Essa filosofia se estende ao lado de gerenciamento do Azure, e não apenas à nuvem voltada para o cliente, onde os administradores de sistemas tratam tudo como código, possibilitando a automação de todas as operações.
Há alguns dias, o Azure estava testando uma alteração nos componentes de gerenciamento. O objetivo era substituir alguns componentes mais antigos por outros mais recentes, o que envolveu a remoção de alguns pacotes NuGet e a instalação de novos. Como parte da troca dos pacotes NuGet, o código que fazia referência a eles também precisou ser ligeiramente alterado — os nomes dos pacotes eram diferentes e algumas convenções de chamada mudaram. Não foi exatamente uma substituição direta.
As alterações foram programadas, confirmadas, revisadas, testadas e, em seguida, implantadas em um ambiente de teste conhecido como “Ring 0” no Azure-land, em referência ao nome do modo com os maiores privilégios. Depois que tudo correu bem no Ring 0, as alterações foram implementadas no Ring 1, o ambiente de produção visível aos clientes.
No entanto, o Ring 0, assim como muitos ambientes de laboratório ou de teste, é uma versão simplificada do ambiente de produção, sem a mesma carga, base de usuários ou interações complexas entre sistemas.
Curiosamente, uma tarefa relativamente rotineira que os administradores de sistemas do Azure realizam em ambiente de produção é a criação de instantâneos de bancos de dados em execução para fins de depuração, sem afetar as cargas de trabalho reais nem os clientes. Como não há necessidade de criar instantâneos em um ambiente de laboratório, que não conta com bancos de dados reais de produção nem com os problemas que ocorrem neles, o Ring 0 não possuía instantâneos.
Uma das alterações nos pacotes do NuGet foi uma mudança nas funções responsáveis pelo gerenciamento de instantâneos.
Internamente, o Azure executa uma tarefa em segundo plano para excluir instantâneos antigos periodicamente. Como não havia instantâneos no Anel 0, ele nunca tentou excluir nenhum durante a fase de teste. No entanto, no ambiente de produção, onde havia instantâneos, a tarefa em segundo plano foi executada com as alterações do pacote NuGet, e o que antes era uma chamada para remover um instantâneo do banco de dados instantâneo transformou-se em uma chamada para remover um servidor de banco de dados servidor de banco de dados.
Como um acidente de carro que ocorre lentamente, quando a tarefa foi executada, todos os servidores de banco de dados com um snapshot antigo o suficiente foram excluídos — enquanto, um serviço após o outro, deixava de responder.
As consequências da interrupção do serviço do Azure
A exclusão do servidor desencadeou uma cadeia de eventos tangencialmente relacionados:
- No Azure, um cliente não pode restaurar por conta própria um servidor excluído. Isso precisa ser feito pela equipe de suporte do Azure.
- Nem todos os servidores afetados possuíam o mesmo tipo de backup, o que causou variações na velocidade de restauração. Alguns estavam armazenados na mesma região (ou seja, no mesmo datacenter), enquanto outros apresentavam redundância geográfica, o que significa que estavam armazenados em diferentes regiões do Azure. Os dados precisaram ser transferidos antes da restauração. Isso aumentou o tempo de recuperação.
- Descobriu-se que alguns servidores web que dependiam dos servidores de banco de dados que haviam sido excluídos executavam um teste na inicialização para determinar quais bancos de dados estavam disponíveis e acessíveis. Essas solicitações eram direcionadas a todos os servidores de banco de dados e tinham o efeito colateral indesejado de interferir no processo de recuperação dos servidores de banco de dados. Além disso, quando o teste falhava, os servidores web acionavam imediatamente uma reinicialização. O que aconteceu. E aconteceu novamente. E mais uma vez, já que esses bancos de dados permaneceram indisponíveis por um período prolongado.
- Como medida de precaução, uma técnica chamada “backoff” é empregada quando um teste falha. Basicamente, isso significa que, quando se tenta um teste e ele falha, o intervalo de tempo até a próxima tentativa vai aumentando. Esse aumento pode ser linear ou exponencial, e a ideia é dar tempo suficiente para que o outro lado se recupere da situação em que se encontra, sem precisar lidar com essas solicitações de teste. Nesse caso específico, isso teve a consequência indesejada de fazer com que as reinicializações demorassem mais de uma hora, quando normalmente levariam apenas alguns segundos.
- A restauração dos backups estava lenta porque a infraestrutura estava sobrecarregada com solicitações.
- Assim que alguns servidores voltaram a ficar online, eles rapidamente ficaram sobrecarregados pelo tráfego de clientes.
Para permitir que todos os servidores voltassem a ficar online, foi necessário interromper todo o tráfego até que todos os servidores fossem recuperados. Esse pico de tráfego fez com que a interrupção do serviço (para os clientes dos locatários do Azure afetados) fosse mais longa do que teria sido de outra forma.
O resultado? Aproximadamente 10 horas de inatividade, interrupções nas operações e uma enxurrada de clientes frustrados.
E tudo começou com a atualização de alguns pacotes de código. Não foi um hack, nem um incêndio, nem outro tipo de risco.
Conclusões e lições aprendidas
É essencial contar com um ambiente de testes robusto, capaz de simular o ambiente de produção da forma mais fiel possível. Réplicas exatas são difíceis de se obter, ficam facilmente fora de sincronia e são difíceis de manter. Por outro lado, ambientes de testes excessivamente simplificados são, na prática, inúteis, pois não apresentam os desafios necessários que o ambiente de produção enfrenta.
Estratégias eficazes de backup e restauração são fundamentais. Os backups não devem apenas estar disponíveis, mas também devem ter sido testados em cenários reais de restauração.
O erro humano é um desafio constante no desenvolvimento de código. Devemos reconhecer a possibilidade de deixar passar interações críticas e possíveis bugs em sistemas muito complexos. Na verdade, os sistemas nem precisam ser tão complexos para que os seres humanos não consigam compreender todas as sutilezas e interações existentes neles. Programar nessa situação inevitavelmente leva a problemas.
A nuvem, embora revolucionária, não está imune a falhas. Erros humanos, falhas de software e defeitos de hardware podem ocorrer — e de fato ocorrem. Repetidamente e de forma inesperada. E se Murphy tiver alguma influência nisso, exatamente no pior momento possível também.
Por outro lado, o incidente demonstrou a tenacidade das equipes de suporte e operações do Azure, que conseguiram restaurar os recursos excluídos sem perda de dados em um período relativamente curto. Isso ressalta que, embora o gerenciamento de grandes infraestruturas — especialmente como código — seja desafiador, o verdadeiro parâmetro de um serviço é a rapidez com que ele responde e corrige um problema após um erro.
Em conclusão, é sempre aconselhável automatizar sempre que possível, garantindo que o ambiente de teste reflita o ambiente de produção da forma mais fiel possível. Incidentes como esses servem como lembretes valiosos para que levemos em consideração possíveis vulnerabilidades em nossos ambientes antes que elas levem a falhas.
Também é importante automatizar primeiro as tarefas rotineiras – por exemplo, a implantação automática de patches —, permitindo que o foco seja direcionado para operações mais complexas que exigem níveis mais elevados de atenção. Isso ajuda a liberar o único recurso que a nuvem não consegue escalar (a capacidade intelectual) para tarefas mais importantes.
