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 のインバウンドフィルターを更新し、プロジェクトがコードの予期しない失敗のみを報告するようにします。出口基準は、プラットフォーム上でトリアージされアーカイブされた Issue からのイベントを除外した 30 日間のイベント量を、約 2,600 万のベースラインから 50% 以上削減することです（引用された測定値とアーカイブ済み Issue を除外する根拠は 出口基準参照）。正確なフィルターは、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 つです。
• 長期オーナーの確保は保証されません。 自動化がタスクグループを超えて存続するのは、グループがそれを永続的な責任として受け入れる場合に限られます（詳細は 出口基準参照）。オーナーが見つからなかった場合、自動化は四半期末で終了し、それ自体が有効な結果になります。どのグループも投資するほどの価値がないことを示すからです。
• デプロイとロールアップのレイテンシー。 私たちの変更が効果的かどうかをテストするには、より多くのイベントが入ってくるのを待つ必要があります。これにより、リアルタイムで結果が見える場合よりも作業が長く時間がかかります。

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

ノイズの測定：アーカイブ済み Issue のイベントを除外する理由

Sentry のイベント量の統計では、すでにトリアージされ、エスカレーションまでアーカイブされた Issue からのイベントも含め、受け入れられたすべてのイベントがカウントされます。そのため、生の数値ではトリアージ体験の改善度が実際よりも小さく見えます。

共有エラーハンドラーの場合、これらのイベントをソースで抑制する方法は機能しません。共有エラーハンドラーはノイズとシグナルの両方を扱うため、キャプチャ呼び出しを削除すると両方が失われます。Sentry でアーカイブすればシグナルを維持し、Issue がエスカレートした場合に再表示でき、元に戻すこともできます。決してシグナルにならないイベントには、ソースレベルのフィルターが引き続き適切です。

測定値は、Sentry events API を介した 30 日間の count() から、同じクエリを is:ignored でフィルタリングした値を差し引いたものです。is:ignored は Issue の現在の状態を反映するため、新たにアーカイブされた Issue の過去分のイベントも遡及的に除外されます。指標は現在のトリアージ状態を反映するため、これは意図した動作です。

アーカイブ済みイベント総数の報告

アーカイブ済みイベントを除外すると、この指標は出荷されたコードだけでなく、トリアージの判断にも左右されるようになります。エスカレーションまでアーカイブされた Issue は、それ自体のイベント量の予測を超えた場合にのみ再表示されるため、一定して大量に発生する Issue は無期限にアーカイブされたままになる可能性があります。

これを可視化し続けるため、タスクグループの最終レポートでは、生の受け入れイベント量、アーカイブ済み Issue のイベント数、差し引き後の値という 3 つの数値をすべて記載します。タスクグループがベースラインを確立し、その後ノイズを低く保つことは所有チームの責任です。

出口基準

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

最終レポート

タスクグループは 2026-09-28 に終了しました。出口基準 1 から 3 は満たされています。出口基準 4 は修正を加えたうえで解決しました。自動化の長期オーナーシップを引き継いだグループはなく、自動化の運用終了も行いませんでした。元の DRI のもとで、メンテナンスモードで継続します。その理由を以下に説明します。

1. ノイズ削減

Sentry events API（project=4、dataset=errors、statsPeriod=30d、field=count()）を通じて、2026-09-28 に直近 30 日間を対象に測定した 3 つの数値は次のとおりです：

差し引き後の値はベースラインから 86.5% 減少し、生の値だけでも 68% 減少しています。いずれも目標を十分に達成しています。

終了時の測定値：2026-09-28 までの 30 日間で、生のエラーイベント数は 790 万件でした。3 月は約 2,480 万件でした。

削減につながったのは、Sentry SDK 設定のソースレベルのフィルター（対応不要なエラーパターン、想定内の 4xx レスポンス、拡張機能のノイズ）、Sentry のインバウンドフィルター、そして既知の対応不要な Issue を Sentry でアーカイブし、トリアージ時に表示されないようにしたことです。

2. 自動化

Sentry Signal Loop は、duo-sentry-insightsのスケジュールされたパイプラインです。1 日に 1 回（またはスケジュールに応じて週に 1 回）、1 つの feature_category の新しい Sentry Issue を取得し、それぞれを機密の gitlab-org/gitlab Issue として複製し、Duo Developer にトリアージを依頼します。人間が判断し、パイプラインが下準備を行います。

実装した内容：

