Um erro de digitação no código da Microsoft Azure derrubou o serviço de armazenamento na nuvem da companhia por mais de 10 horas na região sul do Brasil, no último dia 24 de maio. Por causa disso, pelo menos 17 bancos de dados de produção foram excluídos temporariamente.
Em publicado na última sexta-feira (2), o gerente de engenharia de software da Azure, Eric Mattingly, explicou o motivo da interrupção. Segundo ele, é comum que os engenheiros façam “backups” de bancos de dados instantâneos para investigar possíveis problemas ou formas de melhorar o desempenho do sistema.
Enquanto isso acontece, os profissionais contam com um sistema em segundo plano que é executado diariamente. Depois de um tempo, eles são excluídos para dar espaço a novos testes.
No final de maio, porém, os desenvolvedores substituíram os pacotes obsoletos Microsoft.Azure.Managment.* por pacotes Azure.ResourceManager.* NuGet, que mantinham o suporte. O resultado: uma grande solicitação pull – ou seja, uma alteração de código que deve passar por revisão e ajustes no projeto.
“Dentro da solicitação pull estava um erro de digitação no trabalho de exclusão, que trocou uma chamada para excluir o Banco de Dados SQL do Azure para outra que exclui o Servidor SQL do Azure que hospeda todo o banco de dados”, escreveu o engenheiro da Microsoft.
Em outras palavras, o trabalho de exclusão do “backup” instantâneo em segundo plano acabou excluindo todo o servidor.
Evento raro
O Azure DevOps faz testes regularmente para detectar esses problemas. Mas, segundo o engenheiro de software, é raro executar esse código nas mesmas condições. Por isso, os experimentos não identificaram essa possibilidade antes.
A atualização fazia parte do projeto Sprint 222, implantado internamente sem incidentes (até então), porque não havia qualquer banco de dados instantâneo. Dias antes, as alterações do software começaram a funcionar para a unidade de escala do Sul do Brasil, um cluster de servidores com função específica.
Esse ambiente, porém, tinha um banco de dados instantâneo com idade suficiente para acionar o bug. A consequência foi que o trabalho em segundo plano excluiu todo o SQL Server do Azure, além de todos os 17 bancos de dados de produção da unidade de escala.
Recuperação 10 horas depois
Mattingly deixou claro que a equipe recuperou todos os bancos de dados após 10,5 horas do incidente. O motivo da demora é que, como os clientes não podiam reviver os próprios SQL Servers do Azure, os engenheiros de plantão tiveram que lidar com isso. O processo levou até 1 hora para cada um dos afetados.
Outra razão é o fato de que os bancos de dados tinham diferentes configurações de backup. Enquanto a configuração de alguns mantinha um backup com redundância de zona geográfica mais antiga, outros tinham a versão mais recente de armazenamento. Essa incompatibilidade adicionou algumas horas ao processo de recuperação.
“Finalmente, mesmo depois que os bancos de dados começaram a voltar a ficar online, toda a unidade de escala permaneceu inacessível até mesmo para clientes cujos dados estavam nesses bancos de dados devido a um conjunto complexo de problemas com nossos servidores da web”, explicou Mattingly.
Segundo o engenheiro, os problemas têm como base o aquecimento do servidor, que repetia os bancos de dados disponíveis com uma chamada de teste. E, para complicar ainda mais, quando um ou dois servidores começavam a receber o tráfego do cliente de volta, eles sobrecarregavam e caíam.
Assim, os engenheiros precisaram bloquear todo o tráfego para o sul do Brasil até que tudo pudesse se juntar novamente ao balanceador de carga e ter “forças” suficientes para lidar com o tráfego.
A Microsoft disse que já corrigiu o bug e implantou correções para evitar que o erro se repita. “Pedimos desculpas a todos os clientes afetados por esta interrupção”, pontuou Mattingly.