Monetization セクション

ミッション

購入フロー、課金エンジン、それらを支えるために必要なインフラストラクチャ、インテグレーション、コンプライアンス機能を網羅する、スケーラブルな収益化プラットフォームを通じて、お客様が GitLab の製品・サービスを評価、購入、管理できるようにします。

Monetization セクションと Fulfillment セクションは、2026 年 8 月に単一の Fulfillment セクションから分かれました。Monetization は CustomersDotとその運用を担当します。Fulfillment セクションは、利用権限、シート、使用量を担当します。両セクションは共通の業務の進め方に従います。

チーム

Vitaly Slobodin（Senior Staff Fullstack Engineer）はセクション全体を横断して業務を行います。

安定したカウンターパートは、共通の業務の進め方のページに掲載しています。

CustomersDot のエンジニアリング

承認とマージ

CustomersDot の main を対象とするすべての MR には、作成者以外の人による承認が少なくとも 1 件必要です。

• 少なくとも 2 名のレビュアーが必要で、そのうち 1 名はメンテナーとします。ロジックの変更がない軽微な MR（依存関係のバージョン更新、テスト修正、単純な差し戻し）に必要なレビュアーは 1 名です。
• メンテナーによるレビューが必要です。
• Danger botの提案に従ってください。データベースの変更にはデータベースレビュー、セキュリティに関わる変更には Security レビュー、Salesforce API の変更には Sales Systems、Zuora API の変更には Enterprise Applications、ユーザー体験の変更には UX レビューが必要です。

テスト

CustomersDot では、Lint、ユニット、インテグレーション、フロントエンド、E2E のテストを実行します。VCR フラグはデフォルトで Zuora の呼び出しをモック化し、毎日スケジュール実行するパイプラインは Zuora のサンドボックスに対して実行して API の変更を検出します。失敗すると、ステージングと本番環境へのデプロイメントがブロックされます。

エンドツーエンドテストは、GitLabと CustomersDotにあります。CustomersDot は、テストに CustomersDot ポータルが必要な場合にのみ使用してください。CustomersDot E2E ガイドを参照してください。

デプロイメント

CustomersDot は継続的デプロイメントを採用しています。staging にマージするとステージング環境にデプロイし、E2E テストを実行して、3 時間後に本番環境へ自動デプロイします。

graph TD;
    A(Merged) --> |Green tests| B(Staging);
    B --> C[E2E tests on staging];
    C --> D[Verification];
    D --> E(Auto deploy to production in 3 hours);

• 本番環境へのデプロイを停止するには、production::blocker ラベルを付けた機密でない Issue を作成します。
• ブロッカーがある間に修正を急ぐ場合は、本番ジョブのスケジュールを解除し、ラベルを削除した後に手動で実行します。
• 重要な変更にはフィーチャーフラグを使用してください。
• 機能凍結期間は GitLab の他の部分と同じで、マイルストーンが終了する金曜日からリリース日までです。
• Production Change Lockの期間中は、PCL テンプレートを使って、production::blocker の追加と削除の DRI および時刻を記載した Issue を作成します。
• Zuora には、変更リクエストに追加の承認が必要な変更制限期間があります。

収益に影響する変更

私たちの変更は、収益に直接影響することがあります。リスクの高い変更では PM が DRI を務め、Sales、Enterprise Applications、Marketing、Finance、Support から意見を集めます。

リスクの高い例には、価格設定、課金、有料機能のリリースや廃止、利用規約の変更、消費量の計算方法や表示方法の変更があります。リスクの低い例には、フロントエンドでまだ使用していないバックエンドの変更や、フィーチャーフラグの背後にある変更、ベータや実験的と表示された変更があります。

リスクの高い変更では、次のようにします：

• 機能のドキュメントを更新し、ステークホルダーと共有します。
• 機密の Issue と通常の MR プロセスを使用します。
• フィーチャーフラグの背後で提供し、リリース日に向けたロールアウト Issueを作成します。
• 最初に一部のお客様に対して有効にすることを検討します。

アクセスレビュー

EM とセクションのリーダーシップは、アクセスレビュープロセスに従い、役割と部署に基づいて四半期ごとに CustomersDot へのアクセス権をレビューします。Sales は読み取り専用アクセスを維持します。AppSec、Billing、Monetization および Fulfillment のチームメンバー、IT Helpdesk、Support は書き込みアクセスを維持します。判断に迷う場合は却下してください。アクセス権はアクセスリクエストを通じて復元できます。

運用監視

定期的な監視業務は、各マイルストーンの計画 Issue で DRI に割り当て、キャパシティに算入します：

• Provision Tracking System の障害監視
• Salesforce と Zuora の Sentry 監視

トライアル

Growth はトライアルの入口を担当します。Monetization と Fulfillment は、トライアルの内部コードベースと、CustomersDot のすべての運用サポートを担当します。トライアルのオーナーシップとコラボレーションのフレームワークを参照してください。

アーキテクチャレビュー

毎週のアーキテクチャレビューでは、グループ横断のプロジェクト、CustomersDot のアーキテクチャ、Zuora とのインテグレーションを扱います。誰でも参加できます。少なくとも 1 日前までに議題を追加してください。議題がない場合、ミーティングは中止します。

インシデント管理

インシデントや障害のエスカレーションプロセス

Monetization は Tier 2 SME のオンコールローテーションを運用しています。Engineer on Call は incident.io を通じてエスカレーションします：

1. レベル 1：現在オンコールの SME（EMEA、AMER、または APAC）。
2. レベル 2：レベル 1 が 15 分以内に確認応答しない場合、ローテーションの全メンバーにラウンドロビンで通知します。
3. レベル 3：James Lopez。

障害が発生すると、#customersdot_errorsに通知され、James Lopez と Vitaly Slobodinが自動的に呼び出されます。オンコールの SRE は、Slack で @fulfillment-engineering に支援を求めることができます。

緊急の修正

本番環境に不具合がある場合は、Rapid Engineering Responseが適用されるかを確認してください。メンテナーは手動デプロイにより、ステージングから本番環境への 3 時間の待機を省略できます。エスカレーションを説明する Issue を作成し、#fulfillment_monetization_engineeringで告知します。

調査

• 例外：Sentry
• ログ：Kibana
• ヘルスチェック：CustomersDot health、認証情報は 1Password の Subscription portal 保管庫にあります
• 本番環境の障害やデプロイの失敗については、インシデントを宣言します。

お客様に関するエスカレーション

Support や Sales からのライセンスに関するエスカレーションは、Slack ではなくサポート内部リクエストプロセスを通じて行います。リーダーは License Issue High ARR ラベルを購読します。

Slack

共通のチャンネルは、業務の進め方のページに掲載しています。

リンク

• 共通の業務の進め方
• Fulfillment ガイド（CustomersDot の管理とプロセスのドキュメント）
• CustomersDot の参考動画
• パフォーマンス指標とエンジニアリングダッシュボード

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