Je dis erreur de design, tu dis erreur de conception. Pour moi c’est la même chose hein :)

SebGF a écrit :



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é.







Ah si si, il y a bien un incident, j’ai pas été très clair en faite. Ce que je dis, c’est que ce n’est pas juste un incident, c’est un vrai problème de design.



Ce que je veux dire, c’est que si le design est fait correctement, il ne peut pas y avoir d’incident autre qu’une erreur humaine sur une action d’admin ou bug logiciel. Dans le cas présent, le problème, c’est que by-design, l’architecture était vouée a avoir un incident, c’était juste une question de temps pour savoir quand est-ce que ça allait arriver.



Je viens de vérifier avec un mtr sur un domaine que j’ai chez eux en “live dns” et c’est toujours le cas. J’ai exactement la même latence et le même traceroute sur les trois serveurs… Peut être que les IPs sont maintenant annoncées depuis des serveurs différents, mais en cas de problème local sur le datacenter, un truc un peu batard comme de la grosse perte de paquet ou alors que la session BGP reste UP alors que les applis sont down,… ca peut retomber. Alors qu’avoir des DNS répartie sur plusieurs datacenter (ce qu’ils ont en plus), ca permet de se prémunir d’un problème local au datacenter.