インシデント対応 基礎：切り分け・状況共有・復旧・ポストモーテムの型

第6章：連絡とエスカレーション（判断基準/情報粒度）

この章で学ぶこと

  • 連絡は“頻度と粒度”を固定する
  • エスカレーション基準を事前に持つ
  • 必要支援を具体化する
  • 連絡、通知、広報、情報共有を混同せず、担当と承認経路を分ける

成果物（または判断基準）

本文

連絡が機能しない主因は、情報量の過多/不足、更新欠落のいずれかである。テンプレで最小項目と更新頻度を固定する。

共有の最小セット

  • いま何が起きているか
  • 何を試したか（結果）
  • 次に何をするか
  • 影響見込み

更新頻度の目安（Severity 別）

目安であり、組織の窓口/顧客影響/法令要件がある場合はそれらを優先する。

注: ETA（復旧見込み時刻）は確度が低い場合、未確定と明示し、次回更新時刻を先に約束する。

Severity 更新頻度（目安） 共有先（例） 粒度（最小）
P0 10〜15 分ごと 当番/関係者/責任者/CS 影響、暫定判断、次アクション、ETA、リスク
P1 30 分ごと 関係者/CS 影響、進捗、次アクション、判断ポイント
P2 60〜120 分ごと、または節目 関係者 節目（原因候補/暫定対応/復旧見込み）で更新
P3 節目のみ 関係者 予定化（いつ直す/どう検証するか）を明確化

連絡の種類を分ける

インシデント時の「連絡」は一種類ではない。混ぜると、社内調整のつもりで外部通知が漏れたり、未確認情報を公開してしまう。

区分 目的 主な担当/承認
対応調整 現在の対応、担当、次アクションを揃える IC、調査、復旧、連絡担当
通知判断 顧客、委託元、規制当局、本人通知の要否を判断する 責任者、法務/プライバシー窓口、セキュリティ窓口
対外広報 公開ステータス、顧客向け文面、メディア対応を管理する 広報、CS、責任者
脅威情報共有 IoC、攻撃傾向、再発防止に必要な情報を共有する セキュリティ窓口、SOC/CSIRT

通常障害では対応調整が中心になる。セキュリティ/プライバシー疑いでは、通知判断と対外広報の承認経路を早期に立ち上げる。

エスカレーションは“判断根拠”と“必要支援”が揃っていると迅速化する。

エスカレーション文面例（最小）

テンプレを貼り付けて埋めると、情報不足/過多を避けやすい（付録: エスカレーション）。

【エスカレーション】決済 API で 5xx 増加
影響: 決済失敗が一部顧客で発生（失敗率 6%、暫定）
緊急度: 継続中、悪化の可能性あり
Severity: 暫定 P1
判断が必要な事項: ロールバック可否、顧客向け通知要否
必要な支援: DB 担当に接続状況の確認（15 分以内）
暫定策: 機能フラグ OFF、もしくはロールバック判断
次回更新: 11:00 JST

注: セキュリティ疑いがある場合は、影響の確定を待たず証跡保全と所定窓口へのエスカレーションを優先する（組織の手順に従う）。

具体例（場当たり→再現性）

悪い例（場当たり）

原因調査中です（以上）
次に何をするかが不明

良い例（再現性）

状況: 決済 API で 5xx が増加
影響見込み: 決済失敗が一部顧客で発生（暫定）
試行: 直近変更を比較→変更Aが疑わしい
次: ロールバック可否確認→実施判断
支援: DB 担当に接続状況の確認依頼
次回更新予定時刻: 11:00 JST

チェックリスト

  • 共有頻度が定義され、定期更新できている
  • 次アクションが明確
  • エスカレーションの判断根拠と必要支援がある
  • 通知判断、対外広報、脅威情報共有が必要な場合の担当/承認経路が決まっている

まとめ

  • 更新頻度と粒度を定義し、最小セット（状況/試行/次アクション/影響見込み）で共有する
  • 判断根拠と必要支援を整理し、エスカレーションの遅延を防ぐ
  • 対応調整、通知判断、対外広報、脅威情報共有を分け、未確認情報の拡散を防ぐ
  • 状況共有テンプレを一次情報として運用し、関係者の前提を揃える

次章への接続

Edit this page on GitHub