Fasterize incident

JS errors following engine update

Major Resolved View vendor source →

Fasterize experienced a major incident on January 27, 2022 affecting Acceleration, lasting 1h 6m. The incident has been resolved; the full update timeline is below.

Started
Jan 27, 2022, 08:41 AM UTC
Resolved
Jan 27, 2022, 09:48 AM UTC
Duration
1h 6m
Detected by Pingoru
Jan 27, 2022, 08:41 AM UTC

Affected components

Acceleration

Update timeline

  1. investigating Jan 27, 2022, 08:41 AM UTC

    Several customers have errors from JS scripts since 26/01/2022 at 6pm following an engine update. We are currently investigating the issue and applying a rollback.

  2. monitoring Jan 27, 2022, 09:12 AM UTC

    A rollback on the engine has been deployed in order to fix the issue. If you still see any JS errors, please flush your cache on the dashboard : https://fasterizehelp.freshdesk.com/en/support/solutions/articles/43000456842-how-to-flush-the-fasterize-cache- .

  3. resolved Jan 27, 2022, 09:48 AM UTC

    Incident is now closed, sorry for the inconvenience. A post-mortem will follow.

  4. postmortem Jan 27, 2022, 02:03 PM UTC

    # Problème d’erreurs Javascript Date du post mortem : 27/01/2022 Participants du post mortem : * toute l’équipe technique * Yahia # Description de l'incident 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. # Faits et Timeline **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 # Analyse 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. # Métriques ‌ Sévérité 1: arrêt du site non planifié qui affecte un nombre significatif d'utilisateurs * Temps de détection : 17 heures * Temps de résolution : 50 minutes # Contre mesures ## Actions pendant l’incident Rollback des ami des workers Vidage du cache des pages du top clients \+ clients ayant écrit des tickets au support. # Plan d'actions **Court terme :** * correction de la librairie et ajout d’un test fonctionnel * revoir la métrique d’erreurs javascript et créer une alerte sur cette métrique * message automatique si ticket urgent sur [[email protected]](mailto:[email protected]) en heure non ouvrée **Moyen terme :** * **améliorer la procédure de mise en production selon le niveau de risque \(normal ou élevé\). Les MEP avec un niveau de risque élevé seront effectuées uniquement le mardi, mercredi ou jeudi matin avec communication externe préalable.** **Long terme :** * étudier la faisabilité de faire les mises en production en deux temps en mettant à jour un environnement pour les préproduction des clients puis en mettant à jour un environnement avec les production des clients.