ブログ

災害復旧計画に含める13のポイント

災害復興計画 (DRP) is a document you need to keep handy to handle unexpected incidents that could shut down your company’s IT systems and hinder its overall operation.
A DRP aims to get your business up and running as quickly as possible during a disaster or data breach. With an 効果的な災害復旧 計画を立てれば、あまりにも長く利益を失う可能性は低くなります。また、機密データ(社会保障番号やクレジットカード情報)が危険にさらされるのを防ぐために、バックアップを設定しておく必要があります。

あなたのビジネスには災害復旧計画がありますか?

データロス、ダウンタイム、およびテクノロジーの怒りは、現在、トップ企業でさえ遭遇する新しいホラーストーリーの一部です。企業で災害が発生すると、エンジニアリングチームは急いでその損傷を修復します。一方、PRチームは残業して顧客の信頼を回復します。時間と費用がかかると思いませんか?もちろん!しかし、一部の組織はこれらの災害を最も効果的に管理し、それも付随的な被害を少なくしています。どうだろう?シンプルで、包括的でわかりやすく、定期的にテストされた災害復旧計画があります。

Disasters come uninvited with loads of complex challenges, which organizations might take months or years to overcome. Cyber attacks, tornadoes, terrorist attacks, hurricanes, and floods are some of the disasters that can cause data breaches. A disaster plan is a long-term assurance of business operability as it is designed in such a way that it enables businesses to reduce damages of unpredicted outages.

災害復旧計画を持っていますか、それとも組織の計画を作成するプロセスを始めたばかりですか?これらのいずれの場合でも、以下の災害復旧計画チェックリストは、計画にすべての重要なコンポーネントを追加するのに役立ちます。

1.潜在的な脅威と可能な反応を分析する

まず、時間をかけて、ビジネスの流れを妨げる可能性のあるすべての要因を分析します。調査が終了したら、それらのシナリオごとに異なる回復計画を作成します。たとえば、サイバー攻撃はますます広まり、発生する可能性が高くなっています。残念ながら、平均的なファイアウォールはそれらのほとんどから保護するほど強力ではありません。

したがって、たとえば津波よりも強力なサイバー攻撃の可能性を見てください。データの暗号化とハードウェアの保護を選択できます。ハッカーがアクセスを取得するために使用するエントリポイントであるため、システムに存在する脆弱性を理解してください。

最善の方法は、ハッカーが使用する多くのスキームについて最新の状態に保つことです。フィッシングやマルウェア感染の大部分を回避できます。

2.災害復旧の目標を修正する

ディザスタリカバリは、ビジネスを通常どおりに継続的に運用するのに役立ちます。そのため、組織の運営に最も重要なITサービスを修正する必要があります。また、これらのサービス/マシンに必要な目標復旧時間(RTO)および目標復旧ポイント(RPO)。しかし、RTOとRPOを知っていますか?

RPO:ビジネス中断の通知後、災害から回復するのに必要な時間。災害が発生した場合、競合他社の顧客を失うことなく少なくとも1時間のダウンタイムに耐えられない場合、それは非常に重要です。明確に記載された許可RTOで構成される信頼できる災害復旧計画が必要です。

RPO:データが受け入れられる時間枠。災害が発生した後、1日のビジネスがデータ損失に4時間しか耐えられない場合、重要なデータが壊滅的に失われる可能性があるため、RPOは4時間になります。

組織のRTOとRPOは、その回復戦略と関連する費用に影響を与えます。災害復旧戦略の総コストを削減するには、アプリケーションを階層に分割することをお勧めします。ミッションクリティカルなアプリケーション用に予約されている最上位の層には、リアルタイムの継続的なデータレプリケーションに基づく災害復旧テクノロジーが必要です。中間レベルの層にはスナップショットベースのアプリケーションが必要な場合があり、最後に、最下位層は単純なファイルレベルのバックアップシステムで問題を解決できます。

3.災害復旧計画の関係者を認識する

次の重要なステップは、災害が発生したときに更新する必要がある人を特定することです。エンジニア、サポート、エグゼクティブなどが実際のディザスタリカバリの実行に関与します。それでも、ベンダー、PRおよびマーケティングチームのメンバー、サードパーティのサプライヤー、主要な顧客など、他のユーザーも特定する必要があります。ほとんどの企業は、プロジェクトオフィスのドキュメントに関係者の記録を保持しており、災害時に通知します。

4.災害復旧サイトを作成する

災害により本番センターに深刻な損傷を与える可能性が高く、プライマリサイトでの運用を再開できなくなり、重要なワークロードを別の場所に移行できなくなります。災害復旧計画によると、重要なデータ、スタッフ、物理的リソース、広告アプリケーションを緊急に再配置する場合に使用するDRサイトを構築するために必要なチェックリスト。また、重要なワークロードを処理するのに十分なハードウェアとソフトウェアをサイトに装備する必要があります。

5.インフラストラクチャドキュメント全体を収集する

災害が発生すると、すべてがトスになるため、誰もがプレッシャーにさらされています。実際、災害復旧手順をアクティブにするために必要なスキルと知識を持つエンジニアリングチームがいますが、インフラストラクチャのドキュメントは必須です。障害復旧を実行している熟練したエンジニアでさえ、インフラストラクチャのドキュメントからコマンドごとに実行することを好むでしょう。

それでは、このドキュメントは何で構成されていますか?システムの全体的なセットアップとその使用法(インストール、回復手順、実行中のアプリケーション、OSと構成)、クラウドテンプレート、ストレージとデータベース(データの保存方法と保存場所、バックアップの復元方法、データの正確性の検証方法)マッピングされたすべてのネットワーク接続(機能するデバイスとその構成を含む)。

