# A recuperación de Outlook de Microsoft seguía fallando por mor do tráfico Published: 2026-11-13 A interrupción do correo electrónico de Microsoft do 12 e 13 de novembro expuxo un bucle de recuperación: os servidores restablecidos podían volver ser insensibles baixo tráfico. No corte aprobado do 13 de novembro ás 11:04:50 UTC, a recuperación progresara en porcións de Asia Pacífico mentres que os problemas intermitentes e o traballo noutras partes persistían. Este seguimento explica as dependencias e as salvagardas de correo atrasado. Canonical: https://thedailydiff.dev/gl/video/2026-11-13-microsoft-recovery-loop/ ## Que abrangue este vídeo - Verifique a dependencia de backend de cada operación: a maioría da funcionalidade principal de Teams e o acceso directo a ficheiros de SharePoint seguían funcionando, mentres que as funcións dependentes de Exchange estaban deterioradas. - Microsoft informou de que os servidores restablecidos podían volver ser insensibles cando lles chegaba tráfico; a súa explicación do compoñente de procesamento de saúde seguía sendo unha hipótese. - O tempo de espera estendido de corenta e oito horas para o correo electrónico tiña como obxectivo preservar o correo atrasado durante o procesamento da cola e do atraso. Non era unha data límite de reparación nin unha garantía de entrega universal. - A orientación ordinaria de limitación de Graph recomenda respectar Retry-After e o retroceso exponencial cando ese cabeceira está ausente; non diagnostica nin repara este incidente. ## Preguntas e respostas ### Por que os servidores de correo restablecidos de Microsoft podían fallar de novo baixo tráfico? Microsoft informou de que os servidores restablecidos podían volver ser insensibles unha vez que recibían tráfico. A súa investigación describiu procesos sobrecargados e un posible problema nun compoñente que procesa a saúde do servidor, pero o desencadeante inicial aínda agardaba un informe final do incidente. O episodio ilustra conceptualmente a secuencia de "volta, traballo e recaída" informada; non reclama unha arquitectura interna probada ou unha causa raíz final. ### Por que as chamadas de Teams funcionaban mentres as funcións de calendario fallaban? A maioría das chamadas, reunións e chats principais de Teams seguiron funcionando segundo o aviso de saúde de servizo expandido de Microsoft. Os escenarios de calendario e programación dependían de Exchange Online e podían fallar durante a interrupción. O acceso directo a ficheiros de SharePoint tamén seguía funcionando. A distinción útil a nivel de aplicación é a dependencia detrás dunha operación, en lugar de tratar cada función baixo un logotipo de produto como compartindo o mesmo estado de fallo. ### O tempo de espera de corenta e oito horas para o correo electrónico estableceu un prazo de reparación? Microsoft estendeu a xanela de tempo de espera do correo electrónico para preservar as mensaxes atrasadas mentres priorizaba o procesamento da cola e do atraso. Iso deu máis tempo ao correo atrasado durante a recuperación. O aviso público non forneceu un prazo de reparación de corenta e oito horas e ningunha garantía de que todas as mensaxes chegarían ao seu destinatario. Unha notificación pendente ou en cola, polo tanto, requiría unha entrega real ou unha comprobación de resultado antes de que un fluxo de traballo sensible ao tempo puidese depender dela. ### Como afectou a interrupción de Exchange ás aplicacións de Microsoft Graph? As solicitudes de correo, calendario e contactos de Exchange Online podían exceder o tempo de espera segundo Microsoft. Unha aplicación podía atopar diferentes resultados en operacións con diferentes dependencias subxacentes. O episodio recomenda comprobar a dependencia real do servizo da operación. A documentación de limitación ordinaria separada de Microsoft discute o cumprimento de Retry-After e o retroceso exponencial cando ese cabeceira está ausente; esas políticas non establecen a causa deste incidente nin prometen a restauración do servizo. ### Cal foi o veredicto de The Daily Diff sobre a recuperación de Microsoft? O veredicto de The Daily Diff foi NEEDS REVIEW. Niko mantivo a recuperación baixo revisión porque as actualizacións de Microsoft describían que os servidores restablecidos fallaban baixo tráfico. O servizo sostido con traballo real chegando era a proba de recuperación útil. A causa inicial permaneceu aberta no momento do corte do informe do episodio, con Microsoft prometendo un informe completo do incidente e accións de defensa en profundidade despois da mitigación. ## Capítulos - 0:00 Por que os servidores restablecidos fallaron de novo? - 0:19 Que funcións dependían de Exchange? - 1:03 Como a falta de capacidade sobrecarga un servizo? - 1:34 Que intentou Microsoft primeiro? - 2:48 Que se sabía no momento do corte do informe? - 3:17 Por que podía fallar unha solicitude de Graph? - 4:05 Que se consegue coa xanela de correo de 48 horas? - 4:48 Que necesitaría probar unha recuperación sostida? ## Transcrición traducida Traducido da narración orixinal en inglés. O audio e os subtítulos dispoñibles son controlados por YouTube. ### Por que os servidores restablecidos fallaron de novo? 0:00 Microsoft restableceu os servidores de correo. Podían deixar de responder de novo cando volvía o tráfico. Aquí está o seguimento do desenvolvedor. Neste vídeo, por que a recuperación seguía fallando? E que partes da túa aplicación seguían funcionando? Microsoft tamén deu corenta e oito horas para o correo electrónico atrasado. Que se consegue realmente con iso? É venres, trece de novembro, e isto é The Daily Diff. 0:18 Exchange Online é o servizo de correo electrónico aloxado de Microsoft, e outras funcións de Microsoft 365 ### Que funcións dependían de Exchange? 0:22 dependen del. Aquí está a distinción útil da páxina de estado de Microsoft. As chamadas e chats de grupo de Teams funcionaron na súa maioría. As funcións de calendario e as solicitudes de datos de buzón podían fallar. Verifique a dependencia que realmente utiliza a súa aplicación. Isto significa que unha reunión aínda pode ter lugar mentres o calendario se nega a cooperar. O acceso directo a ficheiros en SharePoint tamén seguiu funcionando, mentres que algunhas funcións de compartición estaban afectadas. 0:42 O logotipo na xanela di moi pouco sobre o backend que o seu próximo clic necesita. A interrupción comezou o xoves, con Microsoft investigando inicialmente o acceso ao buzón nas Américas. Logo confirmou que usuarios de calquera rexión podían verse afectados. CNN informou de problemas en bancos, gobernos e tribunais. Un correo electrónico desaparecido é inconveniente ata que o traballo real dalguén depende da súa chegada. A explicación inicial de Microsoft foi unha perda de servidores dispoñibles. ### Como a falta de capacidade sobrecarga un servizo? 1:06 O traballo que esas máquinas deberían ter manexado esforzou a infraestrutura restante. Pode sobrecargar un servizo con demanda ordinaria cando a súa capacidade desaparece. A cola faise máis longa aínda que ninguén descubra de repente unha paixón por enviar correo electrónico. A empresa investigou entón as comprobacións de saúde automatizadas. Estas comprobacións axudan a decidir se un servidor pode recibir traballo. Microsoft dixo que un compoñente que procesa a saúde do servidor podería estar implicado. É unha hipótese dunha investigación aínda en curso. 1:29 Non temos un informe final do incidente que explique exactamente por que eses servidores primeiro quedaron indispoñibles. As actualizacións parecen un turno de garda que se vai interesando ### Que intentou Microsoft primeiro? 1:37 progresivamente menos no almorzo. Pausar implantacións. Mover tráfico. Reiniciar servidores. Microsoft validou unha comprobación de saúde alternativa que recuperou un subconxunto, e preparou sistemas automatizados para detectar e reiniciar máquinas insensibles. Cada actualización describía un intento de recuperar capacidade. Despois veu a liña que explica o bucle de recuperación. Microsoft dixo que os servidores restablecidos podían volver ser insensibles unha vez que recibían tráfico. 1:59 Unha máquina podía volver, recibir traballo real e deixar de responder. Esa observación é unha proba máis forte que a teoría confiada de calquera persoa nas respostas. Imaxine o mesmo servidor a través deses estados. Indispoñible. Restablecido. Recibindo tráfico. Insensible de novo. Isto ilustra o relato de Microsoft. O que desencadea esa última transición segue sen resposta. Un reinicio pode producir unha mellora 2:18 temporal mentres a condición que derrota o servidor segue sen resolverse. O consello de "apagalo e acendelo de novo" empeza a cobrar horas extras. Os enxeñeiros teñen que comprobar o que acontece despois de que volva o traballo. Os clientes necesitan que o servizo siga funcionando coa seguinte solicitude, e coa seguinte. Microsoft limitou certo tráfico que chegaba á infraestrutura afectada nalgunhas localizacións. Tamén reconstruíu un subconxunto de servidores utilizando unha configuración anterior para 2:39 probar se se manterían sensibles. Esas foron as mitigacións experimentais informadas. Pausar as implantacións durante a recuperación non nos dá ningunha proba de que unha implantación de venres causou a interrupción orixinal. ### Que se sabía no momento do corte do informe? 2:48 Segundo a actualización do venres de Microsoft ás once e catro UTC, as accións de recuperación remataran en partes de Asia Pacífico. O tráfico estaba regresando gradualmente, con melloras no acceso ao buzón e no procesamento de correo atrasado. Algúns usuarios aínda podían enfrontarse a problemas intermitentes, e a recuperación noutros lugares continuaba. Ese é o noso corte de informe. Microsoft dixo que non tiña probas de actividade maliciosa, e prometeu un informe completo do incidente despois da mitigación. 3:10 Eu agardaría por ese informe antes de asignar un vilán. O traballo de detective de Internet pode darche un culpable antes de que incluso remates de actualizar a páxina. Para os desenvolvedores, Microsoft Graph fai que a dependencia sexa especialmente fácil de pasar por alto. ### Por que podía fallar unha solicitude de Graph? 3:20 As súas solicitudes de correo, calendario e contactos de Exchange podían exceder o tempo de espera. A súa aplicación pode chamar a Graph con éxito para unha operación e fallar noutra. Unha solicitude non relacionada exitosa di pouco sobre se a operación de buzón que o seu usuario necesita se completará. A páxina de estado incluso necesitaba a súa propia ruta de escape. Microsoft publicou información do incidente porque os administradores poderían non ser capaces de cargar o centro de administración para ler o estado do servizo. Cando o panel para saber o que está roto depende do que está roto, 3:46 o panel uniuse ao incidente. Manteña unha ligazón de estado fóra de banda dispoñible. Para a limitación ordinaria de Graph, a guía de Microsoft di que se debe respectar o atraso de reintento cando unha solicitude obtén unha resposta de "demasiadas solicitudes", e usar o retroceso exponencial cando ese cabeceira está ausente. Esa guía xestiona a limitación. Non diagnostica esta interrupción nin promete que os reintentos restablecerán o servizo. Agora as corenta e oito horas. ### Que se consegue coa xanela de correo de 48 horas? 4:05 A páxina de estado expandida de Microsoft di que priorizou o procesamento da cola e do atraso e estendeu a xanela de tempo de espera do correo electrónico para preservar as mensaxes atrasadas. Isto dá máis tempo ao correo atrasado durante a recuperación. Establece unha xanela de tempo de espera do correo. Microsoft non deu un prazo de corenta e oito horas para solucionar o servizo, e ningunha garantía de que todas as mensaxes chegarían. Así que sexa honesto cos claims de entrega. Unha notificación atrasada non necesariamente desapareceu, 4:28 e unha mensaxe en cola non necesariamente chegou ao seu destinatario. Para traballos sensibles ao tempo, verifique o resultado a través dunha canle independente aprobada. Unha xanela de cliente é un recibo de entrega optimista cando o backend aínda se está recuperando. O que deixa moito que ler no eventual informe do incidente. Se prefires ler isto que escoitarmo, o diff chega á túa caixa de entrada cada mañá, gratuíto en the daily diff dot dev, ligazón a continuación. Entón o veredicto de hoxe, NEEDS REVIEW. ### Que necesitaría probar unha recuperación sostida? 4:49 Mantería a recuperación baixo revisión porque as propias actualizacións de Microsoft mostraron que os servidores restablecidos fallaban baixo tráfico. A proba útil é o servizo sostido con traballo real chegando. Ata o informe final, a causa inicial permanece aberta. E ese é o diff de hoxe. Son Niko de Axrisi. Fusiona con responsabilidade. ## Fontes - [ExpandedMicrosoftservicehealth, reportingcutoffNovember13 11:04:50UTC; earlier10:01:07observationshistorical](https://status.cloud.microsoft/) — Microsoft - [Returned servers can become unresponsive again once they receive traffic](https://x.com/MSFT365Status/status/2121031935010951521) — Microsoft 365 Status - [Health-processing component investigation hypothesis](https://x.com/MSFT365Status/status/2120974801388904932) — Microsoft 365 Status - [Alternative health check returned a subset of servers](https://x.com/MSFT365Status/status/2120985048337830246) — Microsoft 365 Status - [Isolate, restart and reintroduce traffic to test stability](https://x.com/MSFT365Status/status/2121002505911857577) — Microsoft 365 Status - [Unavailable servers strain remaining infrastructure](https://x.com/MSFT365Status/status/2120962673911181437) — Microsoft 365 Status - [Initial Exchange mailbox-access investigation in the Americas](https://x.com/MSFT365Status/status/2120938282204688468) — Microsoft 365 Status - [Users in any region may be affected](https://x.com/MSFT365Status/status/2120941584220827979) — Microsoft 365 Status - [Email timeout extended to preserve delayed messages](https://x.com/MSFT365Status/status/2121172248241348867) — Microsoft 365 Status - [Paused deployments, traffic redistribution and server restarts](https://x.com/MSFT365Status/status/2120957934607700161) — Microsoft 365 Status - [Independent live reporting on the Microsoft email disruption](https://www.cnn.com/2026/11/12/business/live-news/microsoft-global-outage-intl-hnk) — CNN - [Microsoft Graph throttling guidance](https://learn.microsoft.com/en-us/graph/throttling) — Microsoft Learn - [Exchange Online service description](https://learn.microsoft.com/en-us/office365/servicedescriptions/exchange-online-service-description/exchange-online-service-description) — Microsoft 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.](https://commons.wikimedia.org/wiki/File:Satya_Nadella.jpg) — OFFICIAL LEWEB PHOTOS - [Portrait-only CC BY 2.0 licence; separate from third-party source/cartoon rights](https://creativecommons.org/licenses/by/2.0/) — Creative 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.](https://imgflip.com/memetemplate/234202281/AJ-Styles--Undertaker) — 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.](https://giphy.com/gifs/the-simpsons-sideshow-bob-RSOUOj8H9A3Xq) — The Simpsons / 20th Television / Disney; GIPHY source hosting