インシデント対応フロー完全解説
どこからがインシデントか：重大度・SLO・宣言ルール
夜中にアラートが鳴っても「本当に重大？」と迷う時間が一番の無駄です。判断基準は、SLOと重大度を明文化して潰しておきます。例として、月間SLO 99.9%（エラーバジェット約43分）を前提に、次を宣言条件とします。
- 検知基準（例）：5分移動平均でHTTP 500率が5%以上、またはp95レイテンシ3秒超
- ユーザー影響（例）：決済失敗が10分間で50件超
- エラーバジェット消費速度（例）：1時間で20%以上消費する傾向
重大度はS1〜S4で運用します。S1＝収益/安全に直結、全ユーザー影響、即時全員招集。S2＝一部機能や一部地域影響、オンコール＋担当チーム。S3＝回避策あり、営業時間内に対応。S4＝監視調整や軽微な不具合。宣言は「曖昧なら上げて、早めに下げる」を原則に、時間制限（例：2分で判断できなければS2宣言）を付けます。
通知チャネルと命名規約
インシデントチャンネル名は「inc-YYYYMMDD-連番」、チケットも同じIDで統一。発生から2分以内にチャンネル/チケット作成、5分以内に一次報告（何が・誰が・いつまでに次更新）を流します。
分単位で動く対応フロー：検知→切り分け→エスカレーション→復旧
T+0〜5分：検知とアサイン
- オンコールがアラートを確認しACK。S1は2分以内、S2は5分以内をSLAに。
- インシデントコマンダー（IC）を即時指名。ICは指揮と判断専任、手は動かさない。
- 現状共有テンプレ：「影響/範囲/暫定評価/次の更新時刻」。
T+5〜15分：一次切り分けと安全化
- 直近デプロイ有無、トラフィック急増、依存サービス障害を並列確認。
- ユーザー被害の増加を止める行為（カナリアへ切戻し、機能フラグOFF、レート制限）を優先。
- 「最短で安全化、次に正確化」。根本原因の追及は復旧後に回します。
T+15〜30分：専門チーム招集と外部連携
- DB/ネットワーク/認証など領域ごとにエスカレーション。ICは役割を明確化（ハンドラー、コミュニケーション、書記）。
- 関係者向け定期更新（S1は15分間隔、S2は30分）。顧客向け文面は短く事実ベースで。
復旧→検証→クローズ
- 復旧後はメトリクス正常化とユーザー操作回復をダブルチェック。
- 暫定対策を記録し、恒久対策のオーナーと期限を決定。
- クローズ条件（例：1時間安定、再発兆候なし、ポストモーテム起票）を満たして終了。
仕組み化のコア：Runbook・RACI・自動化とAI活用
人の勘に依存しないための3点セットが効きます。
Runbookの最小構成
- 症状の定義（例：p95>3s、500率>5%）
- 想定原因（デプロイ/依存/スパイク/リーク）
- 確認コマンド/ダッシュボードリンク
- 安全化手順（ロールバック、フラグOFF、スロットル設定）
- 復旧判定とロールフォワード条件
RACIと当番設計
IC＝Responsible、各サブシステムTL＝Accountable、SRE/開発＝Consulted、広報/CS＝Informed。週替わりローテーションと連絡先を常時更新します。
自動化とAIの実務活用
- アラート→チケット→チャンネル作成までを自動連携。更新リマインドもボットで。
- ログ要約や初期仮説の草案にChatGPTやClaude、障害タイムライン抽出にGeminiを活用。
- 設定差分のリバートやIaC修正はCopilotでレビュー効率化。
- ポストモーテムは72時間以内に作成。再発防止策は計測可能なKPI（MTTA/MTTR/検知精度）に紐づけます。
身近な企業活用例：中堅D2Cの失敗と改善
セール開始直後、推薦機能の新リリースが接続プールを枯渇させ、500エラーが全体の18%に。オンコールが「様子見」で9分停滞、誰が決めるか不明なままログ収集が乱立し、復旧まで96分。売上は大きく毀損しました。
翌週からフローを刷新。S1しきい値を明確化（500率5%超で即S1宣言）、ICの週次ローテーション、チャンネル命名統一、15分ごとの更新を義務化。Runbookには「機能フラグOFF→推薦API切替→CDNキャッシュ延長→書き込み優先度調整」を追加。初動の要約はChatGPT、時系列の自動整形にClaude、ログの異常パターン抽出にGeminiを導入。設定ロールバックのPRはCopilotで作成しレビュー時間を短縮しました。
結果、次の障害ではMTTA 9→3分、MTTR 96→28分、エラーバジェット消費は許容内に収まり、セールは継続。CSへの一次回答テンプレも整備され、社内外の混乱が激減しました。決め手は「宣言を早く、役割を固定し、手順を短文化」したことです。
インシデント対応は、道具よりもフローと共通言語が威力を発揮します。検知基準と重大度、分単位の行動、RunbookとRACI、そして自動化とAIの下支え。これらが回り始めると、サーバ監視の価値は「見る」から「守る」へと変わります。サーバ監視運用事業に携わる現場こそ、検知から復旧・学習までを一筆書きで回す設計が、日々の安定とチームの余白を生みます。
