Content last updated 2026-08-12

Dedicated Commercial(旧称 Environment Automation)

概要

Dedicated Commercial は、Dedicated グループ 内の機能別チーム群です。私たちのミッションは、主に Dedicated Commercial のロードマップに注力し、GitLab Dedicated ソリューションの自動化基盤を開発・運用することです。 この機能別チーム群は、GitLab の Act 2 後に Environment Automation Team から分離してできたものです。

このページで明示的に記載されている違いがある場合を除き、Dedicated グループ ページに記載されているものと同じプロセスに従います。

マネージャー別チームメンバー

NameRole
Oriol LluchOriol LluchManager, Infrastructure
Andrey RuzmanovAndrey RuzmanovSenior Backend Engineer
Andy KnightAndy KnightStaff Site Reliability Engineer, Environment Automation
Dylan LauDylan LauSite Reliability Engineer
Graeme GilliesGraeme GilliesSenior Site Reliability Engineer, Dedicated:Switchboard
Kunal ParmarKunal ParmarSenior Site Reliability Engineer
Muhamed HuseinbašićMuhamed HuseinbašićSite Reliability Engineer, Environment Automation
Site Reliability Engineer, Environment AutomationSite Reliability Engineer, Environment AutomationSite Reliability Engineer, Environment Automation
Riccardo TrivellatoRiccardo TrivellatoSite Reliability Engineer, Environment Automation
Samir HafezSamir HafezSenior Site Reliability Engineer
Nick SkoretzNick SkoretzSite Reliability Engineer, Environment Automation
Tania RoblotTania RoblotSenior Site Reliability Engineer, Environment Automation
Vihang KotharkarVihang KotharkarSite Reliability Engineer
NameRole
Stephen DenhamStephen DenhamManager, Dedicated:Environment Automation
Alexei OzerovaAlexei OzerovaSenior Site Reliability Engineer, Environment Automation
Chris TaylorChris TaylorSenior Site Reliability Engineer
Dave DittmanDave DittmanSite Reliability Engineer
Harpratap SinghHarpratap SinghSite Reliability Engineer
Jonathan BoweJonathan BoweSite Reliability Engineer, Environment Automation
Konst TchernovKonst TchernovSenior Site Reliability Engineer
Ryan PhamRyan PhamSite Reliability Engineer
Stephan BreitrainerStephan BreitrainerSenior Site Reliability Engineer, Environment Automation
Sean ArnoldSean ArnoldStaff Backend Engineer, Dedicated:Switchboard
Veronica MondoVeronica MondoSenior Site Reliability Engineer, Environment Automation

Act 2 後の機能別チーム

R&D 部門は、3 〜 4 人のエンジニアで構成され、機能領域に完全に集中する小規模チームを重視し、1 人のマネージャーが 2 〜 3 チームを担当する組織構造へ移行しました。また、各機能別チームの Tech Lead であるファンクショナルリードの役割も推奨しました。ファンクショナルリードは、チームの技術的な実行と成長に責任を持つ Staff+ です。

この意図を実現するため、Environment Automation は 5 つの機能別チームに分割されました。

機能別チームサービス提供先スコープとオーナーシップ主なアライメントマネージャーファンクショナルリード
Platform IntegrationGitLab モジュール開発チーム外部製品やモジュール型 GitLab 機能を Dedicated に導入する統合経路を所有します。これには Dedicated との結合、本番運用への対応、統合経路のテスト戦略が含まれます。Theseus と Test Automation Framework。暫定: o-olluch@o-olluchBrendan McKitrickBrendan McKitrick
Platform ResilienceDedicated 運用チーム個々のテナント向けのレジリエンスおよび自己修復製品を所有します。これにはディザスタリカバリ、オートスケーリング、自動キャパシティプランニング、レート制限のほか、人の介入を最小限に抑えながらインスタンスが障害を検知、吸収、復旧し、同時にインフラストラクチャのコスト効率を維持できるようにする仕組みが含まれます。Dedicated Orchestration Automation と Cloud Cost Utilization。Stephen DenhamStephen DenhamKonst TchernovKonst Tchernov
Dedicated Responder AutomationDedicated の SRE および DevOps 対応者Dedicated インシデントに対応するワークフローとツールを所有します。これにはシグナルとアラートの情報付加、アラートルーティング、アラート集約、自動トラブルシューティングが含まれます。Production Engineering の Incident Management および Signals/Observability。o-olluch@o-olluchTania RoblotTania Roblot
Dedicated Orchestration AutomationDedicated オペレーターおよび DevOps チーム中核となるオーケストレーションプラットフォームと変更管理の自動化を所有します。これにはジョブワークフロー、基盤となるインフラストラクチャの変更、メンテナンス操作、テナントモデルのセグメントが含まれます。Platform Resilience、Responder Automation、Platform Integration はこのプラットフォームを利用し、プラットフォーム内の各ワークフローと設定を所有します。Switchboard Orchestration APIs。また、インターフェースが重なる領域では Service Delivery Platform および Cells の運用と連携します。o-olluch@o-olluchSamir HafezSamir Hafez
Dedicated Commercial FeaturesDedicated Product および Dedicated の顧客商用の Dedicated 機能ロードマップと本番運用可能な実装を所有します。これには BYOD、ネットワーク設定、Geo Proxy などの顧客向けインフラストラクチャおよび分離機能が含まれます。アーティファクトの注入、統合、本番品質について Platform Integration および Dedicated Orchestration Automation と連携します。Stephen DenhamStephen DenhamVeronica MondoVeronica Mondo

