Infrastructure Platforms

ミッション

Infrastructure Platforms として、私たちのミッションは、高可用性・信頼性・高性能・スケーラブルなインフラソリューションを構築し、総所有コストを最低限に抑えながら、GitLab が SaaS および Self-Managed プラットフォーム全体で単一の DevSecOps プラットフォームを提供できるようにすることです。

ビジョン

業界をリードする SaaS ソリューションを提供し、最も革新的で効率的な DevSecOps プラットフォームで世界中の組織を支援します。

サポートの取得

GitLab.com の可用性問題について Infrastructure Platforms チームにアラートを出したい GitLab チームメンバーは、インシデントの報告方法に関する簡単な手順をこちらで確認してください: インシデントの報告。

その他のすべての問い合わせについては、getting assistance ページを参照してください。

方向性

Platforms セクション内で推進されるイニシアチブは、複数四半期にまたがることが多く、SaaS Platforms セクションエピック (GitLab チームメンバー) に表現されています。

We are also Product Development

Unlike typical companies, part of the mandates of our Security, Infrastructure, and Support Departments is to contribute to the development of the GitLab Product. This follows from these concepts, many of which are also behaviors attached to our core values:

• Dogfooding
• Everyone can contribute

As such, everyone in the department should be familiar with, and be acting upon, the following statements:

• We should all feel comfortable contributing to the GitLab open source project
• If we need something, our first instinct should be to get it into the open source project so it can be given back to the community
• Try to get it in the open source project first, rather than later, even if it’s 2x harder
• We should be using the whole product to do our jobs
• We are all familiar with our Dogfooding process and follow it
• We should not expect new team members to join the company with these instincts, so we should be willing to teach them
• It is part of managers’ responsibility to teach these values and behaviors

組織構造

(詳細はボックスをクリックしてください)

flowchart LR
    I[Infrastructure Platforms]
    click I "/handbook/engineering/infrastructure-platforms/"

    I --> DE[Developer Experience]
    click DE "/handbook/engineering/infrastructure-platforms/developer-experience/"

    I --> GD[GitLab Dedicated]
    click GD "/handbook/engineering/infrastructure-platforms/gitlab-dedicated/"
    I --> PRODENG[Production Engineering]
    click PRODEND "/handbook/engineering/infrastructure-platforms/production-engineering/"
    I --> SD[GitLab Delivery]
    click SD "/handbook/engineering/infrastructure-platforms/gitlab-delivery/"
    I --> TS[Tenant Scale]
    click TS "/handbook/engineering/infrastructure-platforms/tenant-scale/"

    PRODENG --> NIM[Networking & Incident Management]
    click NIM "/handbook/engineering/infrastructure-platforms/production-engineering/networking-and-incident-management/"
    PRODENG --> Runners[Runners Platform]
    click Runners "/handbook/engineering/infrastructure-platforms/production-engineering/runners-platform/"
    PRODENG --> Observability
    click Observability "/handbook/engineering/infrastructure-platforms/production-engineering/observability/"
    PRODENG --> Runway
    click Runway "/handbook/engineering/infrastructure-platforms/gitlab-delivery/runway/"
    PRODENG --> CCU[Cloud Cost Utilization]
    click CCU "/handbook/engineering/infrastructure-platforms/production-engineering/cloud-cost-utilization/"

    DE --> DevA[Development Analytics]
    click DevA "/handbook/engineering/infrastructure-platforms/developer-experience/development-analytics/"

    DE --> DT[Development Tooling]
    click DT "/handbook/engineering/infrastructure-platforms/developer-experience/development-tooling/"
    DE --> PER[Performance Enablement]
    click PER "/handbook/engineering/infrastructure-platforms/developer-experience/performance-enablement/"
    DE --> TG[Test Governance]
    click TG "/handbook/engineering/infrastructure-platforms/developer-experience/test-governance/"

    GD --> E[Environment Automation]
    click E "/handbook/engineering/infrastructure-platforms/gitlab-dedicated/environment-automation/"
    GD --> PSS[Public Sector Services]
    click PSS "/handbook/engineering/infrastructure-platforms/gitlab-dedicated/us-public-sector-services/"
    GD --> Switchboard
    click Switchboard "/handbook/engineering/infrastructure-platforms/gitlab-dedicated/switchboard/"

    SD --> B[Build]
    click B "/handbook/engineering/infrastructure-platforms/gitlab-delivery/distribution/"
    SD --> Operate
    click Operate "/handbook/engineering/infrastructure-platforms/gitlab-delivery/operate/"
    SD --> R[Release and Deploy]
    click R "/handbook/engineering/infrastructure-platforms/gitlab-delivery/delivery/"

    TS --> DA[Data Access]
    click DA "/handbook/engineering/infrastructure-platforms/data-access/"

    DA --> TSV[Tenant Services]
    click TSV "/handbook/engineering/infrastructure-platforms/tenant-scale/tenant-services/"
    DA --> Git
    click Git "/handbook/engineering/infrastructure-platforms/tenant-scale/git/"
    DA --> Gitaly
    click Gitaly "/handbook/engineering/infrastructure-platforms/tenant-scale/gitaly/"

    TS --> RT[Runtime]
    click RT "/handbook/engineering/infrastructure-platforms/tenant-scale/"
    RT --> Organizations
    click Organizations "/handbook/engineering/infrastructure-platforms/tenant-scale/organizations/"
    RT --> CI[Cells Infrastructure]
    click CI "/handbook/engineering/infrastructure-platforms/tenant-scale/cells-infrastructure/"
    RT --> Geo
    click Geo "/handbook/engineering/infrastructure-platforms/tenant-scale/geo/"

