Gitaly チーム

Gitaly とは何か？

Gitaly チームは、GitLab インスタンスの Git データストレージ層、特に GitLab.com が、信頼性が高く、安全で高速であることを確保するためのシステムを構築・保守する責任があります。Gitaly の詳細については、リポジトリの README と以下のロードマップを参照してください。

チームには、お客様に信頼性が高く、スケーラブルで高速なデータストレージを提供するために協力しているバックエンドエンジニアと SRE が含まれています。

機能的な境界

GitLab は Gitaly プロジェクトの主なコンシューマーですが、Gitaly は GitLab 外部でも使用できるスタンドアロンの製品です。そのため、Gitaly の周りに機能的な境界を達成しようとしています。目的は、Gitaly プロジェクトが Git データを管理するためのインターフェースを作成するが、データをどのように管理するかについてビジネス上の決定を行わないことを確保することです。

例えば、Gitaly はストレージソリューション間で Git リポジトリを移動するための堅牢で効率的な API セットを提供できますが、そのような移動がいつ発生すべきかを決定するのは呼び出し側のアプリケーションの役割となります。

ビジネスの入力とは完全に独立したプロセス（リポジトリのメンテナンスなど）は、Gitaly プロジェクトを使用するすべての人に実質的な価値を提供するため、Gitaly 内に完全に含まれるべきです。

ロードマップ

公開されている Gitaly の製品方向性をご覧ください。

ロードマップを駆動するビジョンと原則は、内部ハンドブックにあります。

現在のロードマップはこの Epic ボードです。管理方法については以下のロードマッププランニングを参照してください。

注目すべき今後の大規模アーキテクチャ変更

安定したカウンターパート

以下の他の機能チームのメンバーが私たちの安定したカウンターパートです:

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

チームへのお問い合わせ方法

緊急 Issue と停止

サポート組織の一員でない場合は、まずサポートに助けを求めることを検討してください。サポートはより良いアベイラビリティを持ち、ほとんどの一般的なケースで対応できます。

それでも助けが必要な場合は、こちらで Issue を提起してください。即座の可視性のために #g_gitaly に投稿し、EM と PM、および一緒に作業しているサポート担当者、そして Gitaly のオンコールチームメンバーに通知するために @tier2-oncall-gitaly にタグ付けしてください。

オンコールローテーション

Gitaly のオンコールは、以下の人々からのみ連絡を受けるべきです:

  • 本番インシデント時のみ SRE オンコールまたは IMOC。
  • お客様の緊急事態時のみ サポートエンジニアまたはサポートマネージャー。

これらのケースには Slack で /incident escalate を使用し、「On-call teams」の下の Gitaly EOC を選択してください。 その他のすべてのケースは カスタマー Issue の下で Issue を提起してください。

これらのケース以外ではオンコールに連絡しないでください。お客様の緊急事態を取り組んでいるがサポートの一員でない場合は、代わりにサポートに連絡してください！

ローテーション

incident.io スケジュールがオンコールの担当者の情報源です。

ローテーションはチームメンバーの業務時間中にスタッフされます（週末なし）。チームメンバーの分布を考慮すると、保証なしで平日の 24 時間をカバーします。

  • 週末は明示的に対象外（スタッフなし）であり、エスカレーションは現在の EOC ローテーションにフォールバックする必要があります。
  • 業務時間中のみの責任であるため、明示的に指定されない限り追加の報酬はありません。
  • シフト後に Workday で the On-Call Time in Lieu オプションを選択することで代替休暇を取得できます。
