災害復旧とインシデント管理
ログインすると、進捗を複数のデバイスで保存できます。ログインするまでは、このブラウザに保存されます。
なぜ重要なのか
どんなシステムにも、いずれ最悪の日が訪れます。プロバイダーの障害、失敗したマイグレーション、削除されたデータベース、侵害された鍵。エンタープライズも規制当局も、インシデントが起きるかどうかは問いません。問うのは、どれだけ速く検知するか、どう伝えるか、どれだけのデータを失い得るか、どれだけ速く復旧するかです。
学習目標
- システムごとに RPO と RTO を定義し、それを満たすバックアップを設計できる。
- 実際にリストアすることでバックアップを証明できる。
- フェイルオーバーを計画し、マルチリージョンが正当化される場面を理解している。
- 明確な役割とコミュニケーションでインシデントを運営できる。
- 持続可能なオンコール体制を整えられる。
- 実際の修正につながるブレームレスなポストモーテムを書ける。
- 管理されたカオス実験を実施できる。
レッスン
13.1 RPO と RTO（83）
- RPO（Recovery Point Objective、目標復旧時点）: どれだけのデータ損失を許容できるか（例: 5 分）。
- RTO（Recovery Time Objective、目標復旧時間）: どれだけの停止時間を許容できるか（例: 1 時間）。
- システムごとに、ビジネス側と合意して決めます。台帳はほぼゼロの RPO が必要ですが、分析用のキャッシュは再構築できます。
13.2 バックアップ（84）
- 3-2-1 ルール: 3 つのコピー、2 種類の異なる媒体/サービス、1 つはオフサイト（別アカウント/別プロバイダー）。
- プライマリデータベースにはポイントインタイムリカバリ（PITR）を使います。
- 侵害された管理者や暴走したエージェントに削除されないよう、バックアップは イミュータブル にし、別アカウントに置きます。（エージェントや攻撃者が本番環境と一緒にバックアップまで削除するのは、繰り返し起きているインシデントのパターンです。）
- DB 以外もバックアップします: オブジェクトストレージ、シークレット/設定（IaC 経由）、再生成できないサードパーティのデータ。
- リストアしたことのないバックアップは、ただの希望です。 リストア訓練を定期的に実施し、実際の RTO を計測します。
13.3 フェイルオーバーとマルチリージョン（85, 86）
- フェイルオーバー（85）: スタンバイ（レプリカ、セカンダリリージョン、2 社目のプロバイダー）を昇格させます。自動フェイルオーバーには、フラッピングやスプリットブレインを避けるための信頼できる正常性検知が必要です。
- マルチリージョン（86）: グローバルなユーザーのレイテンシを改善し、リージョン障害にも耐えられますが、複雑さ、データ整合性の課題、コストという代償を伴います。ほとんどのスタートアップに必要なのは、アクティブ/アクティブのマルチリージョンではなく、1 つのリージョン内のマルチ ゾーン と、リージョン外へのバックアップです。
- 個人データを国境を越えて複製する前に、データレジデンシー を検討します。
- 単一プロバイダーへの依存（LLM ベンダー 1 社、SMS ゲートウェイ 1 社）: セカンダリを計画しておきます。
13.4 インシデント対応（109）
重大度レベル（例）: SEV1 全面停止、データ侵害、またはお金の動きの誤り。SEV2 主要機能の停止。SEV3 機能低下があるが回避策がある。 役割: Incident Commander（調整し、決定する）、Ops/Tech lead（修正する）、Comms lead（ステータスページ、顧客、規制当局）、Scribe（タイムラインを記録する）。一人会社なら 4 つすべてを自分で担うことになります。考えなくても動けるよう、チェックリストを事前に書いておいてください。 流れ: 検知 → 宣言 → まず緩和する（rollback、フラグをオフ、フェイルオーバー）→ 早めに、定期的に伝える → 解決 → フォローアップ。 侵害の場合は法的な期限のカウントが始まります。例えばシンガポールの PDPA では、侵害が通知対象であると判断してから 3 暦日以内に PDPC へ通知する必要があります（14 · コンプライアンス、ガバナンス、監査 を参照）。
13.5 オンコール（110）
明確なローテーション、エスカレーション経路、すべてのアラートに対する runbook、アラート品質の見直し、呼び出し後の手当/休息。ソロ創業者版: スマートフォンに入れたページングツール、バックアップとして信頼できる外部委託先、そして徹底したアラートの整理。
13.6 ポストモーテム（111）
ブレームレス: 誰が誤ったかではなく、システムがどのようにしてその失敗を許したかに焦点を当てます。テンプレート: 概要、影響（ユーザー、期間、金額）、タイムライン、根本原因と寄与要因（なぜなぜ 5 回）、うまくいったこと、うまくいかなかったこと、運が良かったところ、担当者と期限付きのアクションアイテム。アクションアイテムは完了まで追跡します。
13.7 カオスエンジニアリング（87）
仮説を立て（「LLM プロバイダーが落ちても、ユーザーにはフォールバックが表示され、他は何も壊れない」）、被害範囲を限定し、まず staging で実施し、その後ゲームデイで慎重に本番環境で実施し、計測して直します。実際の障害を注入する前に、机上演習から始めてください。
Lab 13: ゲームデイ
- データストアごとに RPO/RTO を書き、PITR と別アカウントのイミュータブルなバックアップを構成します。
- リストア訓練: 本番のバックアップを新しい環境にリストアし、データを検証し、実際の RTO を記録します。
- ゲームデイ: 講師が予告なしにシステムを壊します（問題のあるデプロイ、漏えいした鍵、プロバイダーの障害、削除されたテーブル）。受講者は役割分担、ステータスページ、コミュニケーションを使ってインシデントを運営します。
- 48 時間以内にポストモーテムを書きます。
完了の定義
AI プロンプトパック
- 「このアーキテクチャについて、『プライマリデータベースが利用不可』のインシデント runbook を書いてください。検知、緩和、コミュニケーション、復旧の手順を含めてください。」
- 「このインシデントのタイムラインを、なぜなぜ 5 回と具体的なアクションアイテムを含むブレームレスなポストモーテムにまとめてください。」