コンポーネントオーナーシップモデル

すべての GitLab プラットフォームに新しいインフラコンポーネントを追加するための整備された道筋

コンポーネントオーナーシップモデル図

エコシステムを理解する

コンポーネントオーナーシップモデルは、GitLab の本番環境レディネス有効化プロセス（PREP）を、オーナーシップとすべての GitLab プラットフォームにおいてベストプラクティスを使用した本番環境への整備された道筋に焦点を当てて拡張しています。

このモデルは、Runway 以外のインフラコンポーネントを GitLab.com 向けにオンラインにするチームをガイドします。.com デプロイに焦点を当てていますが、コンポーネントが GitLab のより広いデプロイメントランドスケープ（Dedicated、FedRAMP、Cells、および将来のセルフマネージドサービス）と互換性を維持することを保証します。

このモデルは、より大きな変革の一部です。他のイニシアチブとして、クラウドネイティブな未来に向けたセルフマネージドの区分化ブループリントおよび本番環境レディネス有効化プロセスがあります。コンポーネントオーナーシップモデルは、期待値の整合、オーナーシップの促進、インフラストラクチャプラットフォーム部門からの手動（場合によっては遅い）ゲートキーピングの必要性の削減という方法で、GitLab.com への新しいソフトウェアコンポーネントの提供アプローチの加速と統一に焦点を当てています。

Runway および本番環境レディネスプロセスとの関係

このプロセスは本番環境レディネスプロセスの代替ではなく、本番環境レディネスのサイクルタイムを削減するために設計された、意見を持った整備された道筋です。

これはRunwayの目標と同様です。 Runway を選択することがこのプロセスより望ましく、可能な場合は Runway を使用してください。

残念ながら、Runway はまだセルフマネージド環境へのサービスデプロイをサポートしていません。新しいコンポーネントがセルフマネージドデプロイを必要とし、Runway がセルフマネージドをサポートするまでの場合、コンポーネントオーナーシップモデルが次善の選択肢です。

従来のエンゲージメントモデルと比較して、コンポーネントオーナーシップモデルはチームがより高い自律性で作業し、サイクルタイムを短縮し、インフラストラクチャとのより良い整合を実現できるようにします。

定義

