ストーリー

ポストモーテム（振り返り）とは

ポストモーテムは、インシデント発生後に行う構造化された振り返りです。

Blameless（非難なし）の原則

NG: 「Aさんが設定を間違えたのが原因だ」
OK: 「設定変更時のバリデーションチェックが不足していた」

NG: 「なぜこんなミスをしたのか」
OK: 「なぜこのミスを防げる仕組みがなかったのか」

人ではなくシステムとプロセスに焦点を当てることで、心理的安全性を保ちながら真の改善につなげます。

ポストモーテムテンプレート

interface PostmortemReport {
  // 基本情報
  title: string;
  date: string;
  severity: string;
  duration: string;
  impactSummary: string;
  authors: string[];

  // タイムライン
  timeline: {
    time: string;
    event: string;
    actor: string;
  }[];

  // 根本原因分析
  rootCause: string;
  contributingFactors: string[];

  // 影響
  impact: {
    usersAffected: number;
    revenueImpact: string;
    sloImpact: string;
  };

  // アクションアイテム
  actionItems: {
    id: string;
    description: string;
    owner: string;
    priority: 'P0' | 'P1' | 'P2';
    dueDate: string;
    status: 'TODO' | 'IN_PROGRESS' | 'DONE';
  }[];

  // 学んだこと
  lessonsLearned: string[];
}

ポストモーテムの実例

const examplePostmortem: PostmortemReport = {
  title: 'Payment Service 障害によるの注文機能停止',
  date: '2025-01-15',
  severity: 'SEV1',
  duration: '45分 (10:10 - 10:55)',
  impactSummary: '全注文の決済処理が失敗し、約2000件の注文が影響を受けた',
  authors: ['田中', '佐藤'],

  timeline: [
    { time: '10:00', event: 'Payment Service v2.3.1 デプロイ完了', actor: 'CI/CD' },
    { time: '10:10', event: 'エラー率アラート発火', actor: 'PagerDuty' },
    { time: '10:12', event: 'オンコール担当（田中）が対応開始', actor: '田中' },
    { time: '10:15', event: 'ダッシュボードでPayment Serviceのエラー率急増を確認', actor: '田中' },
    { time: '10:20', event: 'トレースでStripe API呼び出しのタイムアウトを特定', actor: '田中' },
    { time: '10:25', event: 'v2.3.1のコード変更を確認、Stripe SDK更新が原因と推定', actor: '佐藤' },
    { time: '10:30', event: 'v2.3.0へのロールバックを決定', actor: '田中' },
    { time: '10:35', event: 'ロールバック完了', actor: 'CI/CD' },
    { time: '10:40', event: 'エラー率が正常値に回復', actor: '自動検知' },
    { time: '10:55', event: 'インシデントクローズ', actor: '田中' },
  ],

  rootCause: 'Stripe SDK v5.0へのアップデートでAPIのリクエスト形式が変更されており、決済リクエストがすべて400エラーを返していた',

  contributingFactors: [
    'Stripe SDKの破壊的変更がCHANGELOGで見落とされていた',
    'ステージング環境のStripe APIがモックだったため、本番固有の問題を検知できなかった',
    'カナリアリリースが導入されておらず、全トラフィックに即座に影響した',
  ],

  impact: {
    usersAffected: 2000,
    revenueImpact: '約500万円の注文が遅延（最終的にリカバリ済み）',
    sloImpact: 'エラーバジェットの15%を消費',
  },

  actionItems: [
    { id: 'AI-1', description: 'カナリアリリースの導入', owner: '田中', priority: 'P0', dueDate: '2025-01-31', status: 'TODO' },
    { id: 'AI-2', description: 'ステージング環境で実際のStripe Sandbox APIを使用', owner: '佐藤', priority: 'P0', dueDate: '2025-01-25', status: 'TODO' },
    { id: 'AI-3', description: '依存ライブラリ更新のレビュープロセス策定', owner: '鈴木', priority: 'P1', dueDate: '2025-02-15', status: 'TODO' },
    { id: 'AI-4', description: 'Payment ServiceのE2Eテスト追加', owner: '高橋', priority: 'P1', dueDate: '2025-02-28', status: 'TODO' },
  ],

  lessonsLearned: [
    '外部SDKのメジャーバージョン更新は、破壊的変更を前提にレビューする',
    'ステージング環境は本番に可能な限り近づける',
    'カナリアリリースの未導入が影響を拡大させた',
    'オブザーバビリティが整備されていたため、10分以内に原因を特定できた',
  ],
};

根本原因分析（RCA）の手法

5 Whys（なぜなぜ分析）

Why 1: なぜ決済がすべて失敗した？
  → Stripe APIが400エラーを返した

Why 2: なぜStripe APIが400エラーを返した？
  → SDKのv5.0でリクエスト形式が変更されていた

Why 3: なぜリクエスト形式の変更に気づかなかった？
  → CHANGELOGの確認が不十分だった

Why 4: なぜCHANGELOGの確認が不十分だった？
  → 依存ライブラリ更新のレビュープロセスがなかった

Why 5: なぜレビュープロセスがなかった？
  → ライブラリ更新のリスク評価基準が未定義だった

根本原因: 依存ライブラリ更新のリスク評価プロセスの欠如

継続的改善のサイクル

インシデント発生
  │
  ▼
ポストモーテム実施（72時間以内）
  │
  ▼
アクションアイテムの起票・追跡
  │
  ▼
改善の実装・検証
  │
  ▼
カオス実験で改善効果を確認
  │
  ▼
ポストモーテムのレビュー会（月次）
  └─ 傾向分析、プロセス改善

まとめ

チェックリスト

• Blamelessポストモーテムの原則を説明できる
• ポストモーテムレポートを作成できる
• 5 Whys分析で根本原因を特定できる
• アクションアイテムの追跡方法を理解した

次のステップへ

次は演習「SRE運用計画を作ろう」です。これまで学んだSREの知識を統合して、実践的な運用計画を作成しましょう。

推定読了時間: 30分