- [No1][A.1.3]可用性＞継続性＞目標復旧水準（業務停止時）
- ①RPO(Recovery Point Objective)：目標復旧地点
- ②RTO(Recovery Time Objective)：目標復旧時間
- ③RLO(Recovery Level Objective)：目標復旧レベル
- 目標復旧水準（業務停止時）に関するまとめ
- 結論：非機能要件として、目標復旧水準（業務停止時）について合意しよう
[No1][A.1.3]可用性＞継続性＞目標復旧水準（業務停止時）
今回は目標復旧水準（業務停止時）だ。簡単に言うと、システムが故障した後に、いつまでに、どのくらいのレベルで、システムを復旧させるかのことを指している。
システムは必ず故障する。故障するからこそ、どうやって復旧するのかをあらかじめ決めておかねばならないのだ。
目標復旧水準（業務停止時）で決めるべき項目は3点存在する。
- RPO(Recovery Point Objective)：目標復旧地点
- RTO(Recovery Time Objective)：目標復旧時間
- RLO(Recovery Level Objective)：目標復旧レベル
以下、簡単に説明する。
①RPO(Recovery Point Objective)：目標復旧地点
システムにおいて、障害はつきものだ。なぜならば、システムというものは、ソフトウェアがハードウェア上で動いているものだからだ。ソフトウェアとハードウェアの違いについては、下記記事を参照されたい。
ソフトウェアは劣化しないが、ハードウェアは劣化する。車が壊れるのと同様、システムで使っているハードウェアも壊れるのだ。また、停電などが起こったとしても、システムは稼働することができない。そのため、いざ障害が発生したときのために備えて、定期的にデータのバックアップがとられている。そして、障害が発生したときに、バックアップしていたデータを使ってシステムを復旧するのだ。
目標復旧地点とは、上記のようなバックアップの仕組みを使って、いざ障害が発生したときに、いつの時点のバックアップから復旧できるようにするのかという指標だ。バックアップを頻繁にとっておけば、目標復旧地点は近くなる。毎日バックアップを取っておけば、いざ障害が発生したとしても、昨日時点の状態までシステムを復旧できる。毎週しかバックアップを取っていなければ、いざ障害が発生したとしても、先週時点の状態までしかシステムを復旧できない。
もちろん、頻繁にバックアップを取っておいたほうが望ましいのだが、排反として、バックアップをとるためにシステムのディスク容量を確保しておかねばならないという点がある。業務との兼ね合いで、どのくらいの頻度でバックアップを取るべきかを決めることが大事だ。
②RTO(Recovery Time Objective)：目標復旧時間
後述の目標復旧レベルまでシステム(業務まで含める場合もある)を復旧できるまでの目標とする時間が、目標復旧時間だ。復旧に要する時間が指標となっているので、この時間は短ければ短いほどよいのだが、あまりに時間を短くすると、それ相応のシステムや体制を構築することとなる。復旧の早さをあげようとすると、システムのコストは高くなる。業務停止時間がどのくらいまでならば許されるか？を想像して、目標復旧時間を決めよう。
③RLO(Recovery Level Objective)：目標復旧レベル
目標復旧レベルで決めておくべきことは、何をもって復旧完了とみなすか？ということだ。システムの復旧まででよいのか？システムを使っている業務の復旧までも目指すのか？あらかじめ決めておくことが大事だ。業務を行う上で、どうしてもシステムが必要となる場合は、業務の復旧までを目標としたほうがよい。
目標復旧水準（業務停止時）に関するまとめ
今回は目標復旧水準（業務停止時）について紹介した。簡単に整理した資料を上図に示しておく。システムは必ず故障するものなので、何を復旧対象として、いつまでに復旧させなければならないか？どのぐらいの頻度でバックアップを取るべきか？について、顧客側、ベンダ側で、すりあわせておこう。下記3点、必ず双方で話し合っておこう。
- いつの時点の状態に復旧させるか？
- いつまでに復旧させなければならないか？
- 何を復旧対象とするか？システムか？業務か？
