大規模システムの運用において、障害は「発生しないもの」ではなく「必ず発生するもの」として捉える必要があります。エキスパートエンジニアは、障害発生時の被害を最小限に抑え、サービスを迅速に復旧させるための包括的な計画、すなわちディザスタリカバリ（DR）計画を策定し、実行する責任を負います。
この章では、システムの耐障害性を高める設計、主要なDR指標、および具体的なリカバリ戦略について解説します。
1. 障害対策設計の基本原則
システムが単一障害点（Single Point of Failure: SPOF）を持たず、高い耐障害性を持つように設計することが、DR計画の出発点となります。
A. 冗長化と多重化
サーバー/アプリケーション: 負荷分散（ロードバランサー）の下で複数のインスタンスを稼働させます。これにより、一つのインスタンスがダウンしても、残りのインスタンスが処理を引き継ぎ、サービスを継続できます。
データベース: プライマリデータベースに対して、レプリカ（リードレプリカ、スタンバイなど）を準備し、プライマリ障害時に即座に切り替えられるようにします（フェイルオーバー）。
ネットワーク: 冗長なネットワークパスや複数のISP（インターネットサービスプロバイダー）を利用し、ネットワーク機器の障害に備えます。
B. 障害分離（フォールトアイソレーション）
マイクロサービス: サービス間を疎結合に保つことで、一つのサービスで発生した障害（例：メモリリークや無限ループ）が、他のサービス全体に波及するのを防ぎます（サーキットブレーカーパターンの利用）。
リソース制限: 各サービスやコンポーネントが利用できるリソース（スレッド数、接続プール数など）に制限を設けることで、リソースの枯渇による全体障害を防ぎます。
2. ディザスタリカバリ（DR）計画の指標
DR計画を評価・設計する上で、以下の2つの時間指標が不可欠です。
A. RTO（目標復旧時間: Recovery Time Objective）
定義: サービスが停止した後、許容される最大限の停止時間です。サービスが完全に復旧し、通常運用に戻るまでの目標時間を示します。
例: 「ECサイトの決済機能は、障害発生から15分以内に復旧させる」
重要性: RTOが短いほど、よりコストのかかるインフラストラクチャ（アクティブ/アクティブ構成など）が必要になります。
B. RPO（目標復旧時点: Recovery Point Objective）
定義: 障害発生によって失っても許容できるデータ量の最大値です。つまり、データが最後にバックアップされた時点と障害発生時点との間の最大許容間隔です。
例: 「データ損失は直近5分以内に留める」
重要性: RPOが短いほど、より頻繁なデータのレプリケーション（同期）が必要となり、ネットワーク帯域やストレージのコストが増大します。
3. ディザスタリカバリの主要な戦略
RTOとRPOの要件に応じて、システムのリカバリ戦略はいくつかのパターンに分類されます。
A. バックアップ＆リストア (Backup and Restore)
特徴: RPO/RTOが最も長い、基本的な戦略です。データを定期的にバックアップし、障害発生時にデータをリストアし、インフラを再構築します。
用途: RTOが数時間〜数日、RPOが数時間〜24時間程度許容される、重要度の低いシステム。
B. パイロットライト (Pilot Light)
特徴: DRサイト（予備のデータセンター）に、データベースや最低限のインフラ（「種火」となるコアコンポーネント）だけを起動・レプリケートしておきます。障害時に、すぐにアプリケーションサーバーなどのコンポーネントを立ち上げます。
RTO/RPO: RTOは数十分〜数時間、RPOはレプリケーションの頻度による。
C. ウォームスタンバイ (Warm Standby)
特徴: DRサイトに、最小限の容量で動作しているシステム全体を常に稼働させておきます。本番サイトがダウンした場合、DRサイトをスケールアップすることで対応します。
RTO/RPO: RTOは数分〜数十分、RPOは数秒〜数分。多くのミッションクリティカルなシステムがこのレベルを採用します。
D. マルチサイト（アクティブ/アクティブ）
特徴: 複数の地理的に離れたサイト（リージョン）で、両方ともアクティブにトラフィックを処理します。いずれかのサイトが完全にダウンしても、残りのサイトがシームレスに全トラフィックを引き受けます。
RTO/RPO: RTOはほぼゼロ、RPOはほぼゼロ（リアルタイム同期）。最もコストが高く、複雑な設計が求められます。
4. DR計画のテストと運用
DR計画は策定するだけでなく、定期的にテストし、検証することで初めて意味を持ちます。
定期的な訓練（ディザスタリカバリ・ドリル）: 年に一度など、定期的に本番環境をシミュレートした障害復旧訓練を実施します。これにより、手順書の正確性を確認し、チームメンバーの習熟度を高めます。
復旧手順の文書化: 障害発生時にパニックにならないよう、復旧手順、担当者、連絡先を明確に文書化し、アクセスしやすい場所に保管します。
バックアップの検証: バックアップデータが実際にリストア可能であることを定期的にテストし、バックアップの破損や不備がないことを確認します。
変更管理との統合: インフラや設定の変更は、DRサイトにも正確に反映されるように、CI/CDパイプラインに統合します。
エキスパートエンジニアは、これらの計画を実行・維持することで、サービスの信頼性（Reliability）を保証する最終的な役割を担います。