インフラストラクチャ ラベルとタグ

クイックリファレンス

すべてのラベルとタグに gl_ プレフィックスを使用します。すべてのキーはアンダースコア（snake_case）を使用します。すべての値はハイフン（スラッグ値には alpha-dash）を使用する必要がありますが、アンダースコアも許可されています。

特定のレルムのラベルとタグには、レルムプレフィックスを付ける必要があります。レルム変数の詳細については、各レルムのドキュメントをご覧ください。

グローバルラベル/タグ

レルムラベル/タグ

レルム固有のラベルとタグについては、各レルムのラベルとタグのハンドブックページをご覧ください。

• infra-shared-services
• it
• saas
• sandbox
• security

設計上の決定と変更ログ

チームのフィードバックに基づいてこれらの標準の設計中に行われた変更の要約を、将来の参照のために保存しています。

• Issue のフィードバックに基づき、人事管理のレポートライン構造ではなく、機能チームに基づいて部門とグループのリストを刷新しました。
• GitLab ディビジョンは gl_department にプレフィックスが付いているため廃止されました。
• gl_dept_group のプレフィックスとして使用できるよう短くするため、gl_department を gl_dept に名称変更しました。
• team の曖昧さについてのフィードバックと、スプレッドシートで行った再マッピング（ほとんどの部門にはグループ/チームがあるが、エンジニアリングを除いてサブグループを持つものはなく、エンジニアリングにはサブ部門/ステージの組織階層がある）に基づき、gl_team を gl_dept_group に名称変更しました。エンジニアリングのサブ部門はラベル/タグ構造では使用しません。
• gl_product_stage を追加しました。以前のイテレーションでは gl_stage を使用していましたが、stage という用語は曖昧なため、プロダクトステージとして識別します。
• 業界で認識可能な省略形を使用して、より簡単なプレフィックス付けができるようにすべての値を略称化しました。省略形が普遍的に認識できない場合は完全な単語を使用します。Okta の統合では、インフラストラクチャに使用する短い名前に Workday の値を再マッピングします。
• GitLab.com のユーザー名はクラウドプロバイダーのラベルとタグで許可されていない文字を含む可能性があるため、gl_owner_username を削除しました。
• 期待される値を明確にするため、gl_owner_email を gl_owner_email_handle に名称変更しました。
• 現在のアーキテクチャでは別のツールで gl_owner_email_handle を使用してユーザー検索を行うため、クラウドリソースからはアクションを実行しない gl_owner_slack_id を削除しました。
• 各エンティティの収益割合に基づいてグローバルコストを配分する方法との既存の整合性のため、gl_entity に allocate の値を追加しました。
• GCP はラベルを使用しない限りリソースの種類や名前に基づいた簡単なレポートをサポートしていないため、gl_resource_type と gl_resource_name フィールドを追加しました。
• すべてのリソース（ディスク・ネットワークなど）の集約コストを表示するために、親リソースのコストを示す gl_resource_host を追加しました。
• infrastructure-as-code ツール（Ansible など）が同じタイプと設定の複数のインスタンスにリソースをデプロイできるようにするため、gl_resource_group を追加しました。
• 2021 年 7 月 22 日に、gl_dept・gl_dept_group・gl_product_stage のテーブルを最新の値で監査・更新しました。gl_dept_group の期待値の下に、名称変更または削除された部門グループのリストを含む新しいテーブルが追加されました。
• Demo Systems のインフラストラクチャが Business Technology によって管理されるようになったため、sales-cs レルムは business-tech レルムに統合されました。
• トップレベルのインフラストラクチャ管理のために infra-shared-services レルムが追加されました。
• GitLab サービスカタログへの参照として gl_service を追加しました（2026 年）。

環境レルム (gl_realm)

gl_realm: `eng-dev`

これは、ここにどのような種類のリソースが存在し、どのインフラチームが権威ある所有権を持っているかのトップレベルの識別のためのものです。

作成されるカスタムラベルまたはタグは、ラベル/タグキーのプレフィックスとして各レルムスラッグを使用する必要があります（例: gl_sandbox_keyname）。

共有サービス

• gitter レルムは 2021 年 7 月 22 日に削除されました。

部門レルム

