La récupération d'Outlook de Microsoft a continué d'échouer sous le trafic

Ce que couvre cette vidéo

• Vérifiez la dépendance backend de chaque opération : la plupart des fonctionnalités Teams de base et l'accès direct aux fichiers SharePoint sont restés fonctionnels, tandis que les fonctionnalités dépendant d'Exchange étaient altérées.
• Microsoft a signalé que les serveurs remis en service pouvaient redevenir non réactifs lorsque le trafic les atteignait ; son explication du composant de traitement de l'état de santé est restée une hypothèse.
• Le délai d'attente prolongé de quarante-huit heures pour les e-mails était destiné à préserver le courrier différé pendant le traitement de la file d'attente et du carnet de commandes. Ce n'était ni une date limite de réparation ni une garantie de livraison universelle.
• Les directives habituelles de limitation de débit de Graph recommandent d'honorer Retry-After et l'interruption exponentielle lorsque cet en-tête est absent ; elles ne diagnostiquent ni ne réparent cet incident.

Transcription traduite

Traduit de la narration originale en anglais. L'audio et les sous-titres disponibles sont gérés par YouTube.

Pourquoi les serveurs remis en service ont-ils échoué à nouveau ?

0:00 Microsoft a remis les serveurs de messagerie en service. Ils pouvaient cesser de répondre à nouveau lorsque le trafic revenait. Voici le suivi du développeur. Dans cette vidéo, pourquoi la récupération n'a-t-elle cessé d'échouer ? Et quelles parties de votre application fonctionnaient encore ? Microsoft a également accordé quarante-huit heures aux e-mails différés. Qu'est-ce que cela vous apporte réellement ? C'est vendredi 13 novembre, et c'est The Daily Diff.

0:18 Exchange Online est le service de messagerie hébergé de Microsoft, et d'autres fonctionnalités Microsoft 365

Quelles fonctionnalités dépendaient d'Exchange ?

0:22 en dépendent. Voici la distinction utile de la page d'état de Microsoft. Les appels Teams et les discussions de groupe fonctionnaient en grande partie. Les fonctionnalités de calendrier et les requêtes de données de boîte aux lettres pouvaient échouer. Vérifiez la dépendance que votre application utilise réellement. Cela signifie qu'une réunion peut toujours avoir lieu même si le calendrier refuse de coopérer. L'accès direct aux fichiers dans SharePoint est également resté fonctionnel, tandis que certaines fonctionnalités de partage ont été affectées. Le logo sur la fenêtre vous dit très peu de choses sur le backend dont votre prochain clic

0:42 a besoin. La perturbation a commencé jeudi, Microsoft enquêtant initialement sur l'accès aux boîtes aux lettres dans les Amériques. Il a ensuite confirmé que les utilisateurs de n'importe quelle région pouvaient être affectés. CNN a signalé des problèmes dans les banques, les gouvernements et les tribunaux. Un e-mail manquant est gênant jusqu'à ce que le travail réel de quelqu'un dépende de son arrivée. L'explication initiale de Microsoft était une perte de serveurs disponibles. Le travail que ces machines auraient dû gérer a mis à rude épreuve l'infrastructure

Comment une capacité manquante surcharge-t-elle un service ?

1:06 restante. Vous pouvez surcharger un service avec une demande ordinaire lorsque sa capacité disparaît. La file d'attente s'allonge même si personne n'a soudainement découvert une passion pour l'envoi d'e-mails. La société a ensuite enquêté sur les vérifications de santé automatisées. Ces vérifications aident à décider si un serveur peut prendre du travail. Microsoft a déclaré qu'un composant traitant la santé des serveurs pourrait être impliqué. C'est une hypothèse issue d'une enquête toujours en cours. Nous n'avons pas de rapport d'incident final expliquant exactement pourquoi ces serveurs sont devenus

1:29 initialement indisponibles. Les mises à jour ressemblent à une équipe de garde de moins en moins intéressée par le petit-déjeuner.

Qu'a essayé Microsoft en premier ?

1:37 Mettre en pause les déploiements. Déplacer le trafic. Redémarrer les serveurs. Microsoft a validé une vérification de santé alternative qui a ramené un sous-ensemble, et a préparé des systèmes automatisés pour détecter et redémarrer les machines non réactives. Chaque mise à jour décrivait une tentative de récupération de capacité. Puis vint la ligne qui explique la boucle de récupération. Microsoft a déclaré que les serveurs remis en service pouvaient redevenir non réactifs à nouveau une fois qu'ils recevaient du trafic. Une machine pouvait revenir, recevoir un travail réel et cesser de répondre.

1:59 Cette observation est une preuve plus solide que la théorie confiante de quiconque dans les réponses. Imaginez le même serveur à travers ces états. Indisponible. Remis en service. Traitement du trafic. Non réactif à nouveau. Ceci illustre le compte rendu de Microsoft. Ce qui déclenche cette dernière transition reste sans réponse. Un redémarrage peut produire une amélioration temporaire tandis que la condition qui met à mal le serveur reste

2:18 non résolue. Le conseil de l'éteindre et de le rallumer commence à facturer des heures supplémentaires. Les ingénieurs doivent vérifier ce qui se passe après le retour du travail. Les clients ont besoin que le service continue de fonctionner pour la prochaine requête, et la suivante. Microsoft a limité certains trafics atteignant l'infrastructure affectée dans certaines endroits. Il a également reconstruit un sous-ensemble de serveurs en utilisant une configuration précédente pour tester s'ils resteraient réactifs.

