BCP対策において事業の継続性と密接な関係をもつRTO・RPO・RLOは重要な要素です。「いつまでに」「どの時点までを」「どのレベルで」を示しているRTO・RPO・RLOの3つについて、設定の意味や考え方を紹介します。
BCP対策において不可欠となる3要素、RTO・RPO・RLOの共通点は目標値であること。同時に相違点もあります。RTOは「いつまでに」という目標値、RPOは「どの時点まで」の目標値、そしてRLOは「どのレベルで」という目標値です。目標値を設定する対象が異なります。
RTOとはRecovery Time Objectiveの頭文字をとった略語です。Time、つまり時間を対象としています。
RTOは「いつまでに」、あるいは「あとどのくらいの時間で」システムを復旧させるか、システムが復旧するのかという目標値を示しています。したがって、復旧までの時間を明確にすることがRTOを設定する意味です。
RTOを設定する場合には、復旧する側の都合と同時にシステムダウンやサービス停止が利用者である顧客に許容される時間がどのくらいあるかを考えなくてはなりません。極端な話、被災の有無にかかわらず当面サービス利用者が来る予定がなかったというケースと、予約がいっぱいでキャンセル待ちもある人気サービス、または生活に欠かせないサービスとでは、一般的に考えて許容時間は大きく異なります。
利用者や生きるうえでの影響が少ない場合であればじっくりと復旧を進めることが可能ですが、予約待ちや生活に大きな影響が出る場合では急いで復旧したいところです。とはいえ、中途半端な状態でサービスを再開してもお客さまの満足が得られなければ意味がないどころか失敗となってしまうことも。
企業にとってシステムやサービスが動かなくなってしまうことは絶対に避けなければならないことです。しかしながら、いくら万全を期したつもりでいても、ダウンするときはダウンしてしまうのがシステムでありサービスだといえます。滅多に起きないことではあるものの起きる可能性はゼロではありません。
BCP対策では、このダウンタイムを限りなくゼロに近付けることが重要となります。ただし、ゼロに近ければ近いほどコストが増える点に注意が必要です。インシデント発生から即座に復旧できる体制といえば、完全に同じ環境をバックアップとして複数用意しておく必要があります。
そして、いざとなればいつでも動かせる状態をキープしていることが前提です。これではコストが高くつくのも自然なことだといえるでしょう。したがって、RTOの設定においては、許容される時間内で最短の復旧が現実的です。具体的な時間設定は、RLO「どのレベルで」復旧するかも一緒に考えます。復旧レベルによって必要となる時間が異なるためです。
許容できる時間を超えてしまうと、顧客からの信頼が消し飛んでしまったり、取引先やステークホルダーの信用を無くしてしまったり、時にはサービス提供者の生活や生命に悪影響を及ぼしたり、といった事態にもつながりかねないことを頭に叩き込み、忘れないようにしましょう。
RPOとはRecovery Point Objectiveで、どの時点までの（データを）復旧させるかという過去の時点を指す言葉です。
「どの時点まで」というと間違いやすいため注意が必要です。「10分前まで」という場合は現在から10分前までのデータを復旧するという意味ではなく、過去から10分前までのデータを復旧するという意味です。（現在から10分前までシステムが落ちているため、データ自体がないことがほとんどです）したがって、この10分間のデータは復旧されません。どの時点まで復旧すれば業務に支障が出ないか、支障を最小限に抑えられるかを示すことがRPOを設定する意味です。
RPOの設定においては、データの重要性がポイントとなります。業種あるいは業務内容によって重要性が変わるため、慎重な検討が必要です。たとえば、常に詳細な情報が必要とされる業務であれば、RPOは0、つまり0秒前まで復旧しなければなりません。
パソコンでデータを入力しているケースを想定した場合、ひっきりなしに入力しているため0秒前の復旧を前提とするなら、常時保存をかけておく必要があります。しかし、1時間に1回しか入力しないなら、保存作業は1時間に1回だけで間に合います。
また、たとえば毎日午前3時に自動でバックアップを取るとしましょう。翌日の午前2時にデータが飛んでしまうと、最終バックアップからの23時間分のデータが無くなります。入力の頻度にばらつきがある業務で、たまたま数件の入力しかなければ被害は小さいかもしれません。しかし、運悪くこの23時間に大量のデータが入力されていたとなれば被害は甚大となりかねません。RPOの設定は容易ではないといえるでしょう。
データの重要度が低いとか、最近のデータなら復旧できなくても大きな手間をかけずに再入力できるといったケースでは、たとえ頻繁に入力があったとしてもRPOを大きめの数字で設定する扱いもアリだといえます。コストの問題とも無縁ではなく、あくまでも置かれている状況すべての兼ね合いが重要です。
RLOとはRecovery Level Objectiveで、どのレベル（範囲や数値、能力）まで復旧させるかを示しています。
RLOを設定する意味は、システム運用やサービスの提供を再開可能な復旧の程度を見極め、どの段階で再開するか、再開させるかを示すことにあります。
RLOの設定対象となるのはレベルですが、この場合のレベルはさまざまです。施設の物理的なキャパシティーであったり、生産能力値であったり、商品やサービスの品質であったりします。復旧の段階に応じたサービス再開の可能性はありますが、実際に再開するかどうかの決断が重要です。高レベルになるほどコストも高くなります。
たとえば、被災前に提供していた商品が3日間使用できる消費財だったとしましょう。まったく同じ3日間使える商品の製造が可能になるのが10日後で、2日間だけ使えるレベルなら3日後には製造供給できるという状況です。その商品が毎日の生活で欠かせないもので予備が少なければ2日間でも使えれば欲しいところではないでしょうか。
また、電車の復旧も分かりやすい例です。大災害時に全線不通となった路線があるとしましょう。長さ10キロにわたる路線で駅が6つある場合、6つの駅を結ぶ10キロすべてが運転再開することを全線復旧と呼びます。途中の数駅、数キロ分だけの運転再開なら部分復旧です。部分復旧にも少なめから多めまで何段階もあります。当然、復旧のレベルによって所要時間も変わるため、RTOとセットで設定することになります。
電車の例えでは、全線復旧するまで運転再開しないのか、部分復旧で運転再開するのかといった判断が入ります。利用客の利便性を中心にほかの条件も加味して総合的に判断して設定することになるでしょう。
もう1つ例を挙げておきます。飲食店が被災した場合で、数日後には調理可能なレベルまで復旧しました。しかし、お客さまが食事をするホールスペースの復旧はまだ先になるといった場合、調理したものをテイクアウトで提供するか、ホールにお客さまが入れるようになるまで料理を作らないとするのか、2者択一の状況が生まれます。
RTOとRPOとRLOの3つは、それぞれ別の対象についての目標値を示すものですが、BCP対策においては潜在的な緊急事態に備え、有事においては事業継続性を確保する、お客さまや従業員を守り企業も守る要素として重要です。