• 取得、情報補完、照合、計画、適用の各ステージ。デフォルトはドライランで、人間が読める計画をパイプラインのアーティファクトとして出力します。
• Issue の説明内の <!-- sentry-issue-id --> マーカーと、Sentry Issue からの逆リンクによる重複排除。
• feature_category によるルーティング。DRI の割り当て、任意のグループラベル、任意の親エピックを設定します。
• 作成または再オープンされたすべての Issue に対する Duo Developer のトリアージ。Signal または Noise の判定、確信度、根拠のレベル、根本原因、コード参照、修正案、推奨する Sentry での処理を提示します。
• 発生数が最多のカテゴリに限定する仕組み。エラーは、そのイベントが最も多く発生するカテゴリにのみ複製するため、共有コンポーネント（ナビゲーション、セッションモーダル、タイムスタンプ）が全チームの実行で取り上げられることはありません。
• 影響を受けるユーザー数に基づいて優先順位を付けた、実行ごとの作成件数の上限。大量のイベントが発生するカテゴリでドライランを行ったところ、約 100 件の Issue が作成されると分かったため追加しました。
• リリースを考慮したリグレッション検出。クローズした Issue は、クローズ後に作成されたリリースでエラーが発生した場合にのみ再オープンします。古いバンドルを使い、長時間開かれたままのブラウザタブからのイベントには、再オープンの代わりにコメントを 1 件付けます。
• オンボーディングにはパイプラインスケジュールを 1 つ設定し、オフボーディングにはそのスケジュールを無効にします。

ループは 2026-05-22 からタスクグループ終了まで稼働し、258 件の Sentry Issue を 9 つのグループ向けに複製しました。6 つのグループが自分たちの機能カテゴリ用にパイプラインスケジュールを設定し、そのうち 5 つのスケジュールが終了時点で有効でした。

当初の計画では、オプトインから、デフォルトで有効となるオプトアウトへと拡大する予定でした。私たちはオプトインを維持しました。希望していないチームのために Issue を作成することが、自動化への信頼に対する最大のリスクであり、導入の広がりが遅くなる方がよいと判断したためです。

3. 稼働を続ける価値があるほど有用か？ はい

2026-09-28 に、Task Group::Sentry Signal Loop ラベルが付いたすべての Issue を対象に測定しました：

• 78% に対応。 複製から 14 日を超えた 154 件の Issue のうち、120 件で、所有グループが担当者の割り当て、マイルストーンへの追加、クローズ、またはマージリクエストへの紐付けを行いました。50 件がクローズされ、そのうち 24 件は修正 MR によるものでした。4 つのグループは、受け取ったすべての Issue に対応しました。
• 258 件中 248 件の Issue に Duo のトリアージを実施。 Signal が 151 件、Noise が 97 件で、193 件は解決済みのスタックトレースによる裏付けがありました。Signal の判定から 44 件、Noise の判定から 2 件の修正 MR につながりました。所有グループは、この判定を実用的な一次判定として扱っています。
• 大量発生も重複もありませんでした。 停止を求めたグループはなく、パイプラインが同じ Sentry Issue に対して GitLab Issue を 2 件作成することもありませんでした。

4. オーナーシップ：元の DRI のもとでのメンテナンスモード

出口基準 4 で認められていた結果は、所有グループへの引き継ぎ、または運用終了の 2 つでした。どちらにも至りませんでした。

Developer Experience と Observability チームの両方に依頼しましたが、いずれもキャパシティを理由に断りました。両チームは、Sentry 自体がメンテナンスモードで利用面のオーナーがいないこと、今後はセルフサービスのオーナーシップ（「自分で作ったものは自分で運用する」）が基本として期待されることを確認しました。

5 つのグループが積極的に利用し、導入も勧められたツールを運用終了する方が、望ましくない結果になったはずです。そのため、次のように対応します：

• 自動化の稼働を継続します。利用する各グループが自分たちのパイプラインスケジュールを所有し、いつでも無効にできます。
• 元の DRI が共有リポジトリ、稼働に使う 2 つのアクセストークン、およびそのローテーションを維持します。対象はバグ修正と Sentry または GitLab API の変更に起因する不具合です。新機能は追加しません。想定される工数は月にほぼ 0 時間です。
• 運用の詳細は、プロジェクトの OPERATIONS.md に記載されています。
• 緊急停止の方法：パイプラインスケジュールを無効にします。それ以外に稼働するものはありません。
• メンテナーが役職を変更した場合、トークンの管理を維持できなくなった場合、またはオーナーシップを引き継ぎたいグループが現れた場合は、この体制を再評価します。

役割と責任

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