2020年03月10日 08時00分 公開
特集/連載

災害復旧が失敗する6つの落とし穴【前編】テストしていないDR(災害復旧)計画がもたらす残念な結末

さまざまな要因により、災害復旧の優先度が高まっている。だが多くの企業が、普通に考えれば落ちるはずのない落とし穴にはまって復旧に失敗している。この、当然回避できる落とし穴になぜ落ちるのか。

[Stephen Pritchard,Computer Weekly]
iStock.com/fergregory

 災害復旧(DR)は、ITの障害や自然災害など予期せぬ事態が起きた後、「通常業務」に戻す機能である。

 中核ビジネスシステムのメンテナンス、そのシステムデータの保護、クライアントPCやネットワークの提供を担当するのはIT部門だ。最近では、音声通信の提供なども担当に含まれる。だがDR計画は事業規模の課題なので、事業部門にも責任が及ぶ。

 企業はかつてないほどデータを利用するようになっており、IT部門は世界中のどこでもそうしたデータへのアクセスを適切に提供するようになりつつある。こうした状況を背景に、IT部門にはこれまで以上に大量のデータの処理が求められる。ユーザーや顧客はダウンタイムに以前ほど寛容ではなくなっており、データに対する攻撃を企業の機能を停止させ金銭を得るための手段と考える攻撃者も増えている。

 ITサービスの継続性に関する国際規格であるISO 27031では、IT部門向けにDR計画の枠組みが定められている。

 だが事業運営とITシステム双方の複雑さが増しており、不用心な企業の落とし穴は増えている。

DRの落とし穴1:計画の怠り

 最大の失敗は、DR計画を怠っていることだ。

 複雑なDR計画は必要ない。小企業や支社であればあまり複雑な計画にはせず、オフサイトに保管されているストレージやクラウド(最近増加中)にデータを定期的にバックアップすること。最悪の事態が起きた際にデータにアクセスする方法とアプリケーションを復旧する方法を定める程度でいいだろう。

 大企業ならば、

  • 保護対象のアプリケーション
  • その復旧方法
  • 復旧対応を代行できる人員の手配

など、計画をもっと細部まで練り込むことになる。こうしたDR計画としては、IBMの例を参照してほしい。

 Freeform Dynamicsでアナリストを務めるトニー・ロック氏によると、DR計画には各種プラットフォームの復旧順序を明記しておくべきだという。「アプリケーションやサービスの要件からこの順序が明確に決まることもある。だが、主要サイトの復旧が必要な場合は社内の政治力が影響するかもしれない。DR作業に着手できる人員や作業環境がどうなっているかも問題になる」と同氏は話す。

 DR計画を用意しても、その対象範囲を限定し過ぎると別の問題が発生する。




続きを読むには、[続きを読む]ボタンを押して
ください(PDFをダウンロードします)。






ITmedia マーケティング新着記事

news111.jpg

マーケターの5割が自分の仕事の自動化に不安――ベーシック調査
マーケターのキャリアに関する調査結果です。

news150.jpg

SNSマーケティング予算は前年比で増加傾向、注力するのは「Instagram」と「Twitter」――ガイアックス調査
ガイアックスの運営するSNSマーケティングメディア「ソーシャルメディアラボ」が150社を...

news129.jpg

新型コロナウイルス感染拡大で米国のEC取引が急増――Adobe Digital Economy Index
Adobeは、「Adobe Analytics」と、オンラインでの商品およびサービスの売り上げを測定す...