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

リカバリテストとは何ですか?

回復テスト リカバリテストは、ソフトウェアやハードウェアのクラッシュ、ネットワーク障害などの障害からソフトウェアが復旧できるかどうかを検証するソフトウェアテスト手法です。リカバリテストの目的は、災害やデータ整合性の喪失後もソフトウェアの動作を継続できるかどうかを判断することです。リカバリテストでは、ソフトウェアを整合性が保たれていた時点に戻し、障害発生時点までのトランザクションを再処理します。

ソフトウェアエンジニアリングにおいて、回復性テストは、 非機能テスト これは、拡張性やセキュリティなど、特定の機能やユーザー操作に結びつかない側面も対象としています。専門のテスターが実施し、事前に適切なバックアップデータが安全な場所に保管されます。

回復テストの例

この手法の最もシンプルな例を2つのシナリオで示す。どちらのシナリオでも、意図的に障害を発生させ、その後アプリケーションが再開する様子を観察する。

• ネットワーク障害： アプリケーションがネットワークからデータを受信して​​いる間に、接続ケーブルを抜いてください。しばらくしてからケーブルを再び接続し、接続が切断された時点からアプリケーションがデータを受信し続けることができるかどうかを分析してください。
• セッション復元: ブラウザが一定数のセッションを開いている状態でシステムを再起動し、ブラウザがそれらのセッションをすべて回復できるかどうかを確認してください。

以下の図は、同じ考え方を視覚的に表現したものです。

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

• リスタートポイントの数
• アプリケーションが保持するデータ量
• 復旧活動を行う人々の訓練とスキル、および復旧に利用できるツール

複数の障害が発生した場合は、復旧テストを一度にすべて行うのではなく、構造化された方法で実施する必要があります。つまり、あるセグメントに対してテストを行い、次に別のセグメントに対してテストを行うということです。

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

テストケースを設計する前に、リカバリテストがどこで介入するのかを把握しておくと役立ちます。リカバリプロセスのライフサイクルは、次の5つのステップで構成されています。

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

下のフローチャートは、これら5つの段階を順に示しています。

それでは、これらの5つのステップについて詳しく見ていきましょう。

1. 通常の操作。 ハードウェア、ソフトウェア、ファームウェアが統合され、共通の目標を達成するシステムは、規定された期間内に中断なく設計された機能を実行する。
2. 災害発生。 ソフトウェアの不具合、入力ミスによる不具合、ハードウェア障害によるクラッシュ、火災、盗難、ストライキによる損傷などが原因で、システム障害が発生する可能性があります。
3. 混乱と失敗。 これは最も苦痛な段階であり、事業損失、関係の悪化、機会損失、労働時間の損失、そして必然的に金銭的損失と信用失墜につながります。災害復旧計画があれば、この段階を最小限に抑えることができます。
4. 災害復旧作業。 バックアップ計画とリスク軽減プロセスが既に整備されていれば、復旧にかかる時間と労力は大幅に削減できます。各担当者の役割が事前に明確に定義された専任チームを編成することで、責任の所在が明確になり、業務の中断期間を長期化させることを防ぐことができます。
5. 再建。 これには、すべてのフォルダと設定ファイルを再構築するために、複数回の操作が必要になる場合があります。適切な復旧には、適切なドキュメントと明確な再構築プロセスが必要です。

復興戦略

復旧チームは、重要なコードとデータを復旧して業務を正常に戻すための独自の戦略を持つべきです。その戦略は、各組織が扱うシステムの重要度に基づいて組織ごとに異なり、重要なシステムの場合は、以下の選択肢に集約されます。

1. 単一のバックアップ、または複数のバックアップ
2. 複数のバックアップを1か所に、または異なる場所に保存する
3. オンラインバックアップ、またはオフラインバックアップ
4. バックアップはポリシーに基づいて自動的に実行されるか、手動でトリガーされます。
5. 独立した修復チーム、または作業を行う開発チーム

それぞれの選択肢にはコスト要因が伴い、複数のバックアップはより多くの物理リソースを消費したり、独立したチームが必要になる場合があります。依存関係も重要です。企業は単一のプロバイダーに保管しているコードとデータを通じてリスクにさらされ、大規模な AWS 停電によって、有名な消費者向けサービスが同時に停止するという事態が繰り返し発生している。このような場合、独立した復旧能力が極めて重要となる。

回復テストの方法

戦略が固まったら、次はテスト自体をどのように設定するかという問題です。復旧テストを実施する際には、以下の点を考慮する必要があります。

• 実際の展開環境にできるだけ近いテスト環境を構築する。インターフェース、プロトコル、ファームウェア、ハードウェア、ソフトウェアは、本番環境と一致させる必要がある。
• 徹底的なテストは時間と費用がかかるかもしれないが、同一の構成で完全なチェックを行うべきである。
• 可能であれば、最終的に復元するハードウェアでテストを行ってください。特に、バックアップを作成したマシンとは別のマシンに復元する場合は、テストが重要です。
• 一部のバックアップ システムでは、ハード ドライブがバックアップの取得元とまったく同じサイズであることを想定しています。
• 陳腐化の管理: ドライブ技術は急速に進歩しており、古いドライブは新しいドライブと互換性がない場合があります。 バーチャルマシン 仮想化ソフトウェアは、ディスクサイズを含め、既存のハードウェアを模倣できるため、役立ちます。
• オンラインバックアップシステムもテストの対象外ではありません。ほとんどのプロバイダーは、耐障害性ストレージによってユーザーをメディアの問題から保護しているため、障害は後になってから顕在化します。
• オンラインバックアップシステムは非常に信頼性が高いものの、復元側についても、データの取得、セキュリティ、暗号化に問題がないことを確認するためにテストを行う必要がある。

回復運動は最初から最後まで行われるため、これらのランニングは通常、次のスケジュールで行われます。 システムテスト ユニットレベルではなく、より広範なレベルで。

修復後の検査手順

データの復元は作業の半分に過ぎず、復元されたデータが実際に使用可能であることを証明する必要があります。多くの大企業は、独立監査人に定期的に復旧訓練を実施させています。包括的な災害復旧計画の維持とテストには費用がかかるため、小規模な組織はバックアップやオフサイトストレージに頼ることが多いのです。

フォルダとファイルの復元後、以下のチェックによって正しく復元されたことを確認します。

• 破損したドキュメントフォルダの名前を変更して、復元したコピーが元のフォルダと混同されないようにしてください。
• 復元されたフォルダ内のファイル数を数え、元のフォルダのファイル数と照合してください。
• 普段それらのファイルを使用するアプリケーションでいくつかのファイルを開き、データが通常どおり閲覧および更新できることを確認してください。
• さまざまな種類の複数のファイルを開きます。画像、 MP3書類や文書、大小さまざまなもの。
• ほとんどの人が使っているファイルとディレクトリの比較ユーティリティを使用してください OS 提供する。

よくあるご質問