6.正確なテクノロジーのチェリーピック

Disaster Recovery as a Service (DRaaS) and on-premise disaster recovery is not just the feasible solutions available for business continuity. The next option is to make use of cloud-based disaster recovery in order to spin up your disaster recovery site on a public cloud-like Microsoft AzureAWS そして Google Cloud in minutes using an automated disaster recovery solution.

ソリューションを選択する前に、総所有コスト、メンテナンス要件、スケーラビリティ、以前の時点への回復、およびテストの容易さを考慮してください。災害復旧ソリューションに関しては多くの選択肢があるため、徹底的な調査を行い、賢明に選択してください。

7.通信チャネルを起動する

災害がいつあなたのドアをノックすることができるか誰も知らないので、組織であるあなたは、災害復旧のためにチームのリストを(彼らの役割と連絡先情報とともに)保持しなければなりません。各エンジニアリングチーム(データベース、システム、ネットワーク、ストレージなど)の責任者と関連する経営幹部を含む包括的な指揮系統を確立するようにしてください。また、専用の通信チャネルとハブ、またはインスタントメッセージングに使用するオンライン情報共有ツールをセットアップします。

8.インシデント対応手順の概要

災害復旧計画がある場合、「インシデント対応手順」は必須です。ここでは、企業は災害として宣言する必要があるイベントを詳細に定義します。たとえば、システムがダウンした場合、それを災害と見なしますか?また、計画には、災害を検証する方法と、どのように報告するかを示す必要があります。自動監視システム、サイト信頼性エンジニアリング(SRE)チームからの呼び出し、または顧客からの報告によるものですか。

災害が実際に発生していることを確認するには、プロアクティブに監視している重要なネットワークデバイス、アプリケーションログ、サーバーハードウェア、または本番システムのその他の重要なコンポーネントのステータスを確認する必要があります。何かがおかしい場合や機能しない場合は、間違いなくあなたの手に災害があります。

9.アクション対応手順の概要

災害が発生したら、できるだけ早く災害復旧環境をアクティブにする必要があります。アクションレスポンス手順では、必要なすべての手順を使用して、災害復旧サイトにフェイルオーバーする方法の概要を説明します。復旧プロセスがDRaaSを使用しているか、災害復旧ツールを使用して災害サイトを自動的に起動しているかに関係なく、必要なサービスを開始、検証、および制御する方法を確実にするために、アクションレスポンス手順を書面で準備する必要があります。

さらに、別の場所で本番サービスをスピンアップするだけでは不十分であり、必要なすべてのデータが揃っており、必要なすべてのビジネスアプリケーションが適切に機能していることも同様に重要です。

10.プライマリインフラストラクチャへのフェールバックの準備をする

フェイルバックは、フェイルオーバー中にDRサイトに転送された後、プライマリ本番センターのオペレーションを復元します。 DRサイトは日常業務を実行するように設計されていません。代わりに、緊急時にのみ使用できます。 DRサイトは非常に短期間(プライマリサイトが復元されるまで、または新しい運用センターが構築されるまで)構築されます。

災害が終わったら、データとビジネスサービスを主要な場所に戻す実装に多くの労力が必要です。復帰プロセス中にビジネスが部分的に中断する可能性を計画します。幸いにも、プライマリロケーションへの統合フェイルバックを提供するディザスタリカバリソリューションが存在し、プライマリITロケーションの検証が完了すると、自動または手動でアクティブ化されます。

11.事件を利害関係者に報告する

災害が発生したら、まず、DRアクティビティの実行を担当する人だけでなく、ベンダー、顧客、PRおよびマーケティングチームのメンバー、サードパーティサプライヤーなどの主要な利害関係者にも通知します。また、これらの各グループに通知し、それらの懸念に対処するための回答を作成することを検討してください。事前にプレスリリースを作成して、実際の災害時に時間を無駄にせず、公開できる状態にしておくことをお勧めします。

12.広範なテストを行う

災害復旧計画のテストは必須ですが、通常は無視されます。フェイルオーバーテストは通常複雑で、データの損失や製品サービスの中断につながります。したがって、ほとんどの企業は、災害復旧計画を定期的にテストしていません。

災害復旧計画がどの程度うまく機能するかを理解するには、定期的なフェイルオーバーテストをスケジュールする必要があります。災害復旧計画のテストを無視すると、災害ストライキ中にビジネス全体が危険にさらされる可能性があり、結果として、時間内に回復できないか、まったく回復できなくなります。パフォーマンステストは、セカンダリロケーションがビジネス負荷に耐えるのに十分であるかどうかを評価するのにも役立ちます。

13.災害復旧計画を最新の状態に保つ

最後に重要なことですが、災害復旧計画のテストは必須であるため、すべての災害復旧ドキュメントを最新の状態に保ちます。各テストの最後に、何が起こったか、チームがテストをどのように処理するかを確認し、調査結果を文書化します。

サインオフ:

自分で行う災害復旧(安価だがエラーが発生しやすいオプション)を実行するか、会社がすべての失われたデータを復旧し、組織の通常のビジネス運用への復帰を早めるのに役立つ優れた災害復旧計画を用意するかを選択できます。それに加えて、災害が財務上の不利な結果や大きなビジネスの混乱を引き起こさないことも保証します。

組織のあらゆる側面(従業員の数、利用可能な予算、リスク要因、ITインフラストラクチャのサイズなど)を考慮して、自分とチームに最適なものを決定するようにしてください。

返信を残す

jaJapanese