Date du post mortem : 27/01/2022
Participants du post mortem :
Suite à une mise à jour du moteur d’optimisation sur le moteur de règle liée aux configurations, les pages de certains clients ont été cassées.
24/01 au 26/01 : Passage d’une partie de la production avec la nouvelle version (mode canary)
26/01 15h57 : Release du moteur sur la mise à jour de la librairie responsable de la gestion des règles autour des configurations clientes
26/01 18h21 : un ticket au support indiquant un souci de JS.
26/01 18h43 : Fin de la release
26/01 21h42 : nouveau ticket au support
27/01 08h09 : nouveau ticket au support
27/01 09h10 : prise en compte des tickets au support et fait le lien avec la MEP d’hier
27/01 09h15 : Réponse aux tickets support pour indiquer le début d’investigation
27/01 09h23 : nouveau ticket au support
27/01 09h21 : déclaration publique d’un incident
27/01 09h37 : ouverture d’une visioconf de gestion
27/01 09h40 : décision de rollback les workers
27/01 09h41 : mise à jour de l’incident en cours
27/01 10h08 : Fin du rollback des workers
27/01 10h48 : Message sur status page indiquant le retour à la normale
La mise à jour visait à passer le moteur sur une nouvelle version majeure de la librairie de gestion de configuration pour être en mesure de lire des configurations V2. La librairie a été entièrement réécrite avec une interface différente pour gérer le système de contexte d'exécution propre aux configurations V2 qui est différent du système d’exclusion propre aux configurations V1.
Le plan de mise à jour consistait à maintenir la même compatibilité sur la config V1 utilisée actuellement en production par l’ensemble des clients.
Le bug introduit est un bug au niveau de la librairie de gestion des configurations. Lors de l’analyse de règle ayant une blacklist, le code avait un effet de bord qui désactive la règle pour les appels suivants.
Cela a introduit des problèmes au niveau du deferjs car certains scripts n’étaient plus différés.
La mise à jour a suivi le circuit classique de validation : tests unitaires et fonctionnels sur les environnements de pré production verts et suite à la mise en production, l’ensemble des métriques du moteur étaient bonnes.
Lors de la mise en production, aucune statistique n’a remonté le problème. La statistique du nombre d’erreurs JS n’a pas remontée de problème. été fiable et est restée à son niveau habituel.
Malgré que les clients ont signalé le problème via des tickets support, aucune action n’a été prise car les tickets n’ont pas déclenchés l’astreinte pendant les heures non ouvrées.
La mise en production a été déclenchée trop tardivement dans la journée par rapport au niveau de risque et a été terminée à la fin des heures ouvrées. L’équipe de Fasterize n’était plus en place en cas d’incident.
Il n’y a pas eu de navigations manuelles après la mise en production pour détecter un problème côté navigateur lié à du Javascript. Cela aurait peut-être permis de détecter le problème rapidement.
Sévérité 1: arrêt du site non planifié qui affecte un nombre significatif d'utilisateurs
Rollback des ami des workers
Vidage du cache des pages du top clients + clients ayant écrit des tickets au support.
Court terme :
Moyen terme :
Long terme :