Azure : Microsoft s’explique sur l’incident du 1er avril
2 min
Internet
Internet
La date tombait bien mal, mais la panne touchant les services Azure pendant une heure était réelle. Microsoft a publié hier des informations sur les causes de l’incident et les mesures prises.
Selon l’entreprise, un pic d’activité a été constaté dans Azure DNS, un flot conséquent de requêtes provenant d’un peu partout dans le monde et visant certains domaines. Ce flot est normalement diffusé à travers des caches et autres techniques de répartition de charge. Et c’est là qu’a résidé le problème.
Une « série spécifique d’évènements » a permis de mettre au jour un « défaut dans le code » du service DNS. Or, pendant que ce dernier croulait sous les requêtes, les clients affectés par des rejets en émettaient de nouvelles.
Ces requêtes, envoyées automatiquement et légitimes, sont venues s’accumuler avec les autres, créant un pic volumétrique qui a saturé la répartition : plus le trafic grimpait, moins le service DNS était disponible.
L’incident a commencé à 21h21 UTC et a été considéré comme réglé à 22h00. À 22h30, la plupart des services étaient considérés comme revenus à la normale.
La fenêtre d’incident était donc réduite, mais tous les services Azure étaient touchés, avec un impact fort sur l’ensemble de tous les produits hébergés de Microsoft, y compris pour le grand public, dont ceux de la Xbox.
L’éditeur indique que plusieurs actions ont été menées pour que ce problème ne se reproduise plus, notamment la réparation du défaut dans le code et l’amélioration de la détection des modèles d’anomalies de trafic.
Commentaires (5)
Abonnez-vous pour prendre part au débat
Déjà abonné ou lecteur ? Se connecter
Cet article est en accès libre, mais il est le produit d'une rédaction qui ne travaille que pour ses lecteurs, sur un média sans pub et sans tracker. Soutenez le journalisme tech de qualité en vous abonnant.
Accédez en illimité aux articles d'un média expert
Profitez d'au moins 1 To de stockage pour vos sauvegardes
Intégrez la communauté et prenez part aux débats
Partagez des articles premium à vos contacts
Abonnez-vousLe 07/04/2021 à 09h28
ça n’aurait pas été plus simple de dire poisson d’avril?
Le 07/04/2021 à 10h35
Faites comme le ministre de l’éducation, dites que c’est la faute de OVH
Le 07/04/2021 à 12h58
L’argumentaire d’Azure est plutôt du niveau “c’est le stagiaire”.
Globalement on brode autour de “y’avait un bug” en faisant découvrir aux gens que quand un site est pas dispo ça a tendance à faire augmenter la charge sur le serveur à cause des refresh. Breaking news.
Mais bon on laisse le flou sur les possibilités d’une attaque DDoS mal mitigée ou d’une hausse de trafic surprise sur certains domaines.
Le 07/04/2021 à 13h28
C’est pas la première fois qu’ils utilisent une formule édulcorée pour faire passer un gros m*rdoiement de leur part.
Y’a quelques années, ils m’ont planté un service VSTS (Visual Studio Team Server) hébergé (c’était avant la folie des Gitlab).
Le mail disait texto “Le crash nous a révélé des points à améliorer dans notre stratégie de backup”. En gros, il y avait bien un backup mais ils étaient incapables de le réinjecter dans la base de données… Bref, l’historique des sources était conservé, mais la base des Work Items était irrécupérable.
Le 08/04/2021 à 19h42
Ça m’a fait marrer. Ou comment des sociétés incompétentes ne savant ni coder correctement ni dimensionner leurs serveurs se trouvent des excuses… no comment.
Signaler un commentaire
Voulez-vous vraiment signaler ce commentaire ?