Sentry Signal Loop

属性

コンテキスト

GitLab のフロントエンド Sentry プロジェクト (gitlabcom-clientside) は、30 日ごとに約 2,500 万のイベントを受け取っています。シグナルとノイズの比率が悪化し、プロジェクトはトリアージのために機能的に使われていない状態になっています。最も多くのイベントを発する Issue はバグではなく、実際に 存在する バグは埋もれて誰にも所有されていません。

ベースライン: 2026 年 3 月で約 2,480 万のエラーイベント。

その量の意味のある割合は、「私たちのアプリケーションが 2,500 万回壊れている」のではありません。本来、そもそも報告されるべきではなかったイベントです。ブラウザ拡張機能の CSP レポート (例: 広告ブロッカーが当社の Snowplow エンドポイントをブロックする、サードパーティのブラウザ テレメトリ) や、ルールを正しく適用しているアプリケーションからの想定された 4xx レスポンスがリストの上位を占めています。Sentry はコードの予期しない失敗を報告すべきであり、それ以上のものを報告すべきではありません。

量の問題に加えて、トリアージプロセスがありません。すべてのイベントには既に feature_category タグが付与されており、正規の feature_category → 所有グループのマッピング (/handbook/product/categories/features/ 参照) は stages.yml に存在しています。所有権は宣言されています。欠けているのは、データを見る人や仕組みです。何十万人ものユーザーに影響する本物のバグが誰にも割り当てられていないのは、それが誰のものか分からないからではなく、誰も見ていないからです。

Frontend Observability Working Group (2021–2023) は技術的なインストルメンテーションを構築し、きれいに終了しました。フレームワークは機能しています。構築されなかったのは、その上に乗る運用ループです。このタスクグループはこのシグナルループを閉じることを目指します。

ゴール

作業は 2 つのフェーズに分かれ、それらが一体となってループを形成します:

1. 主要ゴール — ソースでノイズを削減する。 Sentry SDK の設定と Sentry のインバウンドフィルターを更新し、プロジェクトがコードの予期しない失敗のみを報告するようにします。出口基準は、約 2,600 万のベースラインから 30 日間のイベント量を 50% 以上削減することです (引用された測定値は 出口基準 参照)。正確なフィルターは、MR がランディングして Sentry データが更新されるにつれてイテレーション的に決定されます。

2. 副次ゴール — Sentry → GitLab Issue → Duo Developer のトリアージ自動化を構築して運用する。 ノイズフロアが下がったら、イベントに対応し続けるシステムを構築します。自動化は毎日のスケジュールで実行され、最新の Sentry Issue を取得し、feature_category を通じて所有グループにルーティングされた対応する GitLab Issue を作成し、Duo Developer を使ってそれぞれにトリアージを生成します。統一されたパターン: エージェントがノイズとシグナルを分離し、各サイドで人間が行動できる提案を生成します。MR は自律的に開かれません。人間への引き継ぎは設計の一部であり、限界ではありません。

課題

• シグナルに対するエージェント支援の作業は本当に難しいです。 フロントエンドのエラーはスタックの他の場所にある根本原因の症状であることが多いため、エージェントの出力は人間にとって有用な出発点である必要があり、完成された答えではありません。そのバーをキャリブレーションすることは、実験の前提ではなく、実験の一部です。
• ルーティングは私たちが完全に制御できないシグナルに依存します。 自動化は Sentry Issue を feature_category を通じて所有グループにルーティングし、結果として生じる GitLab Issue 上で人間の協力のために CODEOWNERS に依存します。両方のシグナルは今日存在しますが、これらが「実際にこの Issue に対応できる人間」にどれだけきれいにマッピングされるかはまだ分かりません。一部のルーティング失敗は予想されており、それをどう扱うかが実験が明らかにする部分です。
• 日次実行間の重複排除。 自動化は 24 時間サイクルで実行されます。今日存在する Sentry Issue は、ほとんどの場合、明日も存在し続けます。根本的な問題は一晩で解決されないからです。自動化は、既に GitLab Issue を作成した Sentry Issue を確実に認識してスキップする必要があり、毎日重複を生み出すべきではありません。これを誤ると、所有グループに同じ Issue のコピーが大量に押し寄せ、自動化への信頼が即座に失われます。Sentry Issue の同一性から GitLab Issue へのマッピングは、私たちが最初に正しく決定すべき設計判断の 1 つです。
• 長期オーナーの確保は保証されません。 自動化がタスクグループを超えて存続するのは、グループがそれを永続的な責任として受け入れる場合に限られます (詳細は 出口基準 参照)。オーナーが見つからなかった場合、自動化は四半期末で終了し、それ自体が有効な結果になります。どのグループも投資するほどの価値がないことを示すからです。
• デプロイとロールアップのレイテンシー。 私たちの変更が効果的かどうかをテストするには、より多くのイベントが入ってくるのを待つ必要があります。これにより、リアルタイムで結果が見える場合よりも作業が長く時間がかかります。

これらは既知の課題ですが、まだ特定されていない追加の問題があるかもしれません。

出口基準

1. ソースでノイズが削減されている (主要な成果)。 Sentry SDK の設定とインバウンドフィルターが更新され、gitlabcom-clientside の 30 日間のイベント量が、2026 年 3 月の約 2,480 万エラーイベントのベースラインから 50% 以上削減され、合計 1,240 万イベント未満になっている (スクリーンショットとライブビューは コンテキスト を参照)。
2. 自動化が存在し、実際の Issue で実行されている。 自動化が毎日のスケジュールで実行され、Sentry Issue を取得し、feature_category を通じてルーティングされた対応する GitLab Issue を開き、Duo Developer のトリアージ (根本原因、コード参照、提案された修正) をそれぞれに生成しています。自動化は実際の所有グループに対して少なくとも 2 週間実行されており、結果がレビュー可能な場所に記録されています (Issue リンク、Duo の出力、所有グループの取った行動)。
3. 自動化は運用を続ける価値があるほど有用である。 私たちが最も注目するのは、自動化が GitLab Issue を開いたとき、所有グループが 14 日以内に実際に何か行動を起こすか (受け取って、アサインして、マイルストーンに乗せて、修正するか)、それとも単に閉じて移動するかどうかです。これにより、Duo のトリアージが役立っているのか、単にノイズを増やしているだけなのかが分かります。2 つの追加チェックがこれを裏付けます: 私たちは Duo の分析のいくつかを手動で読んで、実際にバグを指しているかどうかを確認し、全体で開かれた Issue の数を見ます (良いものがいくつかあるのと、平凡なものが大量にあるのとでは結果は非常に異なります)。最終的に、タスクグループは明確な yes/no の判断とその理由を記録します。「いいえ、これはうまくいかなかった、そして私たちが学んだことはこれです」という答えは問題ありません。 何が「有用」に見えるかを把握すること自体がこれを試す目的なので、事前に目標パーセンテージを決めません。
4. 長期オーナーシップが解決されている。 自動化のための長期オーナーが特定され、タスクグループの最後の 4 週間に関与しており、文書化された引き継ぎを受け入れている、または オーナーが見つからず、自動化がタスクグループ終了時に終了されて理由が文書化されている。

役割と責任

ページのソースコードを見る - ページの編集 - please contribute.