Performance Enablement

ミッション

パフォーマンステストを開発ライフサイクル全体にわたってアクセスしやすく、実用的で、組み込まれたものにすることで、GitLab の R&D チームが高速で信頼性の高いカスタマーエクスペリエンスを提供できるようにします。

ビジョン

すべてのエンジニアがパフォーマンスに自信を持ってオーナーシップを発揮し、顧客より先に問題を発見し、高速で効率的なソフトウェアを構築することに誇りを持つ GitLab を目指します。

ゴール

1. コード変更に関連するテストを優先し、最も失敗しやすいテストを先に実行することでフィードバックループを短縮する
2. パフォーマンス改善のトレンドを可視化・測定可能・実用的なものにすることで、組織全体のパフォーマンス改善を加速する
3. すべての開発チームが SDLC 全体を通じてパフォーマンスを所有するパフォーマンス中心の文化を確立する

チームメンバー

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

ロードマップ

このロードマップは、私たちのチームの戦略的な柱（個別ソリューションではなくプラットフォームの構築、パフォーマンスのオーナーシップをエンジニアリングチームに移管、セルフサービス機能の実現）を四半期ごとの実行フェーズに落とし込んだものです。

ここに示す方向性は、今日知っていることを反映したものです。実行していく中で、何が機能するか、チームの実際の採用状況、そして仮定のどこを修正する必要があるかを学んでいきます。これは意図的なものです。パターンがまだ確立されていない領域で組織的な能力を構築しています。発見とコース修正は作業の一部です。

チームフィードバック、インシデントのトレンド、採用の課題を通じて新しい情報が明らかになれば、戦略的な意図を軸に保ちながら適応していきます。ロードマップは方向性を示し、一貫した意思決定を支援するものであり、硬直したコミットメントではありません。

このロードマップを四半期ごとにレビューし、アプローチを検証・改良するたびに更新します。

Now（現在）

フォーカス: 基盤の構築と早期採用（FY26Q4）

• Git SSH パフォーマンステストプラットフォームを Gitaly をアーリーアダプターとして構築し、一般的な開発者ユースケースのフィードバックループとストレステスト機能を作成する
• GPT 内で k6 への直接アクセスを公開し、リファレンスアーキテクチャ固有のテストからワークフローに依存しないパフォーマンスツールへと転換する
• GitLab の k6 実装を統合し、ツールの重複を防ぐとともに、より広範なパフォーマンステストの構成要素として機能する柔軟で標準化されたテストプラットフォームを作成する
• GitLab 内の内部テスト環境を調査して使用状況とギャップを把握し、将来のテスト環境統合イニシアチブに向けた情報に基づく意思決定を可能にする

Next（次）

フォーカス: プラットフォームの採用拡大と組織的影響力の構築（FY27Q1/Q2）

• Gitaly パイロットからの学びを活用して、より広範なチーム採用に向けたツール・ドキュメント・サポートモデルを改良する
• 確立されたフィードバックループと採用パターンを使用して、パフォーマンステスト機能を 2〜3 の追加エンジニアリングチームに拡大する
• パフォーマンス関連インシデントのトレンドを追跡し始め、テストのギャップを特定してツール投資の優先順位付けを行う
• Gitaly との協働とクロスチームパターンに基づき、パフォーマンステストアプローチに関する初期見解を発展させる
• チームが最小限のサポートでパフォーマンステストを採用できる、セルフサービスの有効化資料（ガイド・例・テンプレート）を作成する

Later（将来）

フォーカス: 統合的なパフォーマンステスト戦略と組織標準の確立（FY27Q3+）

• 意見のあるテストガイドラインを定義・普及させる: 方法論・環境の使用・重要なメトリクス・いつどこでテストするか
• 標準化されたパフォーマンステストアプローチに関する組織的な合意を形成し、Performance Enablement を専門知識のセンターとして確立する
• さまざまなサービスタイプと展開モデル全体にわたるパフォーマンステストのための規範的なパターンとベストプラクティスを作成する
• 一貫した提供・サポート・ソートリーダーシップを通じて、組織横断的な関係と信頼を構築する