• sales-cs レルムは 2021 年 7 月 22 日に business-tech レルムに移行されました。

環境タイプ (gl_env_type)

gl_env_type: 'experiment'

期待値

このリストに新しい値を追加でき、他の変更は不要です。このリストはこのラベル/タグのために作成されており、別のソースから継承されたものではありません。

環境名 (gl_env_name)

gl_env_name: 'learning-kubernetes'

環境名は、環境またはサービスの目的の短い名前または説明です。これは gl_realm と gl_env_type のサブ記述子です。このラベル/タグの標準と使用方法は使用される gl_realm によって異なり、各チームは合理的な方法で使用できます。

レルム使用ガイドライン

自動化インフラストラクチャ環境 ID (gl_env_id)

gl_env_id: 'a1b2c3d4'

環境 ID はさまざまな入力を許可しますが、一般的にはシステムによって生成される短い UUID・長い UUID・SHA またはその他の英数字識別子です。このラベル/タグの使用方法は使用される gl_realm によって異なり、各チームは合理的な方法で使用できます。

レルム使用ガイドライン

環境の地理的大陸（リージョン）(gl_env_continent)

gl_env_continent: 'america'

region はあいまいな言葉なので混乱を避けるために continent を使用します。

これは、この環境のリソースがユーザーによって消費される大陸です。必ずしもデプロイされている場所や環境オーナーの居住地とは限りません。インフラストラクチャのメンテナンスが必要な場合やセキュリティインシデントが発生した場合のユーザーへの影響を理解するのに役立ちます。また、特定の大陸/リージョンにオートスケーリングリソースを持つグローバルリソースのメタデータとしても使用できますが、明示的なコスト配分には gl_entity ラベル/タグが必要です。

ビジネスで使用される略称は時間の経過とともに変わる可能性があり（例: APJ・APAC・Asia Pacific）、クラウドプロバイダーは異なる命名法を使用しているため、プログラマティックタイムゾーンのプレフィックスに基づく完全な名前を標準化しています（例: America/Los_Angeles は america）。地域固有でないサービスには global の値を使用できます。

期待値

いくつかの可能なプレフィックス値は、簡潔さと適用の可能性が低いため、このリストから省略されています（例: brazil・hongkong・indian など）。環境オーナーの裁量で追加できます。

オーナーメールハンドル (gl_owner_email_handle)

gl_owner_email_handle: 'jmartin'

@gitlab.com の前のメールハンドルです。ラベルとタグは @ と . の記号をサポートしていないため、ハンドルのみを使用します。値は個人ユーザーまたは Google Workspace グループエイリアスにできます。個人ハンドルの場合、{firstinitial}{lastname} とし、現在のアーキテクチャではユーザーエイリアスをプログラマティックに検索できないため、ユーザー名エイリアス（例: jeff）は使用しないでください。

これは Okta アカウントとの関連付け・インフラストラクチャ通知・追加メタデータによるユーザーのアカウント識別に使用されます。ユーザーはセキュリティアドバイザリ通知のメールを受け取る場合があります。

オーナータイムゾーン (gl_owner_timezone)

gl_owner_timezone: 'america-los_angeles'

これは、稼働時間を決定するために使用される環境オーナーのタイムゾーンです。稼働時間は午前 6 時（06:00）から午後 6 時（18:00）の間と想定されています。通常、システムを所有する人が 1〜2 人しかいない場合にのみ使用されます。グローバルカバレッジを持つシステムには、このラベル/タグを使用しないでください。

これはプログラマティックなタイムゾーン ID に基づいており、通常は Continent/Locality の形式に従います。完全な例のリストは GCP ドキュメントでご覧いただけます。

ラベルで許可されている文字に制限があるため、/ は許可されておらず、小文字のラベルを使用します。そのため、スラッシュ / をハイフン - に置き換え、小文字のみを使用します。これは + 記号を使用できないため UTC 値を使用しないことにした理由でもあります。

値の例

• america-los_angeles
• america-denver
• america-chicago
• america-new_york
• asia-singapore
• asia-tokyo
• australia-sydney
• africa-johannesburg
• europe-amsterdam
• europe-berlin
• europe-london
• europe-paris
• europe-vienna

