Kubernetes障害対応ランブック実践編：15分で切り分け、60分で復旧するための現場手順
Kubernetes障害対応ランブック実践編：15分で切り分け、60分で復旧するための現場手順 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から影響を数値化 「遅い気がする」ではなく、以下を数値で押さえます。 ...