ドッグフーディング

Infrastructure Platforms 部門は、GitLab.com を含む多くの 環境 を運用するためのメインツールとして、GitLab および GitLab の機能を広範に使用しています。

私たちはエンジニアリングファンクションの一部として、同じ ドッグフーディングプロセス に従いつつ、部門のミッションステートメント を主要な優先順位ドライバーとして維持しています。優先順位付けのプロセスは エンジニアリングファンクションレベルの優先順位付けプロセス と整合しており、Infrastructure Platforms 部門が行う他の技術的決定に対してドッグフーディングの優先度がどこにあるかを定義しています。

GitLab.com を運用するためのツールを構築することを検討する際、5x ルール に従って、GitLab の機能としてツールを構築するか、GitLab の外で構築するかを決定します。GitLab 製品への Infrastructure のコントリビューションを追跡するために、それらの Issue に適切な ドッグフーディング ラベルを付けます。

Infrastructure Platforms 部門でのハンドブック使用

GitLab では、ハンドブックファーストのポリシー を掲げています。これは、プロセス変更を伝達する方法であり、毎日提供される作業の信頼できる単一の情報源を構築する方法です。

ハンドブック使用ページガイド には多くの一般的なヒントが掲載されています。Infrastructure Platforms 部門で最も頻繁に遭遇するものをハイライトします。

1. より広いコミュニティは、トレーニング資料、アーキテクチャ図、技術ドキュメント、ハウツーのドキュメントから恩恵を受けることができます。この詳細情報には、関連するプロジェクトドキュメントが良い場所です。ハンドブックページは高レベルの概要を含み、プロジェクトドキュメント内に置かれたより詳細な情報にリンクします。
2. ハンドブック内の資料を消費するオーディエンスについて考えてください。ハンドブック内の GitLab.com 運用ランブックの詳細なウォークスルーは、Self-Managed ユーザーには適用されない情報を提供する可能性があり、混乱を引き起こす可能性があります。さらに、ハンドブックは運用情報の頼りになる場所ではなく、運用情報を一箇所にまとめて、参照としてリンクを使って一般的なコンテキストを説明することで、可視性が向上します。
3. ハンドブックページが消費しやすいものになるようにしてください。チェックリスト、オンボーディング、繰り返し可能なタスクは、自動化されるか、ハンドブックからリンクできるテンプレートの形で作成されるべきです。
4. ハンドブックがプロセスです。ハンドブックは私たちの原則を記述し、エピックや Issue は私たちの原則を実践に移したものです。

プロジェクト

Infrastructure Platforms 部門のプロジェクトの分類は、インフラストラクチャ部門プロジェクトページ に記載されています。

インフラストラクチャ Issue トラッカー は、インフラストラクチャチームのバックログおよびキャッチオールプロジェクトであり、進行中の変更やインシデントとは無関係に、私たちのチームが行っている作業を追跡しています。

バックログの追跡に加えて、Infrastructure Platforms 部門のプロジェクトは Infrastructure Platforms 部門エピック および 四半期の目標と主要結果 に取り込まれています。

設計

Infrastructure Library には、私たちが解決している問題に関する考えをまとめたドキュメントが含まれており、あらゆるトピックの 現在の状態 を表現し、私たちが直面する課題に対応するための技術的ソリューションを生み出す上で重要な役割を果たします。

