J’ai trouvé un bug d’analyse dans notre propre produit d’analyse.
Le pipeline d’événements a fonctionné. De vrais sites ont envoyé de vrais événements. Un booléen interne indiquait toujours que le script de suivi n’était pas installé.
Cette contradiction était importante car le drapeau constituait la première étape de notre score d’activation. Si cela restait faux, un chantier pourrait rester dans le segment froid même après l’arrivée des données.
Au 21 juillet, la production comptait 36 sites. Vingt et un avaient reçu un premier événement. Seuls deux d’entre eux avaient script_installed défini sur true.
Dix-neuf installations en activité ont été décrites comme inactives.
Le problème n’était pas un retard dans la file d’attente ou un tracker défaillant. Nous avions créé une transition d’état qu’aucune filière de production n’avait jamais réalisée.
La valeur était correcte à la création
Lorsqu’un client créait un site, script_installed démarrait comme faux. C’était raisonnable. A ce moment-là, Zenovay n’avait pas reçu la preuve que le script était en cours d’exécution.
La pièce manquante est arrivée plus tard.
Notre système a enregistré le premier horodatage d’événement lorsque les données sont arrivées, mais rien n’a modifié l’indicateur d’installation. Le drapeau avait un écrivain pour la fausse valeur initiale et aucun écrivain pour la vraie valeur ultérieure.
Les tests ont rendu l’erreur facile à rater. Ils ont fourni des appareils où script_installed était déjà vrai, puis ont vérifié que le score d’activation gérait correctement la valeur.
La fonction de notation a été testée. La transition qui a créé son entrée ne l’était pas.
Deux champs décrivent un fait
Nous avions déjà un signal plus fort : first_event_at.
Cet horodatage n’existe qu’une fois que le chemin d’ingestion a accepté un véritable événement d’analyse pour le site. C’est la preuve de quelque chose qui s’est produit. Le booléen n’était qu’une description de cette preuve.
Une fois que les deux champs existaient, ils pourraient être en désaccord :
select count(*)
from websites
where first_event_at is not null
and script_installed is distinct from true;
La requête a renvoyé 19.
C’est le risque d’un état en double. Chaque champ peut sembler valide isolément. La contradiction n’apparaît que lorsque la relation entre eux est vérifiée.
Pourquoi les dégâts sont restés internes
La vérification de l’installation destinée au client a utilisé une condition plus sûre. Il n’avertissait que lorsque le drapeau était faux et qu’aucun premier événement n’existait. Les clients disposant de données réelles n’ont pas été invités à réinstaller le tracker.
Le cron d’activation était également en lecture seule. Il enregistrait la télémétrie et n’envoyait pas d’e-mails sur le cycle de vie.
Cela limitait le rayon de l’explosion, mais cela ne rendait pas le bug inoffensif. Les rapports d’activation internes classifiaient incorrectement les équipes de travail. Toute décision basée sur ce segment partirait de fausses preuves.
La réparation
Nous avons attaché la transition manquante à l’événement qui prouve l’installation.
Lorsque le premier événement visiteur arrive, le même déclencheur de base de données qui enregistre le premier événement définit désormais script_installed sur true et enregistre le moment où le script a été vu pour la première fois.
La mise à jour est gardée. Il s’exécute uniquement lorsque la vérification est en attente ou que l’indicateur d’installation n’est pas déjà vrai. Les pages vues ultérieurement ne réécrivent pas la même ligne du site et ne produisent pas une nouvelle entrée d’audit pour chaque événement.
Nous avons ensuite rempli les 19 lignes incohérentes des preuves existantes du premier événement.
Après la réparation, l’état de production historique comptait 21 sites avec un premier événement et 21 avec le drapeau d’installation activé. Le nombre de disparités était nul.
Un nouveau contrôle de production le 20 août n’a toujours donné aucun site avec un événement mais un faux drapeau d’installation, et aucun site avec un vrai drapeau mais pas de premier événement.
Ce que nous avons modifié lors du processus d’examen
Le correctif de code était petit. Le changement de révision est plus utile.
Premièrement, les jalons d’activation nécessitent un événement observable. « Le script est installé » est une étiquette. « Le premier événement a été accepté à cette époque » en est la preuve.
Deuxièmement, les tests doivent couvrir la transition qui produit l’état. Un test unitaire parfait pour la fonction de notation n’a pas pu révéler que la production n’a jamais fourni la vraie valeur.
Troisièmement, les faits dupliqués nécessitent un invariant. Si deux champs devraient correspondre, exécutez la requête de contradiction en continu. N’attendez pas un audit manuel.
Quatrièmement, les analyses internes méritent le même scepticisme que les analyses clients. Un entonnoir raffiné peut toujours mesurer la fiction lorsqu’un jalon est dérivé d’un état obsolète.
La question que nous utilisons maintenant
On ne demande plus seulement si le flag d’installation est vrai.
Nous demandons quel événement irréversible prouve que cette étape importante s’est produite.
Pour l’installation d’un tracker, cet événement est simple : le premier événement est arrivé.
Quel statut de votre produit est traité comme un fait même si aucun événement de production n’est responsable de sa modification ?
