Analytics:Platform Insights グループ

私たちについて

Platform Insights グループは GitLab の Analytics Stage の一部であり、GitLab Observability と Product Analytics の製品を構築しています。

チームメンバー

チームメンバー情報は原文 (英語) を参照してください。

ステーブルカウンターパート

チームメンバー情報は原文 (英語) を参照してください。

テクニカルアーキテクチャ

アーキテクチャブループリント

アーキテクチャドキュメント

こちらのページを参照してください。

プロジェクトリンク

ClickHouse データストア

Observability とアナリティクスの機能には大量のデータと挿入負荷の高い要件があり、Postgres や Redis には適していません。ClickHouse はこれらの機能要件を満たす適切な選択肢として選ばれました。ClickHouse はオープンソースの列指向データベース管理システムです。大量の行にわたって効率的にフィルタリング、集計、合計を行えるため、これらのユースケースに魅力的です。ClickHouse は GitLab のスタックにおける Postgres や Redis の代替として意図されていません。

当初はセルフホスト型の ClickHouse インスタンスを管理していましたが、ClickHouse へのメンテナンスとスケーラビリティのオフロードによりチームの動きを速めるために ClickHouse Cloud への移行を決定しました。

詳細: ClickHouse データストアワーキンググループ

働き方

私たちは会社の Product Development Flow に基づいたワークフローを採用しています。ワークフローの適用方法に関する変更や明確化については以下に詳述します。

非同期スタンドアップ

毎週水曜日に Slack ベースのスタンドアップ（Geekbot を使用）を行い、金曜日にレトロスペクティブを行います。これらの非同期スタンドアップを使用して、達成したこと、現在のブロッカー、次に取り組む予定を伝えます。

非同期アップデート

毎週金曜日、EM がチームの進捗の非同期アップデートを提供します。

これらのアップデートは general プロジェクトの Issue として公開されます。

Ops 内のすべてのチームからのアップデートとハイライトは、週/月/四半期別にグループ化されてこちらに自動的に収集されます。

ミーティング

週次チームシンク: 現在進行中の作業や、ロールアウトや大きなイニシアチブなどの特定の取り組みを整理することに焦点を当てています。
隔月ソーシャルアワー: このミーティングは業務に関係なく、チームが交流してお互いをよく知るのに役立ちます。
チームメンバーコーヒーチャット: 各チームメンバーは、4〜6週間おきに他のすべてのチームメンバーとコーヒーチャットをスケジュールするべきです。業務や業務外のトピックを自由に話し合えます。タイムゾーンが問題な場合は、非同期の Slack スレッドでチェックインするなど別の方法でつながってください。目標は、1対1でお互いのチームメンバーを知ることです。
Dev シンク: これらはエンジニア主催の同期ミーティングで、IC がテクニカルな問題を議論したり、EM を必要とせずにテクニカルな作業を調整したりすることができます。

コミュニケーション

以下の Slack チャンネルを使用して組織します:

プライマリチャンネル: #g_monitor_platform_insights
スタンドアップチャンネル: #g_monitor_platform_insights_standup
ソーシャルチャンネル: #g_monitor_platform_insights_internal

計画方法

月次マイルストーンサイクルに従っています。作業はエピックに整理され、関連するマイルストーンに割り当てられます。

マイルストーンの開始日は gitlab.org グループのマイルストーンで定義されています。新しい GitLab リリースカレンダーに従い、毎月変更されます。

マイルストーン計画タイムライン:

マイルストーン開始 10日前: PM/EM が高レベルのマイルストーン目標を含む計画ドラフト Issue を作成します。
マイルストーン開始 8日前: 計画ドラフトをチームと共有します。個別貢献者は、これらの目標に関連するエピックと Issue や前のマイルストーンから引き継がれたものを推薦します。
マイルストーン開始 5日前: 計画はチームシンクミーティングでレビューされます。
マイルストーン開始日: マイルストーンの目標と関連するエピックおよび Issue が確定・優先順位付けされるべきです。計画された全作業はマイルストーンボードで確認できます。前のマイルストーンの Issue は新しいマイルストーンまたはバックログに移動されます。
マイルストーン中、進捗を分析し必要に応じて再優先順位付けします。

Issue の優先順位付け

私たちの優先順位はプロダクト全体のガイダンスに従うべきです。これはスケジュールされた Issue の優先度ラベルに反映されるべきです:

優先度	説明	マイルストーンでの出荷確率
priority::1	緊急: 特定のマイルストーンで達成するための最優先事項。これらの Issue はリリースにとって最も重要な目標であり、最初に取り組むべきです；一部は時間的に重要だったり他の依存関係をブロックしていたりします。	~100%
priority::2	高: ビジネスまたは技術的負債に大きな好影響を与える重要な Issue。重要ですが、時間的に重要ではなく他をブロックしていません。	~75%
priority::3	通常: 既存機能への段階的な改善。これらは重要なイテレーションですが、重要度が低いと見なされています。	~50%
priority::4	低: 将来のリリースへの先送りが許容されるストレッチ Issue。	~25%

取り組む作業を探す方法

通常、マイルストーン開始時に EM が作業の概要と注力する関連領域について説明します。マイルストーン開始前にすでに Issue が割り当てられている場合もあります。

追加の Issue を探している場合:

Platform Insight のマイルストーンボードを確認します。
未割り当ての Issue を特定します。
自分を Issue に割り当てます。
Issue に workflow:in dev ラベルを追加します。
スコープや説明が不明確な場合は、EM や PM に確認するか、（自信がある場合は）自分でグルームして進めます。
Issue に取り組み始めます。
関連するすべての MR がマージされたら、~workflow::verification ラベルを設定します。
- MR が Issue を自動クローズしないようにしてください。（MR の説明では Closes #11111 ではなく Relates to #11111 を使用します。）
変更を確認し、例えば Verified on production のように検証に使用した環境を Issue にコメントします。
Issue をクローズします！🎉
繰り返します。

Observability Beta をお客様に有効にする方法

特定のお客様に Logs、Tracing、Metrics ベータへのアクセスを有効にするには、以下のプロセスに従います:

SaaS の場合:

事前に、このページに詳述されている ChatOps コマンドを実行するための適切なアクセスと権限を持っていることを確認します。
お客様にトップレベルグループ名を確認します（例: https://gitlab.com/gitlab-org/ の場合は gitlab-org）。
#production で、このグループのフィーチャーフラグを有効にするために以下のコマンドを実行します（gitlab-org をお客様のグループ名に置き換えます）:

/chatops run feature set --group=gitlab-org observability_features true

すでに有効になっているグループのリストを確認するには、以下のコマンドを実行します:

/chatops run feature get observability_features

リストはグループ名ではなくグループ ID を返します。グループの ID を知るには、グループのページ（例）を閲覧し、ページ右上の “…” メニューを開いて「グループ ID をコピー」を選択します。グループへのアクセス権がない場合は、お客様に行っていただくよう依頼してください。

詳細: 関連するフィーチャーフラグ Issue を参照してください。

セルフマネージドの場合:

現時点では利用できません。

最終更新 May 6, 2026: Merge pull request #100 from kyama0/fix/upload-images-tolerate-upstream-missing (70970e1a)

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