Resumo

  • Segundo a análise final da Microsoft, um procedimento de expansão da WAN continha um comando de limpeza da base IGP que era local em roteadores de dois fabricantes, mas alcançava por padrão todos os roteadores conectados ao IGP em uma terceira plataforma. O procedimento alterado não fora retestado e não trazia as verificações exigidas antes e depois da mudança.
  • A primeira operação manual, às 07:08 UTC, provocou recálculo da topologia IGP e nova divulgação e validação de prefixos por BGP. Como os alertas não chegaram ao responsável pela mudança, a mesma operação foi realizada no segundo roteador de Madri 33 minutos depois e criou uma segunda onda; a análise final não atribui essa repetição a uma automação.
  • A experiência variou por caminho. Quase todos os equipamentos, regiões e serviços haviam se recuperado às 09:05, e o último equipamento de rede às 09:25. A mitigação completa só veio às 12:43, depois da reinicialização manual dos sistemas pausados de monitoramento da integridade da WAN e de engenharia de tráfego.
  • A Microsoft anunciou auditoria e bloqueio de comandos de alto impacto, visibilidade de atividades qualificadas e não qualificadas, treinamento e revisão de procedimentos. As fontes públicas usadas aqui não verificam de modo independente que essas medidas tenham sido concluídas ou se mostrado eficazes.

Um incidente com relógios diferentes

O registro final da Microsoft fixa o período de impacto ao cliente entre 07:08 e 12:43 UTC de 25 de janeiro de 2023. Reduzir o episódio a uma interrupção global de cerca de 90 minutos apaga a sequência de recuperação. Quase todos os dispositivos de rede, regiões e serviços haviam voltado até 09:05. O último equipamento de rede se recuperou às 09:25. Ainda assim, perdas de pacotes acima do normal permaneceram em alguns locais.

A mitigação completa ocorreu às 12:43 porque sistemas de monitoramento da integridade da WAN e de engenharia de tráfego haviam entrado em estado pausado e precisaram ser reiniciados manualmente. A volta ampla da capacidade de encaminhar pacotes não significava, portanto, que todas as funções usadas para avaliar caminhos e direcionar tráfego já estivessem operacionais.

O evento começou durante a adição de capacidade em Madri. A atividade incluía alterar endereços IP de novos roteadores e integrá-los aos domínios IGP e BGP. O IGP distribui topologia e alcançabilidade dentro da rede do operador; o BGP anuncia prefixos alcançáveis entre domínios e caminhos. Uma mudança ampla no estado interno pode obrigar os roteadores de borda a recalcular o que divulgam e como encaminham tráfego.

O nome da tarefa dizia pouco sobre o raio real da ação. O procedimento incluía um comando que eliminava a base de dados IGP. Em plataformas de dois fabricantes, o efeito permanecia local ao roteador. Em uma terceira plataforma, o comportamento padrão se estendia a todos os roteadores ligados pelo IGP. Os fabricantes, os modelos, as versões de software e o texto exato do comando não foram divulgados.

Permissão não comprovou alcance

O sistema de autorização de comandos da Microsoft não havia classificado como bloqueado o comportamento global daquela terceira plataforma. A instrução podia ser permitida sem que seu efeito estivesse qualificado para o limite declarado da mudança. Em uma rede de vários fornecedores, nomes parecidos e sintaxes familiares não garantem a mesma semântica. A realidade operacional é o que o software e o equipamento fazem quando o comando entra em execução.

O procedimento operacional padrão também tinha mudado antes do evento, mas não havia sido testado novamente e carecia das verificações prévias e posteriores exigidas. Esses fatos deslocam a análise de uma acusação pessoal para o desenho do sistema de mudança. O material público não identifica o engenheiro, sua intenção, competência ou contexto completo de console. Ele identifica um procedimento sem nova qualificação, lacunas nas verificações e classificação incompleta de um comando de alto impacto.

