A recuperação do Outlook da Microsoft continuou a falhar sob tráfego
A interrupção do serviço de e-mail da Microsoft de 12 a 13 de novembro expôs um ciclo de recuperação: os servidores devolvidos podiam novamente ficar sem resposta sob tráfego.
A interrupção do serviço de e-mail da Microsoft de 12 a 13 de novembro expôs um ciclo de recuperação: os servidores devolvidos podiam novamente ficar sem resposta sob tráfego. No prazo limite aprovado de 13 de novembro às 11:04:50 UTC, a recuperação tinha progredido em partes da Ásia-Pacífico, enquanto problemas intermitentes e trabalho noutros locais permaneciam. Esta continuação explica as dependências e as salvaguardas de e-mail atrasado.
Ler a edição escrita (Inglês) ↗
O que este vídeo aborda
- Verificar a dependência de backend de cada operação: a maioria das funcionalidades centrais do Teams e o acesso direto a ficheiros do SharePoint permaneceram funcionais, enquanto as funcionalidades dependentes do Exchange foram prejudicadas.
- A Microsoft informou que os servidores devolvidos podiam novamente ficar sem resposta quando o tráfego os atingia; a sua explicação do componente de processamento de saúde permaneceu uma hipótese.
- O tempo limite de e-mail prolongado de quarenta e oito horas pretendia preservar o e-mail atrasado durante o processamento da fila e do backlog. Não era um prazo de reparação ou garantia universal de entrega.
- A orientação normal de limitação do Graph recomenda honrar Retry-After e backoff exponencial quando esse cabeçalho está ausente; não diagnostica nem repara este incidente.
Perguntas e respostas
Porque é que os servidores de e-mail da Microsoft devolvidos podiam falhar novamente sob tráfego?
A Microsoft informou que os servidores devolvidos podiam novamente ficar sem resposta assim que recebessem tráfego. A sua investigação descreveu processos sobrecarregados e um possível problema num componente que processa a saúde do servidor, mas o gatilho inicial ainda aguardava um relatório final do incidente. O episódio ilustra a sequência relatada de retorno, trabalho e recaída conceptualmente; não afirma uma arquitetura interna comprovada ou uma causa raiz final.
Porque é que as chamadas do Teams podiam funcionar enquanto as funcionalidades de calendário falhavam?
A maioria das chamadas, reuniões e conversas centrais do Teams permaneceu funcional de acordo com o aviso de saúde do serviço expandido da Microsoft. Os cenários de calendário e agendamento dependiam do Exchange Online e podiam falhar durante a interrupção. O acesso direto a ficheiros do SharePoint também permaneceu funcional. A distinção útil a nível da aplicação é a dependência por trás de uma operação, em vez de tratar cada funcionalidade sob um logotipo de produto como partilhando o mesmo estado de falha.
O tempo limite de e-mail de quarenta e oito horas estabeleceu um prazo de reparação?
A Microsoft estendeu a janela de tempo limite do e-mail para preservar mensagens atrasadas, priorizando o processamento da fila e do backlog. Isso deu mais tempo aos e-mails atrasados durante a recuperação. O aviso público não forneceu um prazo de reparação de quarenta e oito horas e nenhuma garantia de que todas as mensagens chegariam ao seu destinatário. Uma notificação pendente ou em fila, portanto, exigia uma verificação real de entrega ou resultado antes que um fluxo de trabalho sensível ao tempo pudesse depender dela.
Como a interrupção do Exchange afetou as aplicações do Microsoft Graph?
Os pedidos de e-mail, calendário e contactos do Exchange Online podiam expirar de acordo com a Microsoft. Uma aplicação podia encontrar resultados diferentes em operações com diferentes dependências subjacentes. O episódio recomenda verificar a dependência de serviço real da operação. A documentação separada da Microsoft sobre limitação normal discute a honra do Retry-After e do backoff exponencial quando esse cabeçalho está ausente; essas políticas não estabelecem a causa deste incidente nem prometem serviço restaurado.
Qual foi o veredicto do The Daily Diff sobre a recuperação da Microsoft?
O veredicto do The Daily Diff foi NEEDS REVIEW. Niko manteve a recuperação sob revisão porque as atualizações da Microsoft descreveram servidores devolvidos a falhar sob tráfego. O serviço sustentado com trabalho real a passar era o teste de recuperação útil. A causa inicial permaneceu em aberto no prazo de relatório do episódio, com a Microsoft a prometer um relatório completo do incidente e ações de defesa em profundidade após a mitigação.
Transcrição traduzida
Traduzido da narração original em inglês. Áudio e legendas disponíveis são controlados pelo YouTube.
Porque é que os servidores devolvidos falharam novamente?
0:00 A Microsoft voltou a colocar os servidores de e-mail em serviço. Eles podiam parar de responder novamente quando o tráfego regressava. Aqui está o acompanhamento do desenvolvedor. Neste vídeo, por que é que a recuperação continuava a falhar? E que partes da sua aplicação ainda funcionavam? A Microsoft também deu quarenta e oito horas para e-mails atrasados. O que isso realmente lhe traz? É sexta-feira, treze de novembro, e este é The Daily Diff.
0:18 O Exchange Online é o serviço de e-mail alojado da Microsoft, e outras funcionalidades
Que funcionalidades dependiam do Exchange?
0:22 do Microsoft 365 dependem dele. Aqui está a distinção útil da página de estado da Microsoft. Chamadas e conversas em grupo do Teams funcionaram na sua maioria. Funcionalidades de calendário e pedidos de dados de caixa de correio podiam falhar. Verifique a dependência que a sua aplicação realmente usa. Isso significa que uma reunião ainda pode acontecer enquanto o calendário se recusa a cooperar. O acesso direto a ficheiros no SharePoint também permaneceu funcional, enquanto algumas funcionalidades de partilha foram afetadas.
0:42 O logotipo na janela diz-lhe muito pouco sobre qual backend o seu próximo clique necessita. A interrupção começou na quinta-feira, com a Microsoft a investigar inicialmente o acesso à caixa de correio nas Américas. Em seguida, confirmou que os utilizadores em qualquer região podiam ser afetados. A CNN relatou problemas em bancos, governos e tribunais. Um e-mail em falta é inconveniente até que o trabalho real de alguém dependa da sua chegada. A explicação inicial da Microsoft foi a perda de servidores disponíveis.
Como é que a capacidade em falta sobrecarrega um serviço?
1:06 O trabalho que essas máquinas deveriam ter tratado sobrecarregou a infraestrutura restante. Pode sobrecarregar um serviço com a procura normal quando a sua capacidade desaparece. A fila fica mais longa mesmo que ninguém tenha subitamente descoberto uma paixão por enviar e-mails. A empresa investigou então as verificações automatizadas de saúde. Essas verificações ajudam a decidir se um servidor pode receber trabalho. A Microsoft disse que um componente que processa a saúde do servidor pode estar envolvido. Essa é uma hipótese de uma investigação ainda em curso.
1:29 Não temos um relatório final de incidente que explique exatamente por que esses servidores se tornaram indisponíveis pela primeira vez. As atualizações parecem um turno de plantão
O que a Microsoft tentou primeiro?
1:37 cada vez menos interessado no pequeno-almoço. Pausar implantações. Mover tráfego. Reiniciar servidores. A Microsoft validou uma verificação de saúde alternativa que trouxe um subconjunto de volta, e preparou sistemas automatizados para detetar e reiniciar máquinas que não respondiam. Cada atualização descrevia uma tentativa de recuperar a capacidade. Depois veio a frase que explica o ciclo de recuperação. A Microsoft disse que os servidores que voltavam ao serviço podiam novamente ficar sem resposta assim que recebessem tráfego.
1:59 Uma máquina podia voltar, receber trabalho real e parar de responder. Essa observação é uma evidência mais forte do que a teoria confiante de qualquer pessoa nas respostas. Imagine o mesmo servidor através desses estados. Indisponível. Devolvido ao serviço. A receber tráfego. Novamente sem resposta. Isso ilustra a conta da Microsoft. O que desencadeia essa última transição permanece sem resposta. Um reinício pode produzir uma melhoria
2:18 temporária enquanto a condição que derrota o servidor permanece sem solução. O conselho de desligar e ligar novamente começa a cobrar horas extras. Os engenheiros têm de verificar o que acontece depois que o trabalho retorna. Os clientes precisam que o serviço continue a funcionar durante o próximo pedido, e o próximo. A Microsoft limitou certo tráfego que chegava à infraestrutura afetada em alguns locais. Também reconstruiu um subconjunto de servidores usando uma configuração anterior para
2:39 testar se eles permaneceriam responsivos. Esses foram experimentos de mitigação relatados. Pausar as implementações durante a recuperação não nos dá provas de que uma implementação de sexta-feira causou a interrupção original.
O que era conhecido no prazo limite de relatório?
2:48 Pela atualização de sexta-feira da Microsoft às onze e quatro UTC, as ações de recuperação tinham terminado em partes da Ásia-Pacífico. O tráfego estava a regressar gradualmente, com melhorias no acesso à caixa de correio e no processamento de e-mails atrasados. Alguns utilizadores ainda podiam enfrentar problemas intermitentes, e a recuperação noutros locais continuava. Esse é o nosso prazo de relatório. A Microsoft disse que não tinha evidências de atividade maliciosa, e prometeu um relatório completo do incidente após a mitigação.
3:10 Eu esperaria por esse relatório antes de atribuir um vilão. O trabalho de detetive na Internet pode dar-lhe um culpado antes mesmo de ter terminado de atualizar a página. Para desenvolvedores, o Microsoft Graph torna a dependência especialmente fácil de perder.
Porque é que um pedido do Graph podia falhar?
3:20 Os seus pedidos de e-mail, calendário e contactos do Exchange podiam expirar. A sua aplicação pode chamar o Graph com sucesso para uma operação e falhar noutra. Um pedido não relacionado bem-sucedido diz-lhe pouco sobre se a operação de caixa de correio de que o seu utilizador precisa será concluída. A página de estado até precisava da sua própria rota de fuga. A Microsoft publicou informações sobre o incidente porque os administradores podiam não conseguir carregar o centro de administração para ler o estado do serviço. Quando o painel para descobrir o que está avariado depende do que está avariado,
3:46 o painel juntou-se ao incidente. Mantenha um link de status fora de banda disponível. Para a limitação normal do Graph, a orientação da Microsoft diz para honrar o atraso de tentativa quando um pedido obtém uma resposta de muitos pedidos, e usar o backoff exponencial quando esse cabeçalho está ausente. Essa orientação gere a limitação. Não diagnostica esta interrupção nem promete que as novas tentativas restaurem o serviço. Agora as quarenta e oito horas.
O que ganha a janela de e-mail de 48 horas?
4:05 A página de estado expandida da Microsoft diz que priorizou o processamento da fila e do backlog e estendeu a janela de tempo limite do e-mail para preservar mensagens atrasadas. Isso dá mais tempo aos e-mails atrasados durante a recuperação. Define uma janela de tempo limite para e-mails. A Microsoft não deu um prazo de quarenta e oito horas para corrigir o serviço, e nenhuma garantia de que todas as mensagens chegariam. Portanto, mantenha as reivindicações de entrega honestas. Uma notificação atrasada não desapareceu necessariamente,
4:28 e uma mensagem em fila não chegou necessariamente ao seu destinatário. Para trabalhos sensíveis ao tempo, verifique o resultado através de um canal independente aprovado. Uma janela de cliente é um recibo de entrega otimista quando o backend ainda está a recuperar. O que deixa muito para ler no eventual relatório do incidente. Se preferir ler isto a ouvir-me dizer, o diff chega à sua caixa de entrada todas as manhãs, gratuitamente em the daily diff dot dev, link abaixo. Então, o veredicto de hoje, NEEDS REVIEW.
O que a recuperação sustentada precisaria de provar?
4:49 Manteria a recuperação sob revisão porque as próprias atualizações da Microsoft mostraram servidores devolvidos a falhar sob tráfego. O teste útil é o serviço sustentado com trabalho real a passar. Até ao relatório final, a causa inicial permanece em aberto. E esse é o diff de hoje. Sou o Niko da Axrisi. Faça a fusão com responsabilidade.
Fontes
- ExpandedMicrosoftservicehealth, reportingcutoffNovember13 11:04:50UTC; earlier10:01:07observationshistoricalMicrosoft
- Returned servers can become unresponsive again once they receive trafficMicrosoft 365 Status
- Health-processing component investigation hypothesisMicrosoft 365 Status
- Alternative health check returned a subset of serversMicrosoft 365 Status
- Isolate, restart and reintroduce traffic to test stabilityMicrosoft 365 Status
- Unavailable servers strain remaining infrastructureMicrosoft 365 Status
- Initial Exchange mailbox-access investigation in the AmericasMicrosoft 365 Status
- Users in any region may be affectedMicrosoft 365 Status
- Email timeout extended to preserve delayed messagesMicrosoft 365 Status
- Paused deployments, traffic redistribution and server restartsMicrosoft 365 Status
- Independent live reporting on the Microsoft email disruptionCNN
- Microsoft Graph throttling guidanceMicrosoft Learn
- Exchange Online service descriptionMicrosoft Learn
- Satya Nadella portrait by OFFICIAL LEWEB PHOTOS (2013), CC BY 2.0. Whole portrait-based artwork adapted by cropping, background removal, resizing and text/composition; vendor identity only, no endorsement or current reaction.OFFICIAL LEWEB PHOTOS
- Portrait-only CC BY 2.0 licence; separate from third-party source/cartoon rightsCreative Commons
- WWE still. Brief silent process commentary; WWE, The Simpsons/20th Television/Disney, Microsoft and other source owners retain copyright. Hosting and this specific editorial-use decision provide no blanket reuse grant or copyright clearance. The portrait licence is separate from third-party source/cartoon rights.WWE / Imgflip source hosting
- The Simpsons/Bob GIF. Brief silent process commentary; WWE, The Simpsons/20th Television/Disney, Microsoft and other source owners retain copyright. Hosting and this specific editorial-use decision provide no blanket reuse grant or copyright clearance. The portrait licence is separate from third-party source/cartoon rights.The Simpsons / 20th Television / Disney; GIPHY source hosting



