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

Ce que cette vidéo couvre

• Vérifiez la dépendance dorsale de chaque opération: la plupart des fonctionnalités principales de Teams et l'accès direct aux fichiers SharePoint sont restés fonctionnels, tandis que les fonctionnalités dépendant d'Exchange ont été 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 la santé est restée une hypothèse.
• Le délai d'attente prolongé de quarante-huit heures pour les courriels était destiné à préserver les courriels retardés pendant le traitement des files d'attente et des arriérés. Il ne s'agissait ni d'une date limite de réparation ni d'une garantie de livraison universelle.
• Les directives ordinaires de limitation 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 contrôlés par YouTube.

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

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 courriels retardés. Qu'est-ce que cela vous apporte réellement? Nous sommes le vendredi treize 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 de Microsoft trois

Quelles fonctionnalités dépendaient d'Exchange?

0:22 cent soixante-cinq en dépendent. Voici la distinction utile de la page d'état de Microsoft. Les appels Teams et les conversations de groupe fonctionnaient principalement. Les fonctionnalités de calendrier et les demandes 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 pendant que 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.

0:42 Le logo sur la fenêtre vous en dit très peu sur le backend dont votre prochain clic aura 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 courriel 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.

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

1:06 Le travail que ces machines auraient dû gérer a mis à rude épreuve l'infrastructure 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 de courriels. L'entreprise 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é du serveur pourrait être impliqué. C'est une hypothèse d'une enquête toujours en cours.

1:29 Nous n'avons pas de rapport d'incident final expliquant exactement pourquoi ces serveurs sont devenus indisponibles pour la première fois. Les mises à jour se lisent comme un quart de travail sur appel devenant progressivement

Qu'a essayé Microsoft en premier?

1:37 moins intéressé par le petit-déjeuner. Mettre en pause les déploiements. Déplacer le trafic. Redémarrer les serveurs. Microsoft a validé une autre vérification de santé 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 est venue 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 une fois qu'ils recevaient du trafic.

1:59 Une machine pouvait revenir, recevoir du vrai travail et cesser de répondre. 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. Prendre 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

2:18 temporaire tant que la condition qui met hors service le serveur reste 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 certains endroits. Il a également reconstruit un sous-ensemble de serveurs en utilisant une configuration précédente pour

2:39 tester s'ils resteraient réactifs. Ce sont des expériences d'atténuation signalées. Mettre en pause les déploiements pendant la récupération ne nous donne aucune preuve qu'un déploiement du vendredi a causé la panne initiale.

Qu'était-il connu au moment de la coupure des rapports?

2:48 Selon la mise à jour de Microsoft du vendredi à onze heures quatre minutes UTC, 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 courriels retardés. Certains utilisateurs pouvaient toujours rencontrer des problèmes intermittents, et la récupération ailleurs se poursuivait. C'est notre coupure 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.

3:10 J'attendrais ce rapport avant d'attribuer un coupable. Le travail de détective sur Internet peut vous donner un coupable avant même que vous ayez fini de rafraîchir la page. Pour les développeurs, Microsoft Graph rend la dépendance particulièrement facile à manquer.

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

3:20 Ses requêtes pour le courrier, le calendrier et les contacts Exchange pouvaient expirer. Votre application peut appeler Graph avec succès pour une opération et échouer sur une autre. Une requête sans rapport réussie vous en dit peu sur la question de savoir si l'opération de boîte aux lettres dont votre utilisateur a besoin se terminera. La page d'état avait même besoin de sa propre voie d'évacuation. Microsoft a publié des informations sur l'incident publiquement parce que les administrateurs pourraient être incapables de charger le centre d'administration pour lire l'état du service. Lorsque le tableau de bord pour savoir ce qui ne fonctionne pas dépend de ce qui ne fonctionne pas,

3:46 le tableau de bord a rejoint l'incident. Gardez un lien d'état hors bande disponible. Pour la limitation ordinaire de Graph, les directives de Microsoft disent d'honorer le délai de nouvelle tentative lorsqu'une requête reçoit une réponse « trop de requêtes », et d'utiliser l'interruption exponentielle lorsque cet en-tête est absent. Ces directives gèrent la limitation. Elles ne diagnostiquent pas cette panne ni ne promettent que les nouvelles tentatives rétablissent le service. Maintenant les quarante-huit heures.

Que rapporte la fenêtre de courriel de 48 heures?

4:05 La page d'état étendue de Microsoft indique qu'il a priorisé le traitement des files d'attente et des arriérés et prolongé la fenêtre de délai d'attente des courriels pour préserver les messages retardés. Cela donne plus de temps aux courriels retardés pendant la récupération. Cela définit une fenêtre de délai d'attente pour les courriels. Microsoft n'a donné aucun délai de quarante-huit heures pour réparer le service, et aucune garantie que chaque message arriverait. Alors, gardez les affirmations de livraison honnêtes. Une notification retardée n'a pas nécessairement disparu,

4:28 et un message en file d'attente n'a pas nécessairement atteint son destinataire. Pour les travaux urgents, vérifiez le résultat via un canal indépendant approuvé. Une fenêtre client est un accusé de réception optimiste lorsque le backend est encore en cours de récupération. Ce qui laisse beaucoup à lire dans le rapport d'incident éventuel. Si vous préférez lire cela plutôt que de m'entendre le dire, le diff arrive dans votre boîte de réception tous les matins, gratuitement sur the daily diff dot dev, lien ci-dessous. Alors le verdict d'aujourd'hui, NÉCESSITE UN EXAMEN.

Que devrait prouver une récupération durable?

4:49 Je maintiendrais la récupération sous examen car les propres mises à jour de Microsoft ont montré que les serveurs remis en service échouaient sous le trafic. Le test utile est un service soutenu avec un vrai travail 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.

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