Às 07:08, a execução fez os roteadores da WAN recalcularem a topologia IGP. Em seguida, os roteadores BGP voltaram a anunciar e validar prefixos da Internet. Durante essa movimentação, caminhos de encaminhamento mudaram e clientes enfrentaram combinações variáveis de latência, tempo de espera excedido, perda intermitente de pacotes e perda completa de conectividade em determinados trajetos.

O registro não descreve sequestro de BGP, ataque externo ou ação maliciosa. A causa interna estabelecida pela análise final é o comando de alcance amplo dentro da WAN, somado às falhas de procedimento e autorização que não limitaram sua execução. A instabilidade BGP visível fora da Microsoft foi um efeito do estado interno em mudança, não a origem externa do incidente.

A segunda onda veio de outra operação manual

Trinta e três minutos depois da primeira execução, a mesma atividade foi realizada no segundo roteador de Madri. A análise final informa que o engenheiro responsável pela mudança não havia sido avisado dos alertas ativos. Assim, não se deve apresentar como fato consolidado a hipótese inicial de que uma automação repetiu o comando. A versão final coloca uma segunda operação humana dentro de um processo que não conectou detecção e interrupção a tempo.

Essa distinção determina onde procurar responsabilidade. Observadores externos reconheceram duas ondas e, durante o incidente, discutiram explicações possíveis. Depois que a análise final descreveu a sequência interna, ela passou a ser a referência principal para a causa e para a forma da segunda operação. A observação externa confirma os dois efeitos, mas não identifica sozinha quem ou o que executou a ação dentro da rede.

Um alerta registrado na plataforma de monitoramento é uma proteção incompleta se não puder alterar o estado do trabalho. Em uma mudança de WAN de alto impacto, ele precisa suspender a próxima etapa, revogar temporariamente a autorização, exigir nova aprovação ou transferir o comando ao responsável pelo incidente. O registro público não revela em detalhe quais dessas possibilidades existiam. Ele mostra que o operador capaz de repetir o mecanismo não recebeu a informação necessária antes da segunda execução.

A segunda onda não foi apenas mais uma interrupção. Ela introduziu nova alteração de estado enquanto a rede convergia da primeira. As fontes não medem o dano incremental atribuível a cada onda, portanto não cabe inventar essa divisão. O que elas sustentam é mais estreito: a mesma operação não qualificada alcançou duas vezes o domínio de roteamento, e observadores externos registraram dois movimentos distintos.

O que as observações públicas de BGP demonstram

A ThousandEyes observou retirada e nova divulgação de prefixos da Microsoft, mudanças de caminhos que saíam de interconexões diretas para provedores de trânsito e perda substancial de pacotes. A Kentik observou duas quedas agregadas de tráfego, impactos diferentes entre regiões e prefixos, perda de peering e deslocamentos para trânsito.

Esses dados são evidência independente dos efeitos percebidos fora da rede. As duas ondas e a variabilidade entre caminhos são compatíveis com a cronologia da Microsoft. Mas uma atualização BGP pública ou um registro de fluxo não revela por si só qual comando privado foi executado. A própria Kentik advertiu que a instabilidade vista no BGP público provavelmente era sintoma do problema interno, não sua causa raiz.

As camadas de evidência precisam permanecer separadas. A análise final da Microsoft sustenta o mecanismo interno, o procedimento, a segunda operação e os marcos finais. ThousandEyes e Kentik mostram mudanças de rota, caminho e tráfego observadas externamente. A reportagem contemporânea registra a interrupção visível e as primeiras explicações divulgadas. Uma camada pode corroborar outra, mas não pode assumir seu lugar.

O impacto foi amplo, mas não uniforme

As superfícies afetadas incluíram tráfego entre a Internet e o Azure, tráfego entre regiões do Azure e conexões entre instalações por ExpressRoute, VPN e Virtual WAN. Dependências do Microsoft 365 e do Power Platform, além de serviços do Azure Government dependentes do Azure público, também foram atingidas.

Isso não autoriza afirmar que toda região, serviço, empresa cliente ou rota da Microsoft falhou do mesmo modo. A experiência mudava conforme origem e destino. Alguns caminhos apresentavam latência ou perda intermitente; outros chegavam a timeout ou perda completa de conectividade. A Índia e partes da América do Norte estiveram entre os trajetos de recuperação mais longa, mas não existe no conjunto público um inventário completo por região.

