US Public Sector Services チーム

ミッション

GitLab US Public Sector Services チームのミッションは、完全にマネージドされたシングルテナントの GitLab 環境を作成することです。これは GitLab Dedicated プラットフォームを通じて提供され、連邦・州・地方レベルの米国政府機関、並びに機密性の高いワークロードを扱う請負業者、教育機関、その他の米国カスタマーの特定の規制およびコンプライアンス要件に対応するために特化して構築されています。カスタマーテナントのインストールに対する手動操作を排除し、カスタマーテナントが The One DevOps Platform のパワーを最大限に引き出すことに集中できるようにするために開発されています。

ビジョン

US Public Sector Services グループはカスタマー対応チームであり、チームメンバーは高レベルのインフラ自動化と、GitLab Dedicated for US Government プラットフォームとのカスタマーインタラクションの実現に注力しています。

チームのミッションは以下の通りです:

  • Federal Risk and Authorization Management Program(FedRAMP)の要件を満たすかそれを超えるクラウドインフラを構築する
  • 大量のシングルテナント GitLab サイトをプロビジョニングする 100% 自動化されたシステムを開発する
  • 人間の介入なしにメンテナンスタスクを自動化する
  • 中央の可観測性スタック、およびカスタマーテナントごとの可観測性スタックを作成・管理する
  • カスタマーポータル(Switchboard)を提供し、管理操作をカスタマーテナントに公開する

パフォーマンス指標

チームのパフォーマンス指標はまだ完全には定義されていません。まずプロビジョニング SLO を検討し、その後 DORA 4 メトリクスに続く可能性があります。

チームメンバー

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

私たちとの連携方法

GitLab US Public Sector Services チームと連携するには:

  • カスタマーサポート固有の問題の場合はインバウンダリー RFH を作成し、GDGEOC にアサインする。
  • GitLab Dedicated チームの Issue トラッカーで一般的な Issue を作成する。Issue に group::US PubSec ラベルを付ける
  • Issue を作成する際、誰かを @ メンションする必要はありません
  • 注意を引きたい場合は、以下のグループ階層で定義されているチーム固有のハンドルを使用してください
  • Slack チャンネル
    • GitLab US Public Sector 固有の質問は #g_dedicated-us-pubsec で見つけることができます
      • @dedicated-uspubsec-team Slack グループは、チーム全体にタグ付けするために任意の内部チャンネルで使用できます。
    • Dedicated ステージ全体に関連する Issue は #g_dedicated-team で提起できます
    • Dedicated グループ内の他のチームには、チームワークのディスカッション用の独自の作業チャンネルがあります:

作業の進め方

ミーティングと定例コール

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

チームには定期的な同期コールのセットがあります:

  • チームコール — このコールでは、チームメンバーの日常業務に関する重要な情報を共有し、同期的なディスカッションが必要なプロジェクト項目を議論します
  • 個々のコントリビューターとエンジニアリングマネージャーの 1 対 1

個人間の GitLab Dedicated 作業について議論するための臨時 Zoom ミーティングは必要に応じて作成されます。 これらのミーティングはプライベートストリーミングするか、コンプライアンスの許容範囲内で録画1され、GitLab Unfiltered プレイリストに関連性と許可に応じてアップロードされることが期待されています。コールの結果は永続的な場所に共有されます(Slack は永続的ではありません)。チームが成長するにつれて特に重要です。なぜなら、初期段階で行われた決定は、チームが大きくなった後期段階で問い直されることになるからです。

GitLab グループ階層

私たちは GitLab グループを使用して、GitLab Dedicated プロジェクトに取り組むチームメンバーを論理的に整理しています。 グループは以下のユースケースをカバーしています:

  1. GitLab US Public Sector Services グループメンバーシップ: @gitlab-dedicated/uspubsec
    • GitLab Dedicated US PubSec チームのすべての正式メンバーは、オンボーディングの一部としてこの GitLab グループへのアクセスを得る必要があります
    • グループメンションは、GitLab Dedicated US PubSec チームのすべてのメンバーに関連する情報を共有する状況でのみ使用してください
  2. 個々のチームの GitLab Dedicated グループには、maintainersreviewers の 2 つの追加サブグループがあります。例: @gitlab-dedicated/uspubsec/maintainers
    • reviewers GitLab グループへのアクセスは、正式メンバー、外部請負業者、借入メンバーなどに付与されます。この GitLab グループタイプは、マージ権限のないユーザーを区別するために使用されます。初期レビューはこのグループへクイックアクションを使用してリクエストします。例: /assign_reviewer @gitlab-dedicated/uspubsec/reviewers
    • maintainers GitLab グループは正式メンバーのみに付与されます。このグループはマージ権限を持ち、CODEOWNERS 承認ルールを通じてアクセスが付与されます

