RTO は Recovery Time Objective の略で、障害発生から復旧までに許される時間の目標です。
「何時間止まってよいか」を数字で決めたものだと考えてください。
RPO とセットで決める
この2つは別のことを測っています。
| 何を決めるか | 短くするために必要なもの | |
|---|---|---|
| RTO | どれだけ早く戻すか | 復旧手順の整備、待機環境、自動化 |
| RPO | どこまでのデータを守るか | バックアップの頻度、レプリケーション |
たとえば「1日1回バックアップ、復旧作業は半日」なら RPO は最大24時間、RTO は12時間です。片方だけ短くしても意味がないので、必ず両方を並べて決めます。
目標ではなく実測で語る
いちばん多い失敗は、復旧したことがないのに RTO を宣言することです。「バックアップがあるから4時間で戻せます」と書いてあっても、実際にやると次の時間が乗ります。
- 障害と判断して復旧を決断するまでの時間
- 担当者を集める時間（夜間・休日なら特に）
- データを転送・展開する時間（数百GBなら転送だけで数時間）
- DNSやロードバランサの切り替えと反映待ち
- 正常性を確認して「復旧した」と宣言するまでの時間
復旧訓練をして実測する以外に、正しい RTO を知る方法はありません。 やってみると当初の想定の2〜3倍かかるのが普通です。
短くしたいなら、お金か手間がかかる
RTO を短くする方法は限られています。待機系を常時動かす（費用がかかる）、手順を自動化する（作る手間がかかる）、判断基準を事前に決めておく（合意形成が要る）。
逆に言えば、費用をかけずに RTO だけ短く宣言することはできません。事業側と数字を握るときは、必ず対価をセットで示してください。