コンポーネント: GitLab.com に特定の機能を提供する自己完結型のインフラストラクチャーアズコードモジュール。このコンテキストでは、クラウドリソースまたは Kubernetes ワークロードを定義するHelm チャートまたはTerraform モジュールを具体的に指します。コンポーネントはバージョン管理され、テストされ、明確に定義されたインターフェースを通じてアクセスされます。
ポリシーアズコード: Open Policy Agent や conftest などのツールを使用して機械可読なルールとして定義されたインフラストラクチャの標準と要件。書面によるドキュメントではありません。ポリシーはバージョン管理され、OCI イメージとして共有・配布されます。
セマンティックバージョニング（SemVer）: MAJOR.MINOR.PATCH フォーマットを使用するバージョニングスキーム。詳細な仕様については semver.org を参照してください。
コンポーネントオーナー: 設計から本番運用まで、オンコール責任、セキュリティアップデート、継続的なメンテナンスを含めてコンポーネントの責任を持つステージグループチームまたはインフラチーム。
Runway 以外のコンポーネント: 特定の要件または制約により GitLab の Runway プラットフォームを使用できないインフラコンポーネントで、コンポーネントオーナーシップモデルのアプローチを必要とするもの。 GitLab アプリケーションコンポーネントの場合、現在の主な理由はセルフマネージドへのデプロイが必要なことです。この機能の作業は計画されていますが、まだ利用できません。さらに、一部のサービスは Runway がカバーしていないインフラ機能（例: 高度なステートフル Kubernetes 機能（Persistent Volume、Stateful Set など））に依存しています。
インテグレーションエンジニア: コンポーネントの GitLab.com インフラへの統合をガイドし、設計に対して実装をレビューし、統合ステージ中のポリシーコンプライアンスを確保するプロダクションエンジニアリングチームのメンバー。
レビュアー SRE: コンポーネント設計をエンゲージメントステージで評価し、スケーラビリティ、運用、アーキテクチャの決定に焦点を当てるプロダクションエンジニアリングの Staff+ 個人貢献者。
整備された道筋（Paved Path）: 開発を加速しながら一貫性とコンプライアンスを確保するために、事前構築されたツール、テンプレート、自動化を備えた意見を持った標準化されたアプローチ。
config-mgmt: インフラ用の GitLab の設定管理リポジトリ。コンポーネントオーナーシップモデルでは、コンポーネントをこのリポジトリに直接追加してはなりません。
k8s-workloads: GitLab のKubernetes ワークロードリポジトリ。 config-mgmt と同様に、アプリケーションコンポーネントは個別に管理され、バージョン管理された依存関係として統合される必要があります。
common-ci-tasks: ポリシーを適用し、テストを実行し、デプロイを自動化する標準化された CI コンポーネントを https://gitlab.com/gitlab-com/gl-infra/common-ci-tasks で提供する GitLab リポジトリ。
Copier テンプレート: 標準化されたプロジェクト構造を生成する Copier ツールを使用したプロジェクトテンプレート。 https://gitlab.com/gitlab-com/gl-infra/common-template-copier で利用可能。
Metrics Catalog: サービスメトリクスを定義するための GitLab の集中システムで、ダッシュボードとアラートを自動的に生成します。コンポーネントはオブザーバビリティのためにこのシステムと統合する必要があります。jsonnet の依存関係はランブックリポジトリからインポートできます。
本番環境レディネス: サービスが本番デプロイ前に運用要件を満たしていることを確認するための GitLab の既存プロセス。コンポーネントオーナーシップモデルはこのプロセスを拡張・加速します。本番環境レディネスプロセスはハンドブックに文書化されています。
infra-mgmt: https://gitlab.com/gitlab-com/gl-infra/infra-mgmt にあるインフラ管理リポジトリ。 GitLab.com における GitLab のリポジトリの作成と管理の自動化、ベースラインプロジェクト要件の適用、 Vault 統合の管理、シークレットのローテーション、GitLab インスタンス間のミラーリングに使用されます。
SLA（サービスレベル契約）: セキュリティアップデート、ポリシーコンプライアンス、インシデント対応など、さまざまな運用活動に対する定義された応答時間と解決目標。
CVE（共通脆弱性識別子）: cve.mitre.org で追跡される公開されたセキュリティ脆弱性で、深刻度レベルに基づいて定義された SLA に従って適時に修正が必要です。
CVSS（共通脆弱性評価システム）: セキュリティ脆弱性の深刻度を評価するために使用される業界標準のスコアリングシステム（0〜10）。詳細については FIRST CVSS 仕様を参照してください。

ロール

3 つの明確なロールがコンポーネント追加プロセスを推進します。それぞれが特定の専門知識をもたらします。それぞれが異なる責任を持ちます。

ロール	チーム	責任
コンポーネントオーナー	新しいコンポーネントを導入・所有するチーム	コンセプションから本番環境まで所有するステージグループチームまたはインフラチーム。エンゲージメントプロセスを推進します。成果物（コンテナイメージ、Terraform モジュール、Helm チャート、設計ドキュメント）を作成します。
設計レビュアー	プロダクションエンジニアリング（Staff+ IC）	設計を評価します。スケール、運用、アーキテクチャ、セキュリティについて難しい質問をします。承認は設計が本番環境の要求に耐えられ、将来的にセルフマネージドで実行可能であることを示します。
インテグレーションエンジニア	プロダクションエンジニアリング	コンポーネントの GitLab.com インフラへの統合をガイドします。承認された設計に対してコードをレビューします。ポリシーコンプライアンスを検証します。実装が約束を満たしていることを確認します。

ビジョン: セルフサービスインフラ

