Environment Automation チーム
概要
Environment Automation は Dedicated グループ 内のチームです。私たちのミッションは、GitLab Dedicated ソリューションの自動化された配管を開発・運用することです。
このページで明示的に記載されている違いがある場合を除き、Dedicated グループ ページに記載されているものと同じプロセスに従います。
チームメンバー
チームメンバー情報は 原文 (英語) を参照してください。
私たちとの連携
Environment Automation チームと連携するには:
- GitLab Dedicated チームの Issue トラッカーで Issue を作成 する
- Issue に以下のラベルを付ける:
workflow-infra::Triagegroup::environment automation
- Issue を作成する際は、誰かを
@メンションする必要はありません - 注目を得たい場合は、Dedicated グループ階層 で定義されている特定のチームハンドル(例: @gitlab-dedicated/environment-automation)を使用してください
- Slack チャンネル
- Environment Automation 固有の質問については #g_dedicated-environment-automation-team で私たちを見つけられます
- Slack グループハンドルは
@dedicated-envauto-teamです
- Slack グループハンドルは
- Dedicated グループ全体では: #g_dedicated-team
- Dedicated グループ内の他のチームには作業ディスカッション用の独自の作業チャンネルがあります:
- Environment Automation 固有の質問については #g_dedicated-environment-automation-team で私たちを見つけられます
- 数時間から数日以内に支援が必要な場合:
- Request For Help (RFH) プロセスに従ってください。特定のテンプレートはこちら から探してください。
- 顧客影響がある場合は、Dedicated Commercial のインシデント管理プロセスに従い、私たちにページしてください。
- Geo マイグレーションについては、EA と PS が特定のエンゲージメントモデルを持っており、マイグレーションフェーズに応じて対応します。
作業方法
私たちは、プロジェクト管理セクション で説明されているプロジェクト Issue トラッカー内で非同期的に作業することを優先しています。
チームには一連の定期的な同期通話もあります:
- Environment Automation チームシンク(隔週):
- EMEA/AMER: 火曜日 15:00 UTC(EMEA と US East に適しています)
- PST/APAC: 水曜日 00:00 UTC(APAC と US West に適しています)
- GCP での Dedicated 週次デモ: 水曜日 07:30 UTC
- Dedicated グループデモ
四半期計画プロセス
四半期計画プロセス
四半期計画は戦略的優先事項とチームキャパシティのバランスを取るために使用されます。一貫した実行、非同期アライメント、およびステークホルダー全体の可視性を確保します。計画は新しい四半期の 4 週間前に開始し、実行可能な作業項目を確保するためのエピックバックログ精緻化が統合されています。
ステップ 1 – 計画 Issue の作成(週 -4)
- オーナー: エンジニアリングマネージャー(EM)
- アクション:
- 四半期計画 Issue(例: Q4 FY26 計画)を作成する。
- この Issue を非同期ディスカッション、戦略ドキュメントへのリンク、および最終決定のログに使用する。
- すべてのステークホルダーと Issue リンクを共有する。
- 成果物: 計画 Issue を開いてすべてのステークホルダーと共有する。
ステップ 2 – 戦略的インプット(週 -4 から -3)
- オーナー: PM、カンパニーインターロックプロセス
- アクション:
- PM が FY26 Dedicated ステージロードマップ計画スプレッドシート を定期的に更新する。
- カンパニーインターロックプロセスがトップティアイニシアチブを提供する(インターロックトラッカー)。
- EA EM と PM が週次火曜日の会話を開催して以下を議論する:
- その日の Issue
- チームへの認識のためのフラグ
- 四半期計画のインプットと更新
- 成果物: 計画 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 定義
計画成果物とテンプレート
- FY26 Dedicated ステージロードマップ計画
- 顧客ロードマッププレゼンテーション
- カンパニーインターロックトラッカー
- EA 継続的計画スプレッドシート
- エピック精緻化チェックリスト(MVC、ビジネスケース、設計、複雑度)
- エピックステータス追跡(Triage/Proposal/Ready)
役割と責任
| 役割 | 責任 |
|---|---|
| プロダクトマネージャー | 戦略的ロードマップを維持し、計画スプレッドシートを更新し、エピックビジネスケースを提供する |
| エンジニアリングマネージャー | キャパシティ評価を主導し、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レビューの作業負荷を分散させるためにこれを使用しています。使用するには:
- レビュアールーレット ページに移動する。
Spin the wheelをクリックする。
完全な MR プロセス を参照してください。
エピックステータス更新
毎週、自動化によって DRI はエピックの進捗更新を求められます;これらは収集され、ビジネスによって集合的にレビューされます。DRI は エピックが正しく設定されていること を確認し、PTO の場合に備えて更新を書くか委任する必要があります。
レスポンス例
キャパシティプランニングアラートへの具体的なレスポンス例を示します。
- キャパシティプランニングからメトリクスを削除する - 高度な検索メモリ負荷 は長期トレンドに従わず、有用な予測ではありませんでした。 実際の限界を超えた場合にアラートとなるメトリクスとして残っています。
- 飽和メトリクスを完全に削除する - kube_pool_cpu は多くの場合で不正確で、正しく取得するのが困難でした。 異なる飽和メトリクス(ノードベースの CPU)に置き換える必要がありました。
- 飽和メトリクスを追加する - Kubernetes PVC はまったく監視されておらず、ニアミスインシデントが発生していました
- 飽和メトリクスを修正する - 高度な検索ディスク は不正確で、より良い promql 式に置き換える必要がありました