2:39 Ce sont des expériences d'atténuation signalées. La mise en pause des déploiements pendant la récupération ne nous donne aucune preuve qu'un déploiement de vendredi a causé la panne initiale. Selon la mise à jour de Microsoft du vendredi à 11h04 UTC,

Que savait-on à la date limite du rapport ?

2:48 les actions de récupération étaient terminées dans certaines parties de l'Asie-Pacifique. Le trafic revenait progressivement, avec des améliorations dans l'accès aux boîtes aux lettres et le traitement des e-mails différés. Certains utilisateurs pouvaient encore rencontrer des problèmes intermittents, et la récupération ailleurs se poursuivait. C'est notre date limite de rapport. Microsoft a déclaré n'avoir aucune preuve d'activité malveillante, et a promis un rapport d'incident complet après l'atténuation. J'attendrais ce rapport avant d'attribuer un coupable.

3:10 Le travail de détective sur Internet peut vous donner un coupable avant même d'avoir terminé de rafraîchir la page. Pour les développeurs, Microsoft Graph rend la dépendance particulièrement facile à manquer. Ses requêtes pour le courrier, le calendrier et les contacts Exchange pouvaient expirer.

Pourquoi une requête Graph pourrait-elle échouer ?

3:20 Votre application peut appeler Graph avec succès pour une opération et échouer pour une autre. Une requête sans rapport réussie vous en dit peu sur la réussite de l'opération de boîte aux lettres dont votre utilisateur a besoin. La page d'état avait même besoin de sa propre voie de secours. Microsoft a publié publiquement les informations sur l'incident car les administrateurs pourraient être incapables de charger le centre d'administration pour lire l'état du service. Lorsque le tableau de bord pour découvrir ce qui est cassé dépend de ce qui est cassé, le tableau de bord a rejoint l'incident.

3:46 Gardez un lien d'état hors bande disponible. Pour la limitation de débit Graph ordinaire, les directives de Microsoft indiquent d'honorer le délai de réessai lorsqu'une requête reçoit une réponse "trop de requêtes", et d'utiliser le "backoff" exponentiel lorsque cet en-tête est absent. Ces directives gèrent la limitation de débit. Elles ne diagnostiquent pas cette panne ni ne promettent que les réessais rétabliront le service. Maintenant les quarante-huit heures. La page d'état étendue de Microsoft indique qu'elle a priorisé le traitement de la file d'attente et du backlog

À quoi sert la fenêtre de 48 heures pour les e-mails ?

4:05 et étendu la fenêtre de délai d'expiration des e-mails pour préserver les messages différés. Cela donne plus de temps aux e-mails différés pendant la récupération. Cela définit une fenêtre de délai d'expiration des e-mails. Microsoft n'a donné aucun délai de quarante-huit heures pour réparer le service, et aucune garantie que chaque message arriverait. Alors, soyez honnête sur les affirmations de livraison. Une notification différée n'a pas nécessairement disparu, et un message en file d'attente n'a pas nécessairement atteint son destinataire.

4:28 Pour un travail urgent, vérifiez le résultat via un canal indépendant approuvé. Une fenêtre client est un reçu de livraison optimiste lorsque le backend est toujours en cours de récupération. Ce qui laisse beaucoup à lire dans le rapport d'incident éventuel. Si vous préférez lire ceci plutôt que de m'entendre le dire, le "diff" arrive dans votre boîte de réception chaque matin, gratuitement sur the dailydiff dot dev, lien ci-dessous. Le verdict d'aujourd'hui, NEEDS REVIEW. Je garderais la récupération à l'étude car les propres mises à jour de Microsoft ont montré des serveurs

Qu'est-ce qu'une récupération soutenue devrait prouver ?

4:49 remis en service échouant sous le trafic. Le test utile est le service soutenu avec un travail réel qui arrive. Jusqu'au rapport final, la cause initiale reste ouverte. Et c'est le "diff" pour aujourd'hui. Je suis Niko d'Axrisi. Fusionnez de manière responsable. Fusionnez de manière responsable.

Sources

1. ExpandedMicrosoftservicehealth, reportingcutoffNovember13 11:04:50UTC; earlier10:01:07observationshistoricalMicrosoft
2. Returned servers can become unresponsive again once they receive trafficMicrosoft 365 Status
3. Health-processing component investigation hypothesisMicrosoft 365 Status
4. Alternative health check returned a subset of serversMicrosoft 365 Status
5. Isolate, restart and reintroduce traffic to test stabilityMicrosoft 365 Status
6. Unavailable servers strain remaining infrastructureMicrosoft 365 Status
7. Initial Exchange mailbox-access investigation in the AmericasMicrosoft 365 Status
8. Users in any region may be affectedMicrosoft 365 Status
9. Email timeout extended to preserve delayed messagesMicrosoft 365 Status
10. Paused deployments, traffic redistribution and server restartsMicrosoft 365 Status
11. Independent live reporting on the Microsoft email disruptionCNN
12. Microsoft Graph throttling guidanceMicrosoft Learn
13. Exchange Online service descriptionMicrosoft Learn
14. 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
15. Portrait-only CC BY 2.0 licence; separate from third-party source/cartoon rightsCreative Commons
16. 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
17. 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