Keeping The Lights On（KTLO）

計画された作業に加え、Performance Enablement チームは既存のパフォーマンステストインフラの継続的なサポート、重大なパフォーマンスインシデントへの対応、現在のテストフレームワークとツールのメンテナンスを担当します。

共通リンク

主要プロジェクト

すべてのプロジェクト

私たちとの連携

新機能のパフォーマンステストへのサポートを依頼する場合は、GPT プロジェクト内でリクエストフォーテンプレートを使用して新しい Issue を作成してください。

個別の質問については、Slack チャンネルを通じてチームに連絡してください。

Slack チャンネル

働き方

ミーティングと定期的な通話

私たちはプロジェクトの Issue トラッカー内で非同期的に作業することを好みます。

チームには定期的な同期通話があります:

• Performance Enablement チームミーティング
• 個人コントリビューターとエンジニアリングマネージャーの 1on1

プロジェクト管理

私たちのプロジェクト管理プロセスの大部分はプラットフォームレベルで説明されており、すべての Infrastructure Platform チームで共有されています。

プロジェクト管理リンク

• チーム プロジェクトステータス Epic
• チーム ロードマップ Epic

戦略

観察

パフォーマンスは共有責任ではなく、専門的な機能として扱われています 現在、パフォーマンステストと最適化は Performance Enablement チームの機能として認識されています。開発チームはパフォーマンスを、後から別のチームが対応するものとして捉えており、機能開発とオーナーシップの根本的な部分とは考えていません。そのため、パフォーマンスの問題は開発の中で防止されるのではなく、本番環境で発見されてから対処されています。責任共有のマインドセットがなければ、チームはパフォーマンス成果に対する説明責任を持てません。

私たちのチームは現在、R&D 全体にわたる乗数的な力ではなく、ハンズオンサポートのレベルで機能しています 少数の R&D チームに対してツールを構築し、個別環境のセットアップとテストを提供してきた実績があります。しかし、これらのツールには環境セットアップ・カスタム設定・継続的なテストサポートなど、チームからの多大な手動関与が必要です。これにより R&D 全体へのスケールが制限され、ボトルネックが生じています。

パフォーマンスの全体的な可視性とガバナンスが不足しています 開発チームを信頼している一方で、機能やリリース全体のパフォーマンストレンドを体系的に追跡する方法がありません。勝利を称え、早期に劣化パターンを特定し、パフォーマンスに関するスタッフィングと投資戦略についてデータに基づく意思決定を行う機会を逃しています。この可視性がなければ、インシデントを防ぎ、グローバルなパフォーマンス改善を推進する能力が制限されます。

テスト環境と本番環境のギャップが有効性を制限しています 多くのパフォーマンス問題は本番スケールとデータ量で顕在化します。現在のパフォーマンスへのアプローチは主に小規模テスト環境に限定されており、本番に近い環境を十分に活用していません。さらに、パフォーマンステストのガイドラインを知らせるために、既存のオブザーバビリティプラットフォームやインシデントデータを活用していません。そのため、顧客が私たちより先にパフォーマンスの問題を発見することが多くなっています。

指針となるポリシー

サービスプロバイダーからプラットフォームビルダーへの転換 チームはハンズオンサポートの提供からシフトし、セルフサービスプラットフォームの構築と、チームへのオンボーディングに注力します。すべての R&D チームが自らの担当領域内でパフォーマンスを独立してオーナーすることを可能にするソフトウェア開発に大きく傾注します。私たちはテクノロジーによってレバレッジを構築するのであり、チームのクリティカルパスにいることによってではありません。

トレードオフ: 私たちの直接関与に依存しているチームはセルフサービスツールとプラットフォームを採用する必要があります。個別チームへの直接関与を手放し、R&D 組織全体により大きなインパクトを提供することに集中します。

