フレームワーク活用ガイドひとことで言うと#
障害の検知から復旧・振り返りまでを「宣言→トリアージ→対応→復旧→ポストモーテム」の5フェーズで標準化し、MTTRを短縮するフレームワーク。
押さえておきたい用語#
- Incident Commander（IC）
- インシデント対応全体を指揮するロールのこと。技術判断ではなく、意思決定と情報整理を担う。
- Severity Level（セバリティ レベル）
- インシデントの影響度を表す等級。Sev1（全面障害）〜Sev4（軽微）のように段階を定義する。
- MTTR（Mean Time to Recover）
- 障害発生から復旧までの平均所要時間を指す。インシデント管理の最重要KPI。
- Postmortem（ポストモーテム）
- インシデント収束後に行う振り返りドキュメント。原因・タイムライン・再発防止策を記録する。blame-freeが原則。
- Runbook（ランブック）
- 既知の障害パターンに対する手順書。対応を標準化しMTTRを短縮する手法である。
インシデント管理の全体像#
こんな悩みに効く#
- 障害が起きるたびに対応が場当たり的で、復旧に時間がかかる
- 障害後の振り返りが形骸化して同じ障害が繰り返される
- 誰が何をすべきか決まっておらず、対応中に混乱する
基本の使い方#
具体例#
エンジニア100名のBtoB SaaS。月に平均 8件 のSev2以上のインシデントが発生。MTTRが平均 2.5時間 で、対応のたびに「誰が何をやるか」から議論が始まっていた。
Severity定義・ロール・プレイブックを整備。
| 改善項目 | Before | After |
|---|---|---|
| IC任命までの時間 | 平均20分 | 5分以内（オンコール= IC） |
| ステータス共有 | なし | 15分ごとにSlack更新 |
| ポストモーテム実施率 | 30% | 100%（Sev2以上） |
6ヶ月後、MTTRが 2.5時間 → 55分 に短縮。ポストモーテムからの再発防止策で、Sev2以上のインシデント数自体も 月8件 → 月3件 に減少した。
月間売上15億円のEC。年末商戦時にデータベース障害が発生し、4時間のサービス停止で推定 8,000万円 の損失が出た。同様のDB関連障害は過去1年で 3回目 だった。
障害後、全社的にblame-freeポストモーテムを導入。テンプレートを用意し、Sev1/Sev2のインシデントは必ず48時間以内にドキュメントを作成するルールにした。
再発防止策として「DB接続プールの自動スケーリング」「Read Replicaの自動フェイルオーバー」を実装。以降12ヶ月でDB関連のSev1障害はゼロ。ポストモーテムのライブラリが蓄積され、新メンバーのオンボーディング資料としても活用されている。
エンジニア25名の決済系スタートアップ。深夜のオンコールでジュニアエンジニアが対応に入ると、シニアをエスカレーションするまで平均 40分 かかっていた。
頻出インシデントのTop10に対してRunbook（手順書）を整備。各Runbookには「症状」「確認コマンド」「対応手順」「エスカレーション基準」を記載した。
Runbookを使った対応訓練を月1回実施した結果、ジュニアエンジニアの初動対応時間が 40分 → 8分 に短縮。Runbookで対応可能なインシデントの 75% がエスカレーション不要で解決できるようになった。
やりがちな失敗パターン#
- Severity判定が曖昧 — 「重大かどうか」を感覚で判断すると、同じ障害でも人によってSev2とSev3に分かれる。ユーザー影響の範囲と機能停止の有無で機械的に判定する基準を作る
- ポストモーテムで犯人探しをする — 「誰のコミットが原因か」を追及するとインシデント報告が遅れる。blame-freeの原則を明文化し、経営層にも周知する
- Runbookが更新されない — 半年前のRunbookはインフラ構成の変更で使えなくなっている可能性がある。ポストモーテムのたびにRunbookの正確性を確認する
- すべてのインシデントを同じ重さで対応する — Sev4にSev1と同じ対応をするとチームが疲弊する。Severityに応じた対応レベルを設定する
まとめ#
インシデント管理は 「検知→トリアージ→緩和→復旧→学習」 の5フェーズで障害対応を標準化するフレームワーク。Severity定義とロールを事前に決め、プレイブックで判断に迷う時間を減らすことでMTTRを短縮する。ポストモーテムはblame-freeの原則で実施し、再発防止策とRunbook更新を通じてインシデントそのものを減らしていくサイクルが重要になる。