これらは例であり、完全なリストではありません。インクルーシブなバリューの一環として、すべてのタイムゾーンが等しく価値があることをご了承ください。これはチームマップ上で一人当たりのチームメンバー数が最も多いいくつかの地域に基づいて作成されました。

GitLab エンティティ (gl_entity)

gl_entity: 'allocate'

これにより、財務レポートで各ビジネスエンティティにコストを配分できます。設定されていない場合、allocate と想定されます。

期待値

各エンティティの詳細については、GitLab の住所をご覧ください。

レルム使用ガイドライン

Workday マッピング

Okta 連携のテスト中に、このフィールドには予期しない追加の値が入力されています（例: safeguard-italy・federal）。これは www-data/data/entity_mapper.yml に記載されており、各エンティティをリストされているコストセンターエンティティにマッピングします。

GitLab 部門 (gl_dept)

gl_dept: eng-dev

業界で認識可能な省略形を使用して、より簡単なプレフィックス付けができるようにすべての値を略称化しました。省略形が普遍的に認識できない場合は完全な単語を使用します。Okta 連携では、YAML データファイルを使用してインフラストラクチャで使用する短い名前に Workday の値を再マッピングします。以下のテーブルでクイックリファレンスをご覧いただけます。

期待値

GitLab プロダクトステージ (gl_product_stage)

gl_product_stage: eng-dev-manage

eng-dev 部門には多くのグループがあるため、プロダクトセクション、ステージ、グループ、カテゴリハンドブックページを使用してプロダクトステージを使用した親グループを定義します。設計討論中に、プロダクトカテゴリとサブ部門を使用することをイテレーションしましたが、ステージが最も理にかなっていました。

GitLab SaaS とインフラストラクチャのコスト配分または帰属のために、Engineering Infrastructure 部門のチームメンバーは gl_product_stage ラベルを使用して特定のステージに帰属させるべきリソースに付加できます。より詳細な帰属が必要な場合はオプションで gl_dept_group を使用できます。

期待値

GitLab プロダクトカテゴリ (gl_product_category)

gl_product_category: gitaly

期待値

プロダクトカテゴリは、ハンドブックの categories.yml で定義されているカテゴリのいずれかと一致する必要があります: https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/master/data/categories.yml

この値を提供することで、コストを特定の機能セットと、プロダクトおよびエンジニアリングの両方の所有者セットに直接マッピングできます。

サービスカタログ参照 (gl_service)

gl_service: 'ci-runners'

このラベルは、リソースを GitLab サービスカタログのエントリにリンクし、コスト配分とインシデント管理のための明確な所有権と運用責任を確立します。

期待値

サービスカタログエントリは GitLab サービスカタログのエントリと一致する必要があります。値の例:

• ci-runners - GitLab Runner サービス
• ci-jobs-api - CI ジョブ API サービス
• frontend - フロントエンドアプリケーションサービス
• patroni-ci - CI 用 Patroni クラスター

有効なサービスカタログエントリの完全なリストについては、サービスカタログをご参照ください。サービスがまだ登録されていない場合はカタログへの追加をご検討ください。

GitLab 部門グループ (gl_dept_group)

gl_dept_group: eng-support-americas

Engineering Development（eng-dev）部門グループの場合、プロダクトステージスラッグ（gl_product_stage）が gl_dept_group の値のプレフィックスとして使用されます。その他のすべての部門には、gl_dept スラッグをプレフィックスとして使用します。

すべての部門またはステージには、別途識別/機能するグループが必要でない場合に使用できるデフォルトの shared-infra ラベル/タグ/AWS アカウント/GCP プロジェクトがあります。インフラストラクチャの使用量が多いグループには、グループ名をサフィックスとして使用し、グループチームメンバーが使用する専用の AWS アカウント/GCP プロジェクトを提供します。

GitLab の他の部門に共有サービスを提供するグループには、共有コスト配分に使用できる shared-services グループ値もあります。チーム自身のリソースには shared-infra を使用し、私たちが管理する他の全員のリソースには shared-services を使用します。

このスキーマの設計に使用したスプレッドシートで編集可能なバージョンを取得できますが、最近の変更は反映されていない場合があり、このハンドブックページが SSOT（信頼できる唯一の情報源）です。

期待値