オンコールシフト中の期待事項
  • 合理化されたオンボーディングプロセスについてはレスポンダークイックスタートガイドを参照してください。 注意: Gitaly チームへのすべてのエスカレーションは incident.io を通じて行われます
  • オンコール中の incident.io からの連絡に対して 15 分の応答時間。これは @tier2-oncall-gitaly Slack ハンドルへの ping には適用されません。これは Gitaly のオンコール担当者に関連する出来事を通知するために使用すべきですが、緊急事態には使用すべきではありません。
    • オンコールは_利用可能で連絡可能_であることが期待されます（必ずしも積極的に作業している必要はありませんが、この SLO 内に調査を開始できる状態であること）。
    • シフト終了の 15 分未満前に連絡を受けた場合でも、応答してインシデントを明示的に引き継ぐ必要があります。
  • #g_gitaly チャンネルでの質問と新しいサポートリクエスト Issue の連絡先として機能する。
    • #g_gitaly チャンネルでのお問い合わせにベストエフォートベースで対応する。
    • 新しいサポートリクエスト Issue のトリアージ: 緊急度を確立し、EM/PM と協力してマイルストーンを割り当てる。
  • 継続的な本番インシデントとお客様エスカレーションは、退任するオンコールから Slack のインシデントチャンネルを使用して次の Gitaly のオンコール担当者に明示的に引き継がれます。
  • チームメンバーは PTO と祝日のカバレッジを見つける責任があります。incident.io モバイルアプリケーションをインストールし、Schedules に移動して人アイコン（矢印付き）をクリックしてカバーをリクエストしてください。
  • サポートによって連絡を受けた長時間のお客様緊急コール中に、Issue が Gitaly から外れ、あなたの専門知識が積極的に必要でなくなった場合は、サポートエンジニアに積極的に離席できるか確認してください。受動的に監視を続けることができ、Gitaly の関与が再び必要になった場合は再度参加できます。

カスタマー Issue

こちらで Issue を提起してください。即座の可視性のために #g_gitaly に投稿してください。

お客様エスカレーションと関与に関する注記

お客様が必要とするときは喜んでお手伝いします！ただし、私たちは主に_開発_チームであり、「フィールドエンジニアリング」に対応できるわけではありません。

私たちの_エンジニア_は、できれば非同期で次のことをお手伝いできます:

  • サポートおよび CSM との緊密なパートナーシップの中で、_データ_に基づいた深い技術調査と優れた技術的なコラボレーション
  • 製品レベルの修正または改善の提供、EM と PM の指揮の下で通常どおりスケジュールされて結果がリリースされる作業
  • 何かが不明な場合のドキュメントの改善

エンジニアリングマネージャー（@jcaigitlab）と_プロダクトマネージャー_（@mjwood）は、ロードマップ、製品機能とタイムラインの明確化が必要な場合や、正しい優先順位付けを確保するためにお客様と関わることも喜んでいます。

ただし、以下の場合は適切ではありません:

  • セルフホスト環境での GitLab インスタンスの設定またはアーキテクチャに関するアドバイス（リファレンスアーキテクチャとプロフェッショナルサービスが対応できます）
  • 明確な終了基準のない関与（まず明確にしてください。「話し合うために電話しましょう」は通常このカテゴリに該当します）
  • 長期的な「アドバイスをください」シナリオ（サポートとドキュメントを参照するか、プロフェッショナルサービスをご利用ください）

このEpic では、この関与モデルの開発の可能性について議論しています。

通常優先度のリクエスト

Gitaly チームに何かを取り組んでもらうには、Gitaly Issue トラッカーで Issue を作成し、group::gitaly と workflow::problem validation ラベル、およびその他の適切なラベルを追加するのが最善です。その後、上記にリストされている関連するプロダクトマネージャーおよび/またはエンジニアリングマネージャーをタグ付けしてください。

情報リクエストやその他の簡単な一回限りのことについては、Issue に注意を向けるために Slack の #g_gitaly を気軽にご利用ください。

Infradev ラベルが付いた Issue

これらは通常、厳格な SLO 追跡を持つ是正措置またはその他のフォローアップ項目です。EM および/または PM がこれらのダッシュボードをポーリングすることで、上記いずれかのパスを通じてスケジュールされます。

トレーニング資料

ローター管理

メカニクス（オンコールの交換、ローテーションへの新しいチームメンバーの追加）については https://handbook.gitlab.com/handbook/engineering/on-call/#pagerduty を参照してください。

チームメンバー

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

プロダクトとの連携

Gitaly のアジャイルワークフロー

一般的に、製品開発フローに従って作業をスケジュールおよび追跡します。

作業は小さなチャンク（2〜3 日の作業）で実行され、それぞれが Issue として追跡されます。これにより、安全なコンテキスト切り替えのための自然な「チェックポイント」が可能になります。 トリアージとスケジューリングは、現在の作業の実行とは別です。すべての受信作業が追跡され、新しい作業を選ぶことについて意図的です。

すべての種類の受信作業（プロジェクトと臨時の割り込みの両方）は、EM と PM のトリアージを通過します。実現可能性、製品の戦略的ロードマップとの適合性などについてエンジニアリングの相談がある場合があります。一部はスケジュールされ、一部はバックログに移ります。その取り組みが必要でないか、ロードマップと整合していないと判断された場合は、将来の参考のためにクローズされる理由のコメント付きで Issue をクローズします。

マイルストーンのスコープを、意欲的だが圧倒的でないタスクリストになるように設定することを目指しています。受信インシデントのためにある程度の余裕を意図的に残します。 作業の終わりなき山という感覚を避けるために、健全なワーク/ライフバランスを促進します。 マイルストーンはあくまで推奨であり、ベストエフォートベースで作業することを強調することも重要です。

厳格な SLO を持つ Issue については、以下で定義されたプロセスに従います

Issue では次のワークフローラベルを使用します:

  1. workflow::problem validation - 追求するかもしれない/しないかもしれない機能を置くのに良い場所。これはプロダクトがユーザーインタビュー、コスト分析、市場適合性などを行い、追求する機会であるかどうかを決定できる場所です。
  2. workflow::solution validation - エンジニアリングが将来のソリューションを調査/提案する必要がある機能/Issue、またはより小さな Issue に分解する必要がある機能/Issue にこのラベルを使用します。
  3. workflow::planning breakdown - 次のいくつかのマイルストーン（ブロックされていないか間もなくブロック解除される予定で、既知のソリューションがある）でスケジュールする準備ができている Issue。長期実行（事前承認済み）プロジェクトのリーダーはこれを使用して PM とコミュニケーションを取ります。
  4. workflow::ready for development - マイルストーン（現在または将来）にスケジュールされた作業。
  5. workflow::in dev - エンジニアリングチームが積極的に作業中
  6. workflow::in review - レビュー中の作業
  7. workflow::verification - コードが本番環境にあり、DRI エンジニアによる検証待ち
  8. workflow::complete - 変更が検証されており、Issue をクローズできる

確実にリリースに向けて優先したい Issue には Deliverable ラベルが付けられ、リストの上部に移動されます。 これらの Deliverable Issue は、これらの Issue に取り組むことに関して GitLab とお客様へのコミットメントを示す手助けになります。

ワークフロー

プロジェクト作業

Gitaly の最上位 Epic にはチームが取り組んでいるプロジェクトを表すリンクされた Epic が含まれています。チームメンバーは Epic の主要オーナーまたは サポート貢献者のいずれかになります。これにより、チーム全体で知識が共有されます。

DRI とサポート貢献者

Epic の DRI は、プロジェクトの技術的方向性に関する決定を行う責任を負います。決定を行うことには、提案を作成し、同僚およびエンジニアリングマネージャーからのフィードバックを集めることが含まれます。また、該当する場合にはチーム外のステークホルダーと連絡を取り協力することも含まれます。

DRI はまた、プロジェクトマネジメントの責任も負います。これは Epic を関連する Issue で最新の状態に保ち、もはや関連のない Issue を削除し、次の形式で Epic の自動生成コメントに週次更新を書くことを意味します:

HIGH_LEVEL_SUMMARY

:tada: **achievements**:
-

:issue-blocked: **blockers**:
-

:arrow_forward: **next**:
-

Epic のサポート貢献者は、Issue への取り組み、MR のレビュー、技術的なディスカッションへの参加において DRI をサポートする責任があります。セカンダリオーナーは DRI が不在の場合（バンド幅に応じて）主要オーナーとして代理を務めることもできます。

サポート貢献者は強く推奨されますがオプションです。プロジェクトに複数のセカンダリオーナーがいることもあります。

全員が DRI である必要はありませんが、全員が少なくとも 1 つのプロジェクトのサポート貢献者であるべきです。

DRI とサポート貢献者の両方を持つ構造は、レビューと承認はチームの誰でも行えるため、MR を前進させるための厳格な要件を導入しません。

テクニカルロードマップ、カスタマー Issue、クロスファンクショナル Issue

Gitaly テクニカルロードマップ & カスタマー Issue ボードには、プロジェクトの一部ではないが、対処することが重要な一回限りの Issue が含まれています。これにはテクニカルロードマップIssue、カスタマー Issue、および他のチームが依存する Gitaly のクロスファンクショナル作業が含まれます。これらの Issue は優先度でソートされます。チームメンバーはプロジェクト Epic の一部として取り組んでいる Issue に加えて、このボードから作業を選ぶことができます。

経験則として、プロジェクト作業とテクニカルロードマップ、カスタマー Issue の比率はおよそ 70/30 であるべきです。

緊急と高優先度の Issue

P1/S1 の Issue は緊急に対処すべきです。そのような Issue がまだスケジュールされていない場合は、行動バイアスが奨励されます。 現在のマイルストーンに引き込んでいきますが、EM と PM に通知してください。

ブロックされた Issue

作業がブロックされている場合は、workflow::blocked を使用し、明確にするためにブロッキング Issue を設定してください。その後、他のものを選ぶ前に助けを求め、および/または他のチームメンバーのブロックされた作業のブロック解除を手伝うことを検討してください。

長時間ブロックされた Issue は、マイルストーンを削除して割り当てを解除することでこのプロセスから削除する必要があります。

チームへの作業追加

誰でも、より多くの作業が発見された際に新しい Issue を提起し、このプロセスに取り込むことができます。そのためには、Issue を提起し、EM と PM にタグ付けし、マイルストーンなしで workflow::planning breakdown を割り当ててください。実行する必要がある_内容_と_理由_（つまり、影響と緊急性）の両方を説明し、作業を選ぶ準備ができているかどうかを明確にしてください。（これは、プロジェクト DRI がプロジェクトの次のステップをワークフローに追加する方法でもあります。）

メタ

プロダクトマネージャーとエンジニアリングマネージャー（Gitaly と Git チームの両方）の間で週次の通話が行われます。誰でも参加歓迎であり、これらの通話はグループに影響を与えるブロッカー、懸念事項、状況更新、成果物、またはその他の考えを議論するために使用されます。

ロードマッププランニング

現在のロードマップはこの Epic ボードです。四半期以上継続するテーマ/プロジェクト（場合によってははるかに長い）で構成されています。後者の場合、サブプロジェクトをロードマップに直接追加することは許容されます。

  • 誰でもプロジェクトを提案できます: Epic を提起してチーム（および EM+PM）とディスカッションしてください。group::gitaly ラベルをお忘れなく。
  • 承認されたら、Roadmap ラベルを追加します。
  • 継続中のロードマップ項目は roadmap::now を取得し、roadmap::next と roadmap::later は現在のところトリアージされて将来に押し出されたものを示します。
  • 四半期ごとのプランニングでは:
    • ロードマップ項目をレビューします（ビジョンと原則からの議論、現在のビジネス優先事項などを使用）
    • そして、それらの目標を前進させる OKR を採用します。

四半期プランニング

四半期プランニングは、全員のインプットを得ながら次の 3 マイルストーンについて毎四半期の前に行われます。その時点では、実行する必要がある作業についての良いアイデアがすでに必要です。

プロセスは次のとおりです:

  1. EM+PM（エンジニアとステークホルダーのインプットを受けて）: 部門レベルの OKR と整合した作業スコープを決定します。

  2. EM+PM+エンジニア: ロードマップ項目に基づき、3 マイルストーン（つまり 1 四半期）で完了できるより小さな Epic/Issue を必要に応じて提起します。全体的なプロジェクト Epic に紐づけます。これは実際の作業を追跡する場所です。

  3. EM: Gitaly 最上位 Epicを変更して作業を反映させます。

  4. PM: 四半期のスコープが明確になったら、Issue のリストを取得し、3 つのマイルストーンのうち 1 つを割り当て、分解が必要な大きな Issue については workflow::planning breakdown（または workflow::ready for development）を割り当てます。

  5. エンジニア: workflow::planning breakdown 項目を分解し、必要に応じてより小さな Issue を提起して、合理的な範囲で同じ 3 マイルストーンに追加します。必要に応じて例外を提起します。

厳格な SLO を持つ Issue の処理

Infradev ラベルが付いた Issue は通常、厳格な SLO 追跡を持つ是正措置またはその他のフォローアップ項目です。これらは上記いずれかのパスまたは EM によってスケジュールされます。

  1. EM+PM: 少なくとも週次でダッシュボードをポーリングします。SLO を満たせるようにこれらの Issue をトリアージしてスケジュールします。必要に応じて、Issue を Gitaly トラッカーに移動するか、作業ボードに表示されるようにプロキシ Issue を提起して、ブロッキングとしてマークします。workflow::ready for development 列の上部に Issue をドラッグします。

  2. EM+PM: Issue がブロックされているか進行中の作業に依存している場合は、SLO と保留中の作業に合ったマイルストーンを追加します（忘れないように）。ブロッキング作業が先にスケジュールされることを確保します。

  3. エンジニア: この作業を優先的に選んでください。元の Issue に頻繁（最大週次、変更がなくても）の更新を投稿してください。ブロッキング Issue はそのようにマークしてください。

Gitaly のコンシューマー

計画された変更、更新、破壊的な変更の可能性についての常時コミュニケーションフローを確保するために、#g_gitaly Slack チャンネルがあります。チャンネルでは、サービスを使用するすべてのチームに更新を提供しますが、計画された変更または改善についてのフィードバックと洞察を提供するための支援も求めます。

このプロアクティブなコミュニケーションをさらに支援するために、コードベースの調査と Gitaly を使用するすべてのチームとの調整を支援するためのコンシューマー側の個別のカウンターパートもあります。コンシューマー側の DRI は Igor Drozdov です。

Gitaly のコンシューマーは:

Gitaly の非推奨

Gitaly は多くのお客様向け機能を提供しています。そのため、お客様向け機能のすべての非推奨は、標準の GitLab 機能非推奨ガイダンスに従い、非推奨ドキュメントページ内で告知されます。

Gitaly はまた、GitLab や Gitaly と直接インターフェースする他のお客様が使用する、多くの非お客様向け機能も提供しています。これらの Gitaly レベルの非推奨は、GitLab エンドユーザーが直接インターフェースするように設計されていないため、上記の方法を使用して告知されません。これらの非お客様向け機能の例として、GitLab ユーザーが呼び出すべきでないストレージレベル API があります。

メトリクス

gitlab.com 上での

チーム開発

オンボーディング

チーム固有のオンボーディングを完了するには、こちらで Issue を提起してください。

オフボーディング

メインテナー権限が取り消され、承認済み承認者リストから開発者を削除するには、gl-gitaly GitLab.com グループから削除してください。

Gitaly サービスのデバッグ
このドキュメントについて このドキュメントは Gitaly エンジニア向けに作成されており、GitLab の本番環境のレイアウトを把握し、本番環境の問題を効果的にデバッグする能力を身につけることを目的 …
最終更新 May 6, 2026: Merge pull request #100 from kyama0/fix/upload-images-tolerate-upstream-missing (70970e1a)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License