インシデント管理

インシデント管理とは

インシデント管理は、システム障害の検知から復旧、再発防止までを体系的に管理するプロセスである。「誰が何をするか」を事前に定義し、障害時の混乱を最小化する。

インシデントの重大度

インシデントの重大度を以下にまとめる。

レベル	影響	対応
SEV1	サービス全体がダウン	即時対応、全員招集
SEV2	主要機能が利用不可	30 分以内に対応開始
SEV3	一部機能に影響	翌営業日に対応
SEV4	軽微な問題	バックログに追加

SEV1 から SEV4 という段階の切り方は広く使われているが、業界共通の規格ではなく、各組織が自分のサービスに合わせて定義するものである。上の表の対応時間も一例にすぎない。実際に効くのは段階の数より判定の書き方で、「影響を受けるユーザーの割合」「主要機能が使えるか」のように観測できる形にしておくと、深夜のオンコール担当者でも迷わずに済む。判断に迷ったら高い方を付けて後から下げる運用にする。低く見積もって放置した障害は、後で重大度を上げても失われた時間が戻らない。

インシデント対応の流れ

インシデント対応は検知、トリアージ、対応、復旧、振り返りの 5 段階で進行する。アラートで検知した後、重大度を判定してインシデントコマンダーを任命し、ランブックに従って復旧作業を行う。サービスの正常動作を確認したら、ポストモーテムで根本原因を分析し、再発防止策を実施する。

1. 検知 (Detection)
   CloudWatch アラーム → SNS → PagerDuty → オンコール担当者

2. トリアージ (Triage)
   重大度を判定、インシデントコマンダーを任命

3. 対応 (Response)
   ランブックに従って復旧作業
   コミュニケーションチャネルで状況を共有

4. 復旧 (Recovery)
   サービスの正常動作を確認

5. 振り返り (Review)
   ポストモーテムで根本原因を分析
   再発防止策を策定・実施

インシデントの役割

インシデントコマンダー (IC) が全体の指揮と意思決定を担い、技術担当が調査・復旧を行う。コミュニケーション担当がステークホルダーへの報告を担当し、スクライブがタイムラインを記録する。

この分担は災害対応で使われる Incident Command System を下敷きにしたもので、Google の SRE 本も自社の仕組みがそれに基づくと述べている。核心は役割の境界を越えないことにある。IC は委譲していない役割をすべて自分が持っているものと見なし、逆にシステムに手を入れるのは技術担当だけに限る。指揮役が自分で復旧作業を始めると、手を動かし出した瞬間に全体を見る人がいなくなる。

IC の最も重要な仕事は、進行中の状況を書き続ける記録の維持である。同時編集できる場所に時刻・確認した事実・実施した操作を残しておくと、途中から参加した人の立ち上がりとポストモーテムの精度がそのまま変わる。長時間に及ぶ障害では、就業終了時に IC を明示的に引き継ぐ。誰が IC なのか曖昧な時間帯は、そのまま対応の空白になる。

呼び名は組織によって違う。PagerDuty が公開している対応手順書では、IC を補佐する Deputy、記録係の Scribe、該当コンポーネントの専門家である Subject Matter Expert (Resolver とも呼ぶ)、社外向けと社内向けの連絡担当を分けている。人数が足りない小さなチームでは 1 人が複数の役割を兼ねることになるが、そのときも「今はどの役割として発言しているか」を宣言する習慣が混乱を防ぐ。

ステータスページ

ステータスページを図で示す。

[Investigating] 18:00 - API のエラー率が上昇しています。調査中です。
[Identified]    18:15 - DynamoDB のスロットリングが原因と特定しました。
[Monitoring]    18:30 - 対策を実施しました。監視中です。
[Resolved]      19:00 - 正常に復旧しました。

AWS でのインシデント検知

CloudWatch Alarms (メトリクスベースのアラート)、CloudWatch Anomaly Detection (異常検知)、GuardDuty (セキュリティインシデント)、Health Dashboard (AWS サービスの障害) を組み合わせて検知する。