コラボレーションガイド

私たちのチームは GitLab US Public Sector Services の作業を追跡するために 2 つの公式 Issue トラッカーを使用して協力しています。

1. CompSecGov(セキュアテナント)

リンク: https://compsecgov.gitlab-dedicated.us/gitlab-dedicated-us-public-sector/ ラベル: group::US PubSec

属性詳細
目的カスタマーの機密データと FedRAMP 準拠の情報
アクセスUS PubSec エンジニアチーム、US PubSec プロダクトマネジメント、セキュリティコンプライアンス、セキュリティチーム、サポート、パブリックセクターフィールドチームメンバー(カスタマーアクセスなし)
アクセス要件FedRAMP オンボーディングとシチズン検証
オーナーエンジニアリング / プロダクトマネジメント
対応 SLAIssue/コメントのアカウントチームへの対応(インシデントや RFH を除く)は 24 時間(祝日/週末を除く)

ユースケース:

  • セキュリティに関わるカスタマー情報
  • コンプライアンスドキュメント
  • カスタマー固有の詳細を含む内部計画
  • RFH(Request for Help)
  • インシデント
  • トライアル
  • カスタマーオンボーディング
  • アカウントチームのセルフサービスアクセスポイント

2. Dedicated チームトラッカー

リンク: https://gitlab.com/gitlab-com/gl-infra/gitlab-dedicated/team/-/issues ラベル: group::US PubSec

属性詳細
目的内部計画と機能開発
アクセスGitLab 内部チームのみ(カスタマーアクセスなし)。他の Dedicated チームと共有
オーナープロダクトマネジメント / エンジニアリング

ユースケース:

  • スプリント計画とロードマップ
  • 機能開発(必要に応じてコードネームを使用)
  • Grand Review 項目
  • アカウントチームのセルフサービスアクセスポイント
  • 機能リクエスト
  • マイグレーション計画

注意: 特定カスタマー向けの追加コラボレーション Issue トラッカーは、フィールドチーム(CSM/SA)が所有・運営することがあります。US Pubsec PM/エンジニアリングチームの SSOT として機能するのは、この 2 つの公式 Issue トラッカーのみです

Slack チャンネル

私たちは Slack でコラボレーションしています。各チャンネルの目的を理解するためのガイドです

チャンネル名目的
dedicated-for-gov-fielddedicated for gov について議論するプライベートチャンネル。カスタマーのパブリックセクター情報を保護するためにプライベートです。メンバーシップはフィールドの US Pubsec メンバー、Dedicated for Gov R&D スタッフ、セキュリティ、コンプライアンス、サポートなど、プロダクトの質問に回答する人々に限定されています
g_dedicated-us-pubsecパブリックチャンネル。一般的なエンジニアリングのディスカッションに使用してください。
dedicated-for-gov-stableプライベートチャンネル。dedicated for gov 安定ワーキンググループのメンバー用。

プロジェクト管理

私たちはエピックIssue、および Issue ボードを使用して作業を整理しており、これらは相互に補完し合っています。

異なる機能にわたる すべての GitLab US Public Sector Services 作業の唯一の信頼できる情報源はトップレベルの GitLab US Public Sector Services エピックです。アクティブおよび予定されている作業の詳細については、そのエピックを参照してください。チームが取り組んでいる具体的な Issue を確認するには、チームの作業の全体的な Issue ボードを参照してください。

エピック階層

サブエピックはトップレベルエピックの下に作成され、作業を特定のイニシアチブやプロジェクトマイルストーンに向けた整理されたリストの Issue に論理的に分割します。

