AWS : le post-mortem de la grande panne révèle un bug rare et une automatisation extrême
Quelle dépendance ?
Amazon Web Services a publié un long post-mortem, revenant de manière détaillée sur la gigantesque panne qui a affecté ses services le 20 octobre. À la racine de la cascade, une situation de compétition autour d’enregistrements DNS et un effondrement d’autres services par effet domino. L’automatisation s’est retournée contre ses concepteurs.
La panne AWS du 20 octobre a affecté de très nombreuses entreprises s‘appuyant sur son cloud pour proposer leurs services. Alexa, Asana, Snapchat, Fortnite, Epic Games Store, ChatGPT, Autocad ou encore Docker ont été directement touchés, avec une interruption totale ou partielle de leurs activités pendant plusieurs heures.
Comment une telle panne a-t-elle pu arriver ?
AWS avait publié une série d’informations tout au long de la panne, ne serait-ce que pour tenir informée la clientèle, forcément démunie. On savait que le service de base de données DynamoDB était impliqué et qu’Amazon avait rencontré des problèmes avec les DNS. Mais le rapport complet de l’incident est nettement plus intéressant.
Pour comprendre ce qui s’est passé, rappelons qu’AWS est une infrastructure immense, dans laquelle DynamoDB tient une place importante. Le service utilise des centaines de milliers d’enregistrements DNS pour gérer la flotte de serveurs qui lui sont rattachés. Deux systèmes entièrement automatisés sont chargés d’assurer la résilience de l’ensemble en gérant ces enregistrements et en assurant la cohérence du tout.
C’est aussi à travers eux que le problème s’est présenté, sous la forme d’une situation de compétition (race condition en anglais). Expliquons rapidement de quoi il s’agit : une situation de compétition est un bug survenant quand le comportement d’un programme dépend de l’ordre ou du moment précis d’exécution de plusieurs processus tournant en parallèle.
Dans le cas présent, les deux systèmes automatisés travaillaient simultanément sur les mêmes enregistrements DNS. En temps normal, ce n’est pas un problème et des mécanismes existent pour gérer les résultats. Mais pour une raison inconnue (AWS ne dit pas laquelle), l’un des systèmes automatisés, appelé DNS Enactor, s’est mis à afficher un retard important dans ses calculs et donc dans la mise à jour des enregistrements DNS. L’autre système a fini ses calculs, mis à jour les enregistrements DNS, puis a lancé un nettoyage pour effacer les anciennes informations.
Commentaires (19)
Le 27/10/2025 à 14h29
J'ai un module d'enchère, acheté avec du support, que j'ai entièrement dû reprendre avec des LLM parce que les devs d'origine étaient incapables de gérer des problèmes de ce type, et je me retrouvais aléatoirement avec plusieurs produits gagnés d'un coup pour un ou plusieurs clients différents... Un comble...
Le 27/10/2025 à 15h53
Pour le taf j'ai fait une expression de besoin, avec une série de conditions, pour traiter un fichier.
On m'a indiqué qu'une recette avait eu lieu ... et on m'a présenté le résultat.
Une valeur impossible, qui ne fait pas partie des spécs était présente, ça n'a choqué aucun des devs présents, le fait de compter 2 fois des éléments, ça ne les a pas choqué non plus.
Ils ont réussi à me pondre un outils qui ne respecte même pas les specs ...
J'ai d'autres exemples sur d'autres process où seul le cas nominal est codé, genre une IHM, on demandé un téléphone, bah aucun contrôle sur le type de données, donc on peu balancer l'alphabet chinois pour faire planter l'interface, 0 contrôle de surface.
et la réponse des devs ? "nan mais l'utilisateur il fait pas ça, nous on sait comment ça marche on ne le fait pas"
C'est beau la naïveté, ou l'ignorance, ou un mélange des deux ...
Le 27/10/2025 à 17h04
"nan mais les devs c'est obsolète maintenant on fait tout avec des prompts chatgpt & bientôt des agent qui vont mettre en prod tout seul".
Ca ne peux que bien se passer dans l'avenir...
Modifié le 27/10/2025 à 17h27
De mon côté, sans faire un reverse engineering complet du code qu'on m'avait donné via les llm, ça aurait été un boulot encore plus monstrueux en matière de travail de partir de 0...
Tout corriger et stabiliser m'a demandé quasiment cinq semaines de boulot à temps plein pour anticiper tous les besoins et corriger toutes les incohérences, heureusement qu'avec ma pépinière, je peux me le permettre...
Pas le choix ceci dit, c'étaient les seuls à proposer un module du genre sous prestashop...
Modifié le 27/10/2025 à 19h02
Le 27/10/2025 à 19h16
Le 27/10/2025 à 21h33
Alors certes tu as des idiots, mais d'expérience faut regarder la chaîne de commandement.
Le 03/11/2025 à 07h34
- trop "sécuriser" un algo revient à multiplier les points communs de synchro, verroux, contrôles ou autres sémaphores, au final ton algo devient lent (monothread), critique (un internaute commençant un acte va bloquer les autres) et ralenti toute la chaîne.
- trop paralléliser à l'inverse, améliore les perfs, supprime les deadlocks, mais ouvre la voie au bug aléatoire impossible à déboguer ou reproduire.
=> les deux types d'algo sont valables et doivent être choisis / codés selon le besoin.
Dans tous les cas le dev n'est pas l'unique responsable, il y'a souvent une défaillance dans les expressions des besoins, ces 3 règles sont valables :
- "il n'est pas possible de commander plusieurs fois le même produit." (typiquement on vend un produit unique, ce qui pourrait être le cas d'une vente aux enchères)
- "le produit est industriel, il peut toujours être commandé, les ventes n'impactent que le délais de livraison" (une voiture, une carte graphique quoi-que
- "le système doit gérer une série limitée c-à-d un volume restreint avec un fort risque de pic de ventes parallèle" (typiquement des places de concerts attendues day-one où tu va bouffer un traffic monstre sur quelques minutes)
Dans le premier cas, il faut gérer un verrou à chaque enchère et ne libérer que lorsque l'enchère est passée
Le second cas ne nécessite aucun verrou, mais devra sans doute être connecté au système de planification pour informer assez tôt des délais de production / livraison
Le dernier cas est l'opposé du premier : il ne faut surtout pas verrouiller ou contrôler les stocks, tout laisser passer en mémorisant simple l'ordre de commande, et uniquement après la validation du paiement contrôler le stock réel, en parallèle il faut prévoir un système de remboursement, de désactivation des ventes (soldout), voire revente et liste d'attente.
Un dev ou son equivalent automatisé ne va pas (facilement) identifier ou inventer une RG non-exprimée, bien souvent ce qui est "sous-entendu", "induit" voire même "évident" pour le key user, ne l'est pas pour le dev qui jongle avec des contextes de clients très différents.
Pour moi le rôle du dev est aussi d'être consultant : conseiller, participer à la rédaction de l'expression du besoin en posant les bonnes questions.
Gérer la billetterie du Hellfest qui vend 240000 billets en 80min (50 passes par secondes !) ce ne sont pas les mêmes contraintes que faire une plateforme de vente aux enchères d'article d’occasion, naïvement c'est la même chose : "Fais moi une plateforme de vente en ligne"
Modifié le 27/10/2025 à 15h08
Ce qui est moche également, c'est qu'une grande partie de l'infra AWS dépende du DC US-EAST1.
Vive le Minitel 2.0, France Télécom / Orange en rêvait, Amazon et CloudFlare l'ont inventé…
Le 27/10/2025 à 15h22
Le 27/10/2025 à 16h00
C'est pas la 1er fois fois que l'on voit des licenciements pendant des années records de bénéfices...
Le 27/10/2025 à 18h26
Dans un cas comme on a eu là, c'est probablement grâce à un "sachant" réveillé à 2h du mat' que la solution a pu être rétablie. L'IA, elle, serait probablement tombée en panne, ou n'aurait juste pas su répondre car le cas était littéralement jamais vu...
Le 28/10/2025 à 10h10
Le 28/10/2025 à 10h50
Le 27/10/2025 à 18h32
Surtout dans des entreprises qui considèrent le personnel comme jetable et renouvelable à souhaits. Et je suppose que Amazon, comme Microsoft ou Google, doit désormais aussi réduire ses dépenses RH au profit de leurs IA.
Le 27/10/2025 à 21h48
https://www.reuters.com/business/world-at-work/amazon-targets-many-30000-corporate-job-cuts-sources-say-2025-10-27/
Modifié le 28/10/2025 à 14h10
Le 27/10/2025 à 21h58
Le 28/10/2025 à 14h46
Signaler un commentaire
Voulez-vous vraiment signaler ce commentaire ?