戻せるのは「いつの時点」か、それとも「どれだけ早く」か

過去方向はRPO、未来方向はRTO

オーディットコア・ハブのアキラです。

この記事では、障害が起きたときに、どの時点のデータまで戻せるのか、それともどれだけ早く戻せるのか、という似た2つの問いを見分けていきますね。

名前の似た指標が並ぶところですから、私と一緒に整理していきましょう。

データの話か時間の話かは、障害発生の時点から見て過去方向か未来方向かで先に振り分けます。

この一文が、今回の暗記対象なんです。

ひとことで言えば、障害発生の時点に線を引いて、過去方向はRPO、未来方向はRTOと決めておく、ということなんですね。ここは知識よりも整理の問題ですよ。

この記事で分かること

• RPO・RTO・RLOがそれぞれ何を測る指標で、BIAやSLAとどう立場が違うのか
• 代替施設の速さと費用の並び、そして不測事態対応計画がどんな順序で進むのか
• この論点で想定される3つの出題型と、その切り方

戻せるのは「いつの時点」か、それとも「どれだけ早く」か（P2-A-03-d）

よくある誤解

• 障害のときにどの時点のデータまで戻せるかを問われて、復旧までにかかる時間の指標を答える取り違え
• ビジネスインパクト分析（BIA: Business Impact Analysis）を、データ損失量を表す単一の指標だと考える混同
• サービスレベル合意（SLA: Service Level Agreement）を、データ損失量を表す指標だと考える混同
• バックアップを取る間隔と、復旧目標の設定は別々に決めてよい、という切り離し

並んでいる言葉は、どれも実際の計画に出てくるものです。けれども、その言葉が何を測っているのかを取り違えると、そのまま結論を外します。

何とつながっているのかを取り違えたときも同じです。ここは、知識よりも整理の問題なんですね。

解説

障害が起きたときの時間軸を、まず一本引きましょう。

左から順に、最後のバックアップを取った時点、障害が発生した時点、システムの利用を再開した時点、システムが完全に復旧した時点。この4つが並ぶんです。

ここで大事なのは、障害発生の時点を境にして、話が過去方向と未来方向に分かれることなんです。どの時点まで戻せるのか、それともどれだけ早く戻せるのか。

聞かれているのは、どちらでしょうか。

過去方向、つまり最後のバックアップから障害発生までの区間が、目標復旧時点です。略してRPOと呼びます。

どの時点のデータまで復旧できると約束するか、を示す指標ですね。RPOを1時間と置いたなら、止まる1時間前の状態までデータが戻る、という意味になります。

逆に言えば、その1時間分は失われるということですよね。だからRPOは、許容できるデータ損失の幅そのものなんです。

未来方向、つまり障害発生から利用再開までの区間が、目標復旧時間です。こちらは略してRTOですね。

あらかじめ決めた水準までシステムが戻るのに、どれだけの時間をかけてよいか。業務の重要度に応じて設定します。

もうひとつ、目標復旧レベル、略してRLOという指標もあります。こちらは、RTOの時点でどこまでの機能が戻っているかを示す指標ですね。

全機能を同時に戻すこともあります。一部の機能を先に戻すこともあります。

だから、どの水準まで戻すのかを明示しておくんですね。

短くする手立ても、それぞれ違います。RPOは、バックアップを取る間隔を詰めれば短くなります。

RTOは、復旧に使う代替施設を先に整えておけば短くなります。

たとえば、書きかけのレポートを1時間ごとに保存していれば、パソコンが落ちても失うのは最大1時間分ですよね。

つまり、バックアップ頻度とRPOは切り離せない関係にあります。頻度が粗いほど、失うデータの幅は広がるんです。

データの話か時間の話かは、障害発生の時点から見て過去方向か未来方向かで先に振り分けます。

3つの指標を、段階に分けて設定する例も見ておきましょう。先に見取り図を渡しておきますね。

段階が進むと変わるのは、復旧時間と復旧レベルです。変わらないのは、復旧時点ですね。

復旧の第1段階では、目標復旧時間を2時間、目標復旧時点を1時間と置きます。目標復旧レベルは、オンライン機能をすべて戻すところまでなんです。

第2段階では、目標復旧時間を1日まで伸ばします。目標復旧時点は1時間のままです。

目標復旧レベルは、バッチ機能まで含めた完全復旧になります。

この例で目に留めてほしいのは、目標復旧時点だけが両方の段階で同じ値になっているところなんですね。

どれだけ早く戻すか、どこまでの機能を戻すかは、段階に応じて動かします。どの時点まで戻すかは、共通に置きます。

そういう組み方になっているんです。3つを別々の欄として持っておくと、こういう読み分けができます。

まずは、欄を3つに分けて持ってみてください。

BIAについても整理しておきましょう。BIAは指標ではなく、手法なんです。

