Rapport d’incident Cloudflare du 2 juillet 2019 [Traduction]
(ryanking13.github.io)Le CTO de Cloudflare y résume la vue d’ensemble de l’incident ainsi que la réponse apportée, dans un texte qui permet de comprendre comment des problèmes surviennent au sein d’une organisation de grande taille et comment ils sont gérés.
5 commentaires
L’appendice de l’original est aussi intéressante. Elle contient une explication détaillée de la raison pour laquelle le motif problématique
.*.*=.*a fini par épuiser le CPU, et il me semble que, même si corriger l’expression régulière est une bonne chose, le fait d’avoir envisagé en alternative un remplacement du moteur est également pertinent.C’est un sacré rapport d’incident. Le fait qu’il explique en détail comment la situation a été gérée est déjà remarquable, mais il y a surtout beaucoup à apprendre dans la manière dont ils n’ont pas réduit le problème à une simple erreur d’un ingénieur, et ont au contraire identifié des causes multiples pour les résoudre une à une. Il y a bien eu une panne, mais cela donne presque l’impression que la confiance envers l’entreprise en sort renforcée.
Je me reconnais beaucoup dans ce point de vue. J’ai moi aussi trouvé marquante la manière dont les causes multiples ont été mises en évidence. Le fait de ne pas y voir seulement l’erreur d’un seul ingénieur me semble riche d’enseignements.
Oui, c’est vrai. Il y a peut-être même un dirigeant chargé des rapports d’incident ? C’est déjà impressionnant de pouvoir identifier et analyser les causes avec autant de détails, mais le rapport est aussi si bien rédigé qu’on en viendrait presque à se demander s’il fallait vraiment aller jusque-là.
John Graham-Cumming, le CTO de Cloudflare qui a écrit cet article, est déjà un blogueur bien connu. https://blog.jgc.org/