チェックリスト集
Severity（P0/P1/P2/P3）最小定義
| Severity | 目安 | 例 | 初動 |
|---|---|---|---|
| P0 | 全面停止/重大な情報漏えいの疑い | ログイン不可、決済停止、秘密情報の外部流出 | 直ちに対応、関係者招集、変更凍結も検討 |
| P1 | 主要機能の劣化/限定的な情報漏えいの疑い | 一部APIエラー増加、特定顧客のみ影響 | 優先対応、迂回策/ロールバック判断 |
| P2 | 影響が限定的/回避可能 | 管理画面のみ不具合、手動対応で回避可 | 予定化、恒久対策の計画 |
| P3 | 影響が軽微/改善要望 | 表示崩れ、低頻度の警告 | 低優先（バックログ化して定期見直し） |
関連（秘密情報漏えい疑いの初動/証跡/隔離）: セキュリティ/プライバシー リテラシー
役割（最小）
| 役割 | 主な責務 | 権限/判断 |
|---|---|---|
| IC（Incident Commander） | 全体の優先度付け、復旧方針、タスク割り当て | 迂回策/ロールバックの判断、連絡方針 |
| 調査（SME） | 原因候補の絞り込み、検証、証跡整理 | 追加調査の指示、再現のための環境確保 |
| 復旧担当 | 迂回策/ロールバック/修正の適用 | 手順の実行、変更リスクの報告 |
| 連絡/広報 | ステータス更新、対外/対内コミュニケーション | 周知内容の合意、更新頻度/粒度 |
| 記録係 | タイムライン、判断理由、実施内容の記録 | 証跡の回収、ポストモーテム素材化 |
注: 本書では「切り戻し」は「ロールバック」と同義として扱う。
- 小規模では兼務でよい（ただし IC と記録は分けると混乱を抑えやすい）
初動チェック
- 証跡保全（ログ/メトリクス/設定）
- 誤操作防止（権限/手順の統制）
- 関係者連絡（影響/次アクション）
切り分けチェック
- 影響範囲の縮小（どこまで壊れているか）
- 比較（正常系との差分）
- 直近変更点の確認
復旧判断チェック
- ロールバック可否
- 暫定措置のリスク
- 影響見込み（顧客/売上/法令）
暫定対応→恒久対策（判断の最小観点）
- 暫定対応が“安全側”か（データ整合性/セキュリティ/コスト）
- 恒久対策の前提が揃っているか（再現性/原因候補/影響範囲）
- ロールバック条件（どの指標で戻すか）を定義した
通しの訓練シナリオ（例）
初学者が進め方で迷わないよう、検知→Severity→役割→タイムライン→状況共有→エスカレーション→復旧→ポストモーテムまでの一連の流れを例示する。
シナリオ（例）
- 事象: 決済 API で 5xx が増加し、決済失敗が一部顧客で発生
- 想定 Severity: P1（主要機能の劣化）。失敗率が高い/継続する場合は P0 に引き上げ
進め方（テンプレを埋める場所）
タイムライン例（抜粋）
注: 時刻はタイムゾーンを明記する（例: JST/UTC）。
| 時刻 | 観測/状況 | 判断/アクション | 記録（どこに残すか） |
|---|---|---|---|
| 10:00 JST | アラート: 決済 API の 5xx 率が上昇 | IC 任命、Severity 暫定 P1 | incident-log / timeline |
| 10:05 JST | 影響確認: 失敗率 6%（直近 30 分） | 15 分ごとの状況共有を開始 | status-update |
| 10:10 JST | 直近変更: PR#123 のデプロイが疑わしい | ロールバック可否と副作用（DB 変更有無）を確認 | incident-log |
| 10:15 JST | DB マイグレーションなし | ロールバック判断（手順/検証項目を確認） | timeline |
| 10:25 JST | ロールバック実施 | エラー率/レイテンシ/決済成功率で効果確認 | status-update |
| 10:40 JST | 指標が正常化 | 恒久対策の Issue 化、再発防止（検知/手順）着手 | postmortem |