Uma interrupção no Microsoft Azure DevOps no Brasil foi causada por um erro de digitação no código de atualização.

Na quarta-feira, 24 de maio, o Microsoft Azure DevOps ficou offline das 12:10 às 22:31 UTC depois que o Azure SQL Server foi acidentalmente excluído.

Em um relatório de atualização de status, o gerente sênior de engenharia de software da Microsoft, Eric Mattingly, disse: "Durante o Sprint 222, atualizamos a nossa base de código para substituir o Microsoft.Azure.Management obsoleto.

"Isso resultou em um grande pull request para mudanças mecânicas que trocaram as chamadas de API. Oculto nesse pull request havia um erro de digitação no trabalho de remoção de snapshot que alterava uma chamada para remover o banco de dados SQL do Azure para uma que removia o Azure SQL Server que hospedava o banco de dados."

Os engenheiros de DevOps tiram instantâneos de bancos de dados regularmente para explorar problemas ou testar aprimoramentos e contam com um sistema em segundo plano que é executado diariamente e exclui instantâneos antigos.

Inicialmente, o Sprint 222 foi executado internamente sem problemas, mas quando implantado no ambiente do cliente, ele acessou um banco de dados de snapshot antigo o suficiente para acionar o erro de exclusão.

Ao excluir o servidor em vez do banco de dados pretendido, o código removeu todos os dezessete bancos de dados de produção da unidade de escala, tornando-a incapaz de processar as solicitações dos clientes. De acordo com a empresa, não houve perda de dados durante a interrupção.

Embora o Azure estivesse ciente do problema em 20 minutos, foram necessárias mais de 10 horas para corrigi-lo. De acordo com Mattingly, isso ocorreu em parte porque um engenheiro do Azure se envolveu e trabalhou no problema, e alguns bancos de dados foram criados antes que o backup com redundância de zona geográfica estivesse disponível, o que significa que alguns bancos de dados tiveram que ser copiados para uma região emparelhada, o que acrescentou várias horas.

A causa final do atraso, de acordo com Mattingly, foi o resultado de uma série de problemas com os servidores do Azure, nos quais os processos w3wp continuavam se reciclando e, a cada vez, executavam uma tarefa de aquecimento que levava cerca de 90 minutos para ser concluída.

"Como esse processo era escalonado em todos os servidores da Web, quando terminava, apenas um ou dois servidores voltavam ao balanceador de carga e recebiam tráfego de clientes. Em seguida, eles ficavam sobrecarregados e o ciclo começava novamente. Perto do final da janela de interrupção, bloqueamos todo o tráfego para a unidade de escala com nosso recurso de utilização de recursos para permitir que todos os servidores da Web se aquecessem e entrassem corretamente no balanceador de carga. Isso fez com que os usuários recebessem limites de taxa e erros de uso. Quando todos os bancos de dados estavam saudáveis, desbloqueamos gradualmente os usuários para aumentar o tráfego de clientes para níveis normais", disse Mattingly.

A Microsoft implementou vários ajustes para evitar que isso ocorra novamente no futuro.

Em janeiro deste ano, a Microsoft sofreu uma interrupção generalizada que afetou o 365, Outlook, GitHub, Teams e outros. A interrupção durou cinco horas e foi explicada, em última análise, por uma alteração no IP do roteador da rede de longa distância (WAN).