ITサービス継続性管理では一般的には「災害対策設計」などと呼ばれる部分に相当し、災害発生時に事業の継続に影響する事態に対してITサービスの復旧能力を保証する為のプロセスである。例えばサービス提供源となっているサーバが設置されているデータセンタが被災した場合、サービスの提供が不可能となるが、あらかじめ確保しておいた別地域の災害対策センタへデータをリストアする事により最小限の時間でサービス復旧を可能にするという事が求められる。それら災害に対するリスクの分析をあらかじめ実施しておき、実際に発生した場合の対策をコントロールする。ITサービス継続性管理では、事業の継続上要求される最小限のサービスレベルを明確化し、災害発生時に最小時間でITサービスを復旧させる事を目的として以下の目標を掲げている。

• 災害時の事業への影響を確認する
• 効果的なリスク分析とリスク管理を実施する
• 企業の事業継続性計画に統合した管理を実施する

具体的には、ITに関するサービス継続計画を作成し、その中で、予防対策・復旧方法・復旧計画などを定める。

可用性管理では提供されるサービスに対し、ITサービスが必要な時に提供できる能力について管理する。利用者が利用したい時にサービスを利用できるようITサービスを構成する個々の機能についてそれぞれ維持管理を行う。キャパシティ管理がサービスレベルに対するITサービスの「量」をコントロールするのに対し、可用性管理ではITサービスの「質」をコントロールする。可用性管理ではITサービスの可用性/非可用性を予測、計画して管理することを目的として以下の目標を掲げている。

• 将来的なサービス損失の予防
• 外部ベンダに対する契約調整
• サービスを構成するアイテムについての適切な保守活動

可用性は、稼働率で表すこともできる。稼働率は、
MTBF ÷ (MTBF ＋ MTTR)
で求めることができ、MTBFで示される信頼性と、MTTRで示される保守性の2つを高めれば可用性も高くなる。

【 サービス性 】
運用業務を外部または組織内のシステム部門などに委託している場合に、可用性、信頼性、保守性が契約内容または合意内容を満たしていること。

障害時運用設計とは、システムが正常に稼働しなくなったときの対応を前もって検討しておくこと。

【 待機系への切り替え 】
システムをデュプレックスシステムで運用している場合で、障害が発生した場合に速やかに待機系へ業務を引き継ぐための方法を検討しておく。
システムを素早く切り替えることでRTOを短くすることができる。

• コールドスタンバイ
  システムが正常なときには、待機系のシステムは、補助的な処理を行ってシステム資源を有効に利用しておく。
  主系に障害が発生すると、主系から待機系にシステムを切り替える。待機系は別の処理を行っているので、その処理を止め、主系の処理ができる環境に入れ替え、主系から待機系に切り替えないといけないので切り替えるための時間がホットスタンバイよりかかる。
• ホットスタンバイ
  待機系は、主系と同じ環境になっていて、主系に障害が発生したときでも、すぐに待機系に切り替えることができる。

【 RTO ( Recovery Time Objective ：目標復旧時間） 】
障害発生からシステムを回復するまでの時間の目標値のこと。
システムダウンの損失が大きい場合は、より短い時間での復旧が要求されるがそのためのコストも大きくなる。

【 RPO ( Recovery Point Objective ：リカバリポイント目標） 】
障害発生時に、どの時点までの復旧ポイントに戻るかの目標値のこと。 システムの復旧ポイントは、データのバックアップのデータがどの時点まで存在するかで決定される。
よって、RPOはバックアップのタイミングを決める。障害発生の時点まで戻すためには、バックアップを短い間隔で取る必要がある。

【 RLO ( Recovery Level Objective ：目標復旧レベル） 】
障害から復旧させる場合に、どの程度のサービスレベルまで復旧させるかの基準

【 バックアップ 】
システムの障害時に復旧させるためには、プログラムなどのソフトウェアと障害発生時点までのデータが必要になる。システムのプログラムなどは、導入時の環境が残っていれば元に戻すことができるが、データは、常日頃から定期的にデータのバックアップを行っていないと復旧させることができない。
バックアップの留意点

• バックアップは定期的に行う必要がある。月次、週次、日次など
• バックアップデータは持ち運びのできる媒体に保存し、厳重に保管する。
• 媒体エラーなどに備えて、複数の媒体にコピーしておく