Entre 15h26 et 15h48, « deux nœuds DNS sont tombés en panne », provoquant des erreurs lors d’une requête. L’incident n’a duré que 22 minutes, mais un post mortem a été mis en ligne, une transparence appréciable.
La cause principale de la panne est un « bug logiciel » ayant entraîné l’arrêt du serveur. Pour ne rien arranger, cette panne est arrivée en même temps qu’un « incident » sur un réseau interne de l’hébergeur. Ce dernier a causé « beaucoup de bruit dans nos systèmes de surveillance, conduisant à une mauvaise interprétation des alertes déclenchées par les serveurs DNS ».
De nouvelles procédures sont mises en place afin d’éviter que cela ne se reproduise.
Commentaires (6)
#1
La transparence du post morten est a saluer.
Cependant, pour l’incident, ça montre un manque de connaissance. Le design, qui est fait a tête reposé en amont de l’implémentation, est clairement mal fait:
Anycaster les 3 IPs depuis un même serveur, et je dirais même, depuis une même zone géographique, c’est une faute de design, pas un incident.
Le DNS, c’est l’une des rangés de parpaing qui fait parti des fondations de l’Internet. Si ca tombe, y a juste plus rien qui fonctionne. Le DNS est justement un protocole super simple et basique, qui le rend donc super robuste pour cette raison. Vouloir faire de l’over-ingénieurie au dessus, c’est le fragiliser, et voilà ce qui arrive.
#2
Le côté « positif » c’est que sur une aussi courte durée la plupart des résolutions ont du se faire au niveau des caches des FAI (ou autres 8888 ou 1111).
#3
#4
Je dis erreur de design, tu dis erreur de conception. Pour moi c’est la même chose hein :)
#5
Mon propos était plutôt sur la causalité. Nous sommes tous les deux d’accord sur le fait que la conception est discutable.
Ce qui me faisait tiquer, c’est le fait que tu estimes que ce n’est pas un incident mais un défaut de conception. Un défaut de conception peut être fonctionnel sans provoquer d’incident. Ce qui n’empêche pas de le corriger aussi avant qu’il n’en provoque. (l’erreur est humaine, constater l’ano avant qu’elle ne provoque des dégâts et dresser un plan d’action pour la corriger est la bonne démarche… L’inverse serait une bêtise par contre)
C’est sur ce lien de causalité que ma remarque portait, ou alors j’ai mal interprété.
#6