私たちとの連携

機能別チームへの移行中であるため、いずれかの機能別チームと連携する場合は Environment Automation チームを参照してください(機能別チームごとに新しいコミュニケーションチャネルが利用可能になった時点で、このセクションを更新します)。

  • GitLab Dedicated チームの Issue トラッカーで Issue を作成 する
  • Issue に以下のラベルを付ける:
    • workflow-infra::Triage
    • group::environment automation
  • Issue を作成する際は、誰かを @メンションする必要はありません
  • 注目を得たい場合は、Dedicated グループ階層 で定義されている特定のチームハンドル(例: @gitlab-dedicated/environment-automation)を使用してください
  • Slack チャンネル
  • 数時間から数日以内に支援が必要な場合:
    • Request For Help (RFH) プロセスに従ってください。特定のテンプレートはこちら から探してください。
    • 顧客影響がある場合は、Dedicated Commercial のインシデント管理プロセスに従い、私たちにページしてください。
    • Geo マイグレーションについては、EA と PS が特定のエンゲージメントモデルを持っており、マイグレーションフェーズに応じて対応します。

作業方法

私たちは、プロジェクト管理セクション で説明されているプロジェクト Issue トラッカー内で非同期的に作業することを優先しています。

チームには一連の定期的な同期通話もあります:

  1. Environment Automation チームシンク(隔週):
    1. EMEA/AMER: 火曜日 15:00 UTC(EMEA と US East に適しています)
    2. PST/APAC: 水曜日 00:00 UTC(APAC と US West に適しています)
  2. GCP での Dedicated 週次デモ: 水曜日 07:30 UTC
  3. Dedicated グループデモ

四半期計画プロセス

四半期計画プロセス

四半期計画は戦略的優先事項チームキャパシティのバランスを取るために使用されます。一貫した実行、非同期アライメント、およびステークホルダー全体の可視性を確保します。計画は新しい四半期の 4 週間前に開始し、実行可能な作業項目を確保するためのエピックバックログ精緻化が統合されています。

ステップ 1 – 計画 Issue の作成(週 -4)

  • オーナー: エンジニアリングマネージャー(EM)
  • アクション:
    • 四半期計画 Issue(例: Q4 FY26 計画)を作成する。
    • この Issue を非同期ディスカッション、戦略ドキュメントへのリンク、および最終決定のログに使用する。
    • すべてのステークホルダーと Issue リンクを共有する。
  • 成果物: 計画 Issue を開いてすべてのステークホルダーと共有する。

ステップ 2 – 戦略的インプット(週 -4 から -3)

  • オーナー: PM、カンパニーインターロックプロセス
  • アクション:
  • 成果物: 計画 Issue に文書化された戦略的優先事項。

ステップ 3 – チーム計画(週 -3 から -1)

  • オーナー: EM とチームメンバー
  • アクション:
    • EM がプロジェクト、タイムライン見積もり、スタッフニーズで EA 継続的計画スプレッドシート を更新する。
    • チームメンバーが見積もりをレビューし、リスクにフラグを立て、依存関係を表面化する。
    • EM とチームが計画 Issue のコメントを使用してキャパシティを測定し、インプットを結びつける
  • 成果物: 計画 Issue にリンクされた四半期実行計画のドラフト。

ステップ 4 – エピックバックログ精緻化(週 -2 から -1)

  • オーナー: EM + PM とチームメンバー
  • アクション:
    • ロードマップ計画スプレッドシートから次の四半期に特定されたエピックを取得する
    • 実行対象の各エピックについて、以下が含まれていることを確認する:
      • MVC スコープ が明確に定義されている
      • ビジネスケース / 根拠 が文書化されている
      • 高レベル設計へのリンク が含まれている
      • 推定複雑度レベル がエンジニアリングインプットで評価されている
    • エピックをステータス進行させる: Triage → Proposal → Ready
    • エピック精緻化のディスカッションと決定に計画 Issue のコメントを使用する
    • チームメンバーが複雑度見積もりと設計実現可能性について技術的インプットを提供する
    • エピック情報を完成させるために必要に応じて異なるステークホルダーを引き込む
  • 成果物: 即時の四半期実行のためにすべての対象エピックが「Ready」ステータスになった精緻化されたエピックバックログ。

