インシデント管理

🐱 この章の目次

インシデントとは

インシデント（Incident） は、サービスの品質が SLO を下回り、ユーザーに影響を与えている状態を指します。障害が「起きるかどうか」ではなく「いつ起きるか」の問題であると認識し、対応プロセスを事前に設計しておくことが重要です。『入門監視』第 3 章が述べるとおり、インシデント管理の目的はサービスの早期回復であり、原因究明は後回しにします。

インシデントライフサイクル

インシデント対応は 5 つのフェーズで構成されます。

フェーズ	目的	主なアクション
検知（Detect）	異常を認識する	アラート発火、ユーザー報告
トリアージ（Triage）	重大度を判定する	Severity 決定、担当者アサイン
緩和（Mitigate）	影響を最小化する	ロールバック、フェイルオーバー
解決（Resolve）	正常状態に復帰する	修正デプロイ、確認テスト
学習（Learn）	再発を防止する	ポストモーテム、改善タスク起票

重大度レベル

Severity（重大度） を事前に定義し、対応のスピードとエスカレーション範囲を決めます。

レベル	定義	対応目標
Sev1	サービス全体停止	即時、全員招集
Sev2	主要機能の劣化	15 分以内に対応開始
Sev3	一部ユーザーに影響	営業時間内に対応
Sev4	影響なし（潜在リスク）	次スプリントで対応

インシデント中のコミュニケーション

対応中はひとつの War Room（対策チャンネル） に情報を集約します。ステータスアップデートは 15〜30 分ごとに定時発信し、ステークホルダーの不安を軽減します。「何がわかっていて、何がまだわかっていないか」を明示する習慣が信頼を生みます。

ポストモーテム文化

インシデント収束後に ポストモーテム（Postmortem） を実施し、タイムライン・根本原因・改善アクションを文書化します。最も重要な原則は ブレイムレス（Blameless） であることです。個人を責めるのではなく、システムやプロセスの弱点に焦点を当てることで、報告のインセンティブを維持します。

# ポストモーテムテンプレート（例）
postmortem:
  title: "2026-08-09 決済 API タイムアウト"
  severity: Sev2
  duration: "45 min"
  impact: "決済成功率が 60% に低下"
  timeline:
    - "09:15 アラート発火: HighErrorBurnRate"
    - "09:18 オンコール担当が War Room 開設"
    - "09:25 DB コネクションプール枯渇を確認"
    - "09:30 プールサイズを拡張しデプロイ"
    - "10:00 エラーレート正常復帰を確認"
  root_cause: "マイグレーション時にコネクション上限の変更漏れ"
  action_items:
    - "コネクションプール設定を IaC に組み込む"
    - "プール使用率のアラートを追加する"

まとめ

インシデント管理は「人と情報の流れ」の設計です。技術的な修正だけでなく、コミュニケーション・判断基準・振り返りのプロセスを整備することで、チームは障害から学び続けることができます。

📖 参考: 『入門監視』第 3 章 — インシデント管理