Também não há contagem auditada de usuários ou clientes afetados, lista total de serviços e prefixos, número de transações ou perda financeira. O registro não estabelece perda de dados de clientes, dano físico ou uma conclusão jurídica de negligência ou responsabilidade. A gravidade do evento pode ser entendida sem preencher essas lacunas com números ou vereditos não publicados.

A variação por caminho importa para a própria definição de recuperação. Um indicador agregado pode parecer saudável enquanto combinações específicas de origem e destino continuam degradadas. Declarar encerramento apenas com uma porcentagem global de disponibilidade pode esconder danos persistentes para certos clientes.

A recuperação ocorreu em camadas

O monitoramento detectou sinais em DNS e WAN às 07:11 e gerou alertas. DNS foi um sintoma detectado, não a causa central; chamar o episódio de uma pane genérica de DNS distorceria a análise final. O mecanismo estabelecido envolve recálculo IGP dentro da WAN, nova divulgação BGP e instabilidade de encaminhamento.

As equipes examinaram mudanças recentes e identificaram o comando problemático às 08:20, enquanto a convergência automática de roteamento já avançava. Quase todos os dispositivos, regiões e serviços se recuperaram até 09:05. O último equipamento de rede voltou às 09:25. Depois disso, a perda localizada continuou até que sistemas pausados de monitoramento da integridade da WAN e de engenharia de tráfego fossem reiniciados manualmente, permitindo a mitigação integral às 12:43.

Atualizações iniciais mencionaram reversão de mudanças de roteamento. Essa informação contemporânea ajuda a entender o que era comunicado durante a resposta, mas não explica sozinha a recuperação completa. A análise final distingue convergência automática, recuperação dos últimos equipamentos e reinicialização manual das funções de apoio.

Uma prova de recuperação deveria preservar a mesma separação: primeiro a alcançabilidade ampla; depois os equipamentos e caminhos restantes; por fim, os sistemas que detectam caminhos ruins e direcionam o tráfego. As fontes estabelecem essa ordem no incidente, mas não demonstram qual padrão a Microsoft usa hoje nem se compromissos posteriores já foram testados com sucesso.

A conclusão é sobre o sistema de mudança

O encadeamento sustentado pelo registro é específico. Um procedimento alterado e não retestado trazia um comando de alcance diferente entre fabricantes. O sistema de autorização não bloqueou seu efeito global na terceira plataforma. A execução mudou o estado IGP e BGP, causando falhas desiguais para clientes. Os alertas não chegaram ao operador antes de uma segunda execução manual.

A Microsoft listou medidas como auditoria e bloqueio de comandos de alto impacto entre fornecedores e funções, visibilidade para atividades qualificadas e não qualificadas, treinamento e atestação, além de revisão por um comitê consultivo de mudanças para procedimentos pendentes. Essas ações apontam para as fraquezas reveladas pelo incidente. As quatro fontes públicas, porém, não verificam de forma independente que cada medida tenha sido concluída ou impedido ocorrências equivalentes.

É preciso descrevê-las como compromissos de reparação, não como resultados comprovados. Demonstrar eficácia exigiria testes de alcance por plataforma, nova qualificação depois de cada alteração de procedimento, comparação entre o conjunto planejado e o estado real de dispositivos e rotas, registros de que a autoridade de parada bloqueou uma segunda execução e evidência de recuperação tanto do encaminhamento quanto das funções que o asseguram.

O caso não estabelece culpa jurídica, violação contratual ou obrigação de indenizar. Nem publica todos os registros internos ou todos os responsáveis pelas decisões. Ainda assim, deixa uma pergunta precisa de responsabilidade de infraestrutura: uma mudança global só está sob controle quando o alcance efetivo de cada comando é comprovado por plataforma, observado na rede em execução, interrompido quando ultrapassa o limite e recuperado junto com os sistemas necessários para operar com segurança.

Fontes