コンポーネントオーナーシップモデルは、インフラコンポーネントのオーナーシップを左方向に推進します。コンポーネントを提案するチームは、アイデアから本番環境を経て継続的なメンテナンスとサポートまで所有します。コンポーネントオーナーは、インフラリポジトリに変更を直接追加することなく、インフラストラクチャーアズコードの個別リポジトリを維持します。独自のモジュールを維持することで、リリースサイクルを管理し、アラートとインシデントに対応します。インフラチームはプラットフォーム、整備された道筋、ガイダンス、ガードレールを提供します。目標はロードブロックを回避することです。

Infra-Mgmt は、リポジトリ管理、ミラーリング、シークレット管理とローテーションを自動化するために使用されます。

将来のイテレーションには、GCP サンドボックスリソースのプロビジョニングを自動化するセルフサービスプラットフォームが含まれる可能性があります。チームは Terraform 自動化のための Atlantis と、シークレット管理のための Vault を使用して標準化された環境をスピンアップできるようになります。このビジョンは実績あるパターンの上に構築され、インフラチームをクリティカルパスから外します。

明確な境界の維持

現在とは異なり、コンポーネントの IaC 定義は Config-Mgmt または k8s-workloads リポジトリには存在しません。それらは https://gitlab.com/gitlab-com/gl-infra/components 名前空間（TBD）の独自リポジトリに存在します。コンポーネントオーナーはこれらのリポジトリを所有し、オーナー権限を持ち、自分の変更をマージします。リリースを管理します。

チームは Kubernetes ワークロード用に Helm チャートとして、またはクラウドリソースプロビジョニング用に Terraform モジュールとしてコンポーネントを構築します。オブザーバビリティのために Metrics Catalog エントリを定義します。インフラプラットフォームは、弱いオーナーシップの変更をモノリシックリポジトリに吸収する代わりに、これらのモジュールを分離された明確に定義されたバージョン管理された依存関係として使用します。

モジュールについては、設定より規約が強く推奨され、 common-ci-tasks CI コンポーネントおよび common-template-copier プロジェクトテンプレート を使用することでこのアプローチが促進されます。

実績のある基盤の上に構築する

common-ci-tasks リポジトリは、一貫したプロジェクトビルドのための標準化された CI コンポーネントを提供します。チームはポリシーの適用、テストフレームワーク、デプロイパターンを継承します。このアプローチにより、車輪の再発明と乖離した慣行を避け、整備された道筋アプローチが促進されます。

GitLab インフラチームは、common-template-copier プロジェクトに保存されたプロジェクトテンプレートに Copier をすでに使用しています。 Copier テンプレートはコンポーネントを保守可能で一貫性のあるものにするパターンを確立し、破壊的変更を移行するためにプロジェクトへの自動アップグレードを提供します。新しいプロジェクトでこれらの Copier テンプレートを使用することは必須です。

ポリシーアズコード

コンポーネントオーナーシップモデルでは、インフラ標準はドキュメントではなくコードとして存在します。チームは OCI イメージとして公開されたバージョン管理ポリシーを使用します。 conftest はインフラポリシーで定義されたポリシーに対してモジュールを検証するために使用されます。さらに、Helm（helmunit を使用）および Terraform（terraform test を使用）のユニットテストが必要です。 checkov スキャンはより広範な業界標準ポリシーをさらに適用します。

ポリシーバージョンはセマンティックバージョニングに従います:

メジャーバージョンは大規模で破壊的なコード更新を必要とする破壊的変更を導入します
マイナーバージョンは新しいルールを追加します
パッチバージョンは既存コンポーネントを壊さずにバグを修正します

各プロジェクトはサポートされるポリシーバージョンを宣言的に定義します。これはプロジェクトの CI/CD チェックを通じて検証され、開発者ができるだけ早くポリシー違反を認識できます。チームはサポートするポリシーバージョンを宣言します。 Renovate はポリシードキュメントへの更新を提案します。インフラは会議やマージリクエストテンプレートのチェックボックスではなく、ポリシーリリースを通じて標準を伝達します。

ポリシーの進化

インフラは運用経験、チームを特定の方向に誘導する必要性、または小さなリンター修正に基づいてポリシーを進化させます。新しい攻撃ベクターは新しいセキュリティルールを必要とする場合があります。パフォーマンスの問題はリソースポリシーを推進します。チームはサポートウィンドウ内で自分のペースでこれらの更新を使用しますが、インフラプラットフォームチームはチームがモジュールを統合する前に特定の最小ポリシーバージョンを適用することを要求する場合があります。コンポーネントオーナーチームは新バージョンへのアップグレードに責任がありますが、 copier テンプレートを使用してすべての GitLab プロジェクトのアップグレードを自動化するための確立されたアプローチがあります。ソースマイグレーションを使用します。

継続的バリデーション

ポリシーチェックはコードで定義され、コンポーネントプロジェクトで使用される標準の CI コンポーネントに統合されているため、ポリシーはプッシュのたびに検証され、失敗したチェックはマージをブロックします。チームは標準に違反した場合にすぐに認識できます。

開発中のポリシー違反は学習の機会です。チームは正当な理由があれば特定のポリシーを一時的に無効にできます。これらの例外は統合中のレビューが必要です。

オブザーバビリティアズコード

Metrics Catalog の統合は開発中に始まります。チームは Helm チャート定義の一部として PodMonitor および ServiceMonitor 設定を定義します。

サービスは Helm チャートと並べて metrics-catalog 設定を定義します。これらの設定はダッシュボードとアラートを生成します。アラートはオーナーチームに自動的にルーティングされます。

デカップルされたライフサイクル

コンポーネントリポジトリは独自のリリースサイクルを維持します。チームはセマンティックコミットを使用して自動化されたセマンティックリリースプロセスを推進します。

インフラリポジトリは特定のコンポーネントモジュールバージョンを参照しますが、コンポーネント（IaC）コードは含みません。チームはマージリクエストを通じてバージョン更新を提案し、または Renovate が自動的に開きます。アップグレードは本番環境への前にステージングで検証する必要があります。

バージョン管理されたモジュールを使用することで、各環境間の実装間で発生しうるドリフトに物理的な制限があります。これは現在時々使用されるコピーペーストスタイルのアプローチとは異なり、そのアプローチは時間の経過とともに環境間の設定ドリフトをもたらします。

重要なことは、複数の環境に単一のモジュールを使用することで、チームはモジュールへの_インターフェース_と適切な抽象化レベルを考慮する必要があります。これは設計プロセスの重要な部分ですが、単に Terraform リソースを宣言するだけでは見落とされる可能性があります。

サービスレベル契約

インフラプラットフォームとコンポーネントオーナーチームは、以下の SLA を維持することを約束します。

インフラプラットフォームチームの SLA

プラットフォームプロバイダーとして、インフラプラットフォーム部門は以下の SLA を約束します。

初期設計レビュー応答: 設計ドキュメントへの初期フィードバックを提供するまで 10 営業日
統合レビュー所要時間:
- 初期レビュー: 最初のパスまで 2 営業日
- 変更後の再レビュー: 1 営業日
サポート応答時間:
- ブロッキングの問題: 2 営業日
- ブロッキングでない質問: 5 営業日
プラットフォーム可用性:
- CI/CD パイプラインの可用性、上流のブロッカーなし: 99.5% アップタイム

コンポーネントオーナーチームの SLA

コンポーネントオーナーは以下の SLA を約束します。 - コンポーネントオーナーはセキュリティ部門の脆弱性軽減と修正の SLAに従うことを約束します。 - 禁輸脆弱性については: 協調開示タイムラインに準拠する必要があります。

ツールおよび依存関係のアップデート:
- ツールの破壊的更新（Terraform、Helm のメジャーバージョン）: インフラチーム採用から 30 日
- 依存関係のセキュリティアップデート: 上記のセキュリティインシデント SLA に従う
- プロバイダープラグインの更新: クリティカルプロバイダー（GCP、Kubernetes）で 14 日
- 注: Renovate がこれらの MR 作成を管理し、十分なテストカバレッジがあれば、これらの更新は低労力になります。ただし、コンポーネントが手動テストを必要とする場合、コンポーネントオーナーの負担になります。依存関係のアップグレードオーバーヘッドを削減するために、コンポーネントオーナーによる適切な自動化テストの維持を強く推奨します。
ポリシーコンプライアンスの更新:
- メジャーポリシーバージョン: リリースから 90 日
- マイナーポリシーバージョン: リリースから 30 日
- セキュリティ関連のポリシー更新: 14 日
運用対応:
- 本番インシデント（S1/S2）: 15 分の応答時間
- パフォーマンス低下: 1 時間の応答時間
- キャパシティアラート: X 営業日
ドキュメントのメンテナンス:
- ランブックの更新: 重要な変更プロジェクトの一部として提供
オンコールカバレッジ:
- コンポーネントオーナーチームは Tier 1 オンコールまたは Tier 2 オンコールを提供する必要があります。注: 現在 24x5 パイロットオンコールが検討されており、利用可能になったら使用できます。
- PagerDuty でエスカレーションパスを自動化で設定済み
- 引き継ぎ手順を文書化済み

測定とレポート

できる限り合理的な範囲で、GitLab 製品を使用して GitLab のセキュリティ調査結果のレポートを管理します。
インフラプラットフォームとコンポーネントオーナー間の四半期レビュー
運用データに基づく年次 SLA レビューと調整

SLA の例外とエスカレーション

猶予期間はインフラプラットフォームリーダーシップの承認で延長できます
免除には両チームのディレクターレベルの承認が必要です
コンプライアンス違反は以下の場合にディレクターレベルの責任者へのエスカレーションを引き起こします:
- 四半期に 2 回の SLA 違反
- クリティカルなセキュリティ SLA 違反
- 同じ SLA の繰り返し違反
- SaaS 可用性ウィークリースタンドアップで報告

実現する

コンポーネントオーナーシップモデルは自動化と明確なオーナーシップを通じて成功します。標準が自動化されているため、チームはより速く動けます。

コンポーネントオーナーは運用オーナーシップを受け入れる必要があります。インフラチームはパーミッションではなくプラットフォームを提供する必要があります。

COM ライフサイクルステージ

ステージ 1: 設計ステージ

プロセスはエンゲージメントと設計から始まります。コンポーネントオーナーは小さな設計ドキュメントを作成します。これは広大な仕様ではなく、コンポーネントの GitLab.com へのデプロイに特化した焦点を絞った提案です。この同じドキュメントは後でサービスランブックと本番環境レディネスプロセスの一部として使用されます。

プロダクションエンジニアリングサブ部門の Staff+ エンジニアがコンポーネントオーナーと連携して設計を検証します。

承認が与えられる前に以下のような前提条件の質問を網羅する必要があります:

本番環境レディネス設計レビューチェックリスト

注: このセクションは、より広い本番環境レディネスチェックリストのセクションに進化する可能性があります。

