インシデント対応マトリクス
概要
このページでは、GitLab Marketing サイトで発生するインシデントに関するインサイトを提供し、深刻度レベルを評価する方法を示し、サポートを得るための手段を概説します。
最初に、私たちのマーケティングサイトは複数のプロジェクトで構成されているという多様な構成について理解しておくことが重要です。すべてのデプロイは同じ GCP バケットへ収束しますが、ウェブサイト生成にはさまざまな技術が使用されています。
Marketing サイトは複数のリポジトリで構成されています: www、navigation、slippers、そして主に about.gitlab.com。
www-gitlab-com と about.gitlab.com はビルドプロセス中にページを生成し、これらのアーティファクトを単一の GCP バケットへアップロードします。パイプライン実行時に、すべてのアーティファクトは私たちの GCP バケットの
/publicディレクトリ内に統合されます。
このインシデントはどのレベルですか?
インシデントの深刻度を判断する際に考慮すべき質問は次のとおりです:
- Marketing サイトの停止の影響レベルはどれくらいですか?
- 進行中のインシデントについて、Slack の #digital-experience-team または #dex-alerts チャンネルをモニタリングしましたか?
- インシデントはどれくらい広範囲ですか?影響を受ける個人の数を超えて、次のことを考慮しながら評価することが極めて重要です:
-影響を受けるユーザーの総数。
- 私たちの主要ステークホルダーの様々なカテゴリーへの潜在的な影響。
- 規模に関係なく、インシデントが重要な顧客やパートナーに影響を与えるかどうか。
- 影響を受ける個人の中に、私たちの主要なオーディエンスやステークホルダーの中で影響力のある人はいますか?
- インシデントは私たちのコアビジネス運営に直接影響を与えますか?
- 過去に同様のインシデントに遭遇したことがありますか?要するに、これは会社にとって繰り返し発生する問題ですか?
- インシデントは業界全体の課題やトレンドと関連していますか?競合他社や他社が同様の問題に直面していますか?
- 重要なビジネスページ は現在アクセス可能ですか?
インシデントマトリクス
| レベル 1 | レベル 2 | レベル 3 |
|---|---|---|
| 高リスク | 中リスク | 低リスク |
| ミッションクリティカルなキー + 環境変数の漏洩 | ミッションクリティカル / 法的なコンテンツの誤り(例: 不正確な価格、コンバージョン率の高いページでの大幅な誤字や言い回しの誤り) | サイトの一部が見当たらない(例: events、press releases) |
| インフラ(GCP + Contentful)に関連する主要ベンダーの障害。 | 連携障害(6sense、GA など) | パフォーマンス問題 |
| ミッションクリティカルなページが見当たらない(例: ホームページの不在、プライマリーナビゲーション) | 重大なパフォーマンス問題 | |
| 下記の インシデント報告 を参照してください。 | Issue を作成し、#digital-experience Slack チャンネルへ投稿 | Issue を作成し、#digital-experience Slack チャンネルへ投稿 |
インシデント報告
サイト停止のドキュメント化には、Issue ではなく インシデント を使用するようになりました。インシデントは Issue と同様に動作し、停止のドキュメント化に合わせたテンプレートを使用できます。この方法は、私たちのサイトの信頼性についてより深いインサイトを提供し、プロジェクト全体でダウンタイムイベントの追跡と解決を保証します。
ポイントパーソン: Nathan Dubord - 勤務時間: 午前 9 時~午後 6 時 Eastern
- #digital-experience Slack チャンネルへ投稿し、@digital-experience をメンションします。
- 5 分以内に応答がない場合、次の人にテキストまたは電話してください:
- Eastern Timezone(UTC−5):
- Central Timezone(UTC−6):
- Pacific Timezone(UTC−8):
- インシデントは DEX チームメンバーがプロジェクトに基づいて作成します。例えば、about.gitlab.com プロジェクトでの停止はこちら で作成します。注: 停止のために Issue を作成するときは、必ず 代わりにインシデントを作成 してください。レポートとメトリクスに影響するため、必ず適切なプロジェクトでインシデントを開いてください。一般的なルールとして、トリアージプロセスを回避し、既存のオープン Issue が存在せず、サイトの稼働率に影響がある場合に、インシデントを作成する必要があります。
- 適切な場合、Severity とタイムラインイベント を埋めることを検討してください。
- インシデントが解決した後、インシデントをクローズできます。これは私たちの停止解決時間メトリクス(Time to Resolve = インシデントがクローズされた時刻 - インシデントがオープンされた時刻)に影響を与えます。
15 分以内に応答がない場合は電話で連絡してください
PagerDuty
緊急時には、Digital Experience エンジニアは PagerDuty インシデントを作成し、互いのモバイルデバイスでアラートをトリガーする能力を持っています。これらの PagerDuty インシデントは、PagerDuty へのアクセス権を持つ GitLab チームメンバー(IT Security、Reliability、SIRT など)からもトリガーできます。
Digital Experience チーム向けに PagerDuty インシデントをトリガーするには、次の手順に従います:
- Slack のどこかで
/pd triggerと入力してインシデントを報告します。 - 影響を受けるサービスとして
about.gitlab.comを選択します。 - priority、description、Urgency のフィールドを完成させます。
- これによりインシデントが作成され、PagerDuty が Digital Experience チームのメンバーへ通知します。
- PagerDuty は、チームメンバーと連絡が取れるまで継続的にエスカレーションします。
