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.