ポータビリティ このプロセスは GitLab.com に焦点を当てていますが、コンポーネントは GitLab の他のデプロイメントモデルと前方互換性がある必要があります。セルフマネージドの同等物なしにプロプライエタリなクラウドサービスを必要とする機能はレビューを通過しません。
マルチテナント、シングルテナント、分離 このコンポーネント設計は、Cells や Dedicated など GitLab の他のプラットフォームへの将来のデプロイを考慮していますか? これらの環境と前方互換性がありますか?
オブザーバビリティ標準 コンポーネントは GitLab のオブザーバビリティスタックと互換性のある構造化ログとメトリクスを出力しますか?
依存関係管理 「すべての外部依存関係はバージョン制約とともに文書化されており、制限されたネットワーク環境で動作できますか?」
データライフサイクル コンプライアンス要件をサポートする明確なデータ保持と削除の戦略がありますか?
パフォーマンス低下 コンポーネントは負荷の下で優雅に低下しますか、例えば、明確なサーキットブレーカーとバックプレッシャーメカニズムがありますか?
設定管理 すべての設定を GitLab の標準設定システム（Terraform、Kubernetes）を通じて手動のクリックオプス操作やハードコードされた値なしに管理できますか?
クロスリージョンの考慮事項 コンポーネントは将来の地理的に分散したデプロイと前方互換性がありますか?
リソースクォータ コンポーネントはテナントごとまたはデプロイごとに設定できるリソースクォータとレート制限を実装していますか?
アップグレードパス ローリングアップデートをサポートするゼロダウンタイムのアップグレードパスがありますか?
セキュリティ境界 セキュリティ境界は適切な認証と認可のチェックポイントで明確に定義されていますか?
ディザスタリカバリ コンポーネントは GitLab.com の RPO/RTO 要件に合わせたバックアップ/リストア操作をサポートしていますか。コンポーネントは Cells と Dedicated 全体のさまざまな RPO/PTO 要件と前方互換性がありますか?
統合テスト コンポーネントは外部依存なしに独立して、または統合テストスイートの一部として完全にテストできますか?
データ居住地とプライバシーコントロール コンポーネントは Dedicated および Dedicated-for-Government デプロイのデータ居住地要件とプライバシーコントロールと前方互換性がありますか?
コア変更なしの拡張性 コンポーネントへのインターフェースはコアコードを変更せずに設定を通じてコンポーネントの動作を拡張できますか? 異なるデプロイ設定をサポートしますか?
コンポーネントの代替可能性と独立性 モジュールは明確なインターフェース境界と疎結合で設計されており、他のサービスに影響を与えることなく独立した置き換えまたは移行を可能にしますか?

ステージ 2: 開発ステージ

開発は設計の承認後に続きます。このステージはコンポーネントオーナーチームが主導します。コンポーネントオーナーは自分のリポジトリで構築し、開発のペースを所有します。インフラプラットフォームの関与なしにコンポーネントリポジトリへの変更をマージできます。ポリシー制約の範囲内で、コンポーネントオーナーチームの好みのアプローチに従って開発できます。これにより開発中にインフラプラットフォームのレビューを待つ必要性が軽減されます。

ステージ 3: 統合ステージ

コンポーネントの準備ができたら、コンポーネントオーナーチームと統合 SRE が最初にステージング、次に本番環境への変更の提供に協力します。

最初のステップとして、Config-Mgmt や k8s-workloads などの適切なインフラプラットフォームリポジトリで MR が開かれます。レビューは統合 SRE に割り当てられる必要があります。

各後続環境にモジュールを統合するための変更は別々の MR で実施され、各変更がカナリアおよび最終的に本番環境に展開される前にステージングでテストされます。

変更の準備ができたら、統合 SRE が変更をレビューします。これにはコンポーネントモジュールのレビューが含まれ、以下を確認します:

実装が合意した設計と一致していること（合理的な範囲で）。
ポリシーバージョンが最新で、common-ci-tasks ビルドコンポーネントが最新であること。
テストカバレッジと品質
運用準備（モニタリング、アラート、ランブック）
セキュリティ態勢
リソース効率
バックアップとリカバリ手順

レビューを行う統合 SRE は、できる限り「人間のリンター」にならないようにしてください。小さな些細なリンタースタイルの問題に焦点を当てることは避けるべきです。コンピューターがリンティングを代行でき、人間の時間は大局に焦点を当てるのに遥かに価値があります。小さな細部に焦点を当てることで、レビュアーは木を見て森を見失う可能性があります。

注: これはリンティングが重要でないということではありません。SRE は common-ci-tasks のリンター問題の自動化を目指すべきです。これはゲートキーピングを減らし、コンポーネントオーナーチームが開発サイクルの早い段階でこれらの問題を学べるようにし、プロセスの後半での予期しない遅延を防ぐため、より良いアプローチです。

統合ステージ中は、コンポーネントが十分に安定して本番デプロイの準備ができていると見なされるまで、複数のイテレーションのレビューとデプロイが行われる場合があります。

これらの変更はそれぞれ、モジュールの新しい semver リリースとしてリリースされます。

