IT サービス継続管理

　Q 社は自動車保険を販売する損害保険会社である。Q 社の自動車保険部は，全国に 10 か所ある損害サービス拠点を統括している。損害サービス拠点では，事故対応サービスを利用して，被保険者などから事故発生の連絡を受け付け，損害見積りなどの事故対応を行っている。事故対応サービスは，Q 社情報システム部で運用される損害調査システムによって実現されている。情報システム部では，“事故受付リクエスト全件の 95％に対して応答時間を 5 秒以内とする”ことを，事故対応サービスのサービスレベル目標としている。自動車保険部及び情報システム部は，首都圏にある本社で業務を行っている。情報システム部が運用している主要システムの概要を表 1 に示す。

　各システムの IT インフラ（サーバ，ストレージなど）は，オンプレミスで本社にある自社データセンター（以下，DC という）に配置している。情報システム部は，システム障害対策として，毎日 0 時時点で損害調査システム及び契約管理システムのストレージのデータを 24 時間間隔でフルバックアップしている。また，情報システム部では災害に備えたバックアップの方針として，フルバックアップを遠隔地にも保管することとしている。そこで，フルバックアップは DC 内のバックアップ専用の別ストレージに保存し，災害に備えてクラウド事業者 S 社のサービス（以下，S クラウドという）のストレージサービスにも転送して保存している。なお，S クラウドは，Q 社本社の遠隔地となる関西の S 社データセンターで稼働しており，サービス対象データのバックアップを常に取り，S 社データセンターに保存している。

　Q 社では，地震などの自然災害が発生した場合，被保険者に対して損害サービス拠点で事故対応サービスを継続する方針で，事業継続計画（以下，BCP という）を定めている。情報システム部は，BCP で想定している規模の災害が発生して DC が被災した場合の復旧措置を，IT サービス継続計画に定めている。
　IT サービス継続計画では，損害調査システムを，被災後 48 時間以内に復旧させる計画である。復旧作業を行う場合に必要な復旧手順書の最新版は，DC の文書管理システムに文書ファイル（以下，F ファイルという）として保存していて，情報システム部の要員は，F ファイルに基づいて復旧作業を行う。損害調査システムのストレージの復旧作業が必要な場合は，バックアップしてあるストレージのデータをリストアして，更新ログを使って被災時点のファイルの内容に復旧させる手順となる。ここで，被災によって更新ログが使用不能な場合は，バックアップ時点から被災発生時点までの更新内容は，自動車保険部による再入力が必要となる。また，DC に保存してあるバックアップが被災して使用できない場合は，（ア）S クラウドに保存してあるバックアップを使って復旧する。なお，障害復旧後のシステムの正常稼働については，情報システム部のシステム担当が自動車保険部へ業務面の確認をして判断している。 　2024 年 4 月に Q 社は，競合他社との差別化を図るため，BCP を変更し，災害時は事故受付業務を 12 時間以内に優先して再開することを決めた。情報システムに関連しては，次のように変更する。

• 災害発生後に事故受付業務を再開できるよう損害調査システムを“暫定復旧”する。“目標復旧時間（以下，RTO という）は，障害発生から 10 時間以内”とする。
• 事故受付業務の再開時は，災害発生直前に事故受付した被保険者の対応を，損害調査システムの事故進捗管理機能を利用して継続できるように，目標復旧時点（以下，RPO という）を被災時点に変更する。

　情報システム部は，BCP の変更に伴い，IT サービス継続計画の見直しを開始した。情報システム部長は IT サービスマネージャの R 氏に，事故受付で利用する損害調査システムの IT サービス継続計画の見直しを指示した。
　R 氏は，これまでのオンプレミスでの復旧では RTO 及び RPO の目標達成は困難であると考え，損害調査システムの現用系システムとは別に，S クラウドが提供しているサーバサービスを利用して待機系システムを稼働し，暫定復旧させる復旧方針案を検討した。具体的には，S クラウドのサーバサービスを用いて損害調査システムの待機系システムを準備し，更新ログのデータは現用系システムの更新ログと常に同期をとっておく。損害調査システム復旧の手順は次のとおりである。

• DC 被災時は，S クラウドにバックアップしてあるフルバックアップと更新ログのデータとを用いて待機系システムのファイルの内容を被災時点に更新する。
• 被災時点のファイルが準備できたら，待機系システムを起動する。
• 損害サービス拠点及び本社の PC の接続先を待機系システムに変更する。

　R 氏の考えた方針案は，情報システム部でレビューされた。復旧方針案は，次の 2 点の指摘に対応することを条件として承認され，具体的な IT サービス継続計画の検討に進むこととなった。

• 情報システム部のバックアップ方針に関連して確認すべきことがある。待機系システムを使って損害調査システムを稼働させた場合，待機系システム稼働中にシステム障害が発生したときに備えて，S 社の責任範囲として（イ）S クラウドで実施しているバックアップ運用について S 社に確認を行って，必要な対策を検討すること。
• IT サービス継続計画に基づいてテストを行うこと。（ウ）正式な RTO は，テスト結果を評価して自動車保険部と合意すること。

　R 氏は，災害発生から全面復旧までの緊急時対応について，フェーズごとに対応内容を確認し，表 2 のように整理した。

　次に，R 氏は，IT インフラ担当と実際に S クラウドに待機系システムを準備し，暫定復旧フェーズ及び代替運用フェーズを想定し待機系システムでの障害からの復旧をテストした。テストの結果は次のとおりであった。

• データ回復から業務復旧確認までは 6 時間であり，RTO を達成見込である。ただし，データ回復作業の一部で，S クラウドの S 社担当者と連携して作業を進める必要がある。
• 復旧後の待機系システムで被災前時点のデータ欠落はなく，RPO を達成できる見込である。
• 待機系システムは，損害サービス拠点及び本社の PC から問題なく業務利用できることを確認できた。
• S クラウドのサーバサービスの制約から，待機系システムでは，事故受付リクエスト全件の 95％が応答時間 10 秒以内に収まる結果となった。

　R 氏は，応答時間についてのテスト結果を踏まえ，S クラウドのサーバサービスの能力を向上させる検討を，情報システム部長に相談した。R 氏は，情報システム部長から，“能力向上の検討の前に，（エ）代替運用フェーズの目標復旧レベル（以下，RLO という）について，自動車保険部と協議すること”を指示された。 　R 氏は，検討してきた事項を取り込み，IT サービス継続計画見直し版としてまとめた。情報システム部及び自動車保険部は，R 氏がまとめた IT サービス継続計画見直し版を，合同でレビューした。レビューの結果，現在の緊急事態発動時の連絡体制を改定することになった。現在，BCP では自動車保険部に BCP 対策本部及び自動車保険部事務局を設置し，自動車保険部事務局で業務復旧のコントロールをすることにしている。また，情報システム部に BCP 対策本部及び情報システム部事務局を設置し，自動車保険部事務局と連携して IT サービスの復旧コントロールをする。ここで，情報システム部のシステム担当には，自動車保険部の事故対応サービス担当にaを依頼する役割をもたせ，情報システム部事務局が事故対応サービスにおける復旧状況を判断できるようにしている。現在の緊急事態発動時の連絡体制を図 1 に示す。

　情報システム部では，今まで IT サービス継続計画に基づいた緊急事態対応訓練を年 1 回実施することで，IT サービス継続計画の評価を行い，緊急時の連絡を含む確認を行ってきた。R 氏は，IT サービス継続計画の見直しに伴い，（オ）現在の緊急事態対応訓練の計画に，S 社に要請して体制面の内容を追加し，訓練を実施することを計画した。