「今すぐ直して」は最悪の対応を生む
深夜 2 時のアラート通知。「本番 DB 接続エラー。売上影響あり」——こうした状況でプレッシャーをかけられながら場当たり的に動くと、復旧に 3 時間かかることも珍しくありません。
インシデント対応を構造化されたプロセスとして実行できるエンジニアは、同じ障害を 30 分で収束させます。
ステップ 1：検知と分類（Detection & Triage）
最初の 5 分で「何が起きているのか」を把握します。
確認すべきこと：
- 影響範囲：全ユーザー？特定地域？特定機能？
- 発生時刻：いつから？デプロイ直後か？
- 重大度：売上影響あり？データ損失の可能性？重大度分類の例（Severity Level）
| レベル | 定義 | 例 |
|---|---|---|
| SEV-1 | 全サービス停止・データ損失リスク | 本番 DB クラッシュ |
| SEV-2 | 主要機能に影響・一部ユーザー | 決済フロー全断 |
| SEV-3 | 一機能に影響・回避策あり | 検索が遅い |
| SEV-4 | 軽微・ユーザー影響なし | ログが出ない |
ポイント：重大度を決めると「誰を呼ぶか」「どこまで作業を止めて集中するか」が決まります。
ステップ 2：コミュニケーションの確立（Communication）
SEV-1/2 の場合、最初にインシデントコマンダーを 1 人決めます。
インシデントコマンダーの役割：
- Slack チャンネル（#incident-2026xxxx）を作成
- 状況を 5〜10 分ごとにステークホルダーに共有
- 対応担当者を割り振る
- 意思決定の最終権限を持つコマンダーはコードを書かない。対応と報告に専念することで、技術担当者が集中できます。
「今どうなってるの？」という質問が飛び交う状況は、コミュニケーション構造がないサインです。
ステップ 3：封じ込め（Containment）
完全な原因特定より先に、被害拡大を止めるのが優先です。
代表的な封じ込め手段
- ロールバック：直前のデプロイが原因なら即戻す
- フィーチャーフラグ OFF：問題機能を無効化
- トラフィック制限：問題のあるエンドポイントへの流入を絞る
- フェイルオーバー：バックアップ系に切り替え
# Kubernetes でのロールバック例
kubectl rollout undo deployment/api-server
kubectl rollout status deployment/api-server「原因がわからなくても、ロールバックで直れば今は OK」——完璧主義を捨てることが収束速度を上げます。
ステップ 4：根本原因の特定と解決（Resolution）
封じ込めでサービスが回復したら、本格的な原因調査に移ります。
ログの読み方
# エラーログを時系列で見る
grep "ERROR" app.log | tail -100
# インシデント発生時刻前後 5 分を抽出
awk '/2026-04-25 02:00/,/2026-04-25 02:10/' app.log | grep ERROR
# 特定リクエストを追跡（Correlation ID で）
grep "req-id-abc123" app.log5 Why 分析（根本原因を深掘り）
問題：本番 DB への接続エラーが発生した
Why 1：なぜ接続エラーが起きた？→ 接続プールが枯渇したから
Why 2：なぜ枯渇した？→ 接続がリリースされず溜まり続けたから
Why 3：なぜリリースされなかった？→ 例外発生時に finally でクローズしていなかったから
Why 4：なぜ finally がなかった？→ レビュー基準に含まれていなかったから
Why 5：なぜ基準になかった？→ リソース管理のガイドラインが未整備だったから
根本原因：コーディングガイドラインの欠如ステップ 5：事後分析（Post-Mortem）
責任追及ではなくシステム改善を目的としたふりかえりが Post-Mortem です。
Post-Mortem テンプレート
## インシデント概要
- 発生日時：2026-04-25 02:07 JST
- 復旧日時：2026-04-25 02:43 JST（所要 36 分）
- 影響：決済機能が 36 分停止、推定 140 件の注文失敗
## タイムライン
- 02:07 アラート発報
- 02:12 インシデントコマンダー設置
- 02:25 ロールバック実施
- 02:43 完全復旧確認
## 根本原因
接続プールの finally 漏れ（コードレビューで見落とし）
## アクションアイテム
| アクション | 担当 | 期限 |
|-----------|------|------|
| コーディングガイドラインに finally 必須を追記 | 田中 | 4/30 |
| 接続プール使用率のアラート設定 | 鈴木 | 4/28 |
| E2E テストに接続枯渇シナリオ追加 | 佐藤 | 5/07 |Blameless Post-Mortem の鉄則：「誰が悪いか」を議論しない。「何が起きたか・なぜ起きたか・どう防ぐか」に集中する。
まとめ
1. 検知・分類 → 影響範囲と重大度を5分で把握
2. コミュニケーション → コマンダーを立てて情報を一元化
3. 封じ込め → 原因不明でもロールバックで止める
4. 解決 → ログ・5 Why で根本原因を特定
5. Post-Mortem → 責任追及でなくシステム改善に繋げるこの 5 ステップを体に馴染ませておけば、深夜の緊急対応でも冷静に動けます。