2024年7月19日、CrowdStrikeのアップデートが原因で、大規模な技術障害が発生しました。
マイクロソフトのテクノロジーを利用している数百万人のデバイスが停止し、一般企業や銀行、医療機関に混乱が発生した他、多くの航空会社が運航停止に追い込まれました。ほとんどの企業や組織には、建物や従業員などに関しては災害復旧計画が存在しています。しかし、IT関連の災害復旧計画に関しては後回しになりがちな企業も少なくありません。 IT関連の復旧計画は現代社会においては最優先事項であり、復旧が遅れると時間・資産・生産性など全ての損失につながります。
マイクロソフトのようなクラウドを提供している企業は、これらの外部サービスについて一切責任を負いません。実際、マイクロソフトのShared Responsibility Model（責任共有モデル）では、インフラの障害、ユーザーや管理者のミス、ソフトウェアの破損、悪意のある攻撃などに対する責任は顧客にあることを明記しています。つまり、データのセキュリティ対策や保護は、顧客自身で行わなければなりません。
どのような状況においても事業継続性を確保するためには、IT関連の災害復旧計画が不可欠です。まずは、以下の6つのステップで計画を立ててみましょう。
ステップ1：環境と構造の評価
現状の環境において、クラウド移行の際に「リフト＆シフト」アプローチを採用している場合、このステップは非常に重要です。「リフト＆シフト」アプローチでは、いかに正しく安全に行うかよりも、いかに早く導入するかに重点が置かれているため、脆弱なセキュリティ環境となっている可能性があるためです。
まずは現状の環境を調査し、変更が必要かどうかを確認することが重要です。
AvePoint Discovery Toolのような製品を使用すれば、コンテンツの場所や量、それらの関連性を判断し、構造を改善するためのプランを作成することができます。
環境とその構造を改善することは、ストレージコストの削減やガバナンスの合理化などに役立つだけでなく、情報ライフサイクル管理や将来的なM&A、そして最も重要である事業継続性の確保においても重要な基盤となります。
ステップ2：ITサービスやシステムの一覧表の作成
次に、大小・社内外を問わず、自社で導入しているシステムの一覧表を作成し、それらが自社のビジネスにとってなぜ必要なのかを可視化します。
まず、環境全体をスキャンし、自社開発のアプリケーションから仮想マシンに至るまで、すべてのサービスやシステムの確認と、存在している理由を可視化しましょう。そして、システム間の依存関係、例えば、あるビジネスに直結した自動化プロセスが、あるアプリケーションの機能に依存する場合、その依存関係をマッピングします。これらの依存関係は、インシデントが発生した場合に、復旧の順序を決定するために不可欠となります。
ステップ3：システムに優先順位をつける
有給休暇を申請するシステムより先に、顧客情報システムの復旧が急がれるように、ビジネスへの影響度合に基づいて、STEP2で作成した一覧表をもとに各システムを優先順付する必要があります。これが、災害復旧計画のもととなるビジネスインパクト分析（BIA）を作成するための最初のステップとなります。
ここで重要となるのは、システムの紛失、または利用できなくなった場合に発生する実際のコストを計算することです。それぞれのシステムに一定期間アクセスできない場合に、時間・生産性・金銭の面でどれだけのコストがかかるのかを計算し、最もコストがかかるシステムは優先度を高くします。各システムがビジネスに直結している度合いと、その損失コストを可視化するまでは、災害復旧計画にどれだけの資金を投入すべきかを判断することはできません。
ステップ4：RPO、RTO、RLOの設定
停電やデータ損失といった最悪のシナリオを想定した計画を立てる必要もあります。次のステップでは、そうした障害が発生した場合の復旧時点目標（RPO）、復旧時間目標（RTO）、復旧レベル目標（RLO）を決定します。
これらの略語は耳にしたことがある方も多いかと思います。
・RPO＝最後のバックアップから潜在的な障害ポイントまでの最大時間
・RTO＝ビジネスが復旧に要することができる最大時間
・RLO＝データを復旧しなければならない粒度
自社のビジネスによって、どの項目を優先すべきかは変化します。
例として、病院であれば患者情報の正確な復旧が最重視されますし、SaaSビジネス企業であればCRMの迅速な復旧が最重視されるといった形です。データポイントを参照し、重要なシステムがどれくらいの時間ダウンしたら損失が発生するかを正確に判断することで、3つの目標において意味のある数値を決めることができるのです。
ステップ5：RPO、RTO、RLOをテストする
3つの目標を設定した後は、いよいよリハーサルの実施です。復旧のスピード、正確さ、潜在的なデータ損失の可能性など、これらの指標をリハーサルしなければ、有事の際に復旧可能かどうかはわかりません。「災害が発生したらどうするかわかっているつもり」の状態と、「避難訓練をしたことがある」状態は全く異なります。
初回で3つの目標を達成できることはまれです。改善を繰り返し、目標を達成するために必要な追加リソースを決定していきましょう。また、復旧速度目標の達成のために、データ損失の許容量を増やすなど、目標の再設定も重要です。
AvePoint Cloud Backup for Azure のようなツールに投資することで、データ復旧の粒度と復旧までの時間目標の両方を達成できる場合もあります。
ステップ 6: 災害復旧予算の提唱
IT関連における最悪の状況が発生した場合に、復旧に何が必要になるかの可視化は完了したことになります。しかし、経営陣などは、なぜ復旧にコストがかかるのか理解できないかもしれません。IT担当者以外の多くの人は「クラウド上にある＝保護されている」と考えていることも多いのです。
必要性に関しては、マイクロソフトのShared Responsibility Model（責任共有モデル）を使用したり、他のクラウドプロバイダーからが出されている同様の規定を用いて、役員を説得することができるでしょう。説明の際により重要となるのは、それコストがどのように算出され、どれほど価値があるのかを説明することです。
災害復旧計画は投資です。投資しない場合のコストは、有事の際に計り知れないほど高くなります。特に、評判の低下や顧客の喪失など、計算できないコストがあることに留意すれば、投資しなかった場合の損失に実感がわいてくることでしょう。災害復旧計画への投資は、ビジネスの中断から保護されたときに、アップタイムという形で配当として返ってくるのです。
最後に
災害復旧計画を作成するのは大変な作業です。しかし、早く始めれば始めるほど、より安全で正確、迅速なデータ保護を実現できます。
まずはスモールスタートとして、自社において最も標準的で重要なITサービスの保護から計画してみましょう。そして、信頼できるサードパーティ・プロバイダーとの提携を検討してみてはいかがでしょうか。
AvePointのバックアップ ソリューションは、Microsoft 365、Entra ID、Power Platform、Dynamics 365、Salesforce、Amazon Web Services、Google Workspace 向けの使いやすいソリューションとなっています。
まずはこちらより、お気軽にお問い合わせください。
データ保護に関してはこちらのコンテンツもご覧ください。
ブログ原文：How to Build Your Disaster Recovery Plan – AvePoint Blog | AvePoint