BIAによって明らかになるのは、事業継続計画の対象になる重要業務の特定です。あわせて、業務の継続と復旧の優先順位付けも明らかになります。

そして、目標復旧時間と目標復旧ポイントの設定も出てきます。主たる目的は、有事に優先して戻す業務を選び、その目標復旧時間を決めることにあります。

つまりBIAは、RPOやRTOという数字を生み出す側の手続なんですね。単一の指標だと考えると、BIAと指標の上下関係が見えなくなります。

優先して戻す業務を、どうやって選ぶのか。ここにも順序があります。

出発点は、有事を想定することです。ここから、順に追ってみましょう。

まず環境の面から見ます。対象の業務が使っている建物や、電気・ガス・水道といった社会インフラがどんな被害を受けるかを見積もります。

そこから、業務への影響を考えるんですね。次に業務の面から見ます。

その業務を回すために欠かせない最低条件を整理して、想定した被害のもとで止まってしまう業務を洗い出します。

そのうえで、業績に与える影響やCSR、つまり企業の社会的責任といった観点から順位を付け、先に戻す業務を選ぶんですね。

選び終えた業務について、目標復旧時間と目標復旧時点を定めます。

そして、その目標を達成できるように、予防や代替手段といった対策を考えていく、という流れです。つまり、順位を決めてから目標を置く、という向きなんですね。

不測事態対応計画の全体の流れも、順序で押さえてください。まず、ビジネスインパクト分析でリスクと業務への影響を分析します。

次に、予防・発見・是正の方法を組み合わせて復旧戦略を立てます。それから、復旧計画を含む詳しい計画を作ります。

最後に、テストと維持で有効性を検証していくんですね。

なお、事業継続計画（BCP: Business Continuity Planning）は通信や輸送まで含めた事業全体の復旧を扱い、災害復旧計画を伴います。

復旧に使う代替施設は、速さとコストの並びで覚えると迷いません。ホット・サイトは、適合する機器も電源も空調も整っています。

ですから、瞬時から数時間で業務を再開できるんです。そのぶん費用は非常に高くつきます。

速さを買っている、と思ってください。ウォーム・サイトは、電源や空調といった土台はあるものの、肝心の機器が置かれていない施設です。

緊急時に速やかに機器を調達できることが前提なんですね。コールド・サイトは、場所だけが用意された施設です。

機器の運び込みとインフラの導入が必要になり、再開まで数週間かかることもあるんです。最も経済的なのは、このコールド・サイトです。

相互援助協定は、似た構成の機器やアプリケーションを持つ組織どうしが、災害時にコンピュータの使用時間を融通し合う約束ですね。

低コストですが、装置構成の違いから頻繁なプログラム変更が必要になります。並べてみると、速さと費用が逆を向いているのが見えますよね。

障害回復の技術も一言だけ。フェイルソフトは、壊れた箇所を切り離して影響が広がるのを防ぎ、最低限の稼働を続ける技術です。

ミラーリングは、バックアップサーバーに複製しておいて、主たるサーバーが止まったら引き継がせます。

耐故障コンピュータ・システムは、構成要素を重複して積み、中断せずに提供し続けます。ですから、回復させる時間という概念そのものを持たないんです。

可用性コンピュータは、障害が起きた際に即座に回復するための仕組みです。ここが、耐故障との分かれ目ですね。

一言で対比するなら、耐故障は構成要素の重複で止まらない側、可用性は止まってもすぐ戻す側です。

回復させる時間があるのかないのか、ここで一度立ち止まってみてください。

最後に、監査の手続。不測事態対応計画を検証する方法としては、2つが挙げられます。

ひとつは、計画の内容が定期的に机上でレビューされているかの確認です。もうひとつは、担当者が内容を理解しているかを確かめるインタビューですね。

本番のシステムを実際に止めて、計画どおりに戻せるかを試すところまでは、通常は行いません。

完全に復旧できなかったときのことや、一時的に業務が止まる影響を考えれば、当然といえば当然ですよね。

この論点はこう問われる

近接概念の比較型。 RPO、RTO、RLO、BIA、SLAが並ぶ作りが想定されます。

単位を見てください。時点ならRPO、時間ならRTO、機能の水準ならRLO。BIAは手法、SLAは契約上の合意ですから、そもそも指標の列に入りません。

単位で振り分けるだけで、半分以上は落ちます。

• 例1: 「どの時点のデータまで戻せるか」と問われる形です。単位が時点ですから、答えはRPOに決まりますよ。
• 例2: 「どれだけ早くシステムを戻せるか」と問われる形もありますよね。単位は時間ですから、答えはRTOの側に寄ります。
• 例3: 「RTOの時点で、どこまでの機能が戻っているか」を問う書き方も出てきますよ。単位が機能の水準ですから、RLOに決まるんです。
• 例4: 「BIAは、データ損失量を表す単一の指標だ」と書かれたものが混ざることもありますよ。BIAは手法ですから、そもそも指標の列には入りませんよね。

