Resumo

  • Segundo o Azure, uma restrição temporária às atualizações de sistema operacional expirou e muitas atualizações de gateways foram retomadas em um curto intervalo. Uma alteração anterior também havia aumentado o tempo necessário para processar operações de configuração.
  • A carga combinada afetou operações de gerenciamento de vários serviços de rede em diversas regiões. Em algumas gateways ExpressRoute, a atualização da instância redundante seguinte avançou antes da restauração completa da configuração e das rotas.

A explicação mais fácil para uma falha de nuvem costuma ser: uma atualização causou uma interrupção. A análise do Azure sobre o episódio de 30 de setembro a 1º de outubro descreve uma interação mais importante. Uma restrição temporária havia pausado atualizações de sistema operacional para um grupo de gateways. Quando expirou, muitas foram retomadas em pouco tempo. Separadamente, uma alteração já implantada havia aumentado o tempo de processamento das operações de configuração em um plano de controle de rede regional compartilhado. Mais solicitações chegaram justamente quando cada uma demorava mais.

Isso não equivale a dizer que uma atualização defeituosa foi a causa inteira. A Microsoft descreve um aumento de reinicializações e solicitações de configuração encontrando um serviço mais lento; os mecanismos existentes de limitação e proteção de carga não protegeram suficientemente o processamento crítico. A onda avançou região por região, por isso os horários de impacto variaram. O Azure lista ExpressRoute Gateway, Application Gateway, Azure Firewall, Bastion, Virtual WAN e VPN Gateway entre os serviços afetados, em regiões das Américas, Europa, Ásia-Pacífico, África e Oriente Médio.

A análise pública não traz um inventário de impacto por cliente.

Uma falha de gerenciamento interrompeu algumas conexões

Muitas operações afetadas eram funções de gerenciamento. Em algumas gateways ExpressRoute, porém, houve perda temporária de conectividade com redes locais conectadas. Segundo o Azure, uma instância em reinicialização podia ser marcada como saudável antes que sua configuração e seu estado de roteamento fossem restaurados. A atualização então avançava para a outra instância redundante. Se nenhuma das duas conseguia buscar a configuração de rotas necessária, a conexão caía.

Após cerca de 30 minutos de tentativas malsucedidas para obter a configuração, as gateways afetadas aplicaram localmente a última configuração válida. Esse período é o intervalo de tentativas descrito pela Microsoft, não a duração da interrupção de cada cliente. O incidente geral começou às 20h30 UTC de 30 de setembro e a última onda foi mitigada às 2h15 UTC de 1º de outubro. O Azure alerta que a duração geral não representa a experiência de cada cliente ou recurso.

A cronologia também mostra por que apenas adicionar capacidade não resolveu. A degradação do ExpressRoute foi detectada às 20h43; a deterioração mais ampla do plano de controle, às 20h58. Pausar novas atualizações às 21h45 e redirecionar tráfego trouxe alívio temporário; as tentativas de adicionar recursos também não estabilizaram o serviço. Às 23h55, a investigação associou o maior tempo de processamento a uma regressão de desempenho. A reversão começou em uma região às 1h15 de 1º de outubro, foi validada e depois ampliada. O impacto terminou às 2h15, quando a reversão nas regiões afetadas foi concluída.

A janela de manutenção não define como esvaziar a fila

A documentação do Azure diz que atualizações de gateways podem incluir correções de software, melhorias em componentes de rede e desativação de hardware. Clientes podem escolher janelas de manutenção para determinados gateways; isso controla o horário, mas não prova como as atualizações adiadas serão liberadas quando a pausa terminar. A revisão da Microsoft aponta melhorias para retomada escalonada, verificações que confirmem a restauração de configuração e rotas antes de atualizar a próxima instância redundante, correções nas restrições de escala e mecanismos de limitação e descarte de carga.

São medidas e estimativas da empresa, não comprovação independente de conclusão.

As orientações da Microsoft para implantações seguras recomendam exposição progressiva, verificações de saúde antes de cada fase e interrupção do rollout quando surge um problema. A pergunta operacional deste caso é mais específica: “saudável” significa que o processo reiniciou ou que a configuração e as rotas necessárias ao serviço foram recuperadas e verificadas? Redundância só ajuda se a próxima instância não herdar a mesma dependência ainda indisponível do plano de controle.

A Microsoft diz que os clientes não poderiam ter evitado ou reduzido o impacto desse incidente específico. Ainda assim, podem mapear quais cargas dependem de cada gateway, observar o próprio plano de dados separadamente das operações de gerenciamento e configurar alertas do Service Health. Isso melhora detecção e resposta, mas não transforma o plano de recuperação do provedor em uma garantia controlada pelo cliente.

Fontes: Análise do Azure 7Q30-010; Gateways virtuais ExpressRoute; Manutenção de gateway controlada pelo cliente; Práticas de implantação segura. Enquadramento editorial apenas: Heng Lu, nota 20.