SLA・RTO・RPOの違いとは？BCPの用語を身近な例と図でやさしく解説

会議で説明を聞いても、英字の略語が続くと関係をつかみにくいですよね。
どれもサービスの停止に関わる言葉ですが、答えている疑問は違います。

この記事では、同じ受注システムの例を使って、3つの意味と違いを整理します。
読み終えるころには、復旧計画やサービスの説明書で、どの数字を確かめればよいか分かります。

まずは結論から

SLAはサービス品質についての合意、RTOは復旧までの目標時間、RPOは復旧するデータの時点に関する目標です。
まずは、次の3つの問いに置き換えてみてください。

• SLAは「提供側と利用側で、どんなサービス品質を約束しているか」。
• RTOは「止まってから、何時間以内に再開することを目指すか」。
• RPOは「データは、障害の何分・何時間前の状態まで戻せればよいか」。

RTOとRPOは、守りたい仕事から決める目標です。
それらがSLAに盛り込まれることもありますが、稼働率だけが書かれたSLAから、復旧時間やデータの新しさは分かりません。
以下では、まずBCPとのつながりから見ていきましょう。

BCPと3つの用語のつながり

BCP（ビーシーピー）は「事業継続計画」のことです。
災害や大きな障害が起きても、大事な仕事を続けたり、早く再開したりするための計画を指します。
英語ではBusiness Continuity Planといいます。

たとえば、受注用のシステムが止まった場合を考えてみてください。
パソコンを直すだけでなく、電話で注文を受ける方法、担当者への連絡、発送の優先順位も決めておく必要があります。
BCPが扱うのは、こうした仕事全体の備えです。

その中で「何時間以内に受注を再開するか」を決めるのがRTO。
「注文データはどこまで残す必要があるか」を決めるのがRPOです。
外部のサービスを利用するなら、提供側との約束であるSLAも照らし合わせます。

仕事の再開を引っ越しにたとえると、BCPは引っ越し全体の段取りです。
RTOは新しい場所で仕事を始めるまでの時間、RPOは持っていける帳簿の新しさに当たります。
SLAは、手伝ってくれる業者との間で取り決めたサービス内容と考えると、関係が見えます。

事業を続けるために、優先する仕事と復旧の目標を決める考え方は、中小企業庁のBCP解説でも示されています。

※ 中小企業庁は、中小企業の経営を支援する国の機関です。
リンク先は、同庁のBCP策定運用指針に含まれる公式解説です。

RTOとRPOの意味をつかむ時間軸

どちらも時間で表すので、ここが最も混同しやすいところです。
RTOは障害が起きた後、RPOは障害が起きる前のデータに目を向けると区別できます。

RTOは「何時間以内に再開するか」

RTO（アールティーオー）はRecovery Time Objectiveの略で、日本語では「目標復旧時間」です。
システムや業務が止まってから、定めた状態まで復旧するための目標時間を指します。

13時に受注システムが止まり、RTOを4時間と決めていたとします。
この場合、17時までに再開することが目標です。
「担当者が作業を始めてから4時間」ではなく、ここでは停止した13時を起点に考えます。

復旧とは、必ずしも全機能が元どおりになることではありません。
「注文の登録と確認ができる」など、必要な状態を先に決めます。
画面が開いても注文を保存できなければ、受注の仕事は再開できませんよね。

RTOは実績や保証された所要時間ではなく、達成するために準備する目標です。
実際に再開まで5時間かかったなら、RTO4時間という目標を超えています。
復旧作業だけでなく、障害への気付き、連絡、動作確認の時間も見込む必要があります。

RPOは「どの時点のデータまで守るか」

RPO（アールピーオー）はRecovery Point Objectiveの略で、日本語では「目標復旧時点」です。
障害から復旧したとき、どの時点までのデータを取り戻せる必要があるかを決めます。
データが失われる可能性のある範囲を、時間で表す目標です。

同じ13時の障害で、RPOを1時間とします。
この場合は、12時時点までのデータを取り戻せることが目標です。
12時から13時までの注文は、復元したデータに含まれない可能性があります。

「1時間分なら失っても影響がない」という意味ではありません。
注文メールなどから入力し直せるか、顧客への確認が必要かも含め、仕事として対応できる範囲を決めます。
実際に失うデータが必ず1時間分になるわけでもありません。

RTO・RPOの定義は、AWSの復旧目標に関する公式技術文書でも確認できます。

※ AWSは、Amazonの提供するサーバーやデータ保存などの機能をインターネット経由で提供するクラウドサービスです。
リンク先は、システムの設計・運用を考えるための提供元の技術文書です。

バックアップの頻度だけでは決まらないRPO

バックアップとは、失ったデータを戻すため、別にコピーを保存しておくことです。
RPO1時間を目指すなら、1日1回のバックアップだけでは、日中の障害に対応できません。

ただし、1時間ごとの取得設定があれば十分、ともいえません。
取得の失敗、保存先への転送の遅れ、コピーの破損によって、使えるデータが古くなる場合があります。
確認するのは設定した間隔に加え、実際に戻せるデータの時点です。

バックアップの方式そのものが分からない場合は、種類の違いを先に押さえると、担当者の説明も読みやすくなります。

SLAの意味と稼働率の読み方

SLA（エスエルエー）はService Level Agreementの略で、「サービスレベル合意」と呼ばれます。
サービスを提供する側と利用する側が、品質や責任の範囲を取り決めたものです。
RTO・RPOが目標となる指標なのに対し、SLAは指標や条件を含む合意そのものです。

たとえば「月間稼働率99.9％」や「重大な障害の問い合わせには1時間以内に最初の返答をする」といった項目があります。
ここでの稼働率は、対象期間のうちサービスを利用できる時間の割合です。
すべてのSLAに、同じ項目が入るわけではありません。

最初の返答が1時間以内でも、復旧が1時間以内とは限りません。
「連絡を受けたことを知らせる」「調査を始める」「使える状態に直す」は、それぞれ別の段階だからです。
数字を読むときは、何を終えるまでの時間なのかも一緒に見てください。

稼働率99.9％と「約43分」の関係

30日間を24時間ずっと測り、停止時間だけで単純計算すると、99.9％に対応する停止時間は約43.2分です。
計算は「30日×24時間×60分×0.1％」となります。

これは期間全体の割合を時間へ置き換えた値です。
「1回の障害が43.2分以内に直る」というRTOの約束にはなりません。
実際のSLAでは、停止と数える条件や対象外の事象なども確認しましょう。

仕組みとしての稼働率や、複数の機器を組み合わせた場合の計算は、次の記事で確認できます。

SLA未達時の対応まで含めた確認

SLAがあるからといって、障害が起きないわけではありません。
また、基準を満たさなかった場合も、利用者の損失がすべて補われるとは限らない点に注意が必要です。

たとえば、Amazon RDSのSLAでは、所定の条件で、利用料金に充てるサービスクレジットを申請する仕組みが定められています。
確認するのは数字だけでなく、適用条件、申請方法、期限までです。

※ Amazon RDSは、AWSのデータベース運用サービスです。
データベースは、注文情報などを整理して保存・検索する仕組みを指します。
リンク先は提供元の公式SLAで、条件の詳細は契約時の最新文書を確認してください。

ここまでの違いを、資料を読むときの問いで整理します。

仕事に合う復旧目標の決め方

「結局、何時間にすればよいの？」と迷ったら、システムの性能表より、止まったときの仕事を先に見ます。
RTO・RPOに、すべての会社で使える正解の数字はありません。
次の順で担当者と整理すると、必要な備えを話し合いやすくなります。

1. 守る仕事を一つ選ぶ。
   受注、出荷、給与計算など、止まると困る仕事を具体的にします。
2. 停止とデータ消失の影響を分ける。
   何時間止まると出荷に間に合わないか、何時間分なら別の記録から補えるかを確認します。
3. 目標とサービスの条件を照合する。
   再開に必要な機能を決め、SLA、バックアップ対象、復旧を担当する範囲を確かめます。
4. 実際に戻して測る。
   決めた時点のデータが使えるか、必要な仕事を目標時間内に再開できるかを試します。

たとえば「4時間で再開したいのに、データの復元だけで5時間かかる」と分かれば、今の方法では足りません。
予備の環境や手順を見直すほか、電話受付などの代わりの方法も考えられます。
すべてをゼロに近づけるより、仕事への影響と費用を一緒に比べることが大切です。

試験では、元のデータを上書きしない別の場所や検証用の環境を使いましょう。
ファイルが戻ったことだけで終わらせず、開けるか、注文を登録できるかまで確認します。
AWSの復旧テストに関する公式技術文書も、データの状態と復旧にかかる時間を確かめる考え方を示しています。

よくある質問

• RTOとRPOの覚え方はありますか？
  RTOのTをTime（時間）、RPOのPをPoint（時点）と結び付けると整理できます。前者は「再開までの時間」、後者は「戻したいデータの時点」です。
• BCPとDRはどう違いますか？
  DRはディザスタリカバリの略で、災害などで使えなくなったITシステムを復旧するための備えです。人員や取引先との連絡、代わりの仕事の進め方も含むBCPの中で、ITの復旧を支えます。
• RPOがゼロならバックアップは不要ですか？
  不要にはなりません。データを別の環境へ即座に複製していても、誤削除や破損まで反映される可能性があります。過去の正常な状態へ戻す備えも別に考えます。
• クラウドを使えば自社の復旧計画はいりませんか？
  必要です。提供側が戻す範囲と、自社が担当するデータ保護や設定の復旧を確かめます。社内の通信が使えない場合や、担当者が不在の場合も想定しておきます。

まとめ

BCPの資料に出てくる英字は、仕事を守るための問いに置き換えると読みやすくなります。
押さえる要点は次の3つです。

• SLAはサービス品質と条件についての合意です。数字の対象と、基準を満たさないときの対応も読みます。
• RTOは停止してから再開までの目標時間です。何ができれば再開とするかも決めます。
• RPOは復旧するデータの時点に関する目標です。実際に戻せるコピーがあるか確認します。

まずは身近な仕事を一つ選び、「何時間止まると困るか」「何時間分のデータなら補えるか」を書き出してみましょう。