ストーリー
佐
佐藤CTO
プロセスを知っていても、実際のインシデントは教科書通りにはいかない
佐
佐藤CTO
トリアージ、並行調査、ミティゲーション判断 — これらの実践的スキルが、障害時間を半分にする
トリアージの実践
最初の5分間チェックリスト
□ 何が壊れているか？（症状の確認）
□ いつから発生しているか？（タイムラインの開始点）
□ 影響範囲は？（ユーザー数、地域、機能）
□ 何か変更があったか？（デプロイ、設定変更、インフラ変更）
□ ワークアラウンドはあるか？トリアージの判断基準
| 条件 | 判定 |
|---|---|
| 全ユーザーが主要機能を使えない | P1 → War Room即設置 |
| 一部ユーザーまたは一部機能に影響 | P2 → IC任命、チーム招集 |
| 影響は限定的、ワークアラウンドあり | P3 → 担当チームで対応 |
| ユーザー影響なし | P4 → 通常対応 |
並行調査テクニック
仮説駆動型調査
仮説1: 直近のデプロイが原因
└─ 調査: デプロイ履歴確認、ロールバック検討
仮説2: インフラ障害（AWS等）
└─ 調査: AWS Status確認、CloudWatch確認
仮説3: 外部依存サービスの障害
└─ 調査: 依存サービスのヘルスチェック
仮説4: トラフィック急増
└─ 調査: リクエスト数、CPU/メモリの確認調査の並列化
| 担当者 | 調査領域 | 確認事項 |
|---|---|---|
| エンジニアA | アプリケーション | ログ、エラー率、レスポンスタイム |
| エンジニアB | インフラ | サーバーメトリクス、ネットワーク |
| エンジニアC | データベース | クエリ性能、コネクション数、ロック |
| エンジニアD | 外部依存 | 外部API、CDN、DNS |
ミティゲーション vs 根本修正
判断フレームワーク
| 状況 | 推奨アクション |
|---|---|
| 直近のデプロイ後に発生 | 即座にロールバック |
| トラフィック急増が原因 | スケールアウト + レート制限 |
| 特定のリクエストパターンが原因 | WAFでブロック + 後で修正 |
| データ不整合が原因 | 影響データの修正 + 根本修正 |
| 外部サービス障害 | フォールバック有効化 + 監視 |
ロールバック判断基準
ロールバックすべき場合:
✓ デプロイ直後（30分以内）に問題発生
✓ 問題の原因がデプロイ変更に明確に関連
✓ ロールバックによる副作用が小さい
ロールバックすべきでない場合:
✗ DB マイグレーションを含むデプロイ（後方互換性なし）
✗ 外部サービスの障害が原因
✗ ロールバックにより別の問題が発生するインシデント中のドキュメント
タイムラインの記録
[14:00 JST] アラート検知: payment-service のエラー率が50%超過
[14:03 JST] IC: 田中がIC就任、#inc-20260214-payment 作成
[14:05 JST] トリアージ: P1判定、War Room設置
[14:10 JST] 調査開始: アプリチーム（ログ）、インフラチーム（メトリクス）
[14:15 JST] 発見: 14:00のデプロイ後にDB接続エラーが急増
[14:20 JST] 判断: ロールバック実施
[14:25 JST] ロールバック完了、エラー率低下を確認
[14:35 JST] 正常復帰を確認、監視強化フェーズへ
[15:00 JST] インシデントクローズまとめ
| ポイント | 内容 |
|---|---|
| トリアージ | 最初の5分で影響範囲と重大度を判定 |
| 並行調査 | 仮説を立て、複数チームで同時に調査 |
| ミティゲーション | 根本修正より先にユーザー影響を軽減 |
| ドキュメント | リアルタイムでタイムラインを記録 |
次のステップへ
次は根本原因分析（RCA）の手法を学びます。
推定読了時間: 30分