Incident Response
インシデント対応の仕組みとポストモーテム文化を学ぶ
よくあるシナリオ：深夜のドタバタ対応
決済サービスクライアントで深夜2時に本番障害。5人のエンジニアがSlackで同時に動き始め、重複作業が発生。誰がICか不明なまま2時間経過。やっと原因を特定したが、翌月また同じ障害が再発。
- 「誰が対応するか」が決まっておらず全員が右往左往
- 原因特定コマンドを全員が同時に実行して混乱
- ステータス情報が散らばり顧客への説明が後手に
- 振り返りなし→翌月同じ障害が再発
インシデントライフサイクル
インシデント対応ライフサイクル
核心概念を押さえる
アラート・ユーザー報告・社内気づきで問題を認識。検知が1分遅れると影響が広がる。
例：エラー率が0.1%→2%に急上昇し、Prometheusアラートが発火
影響範囲とSeverityを素早く判定。迷ったら高いSeverityで宣言し、後で下げる。
例：決済APIが全停止→SEV1宣言、全チームをSlack #incident-live に招集
全体を指揮する1人の担当者。ICは自分では作業せず「誰が何をするか」を指示することに専念。
例：IC: 「AさんはDB調査、BさんはステータスページUpdate、私は5分ごとに状況まとめ」
SEV1〜4の段階で対応優先度を定義。全員が同じ基準で判断できるよう事前にドキュメント化。
例：SEV1=全停止・即時対応、SEV4=軽微・翌営業日でOK
障害後の振り返り文書。blame-free（個人を責めない）文化が重要。再発防止アクションを具体的に定義。
例：5 Whys: DB接続プール枯渇→設定ミス→ステージングに負荷テストがない→...
Mean Time To Recover。障害発生から正常復旧までの平均時間。仕組みがあるチームは劇的に短縮できる。
例：仕組みなし: MTTR 4時間 → 仕組みあり: MTTR 45分（-81%）
Severity レベルの目安
| レベル | ビジネス影響 | 対応目標 (MTTR) |
|---|---|---|
| SEV-1 | 本番全停止・データ損失 | 即時対応 |
| SEV-2 | 主要機能の部分停止 | 30分以内 |
| SEV-3 | 一部ユーザー影響 | 4時間以内 |
| SEV-4 | 軽微・回避策あり | 翌営業日 |
AI で SRE の仕事はどう変わるか
- ログを目視でgrepして原因を手探り
- ポストモーテム文書を一から手書き（2〜3時間）
- 類似過去インシデントを記憶や検索で探す
- タイムライン記録を後から手動で作成
- ログ・メトリクスを自動解析し根本原因候補を提示（PagerDuty Copilot）
- インシデントタイムラインとポストモーテム初稿を自動生成（incident.io AI）
- 過去の類似インシデントをリアルタイムで提示・解決策を提案（Rootly AI）
- 対応中のSlack会話からアクションアイテムを自動抽出（FireHydrant AI）
- ビジネス影響を考慮した対応方針の最終判断
- 顧客・経営層へのコミュニケーション
- AI生成ポストモーテムのレビューと承認
- 再発防止アクションの優先度決定と実施
主なツール：PagerDuty Copilot、incident.io AI、Rootly AI、FireHydrant AI、Blameless AI
この先の見通し：2027年には、AIエージェントが障害検知から初期診断・暫定対処まで自律的に実行する「Level 1インシデント自動対応」が普及。人間は複雑・未知の障害（Level 2以上）の意思決定に集中できる環境へ。インシデントの50%以上がAIによって人間の介入なしに解決される見込み。
導入による効果の目安（業界の一般的な傾向）
- MTTR短縮
- -45%
- AI初期診断の効果
- 再発率低減
- -70%
- ポストモーテム品質向上
- ドキュメント工数
- -80%
- AI自動生成の活用
- 意思決定速度
- +60%
- AIによる状況整理