Content last updated 2026-10-26

インシデント対応マトリクス

マーケティングサイトで発生する可能性のあるインシデントへのガイド

概要

このページでは、GitLab のマーケティングサイトで発生するインシデントについて説明し、重大度を評価する方法とサポートを得るための手段を概説します。

まず、私たちのマーケティングサイトは複数のプロジェクトから成る多様な構成であることを理解しておく必要があります。すべてのデプロイ先は同じ GCP バケットですが、ウェブサイトの生成には異なる技術を使用しています。

  1. マーケティングサイトは、www、navigation、slippers、そして主に about.gitlab.comという複数のリポジトリで構成されています。

  2. www-gitlab-com と about.gitlab.com は、ビルド中にページを生成し、それらのアーティファクトを 1 つの GCP バケットにアップロードします。パイプラインの実行時に、すべてのアーティファクトを GCP バケット上の /public ディレクトリ内にまとめます。

このインシデントはどのレベルですか？

インシデントの重大度を判断する際は、次の点を検討します。

  1. マーケティングサイトの停止による影響はどの程度ですか？
  2. 進行中のインシデントがないか、Slack の #digital-experience-team または #dex-alerts チャンネルを確認しましたか？
  3. インシデントの影響範囲はどの程度ですか？影響を受ける人数だけでなく、次の点も考慮して評価することが重要です。 -影響を受けるユーザーの総数。
    • 主要なステークホルダーの各カテゴリーに対する潜在的な影響。
    • 規模にかかわらず、重要な顧客やパートナーに影響するかどうか。
  4. 影響を受ける人の中に、主要なオーディエンスやステークホルダーに対して影響力を持つ人はいますか？
  5. インシデントは、私たちの中核的な事業運営に直接影響しますか？
  6. 過去に同様のインシデントがありましたか？つまり、会社として繰り返し発生している問題ですか？
  7. インシデントは、より広い業界の課題やトレンドと関連していますか？競合他社や他社も同様の問題に直面していますか？
  8. 重要なビジネスページに現在アクセスできますか？

インシデントマトリクス

レベル 1レベル 2レベル 3
高リスク中リスク低リスク
ミッションクリティカルなキー + 環境変数の漏洩ミッションクリティカルなコンテンツや法的なコンテンツの誤り（例：不正確な価格、コンバージョン率の高いページでの重大な誤字や言い回しの誤り）サイトの一部が欠落している（例：イベント、プレスリリース）
インフラストラクチャ（GCP + Contentful）に関連する主要ベンダーの障害。連携の障害（6sense、GA など）パフォーマンスの問題
ミッションクリティカルなページが欠落している（例：ホームページの不在、メインナビゲーション）重大なパフォーマンスの問題
下記のインシデント報告を参照してください。Issue を作成し、Slack の #digital-experience チャンネルに投稿しますIssue を作成し、Slack の #digital-experience チャンネルに投稿します

インシデント報告

現在、サイト停止の記録には、Issue の代わりにインシデントを使用しています。インシデントは Issue と同じように動作し、停止の記録に適したテンプレートを使用できます。この方法により、サイトの信頼性をより詳しく把握し、プロジェクト全体でダウンタイムの追跡と解決を確実に行えます。

担当者： Chris Fraser、Engineering Manager、EST 午前 9 時 30 分 - 午後 5 時 30 分

  1. Slack の #digital-experience チャンネルに投稿し、@digital-experience をタグ付けします。
  2. 5 分以内に応答がない場合は、次の人にテキストメッセージまたは電話で連絡してください。
    1. 東部時間帯（UTC−5）。
      1. Laura Duggan
    2. 中部時間帯（UTC−6）。
      1. Megan Filo
    3. 太平洋時間帯（UTC−8）。
      1. Javier Garcia
  3. DEX のチームメンバーが、該当プロジェクトでインシデントを作成します。たとえば、about.gitlab.com プロジェクトの停止はこちらで作成します。注：停止について Issue を作成する場合は、常に代わりにインシデントを作成してください。レポートとメトリクスに影響するため、必ず適切なプロジェクトでインシデントを作成します。原則として、トリアージプロセスを迂回し、既存のオープンな Issue がなく、サイトの稼働時間に影響がある場合は、インシデントを作成します。
    1. 必要に応じて、Severity とタイムラインイベントを記入することを検討します。
    2. インシデントが解決したら、インシデントをクローズできます。これが停止の解決時間メトリクスに影響します（Time to Resolve = インシデントのクローズ時刻 - インシデントの作成時刻）。

15 分以内に応答がない場合は電話で連絡してください

PagerDuty

緊急時には、Digital Experience Engineers は PagerDuty のインシデントを作成し、互いのモバイルデバイスでアラートを発報できます。PagerDuty にアクセスできる GitLab のチームメンバー（IT Security、Reliability、SIRT など）も、これらの PagerDuty インシデントを発報できます。

Digital Experience チーム向けの PagerDuty インシデントを発報するには、次の手順に従います。

  1. Slack の任意の場所で /pd trigger と入力して、インシデントを報告します。
  2. 影響を受けるサービスとして about.gitlab.com を選択します。
  3. priority、description、Urgency の各フィールドを記入します。
  4. これによりインシデントが作成され、PagerDuty に通知して Digital Experience チームのメンバーへのアラートを発報します。
  5. PagerDuty は、チームメンバーと連絡が取れるまでエスカレーションを続けます。
最終更新 October 28, 2026: Merge pull request #591 from kyama0/translation/batch-2026-10-28-1 (5d840611)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License