インシデントレビュー

インシデントレビューを書くことの主な目的は、インシデントを文書化し、全ての根本原因を十分に理解し、特に再発の可能性や影響を低減するための効果的な予防措置を講じることを確保することです。1

はじめに

インシデントレビューは、ブレームレス（責任追及なし）の文化の中でより深い理解を育む重要な機会です。その目的は再発防止のためのアクション項目を収集することにとどまらず、インシデントに寄与するシステムとエンジニアリング文化の両方について学ぶプロセスです。これらの要素がどのように機能し相互作用するかを議論・分析することで、私たちがサポートする技術環境と、それらが機能するより広い組織のコンテキストについての貴重な洞察を得ます。

GitLab では、ブレームレスなインシデントレビューの実践にコミットしています。これは、個人に責任を帰したり落ち度を見つけようとするのではなく、インシデントの「なぜ」と「どのように」を理解することに意図的に焦点を当てることを意味します。インシデントレビューには、一次情報と貴重なコンテキストを提供するために個人またはチーム名への言及が含まれることがありますが、これらの言及は決して責任を追及するためのものではありません。代わりに、一連のイベント、関与した意思決定プロセス、インシデント中に直面した課題をより深く理解するための手段として機能します。

私たちは、オープンなコミュニケーション、信頼、緊密な協力を促進するためにこのブレームレスモデルに従います。これにより、誰もが報復を恐れることなく自分の視点と観察を共有できます。

継続的な学習がこれらのブレームレスレビューの主要かつ最重要な焦点ですが、実践的な目的もあります。システムの回復力と信頼性を高める実用的な改善の特定と実施につながり、最終的にはエンジニアリング文化を強化し、ユーザーへのサービス提供能力を向上させます。

テンプレート

責任

インシデントリードまたはレビュー依頼者

インシデントリードまたはレビュー依頼者は、適切なテンプレートを使用してレビュー Issue を開き、初期メタデータを追加する責任があります。これには以下が含まれます:

  • 適切な Issue タイトルの設定
  • 正しい Severity::* ラベルの設定
  • レビューとインシデントのリンク
  • レビューを所有する適切な DRI を見つけて Issue をアサイン
  • インシデントレビューに RED データが含まれていないことを確認し、RED データが見つかれば削除
  • Slack でインシデントレビューを告知

サービスオーナー

サービスオーナーはインシデントを引き起こした原因と取られたアクションのナレーティブを書く責任があります。サービスオーナーは最初の対応者よりもサービスについてより多くのコンテキストを持っている可能性が高いため、これにより適切な人が何が起こったか、なぜ起こったかを理解していることが検証されます。根本原因が不明な場合、サービスオーナーは調査からできる限り多くの詳細を提供すべきです。

サービスオーナーは以下を実施します:

  • EOC との会話とインシデント Issue を参照として残りの「主要情報」フィールドを記入する
  • インシデントの短いエグゼクティブサマリーを作成する
  • 何が起こったか、どのように対処したかを説明するナレーティブを書く
  • インシデントに関わった人（EOC、IMOC、CMOC、その他のエンジニアやステークホルダー）を議論に参加させる
  • 是正措置につながるさらなる洞察を得るための調査的な質問をする
  • 是正措置は同様の問題が再発しないことを確保するか？そうでなければ、さらに調査を続け、レビューに参加する人を拡大することを検討する
  • 是正措置、infradev Issue、またはその他のアクションやインシデントからの成果をリンクし、潜在的に作成する
  • Issue に適切なラベルと残りのメタデータを追加する
  • レビューコメントまたは Slack で発生した会話をまとめる
  • SaaS 可用性にインシデントのサマリーを含め、影響と是正措置についての同期または非同期アップデートに参加する
  • 期限日前にレビューを完了する

インシデントレビュープロセス

以下のステップに従うことで、誰でも非同期および同期レビューの両方を要求できます。進め方が不明な場合は、インシデント Issue のアサイニーに支援を求めてください。

レビューはデフォルトで非同期で行います。 同期レビューも、改善策をリアルタイムで議論しブレインストーミングする手段として価値があります。 同期レビューを開催する前に、まず非同期レビューを完了する必要があります。同期レビューを要求するには、インシデントレビュー Issue に投稿してください。

レビューをトリガーする基準

  1. 全てのユーザー向け高重大度（Severity::1 および Severity::2）インシデントはレビューが必要です
  2. インシデント Issue に Review-Requested ラベルが追加されたインシデント
  3. インシデント自体のスコープ外でさらなる情報が必要なインシデント

全てのレビューにおいて、レビューテンプレートの全セクションを完了する必要は_ありません_。 迅速性のために、あなたがレビュー作成者として、より広い組織の注目を集めたい内容や、インシデントに関連する是正措置の生成を促進するセクションを完了できます。

顧客エンゲージメント

インシデントレビューでは、テクニカルアカウントマネージャー（TAM）などの窓口を通じた顧客エンゲージメントが必要になる場合があります。 レビューから出てきた調査結果について同期的な議論を要求する顧客がいる場合、TAM は Infrastructure 管理と連携して重要なステークホルダーとの議論を調整できます。

未所有サービス

所有チームがないサービスが一部存在する場合があります。現在、未所有サービスのインシデントレビューは行っていません。未所有サービスのインシデントレビューが必要な場合は、まずそのサービスをチームに割り当て、サービスカタログを更新してそれを反映させることを推奨します。

レビュー完了の期待タイムライン

インシデントレビューはインシデント解決から 5 営業日以内に完了することが期待されています。インシデントレビュー Issue がまだ開いている場合、5 日後にリマインダーが送られます。Severity 1 インシデントの場合、顧客はインシデント解決から7 日以内に公開 RCA が利用可能になることを期待できます。

  1. Google SRE Chapter 15 - Postmortem Culture: Learning from Failure ↩︎

最終更新 May 6, 2026: Merge pull request #100 from kyama0/fix/upload-images-tolerate-upstream-missing (70970e1a)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License