弊社独自の分析製品内で分析のバグを発見しました。

イベントパイプラインは機能しました。リアルサイトはリアルイベントを発信しました。内部ブール値は依然として追跡スクリプトがインストールされていないことを示しています。

フラグがアクティベーション スコアの最初のマイルストーンだったため、この矛盾は重要でした。 false のままだと、データが到着した後でも作業サイトがコールド セグメントに残る可能性があります。

7 月 21 日の時点では、生産拠点は 36 でした。 21 人が最初のイベントを受け取りました。 script_installed が true に設定されていたのは 2 つだけでした。

稼働中の 19 の施設は非アクティブであると報告されました。

問題はキューの遅延やトラッカーの障害ではありませんでした。私たちは、本番パスが決して実行しない状態遷移を作成していました。

作成時の値は正しかった

顧客がサイトを作成すると、script_installed は false として開始されました。それは合理的でした。この時点では、ゼノベイはスクリプトが実行されているという証拠を受け取っていませんでした。

足りない部分は後から来ました。

ステータス フィールドは消灯したまま、サイトの作成から最初のイベントまで 3 つの段階が続きます

私たちのシステムは、データが到着したときに最初のイベントのタイムスタンプを記録しましたが、インストール フラグは何も変更されませんでした。フラグには、最初の false 値のライターが 1 つあり、後の true 値のライターはありませんでした。

テストにより間違いは見落とされやすくなりました。彼らは、script_installed がすでに true であるフィクスチャを提供し、アクティベーション スコアが値を正しく処理することを検証しました。

採点機能をテストしました。入力を作成したトランジションはそうではありませんでした。

2 つのフィールドが 1 つの事実を説明しました

すでにより強力なシグナル first_event_at がありました。

このタイムスタンプは、取り込みパスがサイトの実際の分析イベントを受け入れた後にのみ存在します。それは何かが起こった証拠です。ブール値はその証拠の説明にすぎません。

両方のフィールドが存在すると、それらは一致しない可能性があります。

select count(*)
from websites
where first_event_at is not null
  and script_installed is distinct from true;

クエリは 19 を返しました。

インストールフラグが固着したままイベント状態が進行し、修復後に両方が収束する

これは状態が重複するリスクです。各フィールドは単独でも有効に見えます。両者の関係を確認して初めて矛盾が現れる。

損傷が内部にとどまった理由

お客様向けの取り付けチェックでは、より安全な条件が使用されました。両方のフラグが false で、最初のイベントが存在しない場合にのみ警告しました。実際のデータを持つ顧客は、トラッカーを再インストールするように誤って指示されたわけではありません。

アクティベーション cron も読み取り専用でした。テレメトリは記録されますが、ライフサイクル電子メールは送信されませんでした。

これにより爆発範囲は制限されましたが、バグが無害になったわけではありません。内部アクティベーションレポートでは、作業チームが誤って分類されていました。そのセグメントに基づくあらゆる決定は、誤った証拠から始まることになります。

修理

インストールを証明するイベントに欠落しているトランジションを添付しました。

最初の訪問者イベントが到着すると、最初のイベントを記録するのと同じデータベース トリガーが script_installed を true に設定し、スクリプトが最初に表示されたときを記録します。

更新は保護されています。これは、検証が保留中であるか、インストール フラグがまだ true になっていないときにのみ実行されます。その後のページ ビューでは、同じサイト行が書き換えられたり、イベントごとに新しい監査エントリが生成されたりすることはありません。

次に、既存の最初のイベントの証拠から 19 の矛盾した行を埋め戻しました。

修復後の過去の運用状態には、最初のイベントが発生したサイトが 21 サイト、インストール フラグが設定されたサイトが 21 サイトありました。不一致数はゼロでした。

8 月 20 日の新たな運用チェックでは、イベントがあるが偽のインストール フラグがあるサイトはゼロ、フラグは正しいが最初のイベントがないサイトはゼロでした。

レビュープロセスで変更した点

コードの修正は小規模でした。レビューの変更がさらに便利になりました。

まず、アクティベーション マイルストーンには観察可能なイベントが必要です。 「スクリプトがインストールされています」はラベルです。 「この時点で最初のイベントが受け入れられた」ことが証拠です。

次に、テストは状態を生成する遷移をカバーする必要があります。スコアリング関数の完璧な単体テストでは、本番環境が真の値を提供していないことを明らかにすることはできません。

第三に、重複したファクトには不変条件が必要です。 2 つのフィールドが一致すると予想される場合は、矛盾クエリを継続的に実行します。手動監査を待たないでください。

第 4 に、内部分析は顧客分析と同様に懐疑的な見方を受けるに値します。洗練されたファネルは、古い状態から 1 つのマイルストーンが派生する場合でも、フィクションを測定できます。

現在使用している質問

1 つの受け入れられたイベントにより、インストール不変式の両側が更新されるようになりました

インストール フラグが true かどうかだけを尋ねることはなくなりました。

マイルストーンが起こったことを証明する不可逆的な出来事はどれか、と尋ねます。

トラッカーのインストールの場合、イベントは単純です。最初のイベントが到着しました。

製品のステータスを変更する責任がある生産イベントがないにもかかわらず、事実として扱われる製品のステータスは何ですか?