Ich habe einen Analysefehler in unserem eigenen Analyseprodukt gefunden.
Die Event-Pipeline hat funktioniert. Echte Websites haben echte Ereignisse gesendet. Ein interner boolescher Wert besagte immer noch, dass das Tracking-Skript nicht installiert war.
Dieser Widerspruch war wichtig, da die Flagge der erste Meilenstein in unserem Aktivierungsergebnis war. Wenn der Wert falsch bliebe, könnte ein Arbeitsstandort auch nach dem Eintreffen der Daten im kalten Segment bleiben.
Am 21. Juli umfasste die Produktion 36 Standorte. Einundzwanzig hatte eine erste Veranstaltung erhalten. Nur bei zwei war script_installed auf true gesetzt.
Neunzehn funktionierende Installationen wurden als inaktiv beschrieben.
Das Problem war nicht eine verzögerte Warteschlange oder ein ausgefallener Tracker. Wir hatten einen Zustandsübergang geschaffen, den kein Produktionspfad jemals durchgeführt hat.
Der Wert war bei der Erstellung korrekt
Als ein Kunde eine Site erstellte, wurde script_installed mit „false“ gestartet. Das war vernünftig. Zu diesem Zeitpunkt hatte Zenovay keinen Beweis dafür erhalten, dass das Drehbuch lief.
Der fehlende Teil kam später.
Unser System zeichnete den Zeitstempel des ersten Ereignisses auf, als die Daten eintrafen, aber am Installationsflag änderte sich nichts. Das Flag hatte einen Schreiber für den anfänglichen falschen Wert und keinen Schreiber für den späteren wahren Wert.
Tests machten den Fehler leicht zu übersehen. Sie lieferten Fixtures, bei denen script_installed bereits true war, und überprüften dann, ob der Aktivierungsscore den Wert korrekt verarbeitete.
Die Scoring-Funktion wurde getestet. Der Übergang, der seine Eingabe erstellt hat, war es nicht.
Zwei Felder beschrieben eine Tatsache
Wir hatten bereits ein stärkeres Signal: first_event_at.
Dieser Zeitstempel existiert erst, nachdem der Aufnahmepfad ein echtes Analyseereignis für die Site akzeptiert. Es ist ein Beweis dafür, dass etwas passiert ist. Der boolesche Wert war nur eine Beschreibung dieses Beweises.
Sobald beide Felder existierten, konnten sie anderer Meinung sein:
select count(*)
from websites
where first_event_at is not null
and script_installed is distinct from true;
Die Abfrage ergab 19.
Dies ist das Risiko eines doppelten Status. Jedes Feld kann isoliert gültig aussehen. Der Widerspruch erscheint erst, wenn die Beziehung zwischen ihnen überprüft wird.
Warum der Schaden im Inneren blieb
Bei der Installationsprüfung vor dem Kunden wurde eine sicherere Bedingung verwendet. Es wurde nur gewarnt, wenn sowohl das Flag falsch war als auch kein erstes Ereignis vorhanden war. Kunden mit echten Daten wurden nicht fälschlicherweise aufgefordert, den Tracker neu zu installieren.
Der Aktivierungs-Cron war ebenfalls schreibgeschützt. Es zeichnete Telemetriedaten auf und verschickte keine Lebenszyklus-E-Mails.
Das schränkte den Explosionsradius ein, machte den Käfer aber nicht unschädlich. Bei der internen Aktivierungsberichterstattung wurden Arbeitsteams falsch klassifiziert. Jede auf diesem Segment basierende Entscheidung würde von falschen Beweisen ausgehen.
Die Reparatur
Den fehlenden Übergang haben wir dem Ereignis beigefügt, das die Installation belegt.
Wenn das erste Besucherereignis eintrifft, setzt derselbe Datenbanktrigger, der das erste Ereignis aufzeichnet, script_installed nun auf „true“ und zeichnet auf, wann das Skript zum ersten Mal gesehen wurde.
Das Update ist geschützt. Es wird nur ausgeführt, solange die Überprüfung aussteht oder das Installationsflag noch nicht auf „true“ gesetzt ist. Bei späteren Seitenaufrufen wird nicht für jedes Ereignis dieselbe Site-Zeile neu geschrieben oder ein neuer Audit-Eintrag erstellt.
Anschließend haben wir die 19 inkonsistenten Zeilen aus den vorhandenen Beweisen für das erste Ereignis aufgefüllt.
Nach der Reparatur gab es im historischen Produktionszustand 21 Standorte mit einem Erstereignis und 21 mit gesetzter Installationsflagge. Die Anzahl der Nichtübereinstimmungen war Null.
Eine erneute Produktionsüberprüfung am 20. August ergab immer noch null Standorte mit Ereignissen, aber einem falschen Installationsflag, und null Standorte mit einem wahren Flag, aber keinem ersten Ereignis.
Was wir im Überprüfungsprozess geändert haben
Der Code-Fix war gering. Die Rezensionsänderung ist nützlicher.
Erstens benötigen Aktivierungsmeilensteine ein beobachtbares Ereignis. „Das Skript ist installiert“ ist eine Bezeichnung. „Das erste Ereignis wurde zu diesem Zeitpunkt akzeptiert“ ist ein Beweis.
Zweitens müssen Tests den Übergang abdecken, der den Zustand erzeugt. Ein perfekter Unit-Test für die Scoring-Funktion konnte nicht ergeben, dass die Produktion nie den wahren Wert lieferte.
Drittens benötigen duplizierte Fakten eine Invariante. Wenn erwartet wird, dass zwei Felder übereinstimmen, führen Sie die Widerspruchsabfrage kontinuierlich aus. Warten Sie nicht auf eine manuelle Prüfung.
Viertens verdienen interne Analysen die gleiche Skepsis wie Kundenanalysen. Ein polierter Trichter kann immer noch Fiktion messen, wenn ein Meilenstein aus dem veralteten Zustand abgeleitet wird.
Die Frage, die wir jetzt verwenden
Wir fragen nicht mehr nur, ob das Installationsflag wahr ist.
Wir fragen, welches irreversible Ereignis beweist, dass der Meilenstein eingetreten ist.
Für die Tracker-Installation ist dieses Ereignis einfach: Das erste Ereignis ist eingetroffen.
Welcher Status Ihres Produkts wird als Tatsache behandelt, obwohl kein Produktionsereignis für die Änderung verantwortlich ist?
