初動対応
アラートが鳴ってから最初の5分が勝負です。この5分で影響範囲の把握と方針決定ができれば、復旧は速くなります。
最初の5分でやること
t=0min アラート受信
│
▼
t=0-1min 状況把握
┌──────────────────────────────────────────────┐
│ □ 何のアラートか？（メトリクス、閾値） │
│ □ いつから？（アラート発火時刻） │
│ □ 今も続いているか？（ダッシュボード確認） │
└──────────────────────────────────────────────┘
│
▼
t=1-2min 影響範囲の判断
┌──────────────────────────────────────────────┐
│ □ 全テナント？特定テナント？ │
│ □ 全機能？特定機能（ログインだけ？トークンだけ？）│
│ □ ユーザーは使えているか？ │
└──────────────────────────────────────────────┘
│
▼
t=2-3min 重大度判定と宣言
┌──────────────────────────────────────────────┐
│ □ Sev レベルを決める（迷ったら高い方） │
│ □ Slack/チャットに宣言 │
│ 「Sev 2: ログインの 5xx 増加、調査開始」 │
└──────────────────────────────────────────────┘
│
▼
t=3-5min 役割分担と方針
┌──────────────────────────────────────────────┐
│ □ IC を決める │
│ □ 調査担当 / 復旧担当 を決める │
│ □ 最初の報告を出す │
│ □ 直近のリリースがあったか確認 │
│ → あれば「ロールバック」が最速の復旧手段 │
└──────────────────────────────────────────────┘
最初に確認するダッシュボード
確認する順番:
① ロードバランサー（外から見た症状）
・5xx エラー率 → サービスがエラーを返しているか
・リクエスト数 → トラフィックの急増/急減はあるか
・レイテンシ → 遅延が発生しているか
・バックエンドヘルス → Unhealthy なインスタンスはあるか
② アプリ（インスタンスの状態）
・稼働インスタンス数 → 停止していないか
・CPU / メモリ使用率 → リソース枯渇していないか
・再起動回数 → クラッシュループしていないか
③ DB（データベースの状態）
・接続数 → コネクション枯渇していないか
・CPU / メモリ → DB がボトルネックか
・レプリカラグ → Reader の遅延
④ キャッシュ（セッションストアの状態）
・ 接続数 → 枯渇していないか
・メモリ使用率 → セッション保存に問題ないか
・Eviction 数 → メモリ不足でデータが追い出されていないか
→ ① で症状を把握 → ②③④ で原因の層を特定
よくある初動パターン
パターン1: リリース直後の障害
状況: 新バージョンをデプロイした直後に 5xx 増加
確認:
□ デプロイ時刻とアラート時刻が一致するか
□ 新バージョンのタスクだけがエラーを出しているか
対応:
→ ロールバックが最速
→ Blue-Green ならロードバランサーの重みを Blue に戻すだけ
→ ローリングアップデートなら前バージョンに rollback
原因調査はロールバック後に落ち着いてやる
パターン2: トラフィック急増
状況: 通常の3倍のリクエストが来ている
確認:
□ 正当なトラフィック増か（キャンペーン等）
□ 攻撃（DDoS/ブルートフォース）か
□ 特定テナントに集中しているか
対応:
→ 正当な増加: インスタンス数を増やす（スケールアウト）
→ 攻撃: WAF でブロック、レート制限を強化
→ 特定テナント: テナント別にレート制限
パターン3: DB 接続エラー
状況: DB への接続がエラーになっている
確認:
□ DB のステータス（管理コンソール）
□ コネクションプールの使用率
□ DB の CPU / メモリ
□ RDS のイベントログ（フェイルオーバー等）
対応:
→ コネクション枯渇: アプリの max-pool-size を確認、再起動
→ DB 障害: クラウドプロバイダーのステータスページ確認、サポートケース起票
→ フェイルオーバー発生: 自動回復を待つ、接続エラーは一時的
パターン4: 原因不明のレイテンシ悪化
状況: エラーは出ていないが、レスポンスが遅い
確認:
□ どのエンドポイントが遅いか（/v1/tokens? /v1/authorizations?）
□ DB のスロークエリログ
□ GC ログ（JVM のフルGC が発生していないか）
□ 外部サービス呼び出しの遅延（Federation、Webhook等）
対応:
→ スロークエリ: EXPLAIN で実行計画確認、インデックス追加
→ GC: ヒープサイズ調整、メモリリーク調査
→ 外部サービス: タイムアウト設定確認、サーキットブレーカー
やってはいけないこと
❌ アラートを無視して「様子見」
→ 症状が悪化してから対応すると復旧が長引く
❌ 原因を完全に特定してから行動する
→ ロールバックで復旧してから調査する方が速い
❌ 1人で抱え込む
→ 5分で解決しなければ人を呼ぶ
❌ 本番環境で「試しに」設定変更する
→ 変更前の状態を記録してから行う
→ できれば2人以上で確認（ダブルチェック）
❌ 報告を忘れる
→ 復旧作業に集中しすぎて、ステークホルダーが状況を知らないのは最悪
まとめ
最初の5分:
1分目: 何が起きているか把握（ダッシュボード確認）
2分目: 影響範囲の判断（全テナント？一部？）
3分目: 重大度を宣言（Sev X として Slack に投稿）
5分目: 方針を決める（ロールバック or 調査続行）
原則:
・リリース直後なら、まずロールバック
・原因調査は復旧してからでいい
・5分で解決しなければ人を呼ぶ
・沈黙はNG、「調査中」でも報告する
次のステップ
- 調査の進め方: 原因を特定する方法