Résultats du post-mortem analysant la panne des modules complémentaires

Analyse de la cause principale

La première question que tout le monde se pose est « comment avez-vous pu laisser cela se passer ? ». Vu de très haut, l’histoire semble simple : nous avons laissé le certificat expirer. Cela ressemble à un simple problème de planification, mais après plus d’investigations cela s’est avéré plus compliqué : l’équipe responsable du système générant les signatures savait que le certificat allait expirer mais pensait (à tort) que Firefox ignorait les dates d’expiration. Une des raisons de cette incompréhension tient au fait que lors d’un incident précédent nous avions désactivé la vérification des certificats d’entités finales, et cela a créé une confusion sur le statut de la vérification des certificats intermédiaires. De plus, le programme d’assurance qualité (QA) de Firefox n’intégrait pas de tests de l’expiration des certificats (et plus généralement de tests du comportement du navigateur à des dates futures) et par conséquent le problème n’a pas été détecté. Cela semble avoir été un oubli fondamental dans notre programme de test.

La leçon ici est donc : 1. nous devons avoir de meilleures communication et documentation de ces parties du système et 2. cette information doit être remontée à notre équipe d’ingénierie et d’assurance qualité pour être certain que nous ne rations rien. Le rapport technique donne plus de détails.

Diffusion du code

Comme je l’ai mentionné précédemment, une fois que nous avons un correctif, nous avons décidé de le diffuser via le système d’Études (une partie du système que nous appelons « Normandy » en interne). Le système d’études n’est pas un choix évident pour ce type de déploiement, car il a été conçu pour déployer des expérimentations et non des correctifs. De plus, parce que les permissions du système d’Études sont couplées à la télémétrie, cela signifiait que certains utilisateurs et certaines utilisatrices devaient activer la télémétrie pour recevoir le correctif, impliquant que Mozilla allait temporairement collecter plus de données que nous voulions réellement, et que nous avons donc dû supprimer.

Ce qui pose naturellement la question : « n’y avait-il d’autres moyens de déployer le correctif ? », question à laquelle nous répondons « en quelque sorte ». Nos autres mécanismes principaux de déploiement de code aux utilisateurs et utilisatrices sont les versions mineures et un système appelé « Balrog ». Malheureusement, tous deux sont plus lents que Normandy : Balrog vérifie les mises à jour toutes les 24 heures tandis que Normandy vérifie toutes les 6 heures. Parce que le problème a touché beaucoup d’utilisateurs et d’utilisatrices, sa correction était de la plus haute priorité. Le système d’Études était donc le meilleur choix technique.

La leçon est donc que nous avons besoin d’un système qui permette des mises à jour rapides qui ne soit couplées ni à la télémétrie, ni au système d’Études. La propriété recherchée est la possibilité de déployer rapidement une mise à jour vers n’importe quelle instance de Firefox ayant les mises à jours automatiques activées. C’est une fonctionnalité sur laquelle notre ingénierie travaille déjà.

Correctifs incomplets

Durant les semaines suivant cet incident, nous avons publié un nombre important de correctifs, dont huit versions du système de modules complémentaire et six versions mineures. Dans certains cas, ces multiples correctifs ont été nécessaires car des cibles du déploiement plus anciennes exigeaient un correctif séparé. Dans d’autres cas, c’était une conséquence de défauts d’un correctif précédent que nous avions ensuite à corriger avec un travail supplémentaire. Bien sûr, les défauts dans les logiciels ne peuvent être complétement éliminés, mais le rapport technique montre qu’au moins dans certains cas, un haut niveau d’urgence combiné à un manque de ressources de contrôle qualité disponibles (ou au moins des problèmes de coordination autour du contrôle qualité) a amené à des tests qui étaient moins complets que ce que nous aurions voulu.

La leçon est que lors d’incident de ce type, nous devons nous assurer que non seulement nous enrôlons du personnel de management, d’ingénierie et d’opérations (comme nous l’avons fait) mais aussi que nous avons les contrôles qualité disponibles pour tester les inévitables correctifs.

Pour en savoir plus

Si vous souhaitez en savoir plus sur nos découvertes, je vous invite à lire les rapports détaillés que nous avons rédigés. Et comme à chaque fois, si tout cela ne répond pas à vos questions, n’hésitez pas à m’envoyer un courriel à ekr-blog[ad]mozilla[point]com.

À propos d’Eric Rescorla

Eric est directeur technique (CTO) de l’équipe Firefox chez Mozilla.

Note du rédacteur : 12 juillet, 13h52 heure du Pacifique – mise à jour de la fréquence de mise à jour de Balrog et ajout d’un peu de contexte.

Nos traductions sur cette panne

Traduction et relecture : Cajuteq, Mozinet, Vincent, Mossroy et anonymes

Précédent article sur Firefox : Tester l’incrustation vidéo (Picture-in-Picture) dans Firefox 69 bêta et Developer Edition

Avez-vous déjà eu besoin de parcourir une recette tout en regardant une vidéo de cuisine ? Ou avez-vous peut-être déjà voulu regarder l’enregistrement d’une conférence tout en consultant les diapositives d’une formation ? Ou peut-être que vous vouliez regarder quelqu’un jouer à des jeux vidéo en streaming tout en travaillant…

Crédit illustration ajoutée à la traduction : Artturi Mäntysaari sous licence permissive Pixabay.