📝
現場で使える障害対応チェックリスト（現場担当者向け）
現場で使える障害対応チェックリスト（現場担当者向け）
概要
このドキュメントは、現実の実務と切っても切り離せない障害対応の現場担当者向けテンプレを自分なりに設計したものです。
SREやオンコール担当だけでなく、現場のエンジニア全員が共通認識を持ち、いざという時の障害に備えることができるよう構成しています。
0) 初動（最初の5分）
-
影響の有無と範囲を一言で：誰に／何が／どの程度
（例：全ユーザー / 決済 / 100%停止） -
緊急度を決める
- S0: 全停止
- S1: 主要機能不可
- S2: 一部退避可
- S3: 影響限定
-
指揮を一人に集約（IC: Incident Commander）
-
チャンネルを一つに固定（Slack
#inc-yyyymmdd） -
変更凍結（当該システムのデプロイ・設定変更を止める）
-
監視・アラートのサイレンス設定（誤爆でノイズ増やさない）
1) 事実の固定化（〜15分）
- 再現手順を1行で書く（入力 → 期待 → 実際）
- 直近の変更3つを列挙（コード／設定／インフラ）
-
メトリクス3本を見る（エラーレート／レイテンシ／トラフィック）
※異常に○印 - ログで時系列の最初の異常点（first seen）をマーク
- 影響面を更新（ユーザー件数 / 売上影響 / 法的リスク）→ 緊急度見直し
2) 切り分け（〜30分）
- 範囲：クライアント？API？DB？外部依存？（当てはまる層に★）
- 変化：ロールバック可能な変更がある？（YES → 即ロールバック試案）
- 単純化：最小ケースで再現できる？（YES → その条件で固定）
-
相関：アラート・メトリクスのピークと変更時刻は一致？
- 不一致なら他要因も
3) 止血（ワークアラウンド）（〜60分）
- ロールバック or フラグ無効化 or トラフィック退避（カナリア／リージョン切替）
- レート制限・キュー一時停止・タイムアウト延長などの被害拡大防止
- ステータスページ＆インアプリ告知（短文テンプレ）
現在、【機能】で障害が発生しています。
影響：{簡潔に}。対応中で、次回更新は{時刻}予定。
4) 恒久対策の設計（止血後〜）
-
根本原因（RCA）仮説 → 検証 → 確証
（再現 → 修正 → 再発防止の証拠） - テストを追加：再現ケースの自動化（ユニット / 統合 / E2E のどれか1つ以上）
- 監視を強化：発生前に検知できたはずの指標を一本増やす
- フェイルセーフ：同系統の単一点障害を無くす（リトライ / サーキットブレーカー / 冗長化）
- ロールバックの所要時間を短縮（手順の自動化 or Runbook化）
5) コミュニケーション（全フェーズ共通）
-
更新頻度：
- S0/S1: 30分毎
- S2: 60分毎に進捗ポスト
-
一枚サマリ（外部 / 内部で文言分け）
- 時刻 / 影響 / 暫定対応 / 次の更新時刻 / 連絡先
-
役割分担（RACIミニ）
- IC（指揮）
- DRV（技術ドライバー）
- COMMS（連絡）
- SCRIBE（記録）
6) 収束条件（Definition of Done）
- 指標が正常範囲に安定（観測窓：少なくとも 30〜60分）
- 再現テストが緑で通る／監視に早期検知が追加済み
- 影響ユーザーへ通知（事後報告／補償要否判断）
- ふりかえりの予定がカレンダーに登録済み
付録A：最小ふりかえりテンプレ（30分）
- 事実：時系列（誰が／いつ／何を）
- 原因：直接原因／誘因／組織要因
- 効いたこと：止血／検知／連携
- 改善：テスト・監視・手順・権限・設計（オーナー／期日）
- 学び：再発防止の原則1行
付録B：禁止事項（よくある罠）
- 再現手順なしで修正着手
- 変更履歴を見ずに憶測で特定
- 連絡チャンネルが分散／指揮が多頭化
- 止血で終わり、恒久対策を先送り
- 事後共有なし（学びが残らない）
付録C：現場ワードの優先度キュー（遭遇率高 → 低）
- ロールバック／フラグOFF
- トラフィック退避
- レート制限
- タイムアウト調整
- キャッシュTTL延長
Discussion