ステージ 4: 運用とメンテナンス

コンポーネントが本番環境に卒業したら、依存関係のアップグレード、パフォーマンスの改善、技術的負債の解消などの変更とともに、継続的な機能改善をイテレーション的に追加できます。

ストレージの増加、運用コスト、新しいコンポーネントに関連するその他のメトリクスを含む運用メトリクスの継続的なレビューが期待されます。

これらのタスクの責任は、コンポーネントを所有するチームに帰属します。

アイデアから本番環境まで、コンポーネントオーナーチームのためのランブック

ステージ 1: 設計ステージ

本番環境レディネスプロセスに従って本番環境レディネス Issue を開きます。早ければ早いほど良いです。本番環境レディネス Issue を開くことでプロセスが開始され、設計レビュー「スロット」の割り当てプロセスが始まります。
本番環境レディネスプロセスに従って本番環境レディネス MR を作成します。この段階では、ドキュメントはかなり空ですが、コンポーネント設計はこのドラフトドキュメントで実施できます。
コンポーネントは Terraform モジュール、Helm モジュール、またはその両方を持つことができます。
コンポーネントのインターフェースを定義し、本番環境レディネスのドラフト MR に文書化します。インターフェースは、Terraform では入力値、Helm では values です。
モジュールが使用するクラウドリソースの図と説明を作成します。

ステージ 2: 開発ステージ

https://gitlab.com/gitlab-com/gl-infra/infra-mgmt でプロジェクトを宣言して、https://gitlab.com/gitlab-com/gl-infra/components に作成します。
1. Infra-Mgmt は現在セルフサービスの更新に最適化されていませんが、会社内の任意のエンジニアがシステムを通じてプロジェクトを管理することが可能です。
2. Infra-Mgmt の UX を改善してセルフサービスをより良くする作業は https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/1632 でトラッキングされています。
新しい空のプロジェクトをクローンし、https://gitlab.com/gitlab-com/gl-infra/common-template-copier の指示に従ってプロジェクトのベーステンプレートを適用します。初期コミットを GitLab にプッシュします。
モジュールの開発をイテレーション的に進めます。MR レビューはチーム内で実施できます。
Copier テンプレートによって提供されたスキャフォールディングを使用して、インフラのユニットテストを構築します。
Sandbox アカウント、KinD などの開発ツールを使用して変更を統合テストします。
ポリシーの失敗を監視し、早期に対処します。
セマンティックコミットを使用してバージョニングを管理します。セマンティックバージョニングはモジュールの新しいバージョンを自動的にタグ付けし、リリースし、これらのバージョンを公開します。

ステージ 3: 統合ステージ

チームがコンポーネントのステージング準備ができたと確信したら、コンポーネントオーナーチームは Config-Mgmt または k8s-workloads リポジトリで MR を開く必要があります。
変更はステージング環境をターゲットにし、コンポーネントモジュールの特定バージョンを参照する必要があります。
コンポーネントオーナーチームはインフラプラットフォームプロジェクトへのマージアクセスを持ちませんが、統合 SRE にレビューを割り当てる必要があります。
統合 SRE は MR をレビューし、上流モジュールが提案された設計を満たしていることを確認します。
上流で変更が必要な場合は、上流モジュールで実施し、レビューが完了してステージング環境に変更がマージされるまで、セマンティックリリースを使用してモジュールの新しいバージョンを公開します。
コンポーネントオーナーチームは変更を検証し、ステージング環境で期待通りに動作していることを確認します。
コンポーネントオーナーチームはオブザーバビリティ、アラートなどを検証します。
1. チームが Infrastructure Runbooks などのインフラリポジトリに定義する必要なく、オブザーバビリティを独自のモジュールで直接宣言・テストできるようにするために、Observability チームによる追加作業が必要になります。
2. この作業は https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/1637 エピックの一部として行われる可能性があります。
上流モジュールと統合プロジェクトへの複数のイテレーションを通じて、変更は本番環境に組み込まれます。
本番デプロイは、より広範な本番環境レディネスプロセスと整合する必要があり、本番デプロイは本番環境レディネスレビューの状態に依存します。ただし、プロジェクトがインフラテンプレート、インフラポリシー、インフラのベストプラクティスを使用しているため、本番環境レディネスレビューは整備された道筋に従わずにコンポーネントが作成される場合よりも大幅に高速になる可能性があります。