テクニカルロードマップ

Infrastructure は、短期 (1年)、中期 (2年)、長期 (3年) のプロジェクト計画のための テクニカルロードマップ を維持しています。 これは私たちの戦略的な羅針盤として機能し、 即時のニーズと長期的な持続可能性のバランスを取るのに役立ちます。

テクニカルロードマップは プロダクトロードマップ に基づいており、 プロダクトが「何を」(顧客のニーズ) および「なぜ」(ビジネス戦略) を提供します。 そしてエンジニアが「どのように」(技術的実装) を決定し、 エンジニアリングマネージャーは「いつ」(スケジューリング) を計画します。 この包括的なロードマップは、持続可能な方法で高品質で完全な機能を構築することを重視しています。

テクニカルロードマップには3つの重要な目的があります。

1. プロダクトバックログに表れない可能性のある重要な領域に対処することで、エンジニアリングの卓越性を構築するのに役立ちます。 例えば技術的負債、パフォーマンス改善、プラットフォーム改善、システムのスケーラビリティなどです。

2. 部門がリアクティブではなくプロアクティブであることを可能にします。 「システム内で最も大きな不安定性がどこにあるか?」や 「最も多くの労役を生み出しているのは何か?」といった重要な質問を定期的に問うことで、 問題が深刻になる前に対処できます。 これにより SLO を維持し、お客様の満足度を保つのに役立ちます。

3. エンジニアリングの取り組みをビジネス目標と整合させ、技術的改善が GitLab の成功を推進するようにします。 各テクニカルロードマップ項目は、ビジネス価値と戦略的整合性に基づいて優先順位付けされます。

現在の状態

Infrastructure ロードマップは静的サイトとして維持されています。 GitLab チームメンバーは、現在のテクニカルロードマップを infra-roadmap.gitlab.com で確認できます。

注意: Infrastructure ロードマップは公開されていません。一部のプロジェクトと イニシアチブが unSAFE と見なされる場合があるためです。

このサイトはロードマップを視覚的に提示し、以下を表示します。

• 計画されたイニシアチブ間の依存関係
• 確信度、ステージ、タグによるフィルタリングオプション
• 部門内の各ステージの個別ロードマップ
• 依存関係の可視化を通じたインパクト分析

ロードマップの更新

ロードマップへの変更は、infra-roadmap プロジェクトへのマージリクエストを通じて行います。 データは YAML 形式で保存されており、YAML を編集することで変更できます。 これにより、マージリクエストプロセスを通じてバージョン管理と協力的な議論が可能になります。

Infrastructure ロードマップの変更方法の完全な手順は、 プロジェクトの README.md で利用可能です。

新しいイニシアチブの提案や、説明の更新や関連 Issue へのリンクの追加といった 小さな変更まで、すべての人にロードマップへのコントリビューションを推奨しています。

プロダクト機能のサポート

私たちはプロダクト機能のサポートに役立つモデルを持っています。このモデル は、本番環境に新しい機能を出荷するためにどう協力するかの詳細を提供します。

私たちの働き方

私たちは GitLab バリュー、プロジェクト管理 プロセス、および AI 利用原則 に従います。

コミュニケーション

Slack

私たちのコミュニケーションの主な方法は Slack です。

本番環境の問題またはインシデントについて支援が必要な場合は、サポートの取得 のセクションを参照してください。

SaaS Platforms

Dedicated

Delivery

Production Engineering

Tenant Scale

SaaS Platforms グループは、ヘルプリクエストを徐々に #infrastructure-platforms Slack チャンネルに振り向けています。 このチャンネルは、質問をどの Infrastructure チームに向けるべきかが不明確な場合に使用できます。 詳細については、サポート取得のランディングページ を参照してください。

#infrastructure-platforms チャンネルは、SaaS Platforms のエンジニアリングマネージャーと Staff+ エンジニアによって監視されており、チームメンバーはあらゆる受信リクエストをトリアージします。このチャンネルをトリアージする際、その質問に最も答えられるチームを見つけ、リクエスター（要求者）にそのチームの優先連絡方法でそのチームに連絡するよう指示する必要があります。リクエスターが適切なチームにつながったら、メッセージに緑のチェック絵文字を追加します。最後に、必要に応じて サポートの取得 ページを変更点で更新します。

ミーティング

