回復テストとは何ですか? 例で

回復テスト

回復テスト ソフトウェア/ハードウェアのクラッシュ、ネットワーク障害などの障害からソフトウェアが回復する能力を検証するソフトウェア テスト手法です。回復テストの目的は、災害や整合性の損失後にソフトウェア操作を続行できるかどうかを判断することです。回復テストでは、ソフトウェアを整合性が判明していた時点に戻し、トランザクションを障害時点まで再処理します。

回復テストの例

アプリケーションがネットワークからデータを受信して​​いるときは、接続ケーブルを取り外します。

• しばらくしてから、ケーブルを再度接続し、ネットワーク接続が切断された時点からデータを受信し続けるアプリケーションの能力を分析します。
• ブラウザが一定数のセッションを開いている間にシステムを再起動し、ブラウザがすべてのセッションを回復できるかどうかを確認します。

ソフトウェア エンジニアリングでは、回復可能性テストは非テストの一種です。 機能テスト。 (非機能テストとは、スケーラビリティやセキュリティなど、特定の機能やユーザー アクションに関連しないソフトウェアの側面を指します。)

回復にかかる時間は以下によって異なります。

• リスタートポイントの数
• 大量のアプリケーション
• 回復活動を行う人々のトレーニングとスキル、および回復に利用できるツール。

多数の障害が発生した場合は、すべての障害に対処するのではなく、構造化された方法で回復テストを実行する必要があります。つまり、XNUMX つのセグメントに対して回復テストを実行し、次に別のセグメントに対して回復テストを実行する必要があります。

これは専門のテスターに​​よって行われます。復旧テストの前に、十分なバックアップ データが安全な場所に保管されます。これは、災害後でも運用を継続できるようにするためです。

回復プロセスのライフサイクル

回復プロセスのライフサイクルは、次の 5 つのステップに分類できます。

1. 通常運転
2. 災害発生
3. 作戦の中断と失敗
4. 復旧プロセスを通じた災害復旧
5. すべてのプロセスと情報を再構築し、システム全体を正常な動作に戻す

これら 5 つのステップについて詳しく説明します。

1. 共通の目標を達成するために統合されたハードウェア、ソフトウェア、ファームウェアで構成されるシステムは、明確に定義され、明示された目標を実行するために運用されます。システムは、規定された期間内に中断することなく設計されたジョブを実行するために、通常の操作を実行するように呼び出されます。
2. 入力による誤動作、ハードウェア障害によるソフトウェアのクラッシュ、火災、盗難、ストライキによる損傷など、さまざまな理由により、ソフトウェアの誤動作により中断が発生する可能性があります。
3. 混乱の段階は、ビジネス上の損失、関係の断絶、機会損失、人的損失、そして必然的に金銭的損失と信用損失につながる、最も苦痛を伴う段階です。賢明な機関であれば、混乱の段階を最小限に抑えるために、災害復旧計画を立てておく必要があります。
4. 災害や混乱が発生する前に、バックアップ計画とリスク軽減プロセスが適切に設定されていれば、時間、労力、エネルギーをあまりロスすることなく復旧を行うことができます。 責任を明確にし、組織が長期にわたる中断期間から救われるよう、指名された個人と、その各担当者に割り当てられた役割を持つチームを定義する必要があります。
5. 再構築には、すべてのフォルダと構成ファイルを再構築するための複数の操作セッションが必要になる場合があります。正しい回復のためには、適切なドキュメントと再構築のプロセスが必要です。

復興戦略

復旧チームは、機関の業務を正常な状態に戻すために、重要なコードとデータを回復するための独自の戦略を持っている必要があります。

戦略は、処理しているシステムの重要性に基づいて、各組織に固有のものにすることができます。

重要なシステムに対して考えられる戦略は、次のように視覚化できます。

1. 単一または複数のバックアップを作成するには
2. 複数のバックアップを XNUMX か所または別の場所に作成するには
3. オンライン バックアップまたはオフライン バックアップを作成するには
4. バックアップはポリシーに基づいて自動的に実行できますか? それとも手動で実行できますか?
5. 独立した修復チームを持つか、開発チーム自体を作業に活用できる

これらの戦略にはそれぞれコスト要素が関連付けられており、複数のバックアップに必要な複数のリソースにより、より多くの物理リソースが消費されたり、独立したチームが必要になったりする場合があります。

データとコードが関係する開発機関に依存しているため、多くの企業が影響を受ける可能性があります。たとえば、次の場合 Amazon AWS インターネットが停止します。 このような場合には、自主的な修復が重要です。

回復テストの方法

リカバリ テストを実行する際には、次の点を考慮する必要があります。

• 実際の展開状況にできるだけ近いテストベッドを作成する必要があります。 インターフェイス、プロトコル、ファームウェア、ハードウェア、およびソフトウェアの変更は、同じ条件ではないにしても、可能な限り実際の条件に近づける必要があります。
• 徹底的なテストには時間がかかり、コストがかかる場合があるため、同一の構成で完全なチェックを実行する必要があります。
• 可能であれば、最終的に復元するハードウェアでテストを実行する必要があります。 これは、バックアップを作成したマシンとは別のマシンに復元する場合に特に当てはまります。
• 一部のバックアップ システムでは、ハード ドライブがバックアップの取得元とまったく同じサイズであることを想定しています。
• ドライブ技術は急速に進歩しており、古いドライブは新しいドライブと互換性がない可能性があるため、陳腐化を管理する必要があります。 この問題に対処する XNUMX つの方法は、 バーチャルマシン。 VMware Inc. などの仮想化ソフトウェア ベンダーは、ディスク サイズやその他の構成を含め、既存のハードウェアを模倣するように仮想マシンを構成できます。
• オンライン バックアップ システムもテストの例外ではありません。 ほとんどのオンライン バックアップ サービス プロバイダーは、フォールト トレラントなストレージ システムを使用することで、メディアの問題に直接さらされることから私たちを守っています。
• オンライン バックアップ システムは非常に信頼性が高いですが、システムの復元側をテストして、取得機能、セキュリティ、または暗号化に問題がないことを確認する必要があります。

修復後の試験手順

ほとんどの大企業には独立した監査人がおり、定期的に回復テストを実施しています。

包括的な災害復旧計画の維持とテストには多額の費用がかかる可能性があり、中小企業にとっては法外な費用となる可能性があります。

小規模なリスクは、大惨事の際にデータを保存するためのデータ バックアップとオフサイト ストレージ プランに依存する場合があります。

フォルダーとファイルが復元された後、ファイルが正しく復元されたことを確認するために次のチェックを実行できます。

• 破損したドキュメントフォルダーの名前を変更する
• 復元されたフォルダー内のファイルをカウントし、既存のフォルダーと照合します。
• いくつかのファイルを開いて、アクセスできることを確認します。 必ず通常使用しているアプリケーションで開いてください。 また、データの参照、データの更新など、通常行っている操作ができることを確認してください。
• 画像、MP3、ドキュメントなど、大小さまざまな種類のファイルをいくつか開くのが最善です。
• ブリッジ OS ファイルとディレクトリを比較するために使用できるユーティリティがあります。

まとめ

このチュートリアルでは、障害後にシステムまたはプログラムが要件を満たしているかどうかを理解するのに役立つ、回復テストのさまざまな側面を学びました。