ストーリー

インシデント対応の役割

標準ロール

役割の分離が重要な理由

悪い例: 1人がすべてを担当
  → 技術対応しながら報告書を書きながら上司に報告
  → すべてが中途半端になり、対応が長引く

良い例: 役割を分離
  IC: 「DBの調査はAさん、ネットワークの確認はBさん、15分後に状況共有」
  Ops Lead: 技術対応に集中
  Comms Lead: 経営層に「現在対応中、影響範囲はX、復旧見込みはY」を報告
  Scribe: タイムラインを記録（ポストモーテムの素材に）

エスカレーションフロー

時間ベースのエスカレーション

重大度ベースのエスカレーション

重大度の判断基準

インシデント対応フロー

標準フロー

1. 検知（Detection）
   ├── 自動: アラート発報（PagerDuty）
   └── 手動: ユーザー報告、内部報告

2. トリアージ（Triage）[5分以内]
   ├── 影響範囲の初期評価
   ├── 重大度の判定（SEV1-4）
   └── ICのアサイン（SEV1/2の場合）

3. 対応（Response）
   ├── インシデントチャンネル作成（Slack）
   ├── 役割のアサイン
   ├── 影響緩和の実行（ロールバック、フェイルオーバー等）
   └── 定期的な状況アップデート（15分間隔）

4. 復旧（Recovery）
   ├── サービスの正常性確認
   ├── SLI値の回復確認
   └── モニタリング強化（24時間）

5. 事後処理（Post-incident）
   ├── インシデントサマリーの作成
   ├── ポストモーテムのスケジュール（72時間以内）
   └── タイムラインの整理

コミュニケーションプラン

エスカレーションのアンチパターン

よくある失敗

まとめ

チェックリスト

• インシデント対応の5つの役割を理解した
• 時間ベース・重大度ベースのエスカレーションフローを理解した
• エスカレーションのアンチパターンを理解した

次のステップへ

次は「ランブックとプレイブック」です。インシデント対応時の手順書の作成方法を学びましょう。

推定読了時間: 30分