週に1度、Platforms leads call を開催し、キャリア開発に関するアクションアイテムを整合させ、一般的な方向性、または非同期で対応されていない進行中の質問に答えます。当日朝にトピックが追加されていない場合、コールはキャンセルされます。

Platforms leads call に加えて、SaaS Platforms リーダーシップカレンダー で見られる定期的なイベントとリマインダーがあります。これをカレンダーに追加して、さまざまなイベントの最新情報を入手してください。

インフラストラクチャのシニアディレクター、Marin Jankovski は、組織に参加した新しいチームメンバーと会うのを好みます。Marin はお互いを知り、チームメンバーがどのようにしているかを確認するために、毎月数回、新しいチームメンバーと非公式な 1:1 のコーヒーチャットをセットアップします。このプロセスはその EBA によって組織され、彼が会う余裕がある場合にチームメンバーに連絡します。チームが大きいため、全員回るには時間がかかる可能性があります。 コーヒーチャットがスケジュールされている時より早く Marin に会う必要がある場合は、その EBA Liki Simonot に連絡してセットアップしてください。

Grand Review

各ステージのエンジニアリングリードとチームメンバーのプロダクトマネージャーは、グループの進捗状況を評価し、プロジェクトの最新情報を共有し、ブロッカーを解決し、勝利を祝うために、毎週進捗レビューを開催します。さらに、プロダクトのディレクターと Infrastructure Platforms のシニアディレクターは、これらのグループレベルのミーティングのサマリーを確認する、より高いレベルのリーダーシップレビューを実施します。

週次スケジュール

• 水曜日 (またはチームに設定されている日に応じて): 各エピック DRI が 進捗の更新についてメンションするノート を受け取ります。更新は短くし、以下を含めます:
  • 高レベルでビジネス指向の観点からの新しい達成事項。グラフ、デモ、可視化も歓迎です。
  • リスク、ブロッカー、タイムライン、スコープの変更、および助けが必要かどうかまたは FYI として表面化することなど
  • 行われた新しい重要な決定
• 完了したプロジェクトは、エピックの説明にクロージングサマリーのハイライト を含めます。エピックはオープンのままにし、In Progress ラベルを付けます。これらのエピックは Grand Review でクローズされます。
• 木曜日: グループレベルのレビューが実施され、Infrastructure Platforms トップレベルエピック にスレッドとして追加されます (例 を参照)
  • Data Access: Data Access の代行シニア EM とグループ PM が運営
  • Tenant Scale: Tenant Scale のシニア EM とグループ PM が運営
  • Production Engineering: Production Engineering のシニア EM とグループ PM が運営
  • Software Delivery: Software Delivery の代行シニア EM とグループ PM が運営
  • Developer Experience: Developer Experience のディレクターとプロダクトマネージャーのローテーションが運営
  • Dedicated: Dedicated ディレクターとグループ PM が運営
• 金曜日: リーダーシップレビュー。Infrastructure Platforms のシニアディレクターと Infrastructure Platforms プロダクトのディレクターが運営。Infrastructure Platforms トップレベルエピック にスレッドとして追加されたグループレベルのサマリーをレビューし、その後、包括的なプロジェクトカバレッジを確保するために特定のグループの深掘りを実施。
• 金曜日: グループレベルとリーダーシップレベルのレビューが一緒に #infrastructure_platforms にリリースされます

レビューは機密の問題をカバーするため、GitLab Unfiltered チャンネルへプライベートでストリーミングされます。すべての録画は Platforms Grand Review YouTube プレイリスト で利用可能です。

Infrastructure Platforms Leads Demo

Infrastructure Platforms Leads Demo は、Infrastructure Platforms グループ全体の Staff+ IC が、サポートするチームで進行中の現在の取り組みをハイライトする同期ディスカッションの機会です。 すべてのチームメンバーがコールに参加できますが、強調は Staff+ IC がチームメンバーが集中している作業、経験している問題、検討している解決策を発表し議論することにあります。

コールは Infrastructure Platforms Leads Demo Unfiltered プレイリスト に録画されます。アジェンダは Google Docs にあります。

GitLab Unfiltered でコールをパブリックにする意図はありますが、デフォルトではプライベートとして公開されます。 コールの終わりに、出席者間で迅速な投票が行われ、コンテンツが #SAFE であるとすべて合意した場合、パブリックとして公開できます。

SaaS Health Review

Infrastructure Platforms のエンジニアリングマネージャーは、SaaS Health に関する定期的なコールをリードします。詳細については、SaaS Health Review ページ をご覧ください。