ステージ 4: メンテナンス

変更がデプロイされたら、チームは上流モジュールでさらなる段階的なイテレーション変更を行えます。
開発フェーズと同様に、変更はコンポーネントオーナーチームが所有します。
統合は通常、下流のインフラプラットフォームプロジェクトへのバージョンバンプで実施できます。
バージョンバンプ MR は Renovate によって自動的に作成されますが、MR 承認のためにインフラプラットフォームエンジニアのレビューが必要です。ほとんどの場合、小さな変更については素早いレビューになります。
Renovate はコンポーネントモジュール自体への依存関係のアップグレードも提案します。これらのいくつかは下流の依存関係の CVE に対処し、チームはこれらを（場合によっては SLA 内で）対処する責任があります。
Terraform や Helm などの一部の共有コンポーネントは、Config-Mgmt と k8s-workloads リポジトリの GitLab.com で使用されているバージョンを厳密に追跡する必要があります。チームはこれらのアップグレードを実施する責任がありますが、Renovate が MR を開きます。
チームはコンポーネントに関連するキャパシティ計画の問題に責任があります。
1. コンポーネントオーナーによってオブザーバビリティがモジュール内で定義されるのと同様のアプローチが、キャパシティ計画の飽和点を定義するために使用されます。
2. この作業は https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/1637 エピックの一部として行われる可能性があります。
チームはサービスへのエスカレーションのためのオンコールスケジュールを維持する必要があります。
1. Incident.io リソースは Infra-Mgmt コンポーネントモジュールと並べて管理される必要があります。

次のステップ

GitLab.com へのコンポーネントのデプロイは、すべての GitLab 顧客に新しいコンポーネントを提供するより大きなプロセスの最初のステップにすぎません。

次に、Cells、GitLab Dedicated、Dedicated for Government、GET、Omnibus、Cloud Native GitLab を使用したセルフマネージドについて考慮する必要があります。

新しいコンポーネントを処理するためのこれらのプロセスの一部は変更中であり、それらの変更はまだ進行中です。完了次第、このガイドは適切な次のステップを参照するようになります。

付録: ケーススタディ: GitLab のテナントオブザーバビリティスタック（TOS）

課題

GitLab は複数のデプロイメントモデルで運用されています: マルチテナントの GitLab.com、シングルテナントの GitLab Dedicated、 GitLab Cells、および Dedicated for Government。それぞれがスケール、分離、コンプライアンスに固有の要件を持ちながらも、すべてが包括的なオブザーバビリティを必要としています。統一されたアプローチなしでは、各プラットフォームチームが独自のオブザーバビリティソリューションを実装し、努力の重複、一貫性のないツール、運用上の負担につながります。

ソリューション: コンポーネントオーナーシップの実践

Observability チームは再利用可能な Terraform モジュールとしてテナントオブザーバビリティスタック（TOS）を作成しました。各プラットフォームにオブザーバビリティを直接組み込む代わりに、 TOS は設定を通じて異なるデプロイシナリオに適応する完全なオブザーバビリティソリューションを提供します。

明確なオーナーシップ境界

Observability チームは TOS モジュールを完全に所有します。彼らは:

gitlab.com/gitlab-com/gl-infra/terraform-modules/observability/tenant-observability-stack でモジュールを維持します
セマンティックバージョニングを通じてアップデートをリリースします
包括的なドキュメントを提供します
セキュリティアップデート、依存関係のアップグレードを処理し、モジュールに機能を追加します
モジュールのコンシューマーを顧客として扱います
TOS を内部製品として扱います

プラットフォームチーム（Dedicated、Cells、プロダクションエンジニアリング）は TOS をバージョン管理された依存関係として使用します。彼らは: