データベースヘルプワークフロー
データベース関連のインシデントや緊急事態でヘルプを要請するための基本的なワークフロー
Data Access サブ部門
ビジョン
Data Access サブ部門は、顧客のニーズと GitLab のビジネス目標に沿って、GitLab のユーザーデータへのアクセスの持続可能性と可用性に責任を持ちます。
ユーザーデータの範囲には、Git、PostgreSQL、ClickHouse、Redis、Object Storage、および GitLab のすべてのデプロイメントに対するスケーラブルなバックアップシステムの開発が含まれます。
すべての GitLab デプロイメントにおいて:
- 私たちは GitLab のデータストレージアーキテクチャとインターフェースを設計、運用、進化させます。または責任者を支援します。
- 私たちはフィーチャーオーナーが機能のライフサイクル全体にわたって安全にビジネス目標を達成できるよう導きます。
- 私たちはインシデントまたはエスカレーション時に顧客を直接支援し、顧客のニーズを満たすためのイノベーションにより間接的にも支援します。
各 Data Access チームの仕事は、フィーチャーオーナーが責任あるアクセスパターンに対して説明責任を持つよう促し、それにより共有データストレージシステムの安定性を確保することです。これは積極的なプロセスであり、コラボレーションのための関係構築、整備されたパスを通じた誘導、チームメンバーが使用および発展させられるツールと知識の提供が必要です。
持続可能性と可用性について
ここでの持続可能性とは、データストレージシステムとそれを使用するソフトウェアアーキテクチャの長期的な保守性、効率性、およびスケーラビリティを意味します。良い持続可能性には、適切な事前計画と、機能、ビジネス目標、インフラが進化するにつれた継続的な適応が必要です。新しい追加と変更の影響は、GitLab アプリケーション全体とストレージインフラストラクチャのコンテキストで考慮される必要があります。
可用性とは、重要なユーザージャーニーが、通常の操作中だけでなく、マイグレーションやアップグレードなどの状態遷移中にも継続的に優れたユーザー体験を提供することを意味します。私たちは、中断と品質低下を最小化するようにアーキテクチャ、プロセス、ツールを設計する必要があります。
ビジョンの実現
私たちが行うこと
- GitLab の関連する持続可能性目標をエンドツーエンドで所有し推進し、互いとフィーチャーオーナーに説明責任を持たせます。
- サービスにおけるデータのスケーラビリティとアクセスパターンの主要なメトリクスを測定し、変化と限界点との関係を追跡します。
- 共有リソースの使用量をその源泉に帰属させるためのツールを公開します（例：特定の製品機能にメトリクスの増加またはデータベースクエリを紐付ける）。
- ドキュメント、コンサルテーション、プロセス、フレームワークを通じて「整備されたパス」（データの保存とアクセス時に従うべき良いパターン）を定義します。
- プロセスと自動化ツールを通じて、開発サイクルのできるだけ早い段階でスケーラブルでないパターンが GitLab に入ることを積極的に検出・防止します。
- 発見された既存パターンを持続可能にする作業を推進します。
- 長期的な持続可能性に貢献するインフラ変更を革新、テスト、デプロイ、移行します。
- ストレージサービスの可用性を維持するための多層防御技術を構築します（ロードシェディング、リクエストアイソレーションなど）。
- 他の Data Access チームと緊密に連携します。イノベーションを促進し、顧客に一貫したソリューションを提供するために、知識、アイデア、概念、ベストプラクティスを共有します。
- 私たちの行動の影響を測定し、目標を設定し、進捗を報告します。
FY26 目標
（GitLab のプロダクト原則および[INTERNAL] Three year (FY26-FY28) - Platforms strategy に沿って）
新機能ローンチの原則
以下は新機能の観点からの考慮事項の非網羅的なリストです。良い判断を行う責任はドメインエキスパートとフィーチャーオーナーの両者にあります。（この説明は RFC2119 の用語を使用しています。）
以下の各ポイントは、すべての GitLab インストールタイプ（Cells、Dedicated、SaaS、Self-Managed）に対して考慮されなければなりません:
- 時間の経過とともに機能が成長しても、サービス全体を危険にさらしてはなりません（MUST NOT）。
- 機能の障害は、サービス全体を危険にさらしてはなりません（MUST NOT）。
- セーフガードはアーキテクチャ的なフェイルセーフ（アイソレーション、サーキットブレーカーパターンなど）であるべきであり（SHOULD）、事後対応的なメカニズムであってはなりません。
- 機能を運用する重要なパスは完全に自動化されなければなりません（MUST）。（例：グラフを見て反応する人間は許可されません。）
- 負荷と成長の源泉を特定して帰属させるための特定の可観測性（モニタリングとアラート）が整備されなければなりません（MUST）。
- データ所有権計画にはデータのライフサイクル全体を含めなければなりません（MUST）：
- バックアップと復元計画
- ビジネス目標に紐付き、すべての潜在的な法的影響（PII、個人識別情報など）を考慮したデータ保持ポリシー
- レプリケーション計画（Geo）
- コスト分析
- エクスポートとインポートなど、既存のデータ管理機能との互換性
- ユーザー向け機能のデータは、機能の成熟度に対応するデータストアに保存され、そこを通じてアクセスされなければなりません（MUST）。
- 例えば、一般提供（GA）ローンチには、データが本番品質のインフラが所有するデータストアに保存され、そこを通じてアクセスされることが必要です（REQUIRES）。
- 変更にはドキュメント化されたロールアウト計画が必要です（MUST）。
- 上記のポイントは、機能がライフサイクルの変更（ローンチ、大幅な成長、成熟度やスコープの変更、廃止）を経験するたびに、その変更が行われる前に再考されなければなりません（MUST）。再訪する責任はフィーチャーオーナーにあり、Data Access エキスパートが支援します。
- 上記のいずれかの例外は、リスク評価とビジネス上の考慮事項とともに徹底的かつ恒久的にドキュメント化し、Senior Manager, Data Access 以上と適切なプロダクトカウンターパートの承認を得なければなりません（MUST）。
全チームメンバー
以下の人々は Data Access サブ部門に属するチームの常駐メンバーです:
Gitaly
Gitaly チームは、GitLab インスタンス、特に GitLab.com の Git データが信頼性が高く、セキュアで高速であることを保証するシステムを構築・維持します。
チームメンバー情報は 原文 (英語) を参照してください。
Git
Git チームは、コミュニティと GitLab の目標に沿って Git を開発し、私たちのプロダクトに統合します。
チームメンバー情報は 原文 (英語) を参照してください。