ヘルプリクエスト

サポート取得のランディングページ では、支援が必要なチームメンバーに、標準テンプレートを使用してヘルプリクエストを上げるよう依頼します。

これらの Issue は ヘルプリクエスト Issue トラッカー に上げられ、関連する SaaS Platforms チームのエンジニアリングマネージャーに自動的に割り当てられます。

エンジニアリングマネージャーは以下を期待されます:

1. 質問が重複でないことを確認し、質問への回答がハンドブックまたはトラッカー自体にまだ発見できないことを確認します。
2. リクエストの緊急性を確認します。
3. ヘルプリクエストに応答するか、エンジニアにリクエストの対応を割り当てます。

Slack と GitLab Issue トラッカーの統合

インフラストラクチャチームに向けられたリクエストの追跡と解決を強化する取り組みとして、#infrastructure_lounge チャンネル内の Slack メッセージを GitLab Issue に変換するボットを評価しています。

ワークフロー概要

• 確認応答: エージェントが Infrastructure Lounge チャンネルの Slack メッセージを確認応答するために acknowledged_emoji (私たちのケースでは 👀) で応答します。
• Issue 作成: Slack ボットは、確認応答するエージェントが割り当てられた Issue を作成します。
• スレッドアタッチ: メッセージに対応する Slack スレッドも、作成された GitLab Issue に投稿されます。
• ラベル割り当て: エージェントは Slack メッセージにラベル絵文字 (ops、foundations、observability) を追加することで Issue をさらに分類できます。このアクションは、Issue をそれぞれのチーム: Ops、Foundations、Observability に自動的に割り当てます。
• プロジェクト追跡: これらの変換された Issue は、Infrastructure Lounge Slack Issue Tracker でホストされる専用プロジェクトの下で追跡されます。
• Issue クロージャ: エージェント／要求者は、resolved_emojis (私たちのケースでは green-circle-check、white_check_mark または checked) のいずれかを追加することで解決時に Issue をクローズできます。

設定

これらの Issue の処理を担当するエージェントは JSON ファイルで定義されており、これは CI/CD 変数 として機能します。現在、このファイルにはインフラストラクチャ部門のすべてのメンバーの静的リストが含まれています。

プロジェクトとバックログ管理

私たちは作業を管理するためにエピックと Issue を使用します。私たちのプロジェクト管理プロセス は SaaS Platforms のすべてのチームで共有されています。

ツール

Platforms セクションは、SaaS プラットフォームのデプロイ、運用、モニタリングを支援するさまざまなツールを構築および保守しています。これらのツールのリストは Platforms ツールインデックス で確認できます。

OKR

私たちは GitLab の OKR に整合する目標を設定するために、目標と主要結果を使用します。 私たちの OKR プロセス は SaaS Platforms のすべてのチームで共有されています。

採用と面接

私たちの採用プロセス は Infrastructure Platforms のすべてのチームで共有されています。

この Infrastructure Platforms 面接ガイド は、定期的に開いているポジションのいくつか、面接プロセス、当社の仕事への応募に関連するその他の有用な情報の詳細を提供します。現在の求人に関する詳細情報は、キャリアページ で確認できます。

Platforms 学習パス

すべてのチームメンバーが、個人開発のための時間をスケジュールすることを推奨されます。次のリンクは、Platforms 関連の学習を開始するのに役立つかもしれません。他者の個人開発に役立つよう、このリストに独自のコントリビューションを追加してください。

Infrastructure Platforms とそのグループについて学ぶ

Platforms 内で使用されているツールとテクノロジーについて学ぶ

1. Jsonnet チュートリアル

共通リンク

• GitLab.com のインシデント管理の方法
• GitLab.com ステータス情報

その他の Slack チャンネル

• #production
• #infrastructure_platforms
• #incidents
• #announcements
• #feed_alerts-general

一般的な Issue トラッカー

• Production Engineering Issue キュー
• 本番インシデントと変更
• Release and Deploy
• Observability
• Tenant Scale
• Runway

リソース

• 本番アーキテクチャ
• 運用ランブック
• 環境
• モニタリング
• Readiness レビュー
• Infrastructure Platforms 標準
• Infrastructure Platforms のキャリア開発とインターンシップ

その他のページ

• オンコール引継ぎ
• オンコールシャドウイング
• SRE オンボーディング
• SRE オンコールオンボーディングバディ
• GitLab.com データ侵害通知ポリシー
• スケールでのコーディング

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