条件のすり替え型。 短い復旧目標が示されているのに、立ち上げに日数のかかる施設が計画に割り当てられている、という作りと相性がよい論点です。

要件として示された時間と、その施設が立ち上がるまでに必要な時間を、必ず突き合わせる。数字が2つ出てきたら、比べるために置かれています。

2つの数字を見つけたら、線で結んでみてくださいね。

• 例1: 「復旧目標は短いのに、機器の置かれていない施設を割り当てた」という作りが来ることもありますよ。
  2つの時間を突き合わせれば、間に合わないと分かります。
• 例2: 「場所だけが用意された施設で、短い復旧目標を満たす」と書かれたものも置かれますよ。
  再開まで数週間かかることもありますから、突き合わせれば外せますね。
• 例3: 「あらかじめ決めた復旧目標の時間」と「施設が立ち上がるまでに必要な時間」が両方書かれていたら、比べるために置かれているんです。
  線で結んでみてくださいね。
• 例4: 「機器も電源も空調も整った施設を割り当てた」と書かれていたら、瞬時から数時間で再開できる側ですね。
  ここでも、示された目標の時間と突き合わせて確かめましょう。

手続・順序型。 不測事態対応計画の流れのどこにいるかを問う型も想定されます。

影響を測る前に、施設や技術を選ばないという順序を持っておくと、先回りした行動を選ばずに済みます。順序を飛ばしていないか、ここで一度確かめましょう。

• 例1: 「不測事態対応計画の流れのどこにいるか」を問う形も考えられます。影響を測る前に施設や技術を選んでいる記述は、順序を飛ばしている側に置けますね。
• 例2: 「先に代替施設を決めてから、業務への影響を分析する」と書かれたものはどうでしょう。影響を測る前に施設を選んでいますから、順序が逆ですよね。
• 例3: 「優先して戻す業務を選んでから、目標復旧時間と目標復旧時点を定める」という記述に出会ったら、これは順序どおりの側です。
  順位を決めてから目標を置く流れでしたから、残しましょう。
• 例4: 順序を飛ばしていないかは、流れを指で押さえると分かります。
  「復旧戦略を立ててから、影響を分析する」と書かれたものは、入れ替わっている側に置けますよ。

試験テクニック

略語が並ぶ問題は、日本語の正式名称に開いてから比べる。 目標復旧時点と目標復旧時間は、日本語にすると一字しか違いません。

それでも、「時点」と「時間」という言葉が目に入れば、過去方向と未来方向の区別を思い出せます。手順は3つですよ。

まず、略語に印を付けます。次に、正式名称を書き添えます。

最後に、読み比べます。この3手を、手を動かして試してみてください。

もうひとつ。代替施設の比較では、コストと復旧速度がトレードオフの関係にあります。

トレードオフとは、つまり、一方を取れば他方があきらめになる関係のことですね。この関係を、先に序列として作っておいてください。

速いものほど高く、安いものほど遅くなります。この並びを持っていれば、「最も速く再開できる」といった聞かれ方には、すぐ見当が付きます。

ただし、コストの側から聞かれたときは、並んでいる記述の顔ぶれを先に確かめてください。

代替施設どうしを比べているのか、相互援助協定まで含めて比べているのかで、見るべき範囲が変わります。

顔ぶれを見ないまま反射で答えるのは、この代替施設の一群では避けたほうが安全です。

• 例1: 「RPOとRTOのどちらを答えるか」と迷う記述では、略語に印を付ける手順1から入りますね。印を付けるだけで、見比べる場所が定まります。
• 例2: 「目標復旧時点と目標復旧時間のどちらか」と迷ったら、正式名称を書き添える手順2まで進めましょう。
  時点と時間という言葉が、方向を思い出させてくれますよ。
• 例3: 「最も速く業務を再開できる施設はどれか」と聞かれる形なら、速いものほど高いという序列を先に作っておくと、すぐ見当が付くんです。
• 例4: 「最も経済的な代替施設はどれか」とコストの側から聞かれたら、並んでいる記述の顔ぶれを先に確かめてください。
  相互援助協定まで入っているかで、見るべき範囲が変わるんです。

覚え方

情報システム部長との打ち合わせで「復旧目標は4時間です」と言われた場面を思い浮かべてください。

そこで次に聞くのは「そのとき、データはいつの時点まで戻りますか」です。前向きの答えをもらったら、後ろ向きの答えも取りにいきます。

これが習慣になっていれば、取り違えは起きないんですね。

教訓を一言で。戻せるデータの幅はRPO、戻るまでの時間はRTO。

この記事の1枚まとめ

全文が読める見本: 3ラインモデル、外部評価の実施間隔