Código mal configurado causou interrupção no Azure em 18 de novembro – Microsoft

Table Of Contents

• Microsoft diz que a interrupção do Azure em 18 de novembro foi causada por código mal configurado
• Protocolo de Anulação
• A Declaração

Microsoft diz que a interrupção do Azure em 18 de novembro foi causada por código mal configurado

Microsoft Azure, sua plataforma de nuvem para empresas, sofreu uma grande interrupção em 18 de novembro, que deixou muitos usuários em apuros. Em uma declaração, a Microsoft afirmou que a interrupção foi causada por seus desenvolvedores implementando código ruim.

Protocolo de Anulação

Parece que os desenvolvedores da Microsoft estavam trabalhando para corrigir um bug em seu software. A solução para a correção do bug, aparentemente, causou a enorme interrupção dos serviços de nuvem do Azure. A Microsoft disse que havia testado a atualização antes de implementá-la. Mas nem sempre é possível prever com precisão o resultado de uma atualização de software em uma plataforma tão grande sob um ambiente de teste controlado. Portanto, a Microsoft segue uma política de implantar qualquer nova atualização seção por seção, algo que eles chamam de flighting, ou seja, limitando a implementação. Desta vez, porém, provavelmente por causa da empolgação excessiva, os desenvolvedores implantaram o pacote de atualização completo de uma só vez, o que causou um efeito cascata em todos os seus servidores. Em uma declaração emitida no blog do Azure, Jazon Zander, CVP, Equipe do Azure, observou que,

Como consequência, as taxas de conexão ao Azure em 18 de novembro caíram de 97% para 7%-8% após as 19h, horário do leste, na Virgínia do Norte. O data center do Azure em Dallas sofreu uma interrupção completa por um curto período. Os data centers na Europa não se recuperaram até bem tarde do dia seguinte.

Ele acrescentou ainda que, embora tenham uma política padrão de implantação para atualização/correção de bugs, houve comunicações aparentes, “A política padrão de implantação de flighting de implantar mudanças de forma incremental em pequenas partes não foi seguida”, escreveu Zander. Zander disse que sua equipe havia identificado o problema principal, que era uma questão de configuração nas interfaces de armazenamento do Azure Table. “A chave de configuração foi habilitada incorretamente para as interfaces de armazenamento do Azure Blob”, escreveu Zander.

As interfaces de armazenamento do Table registram a sequência dos diferentes tipos de dados que vão para um Blob (um serviço para armazenar grandes quantidades de dados não estruturados) e podem ser usadas para guiar a recuperação dos dados. O erro na chave de configuração parece ter causado um loop infinito que, em última análise, resultou na interrupção do serviço de nuvem do Azure.

A Declaração

A atualização original tinha como objetivo corrigir alguns bugs encontrados pela equipe do Azure e melhorar o desempenho da plataforma de nuvem. A atualização provou seu valor em todos os testes na fase de teste alfa. Os resultados bem-sucedidos dos testes alfa provavelmente deixaram os desenvolvedores tão empolgados que decidiram abrir mão do método de flighting de implantação e implementaram a atualização de uma só vez. O resultado, como visto em 18 de novembro, foi uma interrupção total que causou problemas aos usuários. Em resposta, os administradores do Azure agora implementaram uma prática de atualização automatizada, que não permitirá que tal evento ocorra novamente.

Em talvez o resultado mais claro do incidente, Zander escreveu: “A Microsoft Azure tinha diretrizes operacionais claras, mas havia uma lacuna nas ferramentas de implantação que dependiam de decisões humanas… Com as atualizações das ferramentas, a política agora é aplicada pela própria plataforma de implantação.”

Zander reconheceu que as operações em nuvem devem se tornar mais confiáveis e disse que a Microsoft continuará a trabalhar nesse objetivo. “Pedimos sinceras desculpas e reconhecemos o impacto significativo que essa interrupção de serviço pode ter tido em suas aplicações e serviços”, escreveu ele.

Zander pode ter se desculpado sinceramente pela empolgação excessiva de sua equipe de desenvolvimento, mas o fato é que a Microsoft está pressionando patches e atualizações com pressa, sem os testes necessários. Este problema já levou a Microsoft a lançar patches/atualizações com bugs que causam BSOD, em suas atualizações de Patch Tuesday duas vezes, uma em outubro com KB 2949927 e em dezembro com KB 3004394, apenas para removê-los mais tarde. Os usuários esperam que a Microsoft crie um SOP para liberar apenas aquelas atualizações/patches que foram verificadas em um ambiente de trabalho em tempo real.