Kubernetes で障害が起きたとき、技術力より先に問われるのは「順序」です。順序が崩れると、正しいコマンドを打っていても復旧が遅れます。逆に、判断フレームが決まっていれば、難しい障害でも被害を最小化できます。

本記事では、実運用で使える障害対応ランブックを、初動 15 分・復旧 60 分を目安に具体化します。対象は EKS/GKE/AKS を含む一般的な Kubernetes 本番環境です。

1. 最初の5分：人と情報の交通整理

まずやるべきは技術調査ではなく、交通整理です。

• インシデントの指揮者（IC）を1人決める
• ログ担当、メトリクス担当、アプリ担当を分ける
• Slack/Discord の専用チャンネルを作る
• 5分ごとの時系列ログ（タイムライン）を残す

この段階で「誰が何を見ているか」が曖昧だと、同じ調査を3人で繰り返し、誰も復旧判断をしない状態になります。ICは手を動かさず、意思決定に集中するのが基本です。

2. 5〜15分：影響範囲の特定

次に「どのユーザーに、どの機能で、何%の影響があるか」を確定します。

2-1. まず全体の健康状態

1
2
3

kubectl get nodes
kubectl get pods -A --field-selector=status.phase!=Running
kubectl get events -A --sort-by=.lastTimestamp | tail -n 50

見るポイント:

• Node が NotReady になっていないか
• 特定 namespace だけで CrashLoopBackOff が増えていないか
• 直近イベントに FailedScheduling や Back-off restarting failed container がないか

2-2. SLO/SLIから影響を数値化

「遅い気がする」ではなく、以下を数値で押さえます。

• エラー率（5xx / total）
• p95 / p99 レイテンシ
• リクエスト成功率
• 影響時間（何時何分から）

復旧優先順位は「売上影響」「決済影響」「ログイン影響」で並べると迷いにくいです。

3. 典型障害ごとの切り分けテンプレート

3-1. Podが再起動ループする

1
2

kubectl describe pod <pod-name> -n <ns>
kubectl logs <pod-name> -n <ns> --previous

判断軸:

1. アプリ起因（例: マイグレーション失敗、環境変数不足）
2. リソース起因（OOMKill, CPU スロットリング）
3. 依存先起因（DB接続失敗、外部APIタイムアウト）

OOMKill が見えたら、即座に requests/limits の見直し候補です。緊急回避として replicas を増やすより、まずメモリリークや一時的負荷スパイクの切り分けを優先します。

3-2. Podは生きているのに503が増える

1
2
3

kubectl get endpoints -n <ns>
kubectl describe svc <service> -n <ns>
kubectl get deploy <deploy> -n <ns> -o yaml | grep -n "readinessProbe\|livenessProbe"

よくある原因:

• readinessProbe が厳しすぎて endpoint から外れ続ける
• 依存先劣化で app は起動しているが実処理が詰まる
• HPA は増えているが、DB 接続プールが上限で飽和

このケースでは「Pod数が多いのにエラーが減らない」ので、アプリ外（DB、キュー、外部API）を疑うのが早いです。

3-3. 特定ノードでのみ障害

1
2
3

kubectl describe node <node>
kubectl top node
kubectl get pods -A -o wide | grep <node>

ノード隔離が必要なら、以下で新規スケジュールを止めます。

1
2

kubectl cordon <node>
kubectl drain <node> --ignore-daemonsets --delete-emptydir-data

drain は影響が大きい操作なので、IC の明示承認を挟むのが安全です。

4. 復旧アクションの優先順位（実務向け）

障害中は「恒久対策」を始めないこと。順番は固定します。

1. 被害抑制: feature flag で重い機能を止める
2. 暫定復旧: 直前の安定リビジョンへロールバック
3. 性能確保: replicas/HPA 一時調整、キュー消化速度調整
4. 恒久対策: 根本修正は障害収束後にPRで実施

4-1. ロールバックの型を決めておく

1
2
3

kubectl rollout history deployment/<deploy> -n <ns>
kubectl rollout undo deployment/<deploy> -n <ns> --to-revision=<rev>
kubectl rollout status deployment/<deploy> -n <ns>

ポイントは「戻す判断に迷わない基準」を事前に定義しておくことです。

• 5分間で 5xx > 2% 継続
• p95 が通常比 2倍超を 10分継続
• ログイン/決済失敗が監視閾値超え

基準がないと、誰も責任を取りたくなくて引き延ばしになります。

5. 事後対応（Postmortem）で必ず残すべきもの

障害対応の価値は、復旧速度だけではありません。再発率を下げて初めて完了です。

最低限残す項目:

• 発生時刻、検知時刻、復旧時刻
• ユーザー影響（件数、売上影響）
• 技術的原因（直接原因 / 背景要因）
• うまくいった対応、失敗した判断
• 再発防止のアクション（担当者・期限付き）

5-1. アクションを「監視」に落とす

「次は気をつける」は効果ゼロです。必ず機械化します。

例:

• CrashLoopBackOff > N件 を5分継続で即アラート
• DB接続待ち時間の p95 をダッシュボード化
• リリース直後30分は自動で高感度監視モード

6. そのまま使える障害対応チェックリスト

初動チェック（0〜15分）

• IC決定、連絡チャンネル作成
• 影響範囲（機能・ユーザー・売上）を数値化
• Node / Pod / Event の全体確認
• 直近デプロイ有無の確認

復旧チェック（15〜60分）

• 被害抑制（feature flag / トラフィック制御）
• ロールバック判断基準を満たすか確認
• 復旧後 15 分の再監視（再発確認）
• ユーザー向けステータス更新

事後チェック（24時間以内）

• Postmortem 作成
• 再発防止チケット発行
• 監視ルール・Runbook 更新

まとめ

Kubernetes 障害対応は、個人技で勝つゲームではありません。誰でも同じ順序で動ける運用設計が最も効きます。特に「初動の交通整理」「ロールバック基準の明文化」「事後の監視自動化」の3点は、復旧時間と再発率を同時に改善します。

次の障害が来たときに迷わないよう、今日のうちにこのランブックを自チーム用に1ページ化しておくことを強くおすすめします。

7. 障害を早く終わらせるための役割分担テンプレート

実際の現場では、技術調査よりコミュニケーションで詰まることが多いです。そこで、あらかじめ役割を固定しておくと復旧が速くなります。

• IC（Incident Commander）: 優先順位決定、Go/No-Go判断、対外連絡承認
• Ops Lead: クラスタ状態確認、ロールバック実行、インフラ変更の安全確認
• App Lead: アプリログ解析、機能フラグ切り替え、暫定パッチ判断
• Comms: 社内・顧客向けステータス更新、問い合わせ窓口統一

この分担があると、「調査担当が勝手に危険操作を実施する」「連絡が多重化して混乱する」といった二次被害を防げます。

8. よくあるアンチパターンと回避策

アンチパターン1: まず再デプロイしてしまう

原因が不明なまま再デプロイすると、証拠ログを失い再現不能になります。最低限 events と previous logs を保存してから操作します。

アンチパターン2: 「たぶん直った」でクローズする

復旧後 15 分の監視を省くと、同じ障害が波状的に再発します。復旧宣言は「指標が閾値内で安定した」ことを条件にします。

アンチパターン3: 障害後の改善が担当者依存

改善をドキュメント化せず担当者の記憶に任せると、同じ夜間障害を繰り返します。Runbook への反映までをインシデント完了条件に含めるべきです。