第11章：障害対応とトラブルシュート

障害はゼロにはできません。重要なのは「検知→影響限定→復旧→学習」を継続できる運用設計です。
本章では、インシデント対応の型と、Kubernetes で頻出する事象の切り分け方を Runbook/Playbook として標準化するための論点を整理します。

学習目標

• インシデント対応の基本プロセス（役割、Severity、コミュニケーション）を定義できる
• 証跡（メトリクス/ログ/イベント/監査ログ/変更履歴）を確保しながら復旧できる
• 典型事象の切り分けフローをテンプレ化し、運用物として継続改善できる
• ポストモーテムを通じて、監視/標準/変更管理へ改善を戻せる

扱う範囲 / 扱わない範囲

扱う範囲

• インシデント対応の型（体制、手順、証跡、復旧、学習）
• 切り分けの優先順位（変更点、影響範囲、Control Plane/Node/アドオン）
• Runbook/Playbook のテンプレと維持運用
• 付録B（フロー集）を起点にした標準化

扱わない範囲

• アプリケーション固有のデバッグ（コード/依存サービスの深掘り）
• すべての障害シナリオの網羅

インシデント対応の型（最小）

「復旧を急ぐ」ほど証跡が失われ、再発防止が難しくなります。最低限、以下の型を統一します。

1) 検知（監視/通報）と Severity 判定
2) 影響限定（変更凍結、迂回、スケール、隔離）
3) 証跡確保（ログ/メトリクス/変更履歴、必要ならスナップショット）
4) 復旧（暫定復旧→恒久対応の切り分け）
5) 事後レビュー（ポストモーテム、改善のバックログ化）

役割分担（例）

• Incident Commander（IC）: 全体判断、優先順位付け、コミュニケーション統制
• Tech Lead: 技術切り分け、復旧手順の実行管理
• Comms: 対外/対内連絡、ステータス更新、影響説明
• Scribe: 時系列と判断根拠の記録（後のポストモーテムに必須）

切り分けの優先順位（実務）

• 直近の変更（デプロイ、設定変更、アップグレード）を最優先で確認します。
• 影響範囲を「どのテナント/namespace か」「Control Plane か Node か」「ネットワーク/ストレージか」で分類します。
• 復旧操作の前に、ログ/メトリクス/イベント/監査ログの保存方針を確認します（証跡が揮発しやすい環境では特に重要）。

典型事象とフロー（付録Bを起点にする）

頻出の事象はフロー化しておくと、初動のばらつきが減ります。

• API Server に到達できない
• Node が NotReady
• DNS（CoreDNS）が不安定
• Pod が Pending のまま（リソース不足、ノード制約、ストレージ）
• Ingress 到達性障害（LB/Controller/DNS/TLS）
• ストレージ I/O 劣化、Volume Attach 失敗

詳細は 付録B：トラブルシュートフロー集 のフロー雛形を起点に、実運用の事例で更新してください。

Runbook/Playbook テンプレ（雛形）

最低限、以下の項目を埋めると「復旧に繋がる」Runbook になります。

• 目的/適用条件（症状、影響、対象範囲）
• 連絡/エスカレーション（Sev、関係者、顧客影響の扱い）
• 事前条件（権限、break-glass の手順、監査）
• 観測ポイント（ダッシュボード、主要メトリクス、ログ、イベント）
• 切り分け手順（最小の分岐）
• 暫定復旧（影響限定の選択肢）
• 恒久対応（根本原因の除去、再発防止）
• 復旧確認（smoke test、SLO 影響確認）
• 証跡（チケット、時系列、変更内容、ログの保管先）

実務チェック観点（最低5項目）

• Severity 定義と役割分担（IC/Comms/Scribe）が整備され、定期的に演習されている
• 監視/ログ/イベント/監査ログが復旧に使える形で収集され、証跡を残せる
• break-glass（特権操作）の利用条件/承認/証跡/事後レビューが運用されている（第7章）
• 典型事象のフロー（付録B）と Runbook が整備され、オンコールが参照できる
• ポストモーテムからの改善（監視/標準/変更管理への反映）が継続運用されている

よくある落とし穴

• 証跡を取らずに再起動や再デプロイを繰り返し、根本原因の特定と再発防止ができない
• 復旧後に改善がバックログ化されず、同種障害を繰り返す（Runbook が更新されない）

まとめ / 次に読む

• 次に読む: 第12章：自動化と運用標準化