ステップ 5 – 最終確認(週 0)

  • オーナー: EM と PM + ステークホルダー
  • アクション:
    • 計画 Issue での非同期レビュー。
    • スコープ、キャパシティ配分、コミットメントを確認する。
    • エピックバックログ精緻化の完了と準備状況を確認する。
    • 最終決定、成果物、リンクを含む要約コメントを投稿する。
    • EA EM と PM が週次火曜日の会話を使用して未解決の Issue、フラグを確認し、四半期の決定を確認する。
  • 成果物: 精緻化されたエピックバックログを持つ確定した四半期計画;計画 Issue をクローズする。

ステップ 6 – 四半期キックオフ(週 1)

  • オーナー: EM と PM + ステークホルダー
  • アクション:
    • PM と EM が Dedicated ステージキックオフプレゼンテーションで協力する(例: FY26Q3 Dedicated キックオフ
    • PM と EM が前四半期の達成事項と次四半期のイニシアチブを記入する
    • PM と EM がキックオフビデオを録画してチームと共有する
    • エンジニアは精緻化された「Ready」ステータスのエピックですぐに作業を開始できる
  • 成果物: チームアライメントのための四半期キックオフプレゼンテーションと録画ビデオ

計画インプットとソース

  • 戦略的: カンパニーインターロックプロセス、PM ロードマップ、顧客コミットメント
  • 運用的: KTLO 作業、オンコールキャパシティ、計画外作業、エンジニアリングバックログ
  • エピックレベル: 技術設計、複雑度評価、MVC 定義

計画成果物とテンプレート

役割と責任

役割責任
プロダクトマネージャー戦略的ロードマップを維持し、計画スプレッドシートを更新し、エピックビジネスケースを提供する
エンジニアリングマネージャーキャパシティ評価を主導し、EA 継続的計画を更新し、計画 Issue を作成/管理し、エピック精緻化を調整する
チームメンバー見積もりをレビューし、リスクにフラグを立て、依存関係を表面化し、エピック複雑度インプットを提供し、非同期ディスカッションを行う
ステークホルダーフィードバックを提供し、最終確認中にコミットメントを検証し、必要に応じてエピック精緻化に貢献する

成功指標

  • 計画 Issue が週 0 までにクローズされる
  • チームがキャパシティコミットメントを承認する
  • 戦略的優先事項が実行キャパシティにマッピングされる
  • 依存関係とリスクが明確に特定される
  • 完全な精緻化情報を持つすべての対象エピックが「Ready」ステータスになる
  • バランスの取れた配分: 機能開発 40-60%、KTLO 20-30%、オンコール 15-25%、エンジニアリング 10-15%

リスクとベストプラクティス

  • 反応的/計画外の作業に 10-20% のバッファを想定する
  • 計画 Issue 内にディスカッションを文書化する
  • トレーサビリティのためにスプレッドシートとロードマップをリンクする
  • 前四半期の計画外作業をレビューする
  • 戦略的作業と運用上の要件をバランスさせる
  • エンジニアリングの即時実行を可能にするために四半期開始前にエピック精緻化を完了させる
  • エピック複雑度見積もりにエンジニアリングの視点が含まれていることを確認する

バックログ精緻化の統合

この四半期計画プロセスには ステップ 4(週 -2 から -1) 中のエピックバックログ精緻化が統合されています。この精緻化により、エンジニアが四半期実行フェーズ中にエピックを選択する準備ができたら素早く開始できるようになります。

この精緻化されたエピックのセットは、正確なキャパシティ見積もりで次の四半期の計画に役立ち、エンジニアが発見とスコープ調整の活動に時間を費やすのではなく、四半期が始まったらすぐに生産的な作業をすぐに開始できるようにします。

レビュアールーレット

レビュアールーレットは、ランダムにメンテナー + レビュアーを選ぶ GitLab.com プロジェクト向けの内部ツールです。Environment Automation は MR レビューの作業負荷を分散させるためにこれを使用しています。使用するには:

  1. レビュアールーレット ページに移動する。
  2. Spin the wheel をクリックする。

完全な MR プロセス を参照してください。

エピックステータス更新

毎週、自動化によって DRI はエピックの進捗更新を求められます;これらは収集され、ビジネスによって集合的にレビューされます。DRI は エピックが正しく設定されていること を確認し、PTO の場合に備えて更新を書くか委任する必要があります。

レスポンス例

キャパシティプランニングアラートへの具体的なレスポンス例を示します。

  • キャパシティプランニングからメトリクスを削除する - 高度な検索メモリ負荷 は長期トレンドに従わず、有用な予測ではありませんでした。 実際の限界を超えた場合にアラートとなるメトリクスとして残っています。
  • 飽和メトリクスを完全に削除する - kube_pool_cpu は多くの場合で不正確で、正しく取得するのが困難でした。 異なる飽和メトリクス(ノードベースの CPU)に置き換える必要がありました。
  • 飽和メトリクスを追加する - Kubernetes PVC はまったく監視されておらず、ニアミスインシデントが発生していました
  • 飽和メトリクスを修正する - 高度な検索ディスク は不正確で、より良い promql 式に置き換える必要がありました