グループの完全なリストは 2021 年 7 月 22 日に最終監査・更新されました。

脚注:

1. グループが名称変更または削除された場合、以下の廃止グループ名テーブルに表示されます。名称変更されたグループには脚注の指標があります。
2. 最初のリストが作成された後に追加されました。
3. これはチームと直接対応しない可能性がある特別なグループです。eng-dev の場合、通常はその他の機能の下に表示されます。

廃止グループ名

以下のグループ名は名称変更または削除されており、レガシーインフラストラクチャで引き続き使用されている可能性があるため、参照用に保存されています。

リソースタイプ (gl_resource_type)

gl_resource_type: compute-instance

GCP はラベルを使用しない限りリソースの種類や名前に基づいた簡単なレポートをサポートしていません。これはオプションですが、コストが大きなリソースや本番サービスの一部であるリソースには推奨されます。サンドボックスやエフェメラルなユースケースには推奨しません。

期待値

リソース名 (gl_resource_group)

gl_resource_group: prod-app

これは Terraform・Ansible・その他の関連する infrastructure-as-code またはツールで使用するためのオプションです。

このキーの値は、infrastructure-as-code グループ定義内のグループの名前と一致する必要があります（例: Ansible ロール/グループの命名）。

リソース名 (gl_resource_name)

gl_resource_name: prod-app-web1

このキーの値は、クラウドコンソールのリソースの名前と一致する必要があります。

GCP はラベルを使用しない限りリソースの種類や名前に基づいた簡単なレポートをサポートしていません。これはオプションですが、コストが大きなリソースや本番サービスの一部であるリソースには推奨されます。サンドボックスやエフェメラルなユースケースには推奨しません。

リソースホスト (gl_resource_host)

gl_resource_host: prod-app-web1

これは、子リソース（ディスク・スナップショット・バケット・ネットワーク IP など）を親リソース（例: compute-instance）に関連付けて、リソースの集約コストを表示するために使用されます。

このキーの値は、クラウドコンソールの親リソースの名前と一致する必要があります。

GCP はラベルを使用しない限りリソースの種類や名前に基づいた簡単なレポートをサポートしていません。これはオプションですが、コストが大きなリソースや本番サービスの一部であるリソースには推奨されます。サンドボックスやエフェメラルなユースケースには推奨しません。

データ分類 (gl_data_classification)

gl_data_classification: red

値は、クラウドプロバイダーのタグとラベルの一貫性のためにすべて小文字で（データ分類レベル）ドキュメントに記載されているものと一致する必要があります。

期待値

会計と財務報告

透明性のバリューに沿って、財務情報を公開で共有することはできません。チームメンバーは、ラベルとタグが財務報告にどのように影響するかの詳細をこの Issue で確認できます。このドキュメントに、本番環境のコスト配分手法があります。

ビジネスオーナーとインフラチームへの影響

ラベルとタグスキーマの最大の影響は、各クラウドプロバイダーでプロビジョニングされたすべてのリソースに対する既知のオーナーと部門の識別、およびインフラ/セキュリティレビュー中に参照できる Terraform 設定へのクロスリファレンスです。

放置されたインフラストラクチャの問題を解決するリソースに時間制限を設定できることで、大幅なコスト削減が可能です。また、非稼働時間（夜間と週末）にインフラストラクチャを自動的にシャットダウンする自動化を実装することで、支出の最大 65% を節約できます。

ユーザーとマネージャーへの影響

ラベルとタグにより、インフラストラクチャに関するレポートが容易になり、何が実行されているかを理解し、プロビジョニングしたリソースのコストを自己管理するのに役立ちます。

ほとんどのラベルとタグは Terraform と自動化によって自動的に追加されるか、サンドボックスアカウントのアカウント/プロジェクトレベルで追加されるため、ユーザーがリソースにラベル/タグを追加することを覚えておく必要は大きくありません。

将来の自動化では、メール・GitLab ユーザー名・Slack ID が自動的に関連付けられているため、システムの脆弱性に関する通知・セキュリティインシデント・インフラストラクチャの有効期限が近づいていることの Slack でのフレンドリーなリマインダーを含む、ユーザーへの摩擦のないエクスペリエンスを作成することもできます。

脚注

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