リソース配分: チームキャパシティの 80% をプラットフォームの構築・機能強化・ガイダンスに、20% を直接サービスとサポートの提供に配分します。これを四半期ごとに測定し、目標を必要に応じて調整します。

パフォーマンスのオーナーシップを開発チームに移管する パフォーマンスは、ローカル開発から MR・CI/CD パイプライン・本番監視まで SDLC 全体を通じて、各チームの責任の基本的な部分となります。開発チームは私たちのツール・プラットフォーム・一般的なガイダンスを活用して、問題をテスト・解釈・修正します。

トレードオフ: 開発チームはパフォーマンステストと監視の追加責任を負いますが、より速いフィードバックループを得て、早期に問題を発見し、顧客へのパフォーマンス問題の漏洩を防げます。自律性を得る代わりに、パフォーマンス成果に対する説明責任を受け入れます。

パフォーマンス上の意思決定の方法: チームが自分たちのパフォーマンス閾値を選択します。これには、顧客に近い PM やその他の担当者からの意見が含まれます。チームは Performance Enablement プラットフォームとツールの Issue をエスカレーションしたり、Performance Enablement チームに追加機能を要求したりすることができます。Performance Enablement チームは、最大の潜在的な顧客インパクトを持つ作業を優先します。

組織全体のパフォーマンス可視性とガバナンスを確立する すべての機能・チーム・リリース全体のパフォーマンストレンドを体系的に追跡・測定・報告します。これにより、インシデントになる前にトレンドを特定する早期警告指標を提供し、データに基づく投資判断を可能にし、勝利を特定して称えることができます。

機能方法: 月次のパフォーマンストレンドをエンジニアリングリーダーシップに公開し、上位のパフォーマンス改善・成功・劣化およびそれらに関連するチームや責任領域を強調します。各チームは自分たちのパフォーマンスメトリクスとトレンドを示すダッシュボードにアクセスできます。

実データを使用してすべてのデプロイモデルにわたってテストし、既存のオブザーバビリティを活用する 実際のカスタマーエクスペリエンスを反映するために、実データを使用したすべてのデプロイモデルのテストを優先します。既存のオブザーバビリティツールとプラットフォームと統合して、追加のパフォーマンスインサイトを提示し、パフォーマンスの課題を特定します。

トレードオフ: チームは追加のデプロイモデル（.com・セルフマネージド・Dedicated）・環境・ツールを理解する必要があり、追加の時間が必要です。その代わり、早期に問題を発見し、エスケープ欠陥を防ぐことができます。

機能方法: チームは SDLC の一部として .com・セルフマネージド・Dedicated 環境全体でパフォーマンスを検証する必要があります。Performance Enablement チームは、できるだけ摩擦なくテストを実施できるよう、デプロイモデルのプラットフォーム・環境・ツールを提供します。

セルフサービス優先、重大な Issue やリクエストのみのエスカレーション R&D チームはセルフサービスプラットフォーム・ツール・ドキュメントを使用して、パフォーマンスの課題をテスト・特定・修正する必要があります。エスカレーションと手動作業は、ビジネスクリティカルな理由のためにのみ稀に行うべきです。

トレードオフ: R&D チームはツールとプラットフォームの学習により多くの時間を投資します。ヘルプリクエスト（RFH）は重大なエスカレーション以外は即時対応を受けません。結果として、チームは追加の自律性を構築します。

エスカレーション基準と RFH ガイドライン:

• 重大（即時対応）: 顧客に影響する本番インシデントまたはリリースを妨げる完全なプラットフォーム障害
• 高優先度（2営業日）: 一般的なプラットフォームのバグまたは必要な機能の欠如
• 標準優先度（1週間）: 使用に関する質問/シャドーイング、結果の解釈、その他の一般的なプラットフォームのやり取りや指導

標準優先度の Issue をエスカレーションする前に、ドキュメントを参照し、オフィスアワー（予約制）に参加してください。

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