必要に応じて、プロジェクト追跡のために Issue をさらに分割するため、既存のエピック階層内に追加のサブエピックを作成することができます。

  1. サブエピックは、記載されている項目をデリバリーするために必要なタスクをグループ化します
  2. サブエピックはロードマップの項目を表し、特定のフェーズでデリバリーされます
  3. サブエピックは複数ヶ月にまたがることができますが、終了日は追加されたロードマップフェーズの「予想完了日」と一致する必要があります

エピックに加えて、マイルストーンは、複数のエピックにまたがる Issue をターゲットのマイルストーン日と関連付けるプロジェクト追跡ツールとして使用できます。マイルストーンは Issue ボードでフィルタリングでき、チームがアクションを取るべき現在の優先 Issue を単一画面で表示できます。

エピックオーナー

各エピックにはプロジェクトのデリバリーに責任を持つ単一の DRI がいます。各エピックの DRI はエピック構造ごとの各エピックの説明の上部に記載されています。

エピックオーナーの責任

DRI は以下を行う必要があります:

  1. 他の人と協力してボードを通じて Issue を進める
  2. エピックがエピック構造に記載された基準を満たしていることを確認する
  3. 以下のステータス更新プロセスに従って DRI のエピックのエピック説明に更新を提供する

エピック構造

各エピックと子サブエピックには以下を含める必要があります:

説明

  1. このエピックに責任を持つ DRI
  2. エピックを理解しようとする人にコンテキストを提供するための問題提起を含む背景
  3. エピックの具体的な目標のための終了基準
  4. ステータス yyyy-mm-dd は説明の最後の見出しである必要があります。
    1. これにより、エピックに関心を持つ人がすべてのコメントや Issue を読まなくても最新のステータスを確認できます。
    2. この見出しはトップレベルエピックのステータス情報を自動生成するために使用されます。

エピックメタデータ

  1. 開始日はプロジェクト開始時に実際の開始日に更新され、予想開始日に設定されます。
  2. 期限は予想終了日に設定されます。

ラベルはエピックラベルセクションで説明されています。

Issue ボード

Issue ボードはエピックやマイルストーンの全体的なステータスを追跡するために使用されます。

US Public Sector Services Issue ボードへのアクセス
  1. Dedicated Issue トラッカープロジェクトにアクセスします。
  2. 左のナビゲーションメニューを使用して、Issues セクションにカーソルを合わせて Boards を選択します
  3. 左上のドロップダウンメニュー(Search Filter の横)を使用して、表示したいエピックまたはマイルストーンに関連する特定のボードを選択します。表示したいボードの名前がわかる場合は、ドロップダウン検索ボックスに入力できます。
  4. 選択すると、Issue ボードには提供されたフィルター(例: マイルストーン、エピック、ラベルなど)に基づく Issue のリスト、およびさまざまな列(Lists とも呼ばれる)が含まれたカンバンレイアウトが表示されます。US Public Sector Services チームはラベルを主な List フィルターとして使用しています。これらの Issue ボードがどのように作成・フィルタリングされているかについては以下のセクションを参照してください。

注意: 時間ブロックのプロジェクト作業に使用される Issue ボードは、簡潔さを維持するために完了後に廃止する必要があります。

実行

チームはカンバン方式で運営されています。Issue はカンバンボードで優先順位付けされ、自己割り当てされます。私たちはスコープ付きのワークフローラベルを活用して、作業のさまざまな段階を追跡します。

ステータス更新/プロセス

ステータス更新とステータス更新プロセスの詳細については、ステージレベルのステータス更新ページセクションを参照してください

このチームのすべての作業のステータスは、トップレベルの GitLab US Public Sector Services エピックの説明で管理されており、一目で確認できます。

レポーティング

私たちはトップクロスファンクショナルイニシアチブの要件を満たすために GitLab Dedicated のステータスに関するレポートを提供します。


  1. 録画ルールの例外: 1 対 1 のコール、プロジェクト外の業務に関するディスカッション、録画に不快を感じる当事者がいる場合、または FedRAMP コンプライアンスにより録画できない場合。ただし例外があっても、プロジェクト関連のディスカッションの結果は、メインの Issue トラッカーなどの永続的な場所に記録する必要があります。 ↩︎