DR ドライテスト

ドライテストとは、DR計画を紙ベースで練習することです。 ドライテストではリカバリーは行わないが、プランに明らかな穴がないかをチェックする。 例えば、ドライ・テストは以下のことを確認するのに役立つ：

• 適切な人材がいる
• バックアップが存在し、利用可能である
• 担当者間のコミュニケーション・チャンネルが機能している
• DRランブックに欠落したステップがない
• チーム間のハンドオフが効率的に行われる

DRドライ・テストは、他のテストと同じように、スキルと人材の面で努力を必要とする。 実際のリカバリー・アクションは実行されないため、このタイプのテストはより高速であり、通常、他のテスト・タイプと比較して高い頻度で実行される。 プラン全体をテストするか、プラン内の個々のパーツやサービスをテストするかを選択できます。

DR シミュレーション

DRシミュレーションは、実際の緊急事態の状況をシミュレートし、データをリストアすることによって、緊急時のランブックを検証または監査し、ソリューションが提供する 復旧時間目標災害復旧計画において、災害後にビジネスプロセスが復旧するまでの時間。 （RTO）と 復旧時点目標災害復旧計画において、データが復旧するまでの時間は、復旧時点から災害発生時点までを秒、分、時間で測定した時間である。 （RPO）をチェックする方法である。

DRシミュレーションは、本番ワークロードへの影響を避けつつ、プライマリー地域からのデータレプリケーションに潜在的な中断をもたらすため、慎重な計画が必要です。 DR環境をテストしている間、実際のディザスタリカバリ目的では一時的に利用できなくなる可能性があります。 このリスクは、特定のクラウド・サービスとその展開方法に依存する。 サービスによっては、同時にテストや利用が可能な場合もあれば、そうでない場合もある。

DRシミュレーションは、テストと検証のために、指定されたDR地域に本番環境の一時的なコピーを作成します。 シミュレーション終了後、テスト環境は削除またはリセットされ、テスト中に加えられた変更はすべて破棄されます。

スイッチオーバー

切り替えには、生産環境をあるリージョンから別のリージョンに切り替えることが含まれる。 この方法は、代替地域で長期間にわたって生産活動を実行し、維持する能力を検証し、監査するのに役立つ。 本番オペレーションは、第一のリージョンで優雅に停止させられ、第二のリージョンに切り替えられ、必要とされる可能性のあるデータ復元後に再開される。

2つ目のリージョンが期待どおりに動作することを確認したら、本番稼動を再開し、元のリージョンを新しいセカンダリ・リージョンとするようにデータレプリケーションを構成することができます。 本番環境は、再び切り替えることを決めるまで、このサイトから実行され続ける。

DRテストの頻度

DR計画をどの程度の頻度でテストするかは、規制コンプライアンス基準で義務付けられていることを含め、多くの要因によって決まります。 コンプライアンスに懸念がない場合は、少なくとも年に1回は完全なDRテストを実施し、監査人のレビュー用に結果を文書化することを目指す。 年間を通じて小規模なテストを実施し、準備態勢を整えるのは良い習慣だ。

以下の質問を検討し、テスト頻度を調整してください：

私の仕事量はどの程度ダイナミックなのか？

ワークロードが変化すればするほど、何らかの形でDRテストを実施する必要がある。 こうすることで、その変更が回復能力に影響しないことを確認できる。 変更には、新しい依存関係、他のクラウドサービス、インフラの変更などが含まれる。 データセットの増大は復旧に時間がかかるため、特定のRTOを満たす能力に影響を与える可能性がある。

私のスタッフはどの程度ダイナミックなのか？

テスト頻度については、スタッフの入れ替わりも考慮するとよい。 リカバリーを実行するスタッフが変わる場合は、新しいメンバーがDRの仕組みとDR計画における自分の役割を理解していることを確認する。 もし不安な新しいチームメンバーが何人もいたり、DRテストに慣れていなかったりすると、復旧計画にリスクが加わることになる。

私のテストは他に何を重視すべきでしょうか？

災害復旧テストの主な目的は、ワークロードを正常に復旧できるかどうかを確認することです。 ただし、以下もうまく機能していることを確認すること：

• 主要要員：DR計画では、復旧を成功させるために必要な人員とその役割について概説する。 テスト中、より多くの人員や役割が必要なのか、あるいは余剰人員はいるのか、また、その役割をどの程度果たすことができたのかを検討する。
• コミュニケーション：DR計画では、災害が発生した場合のコミュニケーション方法を明確に定めておかなければならない。 使用されたコミュニケーション・チャンネルを含め、参加者間のコミュニケーションが試験中にどの程度機能したかを検討する。
• 文書化された依存関係：DR計画には、依存関係の概要が記載されている可能性が高い。 これらが有効であり、復旧プロセスの妨げにならないことを確認する。 同時に、新しい依存関係が記録されていることを確認する。
• その他の文書：ランブックはリカバリーを実施するために使用される可能性があるため、その正確さと効果を理解することが重要である。 ステップの文書化が不十分だと、遅れにつながる可能性がある。一方、詳細すぎたり、関連性のない詳細を提供したりすると、同じ効果があるかもしれない。 手順が明確であることを確認するために、著者以外の人にテストしてもらう。 こうすることで、災害時に作者が不在でもプロセスが利用できる。

テスト後

テストが終了したら、次のテストの基準として結果を記録する。 後でテスト手順を変更しても、結果を簡単に比較できる。

各災害復旧テストの後、その結果に基づいて計画と関連文書を更新する。 DR計画は生きた文書であり、効果を維持するためには定期的な調整が必要である。 参加者からのフィードバックを活用して、うまくいった点とそうでなかった点を特定し、その洞察を今後のテストに反映させる。 また、役割の明確化、コミュニケーションの改善、技術的スキルの向上など、必要であればさらなる研修の実施を検討する。