Après son incident mondial sur son service de CDN, entraînant des indisponibilités pour de nombreux sites, la société est revenue sur les causes dans un court billet de blog.
« Nous avons connu une panne mondiale en raison d'un bug logiciel apparu le 8 juin après avoir été déclenché par un changement de configuration valide d’un client ». 85 % du réseau renvoyaient alors des erreurs. « Nous avons détecté la perturbation en une minute, puis identifié et isolé la cause et désactivé la configuration ».
La société met en avant sa réactivité : « en 49 minutes, 95 % de notre réseau fonctionnaient normalement », mais reconnaît évidemment que « cette panne était vaste et grave ». Elle présente ensuite ses excuses à ses clients.
Un déroulement minute par minute des faits est également proposé. La crise a commencé à 11h47 (heure française). Le billet sur la page de statut a été mis en ligne à 11h58 et la source du problème a été identifiée 30 minutes plus tard. À partir de 12h36, un retour à la normale a débuté doucement et la majorité était en état de fonctionner à 13h.
Un correctif définitif a été déployé à partir de 19h25.
Commentaires (16)
#1
Je suis déçu du manque de transparence de Fastly, l’article ne dispose d’aucun détail sur l’origine de l’incident. Pourtant Cloudflare par exemple publie des post-mortem bien plus détaillés.
#1.1
Peut-être (spéculation) que c’était un bug vraiment stupide et qu’ils perdraient en crédibilité s’ils le montraient ?
#1.2
Peut-être, mais à mes yeux (et je l’espère à ceux de mes pairs) ils perdent en crédibilité en ne faisant pas de post-mortem digne de ce nom : comment peut-on s’assurer de leur professionnalisme sans un minimum de transparence ?
#1.3
tout simple, c’est une question de communication. Un ancien manager d’un grand opérateur m’avait fait part du fonctionnement entre les aléas et incidents pro et grand public : il indiquait qu’une entreprise avait tout à perdre à communiquer sur les incidents, cela laisse une trace, alors que dans quelques années ce sera oublié, et que ca n’intéresse que 10k de geeks. La trace écrite peut etre très préjudicieuse pour l’image de l’entreprise, ce pourquoi “encaisser” les remontades des clients mécontents coute beaucoup moins cher que de communiquer pro-activement sur un truc qui n’arrive pratiquement jamais.
À savoir, je n’ai jamais vu gmail ni yt communiquer sur les pannes qui ont affecté ces dix dernières années le géant de californie, pourtant il n’y en a pas eu qu’une seule. Seul le geek ans son garage veut savoir pourquoi, mais le GP et les gros clients veulent quelque chose qui marchent, la comm’ ils s’en foutent, ca en devient presque contre-productif, sauf si c’est pour se vanter d’un truc sécurisé face à un concurrent qu’a pris feu ;)
#2
Autrement dit les admins essaient de mettre la faute sur les devs.
Trop gros.
#2.1
On en sait rien…
#3
Je suis quand même extrêmement surpris qu’une config d’un client fasse tomber tout le réseau…
#3.1
Nan, le bug était chez eux c’est juste la config. client qui l’a déclenchée saurait pu être autre chose dans un autre contexte.
#3.2
C’est pas incompatible avec ce que j’ai dit…
Sur ce genre de truc, si tu cloisonnes correctement, un bug ne touche qu’un client et non tous ceux qui n’ont rien demandé.
Du coup, je reste surpris que leurs softs ne soient pas suffisamment cloisonnés.
#3.3
Bah oui, mais si le bug est justement dans le logiciel de cloisonnement, tous les clients sont affectés… P. ex l’hyperviseur qui tombe si une des VM fait trois instructions illégales en séquence. Ou tous les exploits récents sur les processeurs qui exploitent la cache.
#4
Cet incident me fait vachement pensé à ce strip
https://www.commitstrip.com/fr/2013/10/11/mieux-et-moins-cher-que-les-tests-unitaires/
#4.1
J’ai toujours dit, les meilleurs testeurs sont les utilisateurs finaux.
#4.2
C’est comme ça que je testais sur des baies de brassage non étiquetées si les ports étaient vraiment utilisés par des PC derrière. (foutue ToIP où le téléphone était entre deux, donc port affiché comme connecté mais pour un tel dans un bureau vide…)
#5
Personnellement, plus d’info sur la panne ? Mwé.
Quand tu prends un service dans le genre, tu vas regarder le taux de panne (et/ou disponibilité), durée des pannes, et le prix.
Derrière, le pourquoi du comment il y a eu un panne à telle date, c’est pas pertinent pour faire un choix.
#6
Côté géants du web, ils ont pourtant un passif de post-mortems sur leurs différentes perturbations de services.
https://aws.amazon.com/premiumsupport/technology/pes/
https://status.azure.com/en-us/status/history/
https://status.cloud.google.com/summary
Les services grands publics communiquent un peu moins sur ce genre de chose apparemment, mais du côté du pro ça trace plutôt bien.