復旧パターン
調査で原因が特定できたら（あるいは特定できなくても）、サービスを復旧させます。
完璧な原因究明より、まず復旧が原則です。特にユーザー影響が出ている場合、復旧してから落ち着いて原因を調査する方が、結果的に影響時間が短くなります。
復旧手段の選択
原因が特定できた場合:
│
├── リリース起因 → ロールバック
├── リソース不足 → スケールアウト / スケールアップ
├── DB 起因 → フェイルオーバー / コネクションリセット
├── 設定起因 → 設定修正
└── 外部サービス起因 → サーキットブレーカー / 一時無効化
原因が特定できない場合:
│
├── 直近 のリリースあり → まずロールバック
├── リリースなし → アプリ再起動
└── それでもダメ → スケールアウト + エスカレーション
パターン別の復旧手順
1. ロールバック
最も速い復旧手段。 直近のリリースが原因の場合、原因調査より先にロールバックする。
Blue-Green の場合（瞬時）:
ロードバランサーのルーティングを旧環境に戻す
→ 数秒で復旧
ローリングアップデートの場合:
前バージョンのイメージで再デプロイ
→ 数分で復旧（旧バージョンのインスタンスが起動するまで）
Kubernetes の場合:
kubectl rollout undo deployment/my-app
→ デプロイ履歴から1つ前に戻す
2. スケールアウト
トラフィック急増やリソース不足が原因の場合。
アプリインスタンスを増やす:
・コンテナのレプリカ数を増加
・オートスケーリングの閾値を一時的に下げる
DB の読み取り負荷を分散:
・Read Replica を追加
・コネクションプーリング（PgBouncer / ProxySQL / RDS Proxy）の導入
キャッシュの容量を増やす:
・Redis ノードの追加 / スケールアップ
3. アプリ再起動
原因不明だが再起動で直る場合（メモリリーク、コネクション枯渇等）。
注意:
・1台ずつ再起動（全台同時はNG → サービス停止になる）
・コンテナオーケストレーション（Kubernetes / ECS）なら
1台停止すると新しいインスタンスが自動起動する
・再起動で直っても根本原因は後で調査する
4. DB フェイルオーバー
DB の Writer ノードに問題がある場合。
マネージド DB のフェイルオーバー:
・Reader が新 Writer に昇格
・エンドポイントが自動更新（アプリ設定変更不要）
・30秒〜1分で完了
・アプリ側は接続エラーが一時的に発生 → コネクションプールが自動再接続
Kubernetes 上のセルフホスト DB の場合:
・Patroni / Stolon 等の HA ツールが自動フェイルオーバー
・手動の場合は pg_ctl promote でスタンバイを昇格
5. 外部サービスの一時無効化
外部 API 呼び出し（Webhook / メール送信等）の遅延が本体に影響している場合。
対策:
① 外部呼び出しの設定を無効化
→ 管理画面や設定 API で該当機能を OFF にする
② 非同期処理のスレッドプール / キューサイズを調整
→ 外部呼び出しが詰まっても本体に影響しないようにする
③ 外部サービスのタイムアウトを短縮
→ HTTP タイムアウトを 30秒 → 5秒 に
→ 応答しない外部サービスに引きずられないようにする
復旧後にやること
復旧完了
│
├── 復旧確認
│ □ ダッシュボードで正常に戻ったことを確認
│ □ 手動でログイン → トークン発行 → UserInfo のテスト
│ □ 主要テナントの動作確認
│
├── 報告
│ □ 「復旧完了」をステークホルダーに報告
│ □ 暫定対応の内容と恒久対応の予定を伝える
│
├── 監視強化
│ □ 再発がないか、しばらく監視を続ける
│ □ 閾値を一時的に厳しくする
│
└── 振り返り準備
□ タイムラインを整理
□ ポストモーテムの日程調整
まとめ
復旧の原則:
1. まず復旧、原因究明はその後
2. リリース直後なら、ロールバックが最速
3. 原因不明なら、再起動を試す
4. 復旧後も監視を続ける
5. 暫定対応と恒久対応を分けて考える
次のステップ
- ポストモーテム: 障害の振り返りと再発防止