Harness（ハーネス）は、企業がコンピューター、クラウドシステム、デジタルツールへの依存度を高めるにつれ、堅牢な災害復旧テストの必要性が高まっていることを指摘したHarnessでは、災害復旧テストを障害発生後にシステム、データ、サービスが定義された復旧目標を満たすように復旧できることを証明する体系的な手法として位置付けている。効果的なプログラムは、テクノロジーだけでなく、人、プロセス、コミュニケーション、サードパーティーの依存関係をエンドツーエンドで検証する必要があると指摘されている。コア要素としては、アプリケーション層ごとの明確な復旧時間目標（RTO）と復旧ポイント目標（RPO）、依存関係マッピングを含む最新の資産およびアプリケーションインベントリー、フェイルオーバーとフェイルバックのための文書化されたランブックとプレーブック、バックアップ、レプリケーション、スナップショット、不変性などのデータ保護戦略が挙げられている。また、コミュニケーション計画、定義された役割とエスカレーションパス、サードパーティーの復旧コミットメントとサービスレベル契約、監査と継続的改善に適したガバナンスとレポート指標の必要性も指摘されている。Harnessは、定期的なテストを行わなければ、十分に文書化された計画であっても、実証されていないままであり、実際の停電が発生した際に失敗する可能性があると警告している。
Harnessは、低リスクの演習から始めて、最も重要なサービスについては完全なフェイルオーバーへと段階的に進めていくことで、信頼性を徐々に高めていくことを目的とした階層的なテスト戦略の概要を説明。机上演習は、議論に基づいたウォークスルーを通じて役割と意思決定を明確にするための有用な初期ステップとして説明され、シミュレーションは、本番環境に影響を与えることなくアラートや模擬的な依存関係を設定することで現実味を注入すると説明された。運用ウォークスルーは、実行手順書を実際に検証し、権限、ツール、シーケンスを確認するものであり、部分的または完全なフェイルオーバーの前に準備ステップとして機能すると説明された。部分的なフェイルオーバーは、オフピーク時に依存関係を検証するために特定のサービス、コンポーネント、またはリージョンを対象としたテストとして提示され、完全なフェイルオーバーは、本番環境をセカンダリサイトに切り替えて再び戻す包括的なテストとして特徴づけられ、回復力の最も強力な証拠を提供するものの、綿密な計画が必要であると説明された。自動化された検証は、リカバリー環境を起動し、ヘルスチェックを実行し、一貫したフィードバックを提供するコード化されたワークフローを通じて、頻繁で低リスクのテストを行うために推奨される。多くの組織が依然として復旧計画のテストを年に1、2回しか実施しておらず、この頻度の低さではソフトウェア、クラウドアーキテクチャー、人材の急速な変化に対応できない。財務リスクについても言及され、最近の試算では、多くの大企業にとって1時間のシステム停止で30万ドル以上の損失が発生する可能性があり、一部の業界では1時間当たり数百万ドルの損失、中小企業では1分当たり数千ドルの損失が発生していることが示された。
最新のツールとAIは、災害復旧テストをより迅速、継続的、かつ正確にするための触媒となっている。従来の手動テストには数週間かかるのに対し、統合プラットフォームでは、既存のパイプライン内でカオステスト、負荷テスト、災害復旧テストを組み合わせることができ、チームは復旧手順を自動的に実行し、フェイルオーバーを検証し、リスクを早期に明らかにできる。Harnessのレジリエンステストモジュールは、カオステストと負荷テストを災害復旧検証と組み合わせ、CI/ CDパイプライン内での実行をサポートする例として挙げられる。テストライフサイクルにおけるAIの役割は、予測分析によって起こりうる障害点を明らかにすることと、実際のシステム環境に基づいて関連シナリオを生成して優先順位付けする自動化という2つの側面がある。AIにAIテスト結果の分析は、必要な修正をリアルタイムで特定し、各実行から学習することでテストカバレッジを継続的に改善することで、推測を減らすことができる。Harnessは、組織が現在の計画を見直し、少なくとも1つの重要なシステムを選択し、四半期内に簡単な復旧テストをスケジュールすることを推奨し、定期的な自動テストは、ハイブリッドクラウドとマルチクラウドの複雑な時代において、復旧速度を向上させ、収益損失を制限し、顧客の信頼を維持するとしている。
出典：Harness
この製品の詳細については、Harness製品ページをご覧ください。
