自然災害、サイバー攻撃、システムの故障、そして人間のエラーさえは、いつでも起こり得ます。これらは組織の重要なアプリケーションを危険にさらします。よく作られた災害回復計画を持つことは、迅速かつ安全な回復や長期的な停止とビジネス継続性のリスクを区別することができ、組織に何百万ドルかかる可能性があります。 定期的な災害回復テストと演習は、あらゆる災害回復計画に不可欠であり、実際の問題になる前に潜在的な問題を特定し、解決することを可能にします。 災害復旧計画が効果的であることを確認するには、インフラストラクチャ、アプリケーション、およびプロセスのすべての重要なコンポーネントをカバーする包括的なテストおよび掘削戦略を開発する必要があります。 この記事では、災害復旧テストと演習を設計、実行、評価するために取ることができるステップについて説明します。 今日無料のデモを予約して、AWS Marketplace で N2W でデータ保護戦略を最適化し始めましょう。 今日無料のデモを予約して、AWS Marketplace で N2W でデータ保護戦略を最適化し始めましょう。 なぜ災害回復テストが重要なのか Recovery Challenges for Distributed Systems よく設計された分散システムでは、一部のコンポーネントの故障は全体的なシステム故障を意味するべきではありません。むしろ、故障はコンポーネント自体に分離されるべきです。これらの種類の故障を適切に検出し、対応するためにシステムを設計することが可能です。 Network Failure and Data Replication Network Failure and Data Replication(ネットワークの失敗とデータの複製) ネットワークの分割、ネットワークの渋滞、ポリシー、ルール、セキュリティグループ、および他の多くの要因は、システム内のコンポーネント間の間隔的または永久的な切断を引き起こす可能性があります。 失敗した場合の初期および回復ネットワークをどのように設計し、運用しているか? 生産システムと並行してテストする方法を理解することが重要です。 Distributed Transaction Management Distributed Transaction Management(分散取引管理) 分散型システムで実行されるトランザクションは複数のシステムをカバーすることができ、これらのシステム間で調整されなければならないことを意味します。 さらに、トランザクションは、データベースやファイルシステムなどのその他のマシンや外部リソースでの他のトランザクションと調整する必要があるかもしれません。 Service Dependency Resolution サービス依存の解決策 ほとんどのマイクロサービスの実装は、サービスの発見を必要としますが、それはモノリチックアーキテクチャでもアプリケーションを持っています。 Data Consistency and Recovery データの一貫性と回復 ほとんどの場合、災害復旧は、データの損失や破損を最小限に抑えながら、できるだけ早くサービスを復元することを目指しています。 Backup and Disaster Recovery Planning バックアップ・災害復旧計画 バックアップは、あらゆる回復プランに不可欠であり、データのバックアップコピーを持っていない場合、ゼロから再構築することができます。 Disaster Recovery Testing + Verification of Recovery Mechanisms 災害回復テスト+回復メカニズムの検証 回復計画は、生産環境で実装される前にテストする必要がある複雑なメカニズムに依存する。 新しいソフトウェアバージョンが常にリリースされており、回復に影響を与える可能性のある新しい機能があります。 今日無料のデモを予約して、AWS Marketplace で N2W でデータ保護戦略を最適化し始めましょう。 今日無料のデモを予約して、AWS Marketplace で N2W でデータ保護戦略を最適化し始めましょう。 Dependencies and Setting Order of Recovery 依存症と回復順序の設定 分散型システムが失敗した場合、構成要素やサービス間の依存性が多くなるため、分散型システムがどのように回復されるかを判断するのは難しい場合があります。 まず、システム内のさまざまなサービスやコンポーネント間の依存性をマッピングし、システムの機能に最も重要な依存性を特定し、これらの依存に失敗の影響を決定します。 重要な依存性: Critical Dependencies: 重要な依存性: Critical Dependencies: 重要な依存性を特定すると、システム機能に及ぼす影響と、他のサービスやコンポーネントがそれらに依存する程度に基づいて優先順位を設定します。 Prioritize dependencies: 依存性の優先順位: 各サービスまたはコンポーネントの回復手順を定義し、それらを回復するために必要な手順と、それらに依存する依存性を指定します。 回復手順を設定する: 回復手順を設定する: 手動介入を最小限に抑え、システムの回復に必要な時間を短縮するために、可能な限り回復プロセスを自動化することを検討してください。 自動回復プロセス: 自動回復プロセス:   効果的で最新の状態を保証するために、潜在的な問題を特定し、計画を改善するためにマック回復演習を実施します。 Test and validate the recovery plan: 定期的に検査・検証 回復計画をテストし、検証する: Use Case Scenario Examples ケースシナリオの例 以下は、データ復旧のいくつかの用例です。 Use-case #1 – Recovery of Data (AWS and Azure) 組織は、AWS および Azure サービスを使用してクラウドに重要なビジネスデータを格納しています. 最近のサイバー攻撃により、データが破壊され、損失が発生し、組織は重大な財政的および評判の損害を回避するために、できるだけ早くデータを回復する必要があります。 回復のためのステップ: データ損失の範囲を特定する: 組織は、データ損失の範囲と影響を決定する必要があります. This may involve analyzing server logs, monitoring systems, and user feedback to identify the scope of the problem. データ回復プロセスを開始する: 次のステップは、データ回復プロセスを開始することです. AWS と Azure は、バックアップと復元、複製、およびエラーオーバーを含むデータ回復のためのさまざまなオプションを提供します. The specific recovery strategy will depend on the nature of the data loss, the backup and recovery options available, and the organization's recovery time objectives (RTOs) and recovery point objectives (RPOs). バックアップからデータを復元する:バックアップが利用可能であれば、組織はこれらのバックアップからデータを復元できます。AWSとAzureは、組織がデータのバックアップを作成し、管理できるバックアップおよび復元サービスを提供しています。 データの複製: バックアップが利用できない場合または不完全な場合、組織は他のソースからのデータを複製できます。AWS と Azure は、組織がデータの可用性と redundancy を確保するために、異なる地域および可用性ゾーン間でデータを複製できる複製サービスを提供します。 AWS および Azure では、主なシステムが復元できない場合、主なシステムが故障した場合に組織が自動的に次元システムに切り替えることを可能にするサービスを提供しています。 データの完全性と一貫性を確認する:データの復元が完了した後、組織は復元されたデータの完全性と一貫性を確認する必要があります。 回復プロセスを評価する:回復プロセスが完了した後、組織は回復プロセスを評価し、改善のための領域を特定する必要があります。 データ損失の範囲を確認する: データ回復プロセスを開始する: Backupからデータを復元する方法: データの複製: 二次元システムへの失敗: データの整合性と一貫性を確認する: 回復プロセスを評価する: Use-Case #2 – Recovery of a Complex App Made Up of Multiple Services (Compute, Data, Networking) コンピューティング、データ、ネットワークなどの複数のサービスで構成されている組織のミッション・クリティカルなアプリケーションは、自然災害による災害的な中断を経験しました。 依存性を識別する:最初のステップは、さまざまなアプリケーションサービス間の依存性を識別することです。 EC2 インスタンスまたは Azure 仮想マシンを起動し、必要なセキュリティグループ、IAM ロール、およびネットワーク設定で正しく構成されていることを確認する場合があります。 データサービスの復元:コンピューティングサービスが起動し、実行されると、次のステップはデータサービスを復元することです。これには、バックアップからデータを復元し、復元したり、地理的に分散した次元システムなどの他のソースからのデータを複製したりすることがあります。 ネットワーク サービスの復元:コンピュータおよびデータ サービスが復元された後、ネットワーク サービスを復元する必要があります. This may involve configuring virtual private clouds (VPCs), subnets, and network security groups to ensure traffic flows directly between the various services. テストおよび検証:すべてのサービスが復元された後、アプリケーションが正しく機能することを確認するためにテストする必要があります。これには、すべてのサービスが正しく通信し、アプリケーションが期待通りに動作することを確認するための自動テストまたは手動チェックを実行する可能性があります。 回復プロセスを評価する:回復プロセスが完了した後、組織は回復プロセスを評価し、改善のための領域を特定する必要があります。 依存性の認識: コンピュータサービスから始める: データ復旧サービス: ネットワークサービスの復旧: テスト&検証: 回復プロセスを評価する: Automation is Not Desired. It’s Required 自動化は望ましくない、必要です。 今日では、ITシステムは常に利用可能であり、障害が発生した場合に回復可能であると期待されています。伝統的なマニュアル災害回復プロセスは時間がかかる、エラーの可能性があり、RTOやRPOを満たさない可能性があります。 そして、RTOやRPOを達成する必要がある。 災害復興計画 自動化は、回復プロセスを加速し、エラーを排除し、回復プロセスのコントロールと可視性を高めることができます。 Test The Plan, Don’t Plan The Test 「Test The Plan, Don't Plan The Test」 災害回復計画は、その実施と同じくらい効果的です。災害回復計画が必要に応じて機能することを確認するには、定期的にテストすることが重要です。テストは、計画の欠陥と弱点を特定し、学んだ教訓に基づいて計画を改良する機会を提供し、回復プロセスへの信頼を構築します。 ハードウェア、ソフトウェア、ネットワーク、データなどのすべての重要な要素をテストし、IT従業員、ビジネスユニット、および外部サプライヤーなどのすべての関連当事者を含むべきである。 テスト結果の分析に基づいて災害復旧計画を更新する必要があります。組織は、あらゆる潜在的な災害に備えており、計画を定期的にテストすることによって、重要なITシステムとデータを迅速かつ効果的に回復することができます。 👉 TIP: You can  自動災害回復ドリル N2W  and have reports emailed 自動災害回復ドリル N2W Final Words on Disaster Recovery Testing 災害復旧テストについての最後の言葉 強力な災害回復戦略には、災害回復のためのテストと演習が含まれる必要があります。組織は、回復プロセスに対する信頼を強化し、計画の弱点を発見し、修正し、重要なITシステムとデータが破損時に迅速かつ効果的に回復できるようにすることができます。 テストは包括的で、すべての関連当事者を含むべきであることを覚えておくことが不可欠であり、結果は記録され、検討され、必要に応じて災害回復計画を更新するために使用されるべきである。 結局のところ、テスト済みでドキュメンテーション済みの災害復旧計画は、IT障害による財政的および評判的損害を減らし、災害の場合の事業継続性を保証するのに企業を助けることができます。 Get Your Weekends Back: Automated Disaster Recovery Testing with N2W Get Your Weekends Back: Automated Disaster Recovery Testing with N2W オリジナルタイトル N2W の Recovery Scenarios を使用すると、バックアップをテストするだけでなく、ボタンをクリックして完全な災害リハーサルをオーケストラできます。 リソースのグループ(VM、ストレージ、ネットワーク設定)を定義し、優先順位でタグ付け - 手動のスクリプトは必要ありません。 RTO および RPO に関する明確でカスタマイズ可能なレポート、アカウント間および地域間の復元の検証、およびライブ環境に影響を与える前に誤った設定に関する即時警告を取得します。 ネットワーク設定の復元テストで、健全な failover 状態を確保します。 孤立した環境で自動的な failover ドリルを実行し、生産を望むほど頻繁に反映します。 要するに、サイバー攻撃からヒューマンエラーに至るまで、実際の停滞が起きたとき、アプリケーションはサプライズや長期的な停滞なしに、正確に必要な場所に戻ります。 今日無料のデモを予約して、AWS Marketplace で N2W でデータ保護戦略を最適化し始めましょう。 今日無料のデモを予約して、AWS Marketplace で N2W でデータ保護戦略を最適化し始めましょう。

このオーディオは、ストーリーの元の言語で制作されています。

災害回復テストとドリル - 私の計画がうまくいっているかどうかをどのように知りますか?

About Author

コメント

ラベル

この記事は

Related Stories

目に見えない層: ユーザーインタビューがかけがえのない資産である理由

HackerNoon Coded: HackerNoonが最も活発に活動している上位10カ国

HackerNoon ライティングコンテストで優勝したいですか? #crypto-api コンテスト優勝者のおすすめはこちら

フォーラムからフィードへ: ソーシャルメディアアルゴリズムがデジタルインタラクションを形作る仕組み

目に見えない層: ユーザーインタビューがかけがえのない資産である理由

HackerNoon Coded: HackerNoonが最も活発に活動している上位10カ国

HackerNoon ライティングコンテストで優勝したいですか? #crypto-api コンテスト優勝者のおすすめはこちら

フォーラムからフィードへ: ソーシャルメディアアルゴリズムがデジタルインタラクションを形作る仕組み

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps