災害復旧テストのシナリオ概要
現代の企業には、24時間365日の稼働が求められています。業務やサービスの提供において、わずかな遅延であっても、組織の信頼性を損ない、多大な損失につながる可能性があります。業務の停止につながる要因は多岐にわたりますが、その主なものは、常に予期せぬタイミングで発生する災害です。 したがって、市場での競争力を維持し、事業継続を確保するためには、組織が効率的な災害復旧(DR)計画を策定し、定期的にテストを行うことが重要です。このブログ記事では、DR計画のテストを行う前に検討すべき要素を挙げるとともに、DRテストのシナリオを実践することが、災害復旧への備えにどのように役立つかを解説します。
DR計画とは？
一般的に、災害は予測不可能であり、常に予期せぬ形で発生します。そのため、高可用性を重視する組織は、DR計画を策定する必要があります。DR計画とは、災害が組織のITインフラに影響を及ぼした際に実施すべき一連のタスクや手順を文書化したものです。その主な目的は、災害による悪影響を最小限に抑え、起こりうる損害を防ぐことにあります。包括的なDR計画では、災害の前、最中、そして後にどのような行動を取るべきかが定められています。
災害には、自然災害(竜巻、ハリケーン、洪水など)と人為的災害(サーバーエラー、更新の失敗、ハッカー攻撃など)の2種類があります。DR計画は、組織が最も被りやすいリスクや脅威に基づいて作成する必要があります。さらに、事業運営において最も重要な業務やアプリケーションを特定し、復旧順序において最優先順位を付ける必要があります。 こうした要素を事前に検討しておくことで、実際のDR発生時に生じうるあらゆる問題に、DR計画が確実に対応できるようになります。
DR計画のテスト前に考慮すべき要素
DR計画を作成したら、そのテストの準備を整える必要があります。効率的で綿密なDR計画を策定したと確信している場合でも、すべてが計画通りに機能することを確認し、問題があれば事前に特定しておくべきです。 しかし、DR計画をテストする前に、テストの前提条件、テスト範囲、テストの成功基準など、プロセスの成功を確実にするために考慮すべきいくつかの要素があります。
テストの前提条件
テスト準備の最初のステップは、テストの前提条件を定義することです。DRテストに先立ち、復旧チームは最適な結果を得るためにどのような方向性で進めるべきかについて協議する必要があります。基本的に、テストの前提条件は、DRテストのプロセスを構築するための基盤となります。 包括的なテスト前提条件には、以下のものが含まれます。
- 組織が最もさらされているリスクや脅威、およびテスト対象となるそれぞれの対応策
- 実施するDRテストのシナリオと、その選択の根拠
- DRテストの実施に必要なテスト前の条件や状況
- テスト終了時に満たされる必要があるテスト後の条件や状況
- テストプロセス後に達成されることが期待される結果
テスト範囲
もう1つの重要な要素 検討すべき点は、テスト範囲です。これは、テストプロセスで対象とする領域を概説するものです。復旧チームは、どのシステムコンポーネントや機能をテストすべきかを明確に定め、DRテストに関与するシステムの担当者に通知する必要があります。また、復旧チームは、テストプロセスの制限事項や除外事項を定義し、何がテスト対象で何が対象外かを正確に把握することで、事前の混乱を回避すべきです。
テストの成功基準
テストの成功基準は、DRテストプロセスがいつ成功裏に実施されたとみなせるかを決定するものです。 テスト結果を確認することで、期待通りの結果が得られたか、またどの分野に改善の余地があるかを判断できます。DR計画の機能性と有効性が実証されれば、DRテストは一般的に成功したとみなされます。しかし、DRテストの過程でDR計画の弱点が特定された場合も、これも成功とみなすことができます。これにより、復旧チームは対策を策定し、欠陥を修正することで、DR計画を改良することが可能になります。 さらに、テストの成功基準により、スタッフはDRテスト中の自身のパフォーマンスを評価し、組織の災害対応メカニズムを改善することができます。
したがって、予期せぬ問題に備え、適切に対応できるよう、プロセスのすべてのステップを文書化し、テストの前提条件、テスト範囲、およびテストの成功基準を事前に決定することが重要です。
DRテストシナリオとは？
DRテストの実施は非常に困難な作業となり得るため、事前の準備なしにDR計画のすべての構成要素をテストすることは現実的ではありません。 DR事象発生時にDR計画が確実に機能するようにするためには、特定の緊急事態に対して組織がどのように対応するかを確認する必要があります。この目的のために、DRテストシナリオを活用することができます。災害シナリオは、組織のあらゆる側面を考慮に入れて復旧チームが作成することもできますし、オンラインで入手可能な既製のDRシナリオテンプレートを適用することもできます。
一般的なDRテストシナリオでは、通常、DR事象そのもの、その状況、およびそれが当該組織にどのような影響を与えたかが記述されます。DR事象をシミュレートすることで、DRプロセスに対する組織の準備状況を評価し、実際の災害(自然災害または人為的災害)への対応および復旧に向けたより良い方法を特定することができます。
DRテストシナリオの種類
災害復旧(DR)テストのシナリオは、組織のパフォーマンスに何らかの影響を及ぼす可能性のある、さまざまな緊急事態や災害事象を網羅しています。 これらのDRテストシナリオが何を意味するのか、詳しく見ていきましょう。
業務の停止
ほとんどの組織は複雑なシステムを構成しており、その構成要素は相互に強く依存し合っています。したがって、それらの構成要素の1つが故障した場合、システム全体が停止のリスクにさらされることになります。多種多様な運用上の問題を網羅したDRテストシナリオを設計する必要があります。 この目的のためには、あらゆる重要な業務／プロセスと、それらに悪影響を及ぼしたり損害を与えたりする可能性のあるDR事象について検討してください。
この種の災害復旧テストシナリオには、一般的に、組織の業務パフォーマンスを妨げる可能性のあるあらゆる緊急事態が含まれます。業務に関連するDR事象の例としては、生産センターでの火災や爆発、ソフトウェアの誤動作による主要な組立ラインの停止、あるいは人為的ミスによるワークフローの中断などが挙げられます。
技術的な問題
業務の大部分が仮想サーバー環境で稼働している場合、技術関連のDRシナリオをシミュレートすることを最優先すべきです。システム障害が発生した場合、業務が再開されるまでに時間がかかる可能性があります。したがって、組織の業務遂行に重大な影響を及ぼしうる技術的な問題を反映したDRテストシナリオを設計することが不可欠です。こうした問題には、サーバーの障害、ネットワーク接続の途絶、ソフトウェアの不具合、データの損失、またはバックアップへのアクセス不能などが含まれます。
主要スタッフの喪失
スタッフは、いかなる組織においても不可欠な存在であり、従業員は緊急事態に真っ先に直面し、対応する役割を担っています。経営陣は、DRプロセスを最初から最後まで実施・監視する責任を担う復旧チームを結成すべきです。しかし、復旧チームの一部のメンバー、すなわちDR手順に関する重要な知識を持つメンバーが、病気になったり退職したりする可能性があります。 したがって、こうした人材の喪失がもたらす影響を想定し、この問題に対処できるDRテストシナリオを準備しておく必要があります。考えられるDRシナリオの事例としては、スタッフのストライキ、従業員による妨害行為、インフルエンザの流行、あるいは解雇されて不満を抱いた従業員によるハッキングなどが挙げられます。
自然災害
竜巻、ハリケーン、地震などの自然災害は、人や物的資産だけでなく、組織のインフラにも影響を及ぼす可能性があります。自然災害は一般的に予期せぬものであり、それらが引き起こす被害を予測することは通常非常に困難です。したがって、生産拠点の地理的位置を考慮し、その地域が最もさらされやすいリスクや脅威を特定してください。これに基づいて、組織に最適なDR(災害復旧)テストシナリオを設計することができます。 自然災害シナリオの例としては、通信インフラを損なう氷嵐、生産拠点を破壊する地震、輸送上の問題を引き起こす洪水などが挙げられます。
ビジネスリスク
ビジネス関連のDRシナリオは、組織に合わせて具体的に設計する必要があります。つまり、まず自社のビジネスがどのように機能しているか、そしてその継続性を確保するために不可欠な要素は何かを定義する必要があります。 どの領域に高いレベルの保護が必要かを特定するには、ビジネス影響度分析(BIA)を実施します。これは、最も重要な業務と、その中断による影響を評価するものです。これに基づき、経営陣は発生可能性の高いリスクを特定し、それに対応するDRシナリオを策定できます。このようなDRシナリオには、通常、株式市場の暴落、データ漏洩、競合他社への顧客流出、主要サプライヤーの破綻などが含まれます。
発生可能性の低い事象
上述のように、組織に影響を及ぼしうるDR事象は多岐にわたります。しかし、想定外の事象への対応にも備えておく必要があります。 そのような事象が発生する確率は極めて低いですが、スタッフはそれらを認識し、いざという時にどう対応すべきかを理解しておく必要があります。したがって、生産拠点への航空機墜落、火山噴火、内乱といった緊急事態を含むDRテストシナリオを作成すべきです。
DR計画のテストの重要性
たとえ最も綿密に練られたDR計画であっても、テストを行わなければその有効性を証明することはできません。 DR計画のテストを行うことで、DR戦略における欠陥や不整合を特定でき、実際の災害が発生する前に、起こりうる損害を予測し、未然に防ぐことができます。このため、DRテストシナリオに基づいてDR計画を見直すことが強く推奨されます。 復旧チームは、策定した計画のすべての手順を確認して詳細に話し合うだけでよく、費用がかからず、簡単に実施できます。ただし、このテスト方法ではシステムのコンポーネントを実際にテストしないため、DRプロセスの基本的な概要しか把握できません。一方、DR計画のすべてのコンポーネントを実際の稼働環境でテストするため、より費用がかかり複雑な作業となる、本格的なシミュレーションテストを実施することもできます。運用プロセスに影響を及ぼす可能性はありますが、この方法でテストすると、さまざまなDRシナリオに対するスタッフの対応能力を確認し、DR計画の妥当性を検証できます。このように、さまざまなDRシナリオを適用して組織のDR計画を定期的にテストすることで、計画を改善し、予期しない災害が発生しても後れを取らないようにできます。
NAKIVOによるサイトリカバリのテスト
システムが適切に保護され、迅速かつ簡単に復旧できるようにするには、DR計画を用意するだけでは不十分です。DRプロセスをシームレスに実行するため、組織には強力なバックアップおよびレプリケーションソフトウェアをインストールする必要があります。NBRは、あらゆるビジネスのDRニーズに対応できる独自のサイト復旧機能を備えているため、最適なソリューションです。複数のアクションや条件(フェイルオーバー、フェイルバック、VMの起動／停止、ジョブの実行／停止、リポジトリの接続／デタッチなど)を任意の順序で並べたSRジョブをサイトリカバリのワークフローを作成するできます。SRジョブは、あらゆる規模の復旧プロセスを設計できる自動化アルゴリズムです。運用環境に影響を与えることなく、SRジョブを簡単に変更、追加、またはテストできます。その後、プロセスは完全に自動化され、スケジュールに従って、またはオンデマンドで実行できます。
SRジョブは、本番モードとテストモードで実行できます。オンデマンドでSRジョブのテストを実行するには、まずSRジョブがすでにあることを確認するか、新しく作成してください。その後、以下の手順に従ってください。
-
Jobsダッシュボードで、テストするSRジョブを選択し、Run Job. - その後、ダイアログが開き、
Test site recovery jobまたはRun site recovery jobの2つのオプションが表示されます。Test site recovery jobをクリックします。
- 次に新しいダイアログが開き、目標復旧時間(RTO)を設定できます。RTOは許容可能なダウンタイムの期間であり、大きな損失を防ぐために、その期間内にシステムを復旧する必要があります。 このダイアログでは、”目標復旧時間”オプションを無効または有効にできます。有効にする場合は、SRジョブのテストを完了するまでに許容される時間を定義する目標復旧時間の値を必ず設定してください。
-
Testをクリックしてジョブを開始します。注意: SRジョブのテストはスケジュールに従って実行することもできます。新しいSRジョブを作成する際に、
Test Scheduleオプションを設定できます。これにより、選択したスケジュールに基づく定期的なテストを実行するSRジョブを設定できます。
をクリックします。
以前に作成したSRジョブについても、テストスケジュールを設定する別の方法を利用できます。この場合、ホームページの左側のパネルに移動し、テストスケジュールの設定対象となるSRジョブを右クリックします。ジョブ管理用のさまざまなオプション(Run Job, Rename, Edit, Delete, や Disable など)を含むポップアップメニューが表示されます。Edit. をクリックします。
その後、[テストスケジュール] セクションをクリックし、希望するスケジュール設定を入力します。このメニューは、新しいサイトリカバリジョブウィザードのメニューと同じです。
これにより、組織に最適なスケジュールに基づく定期的なテストを実行するSRジョブを設定できます。
まとめ
DRイベントの影響を認識しているすべての組織は、包括的なDR計画を用意することの重要性を理解しています。しかし、多くのDR計画は、テスト不足により無効であることが判明しています。DR計画の有効性と最新性を確保するには、さまざまなDRシナリオを設計し、DRテストプロセスの一環として適用することが重要です。DRシナリオにより、予想外または可能性が低い災害であっても、従業員に対応方法を訓練でき、パニックや混乱の可能性を回避できます。
NBRを使用すれば、システムが確実に保護され、容易に復旧できることを確認できます。新機能のサイトリカバリは、DRプロセスを手動で実施する負担を軽減する、自動化された多機能ツールです。さらに、本番環境に影響を与えることなく、いつでもSRジョブのテストを実行できます。テスト結果を受け取った後、復旧戦略の欠陥を特定し、それに応じてSRジョブを更新できます。このように、サイトリカバリ機能は、事業継続性とデータ保護を確保するためのさまざまなメリットを提供します。
今すぐ無料体験をダウンロードして、VMware、Hyper-V、または混在環境で製品をテストしてください！
