ページの先頭です。
本文へジャンプする。

本ウェブサイトでは、JavaScriptおよびスタイルシートを使用しております。
お客さまがご使用のブラウザではスタイルが未適応のため、本来とは異なった表示になっておりますが、情報は問題なくご利用いただけます。

NEC NECネクサソリューションズ
ここからサイト内共通メニューです。
サイト内共通メニューを読み飛ばす。
サイト内共通メニューここまで。
サイト内の現在位置を表示しています。
ホーム > ソリューション・セミナー > ソリューション・サービス > NECネクサソリューションズのコンサルティングサービス - コンサルタントのコラム
ページ共通メニューここまで。

NECネクサソリューションズのコンサルティングサービス

ITにおけるBC(事業継続)について

[第3回]目標復旧時間(RTO)について

2009年12月7日

目標復旧時間と最大停止許容時間

BCPを構築する上で、目標復旧時間の設定は重要なポイントとなります。
目標復旧時間とよく似た言葉に「最大許容停止時間」がありますが、定義は異なります。

目標復旧時間(RTO
何らかの事象(例えば大規模震災)が発生し、業務が停止してから、一定レベルまで業務が再開するまでにかかる時間(期間)
最大許容停止時間(MTPD
何らかの事象(例えば大規模震災)が発生し、業務が停止してから再開するまでに、「これ以上かかると経営者が当該事業の継続が不可能(経営者が事業からの撤退や清算を考慮)」と判断する時間(期間)

目標復旧時間は最大許容停止時間より短くあるべきです。業務が復旧できたときには経営判断により当該事業から撤退が決定、もしくは会社が倒産していたら洒落になりません・・・。

[図]あるべき姿

目標復旧時間の設定

IT-BCPに関して言えば、目標復旧時間は業務との依存関係によって決まってきます。

目標復旧時間が長く(ゆるく)設定できるケース

ITサービスが停止しても業務側で代替手段があり、一定期間対応できるのであれば、それだけ目標復旧時間を「ゆるく(長く)」設定できるはずです。

現状では無理でも、一定の条件を満たすことで業務継続が可能であるならば、まずその条件を叶えるところから着手することで、それだけ余裕ができるはずです。
例えば、現状はシステムでしか参照できない出荷予定表があるとします。これを、システムに依存することなく参照できるようにすれば、条件を叶えることになります。
条件を叶える手段としては、出荷予定表を定期的にダウンロードしておくことで、システムに依存しなくても参照できるようにする、等です。

目標復旧時間が短く(きつく)設定されるケース

完全に業務がITサービスに依存しているのであれば、業務の目標復旧時間より「きつい(短い)」設定が求められます。
通常はITが稼動後、業務側でデータ確認・再処理等が発生しますので、このケースに該当します。

[図] ITサービスと業務の復旧ITサービスと業務の復旧

目標復旧時間を設定する上で考慮すべきこと

目標復旧時間を短くするということは、当然それなりの投資が必要になります。
この設定を誤ると、過剰な対策を招いたり、逆に必要な対策がとれず、「最大許容停止時間」をオーバーしてしまったりすることになります。

業態にも依りますが、大規模災害が発生した場合、ITと同時に業務部門も同じような被害を受けているはずです。従ってITサービスの復旧を急いでも、使う側が立ち上がっていないのでは意味がありません。
逆に、全国もしくは世界的に展開している事業が、一地方の災害により停止してしまうのでは問題が有ります。

目標復旧時間設定の現状

最近の調査で、ITに求められる目標復旧時間を「半日以内」としている回答が半数近くあった、とのレポートがありました。
私がお客様に目標復旧時間を尋ねると、一次回答の多くは「1日以内」です。これは調査レポートとそれほどかけ離れた数値ではないように思います。

ただし話をよく聞くと、「実際には1週間ぐらいかなぁ」となります。
さらに、実際にどのような行動が必要か洗い出していくと、「ちょっと1週間じゃ無理だね・・・」となります。
特に、自社でサーバルームを構築しているお客様の場合、建屋自体が被災すると場所の確保から考えなければなりません。支社なり地方拠点の一室を流用するにしても、電源や空調といったファシリティから通信回線の手配、ハードの手配等を考えると数ヶ月かかることもあり得ます。

目標復旧時間と必要な対策

経験上の個人的な見解ですが、ITに関して目標復旧時間と必要となる対策例をまとめると、以下の表になります。

目標復旧時間と対策例
目標復旧時間 必要となる対策例 備考
~半日 遠隔地でのアクティブスタンバイ
(データのリアルタイム同期)
ほぼ無停止に近い対策が必要
~1日 遠隔地でのホットスタンバイ
(データの日次同期)
切替判断ができるメンバ(代行者)が
被災地以外にいることが必要
~5日 遠隔地でのホットスタンバイ
(データの週次同期)
~10日 遠隔地での予備機準備
(データ同期なし、バックアップからのリカバリ)
~1ヶ月 バックアップサイトの確保
  • 少なくともファシリティレベルまで準備できていること
  • 汎用的に使えるサーバ構成であること(PCサーバ等)
~数ヶ月 バックアップのみ

システム毎に目標復旧時間が異なるのは当たり前です。
しかし、「最重要なIT」と位置づけられたシステムでも、遠隔地でのホットスタンバイまで準備できている企業は、金融等一部の業種を除いてほとんど無いと思われます。

着手の順序

まずは、自分の会社における重要事業、つまり、継続しなければならない事業が何であり、その事業を継続するためには、どのITサービスが必要なのかを選別してください。
その上で、当該システムの現在の目標復旧時間を把握することから着手してください。

その後、事業影響度分析の手法を使って、経営陣・業務部門と目指すべき目標復旧時間・最大停止許容時間について協議し、現実的な目標復旧時間の設定および必要な対策に着手してください。

執筆

NECネクサソリューションズ
コンサルタント 吉川 明人
[CISA公認情報システム監査人,情報セキュリティアドミニストレータ,ネットワークスペシャリスト,NPO事業継続推進機構会員]

○スキューバダイビング暦15年、トータルダイビング本数1200本以上♪
ダイビングの基本はリスクマネジメントと、自らリスクマネジメントを実践!?
10月に水中撮影用のビデオカメラを新型に更新♪
でも、まだ使いこなせていない・・・

本コラムに関連するNECネクサソリューションズのコンサルティングサービス

ページの先頭へ戻る

Copyright © NEC Nexsolutions, Ltd. 2001-2010. All rights reserved.