ITサービスマネージャ 2025年 春期 午後I 問題

共通の文章

インシデント管理プロセスの分析と改善に関する次の記述を読んで，設問に答えよ。 J社は，全国で電子機器を製造し、販売する電子機器メーカーである。J社の情報 システム部は、販売システム（以下、Kシステムという）の開発と運用を行っている。 J社の全国の支店には販売部の販売担当者がおり，販売サービス（以下、K サービス という）を利用して販売活動を行っている。K サービスは、Kシステムによって実現 されている。 情報システム部には、開発課と運用課がある。開発課は、管理者の開発課長及び数 名の開発担当者で構成され，主に機能追加などの開発業務を開発計画に基づいて実施 している。運用課には，管理者の運用課長及び運用業務の取りまとめを行うし氏がお り、システムの運用を担当する運用チーム及び利用者からの問合せやインシデントの 対応を行うサービスデスクがある。サービスデスクは担当者（以下、オペレーターと いう）の離職率が高く、経験の浅いオペレーターも多い。また，情報システム部は， インシデント管理、問題管理，変更管理などのサービスマネジメント活動ごとに，対 応手順を定めている。サービスマネジメント活動全体はL氏が統括している。 K サービスについて、情報システム部と販売部とは表1に示す SLAを合意している。 表1 K サービスの SLA （抜粋） サービスレベル項目 目標値 インシデント解決時間 重大インシデントは3時間以内 通常インシデントは8時間以内 注記重大インシデントとは販売部の基幹業務に影響を与えるインシデントのことで ある。通常インシデントとは重大インシデント以外のインシデントのことである。 今年になって、Kシステムを更改したこともあり、インシデントの発生が多くなっ ている。先月は，重大インシデントはなかったが、通常インシデントが200件発生し た。インシデントの解決時間は最長で7時間 40分も掛かっており，SLAの目標値達成 が危ぶまれる状況になっている。そこで，通常インシデントの管理について分析する ことにした。 ［インシデント管理の概要〕 オペレーターは，利用者から"Kサービス利用中にある事象が発生し、対処の仕方 が分からない”との問合せを受け，事象について利用者とコミュニケーションを行っ た結果、当該事象をインシデントと認識する場合がある。このようにインシデントの 発生を認識した場合は，自らが解決担当者となってインシデント管理プロセスを開始 する。サービスデスクにおけるインシデント管理プロセスの手順を表2に示す。 表2 サービスデスクにおけるインシデント管理プロセスの手順 手順 活動番号 活動の内容 記録・分類 インシデントの内容をインシデント管理ファイルに記録する。インシ デントには，一意のインシデント番号を付番し、インシデントをあら かじめ決められたカテゴリ （ストレージの障害など）に分類する。 優先度の割当て 121 インシデントに優先度を割り当てる。 既知の誤りの 131 解決担当者は、既知の誤り”を調査して回避策を探す。回避策が見つ 調査 かった場合は、手順“解決”を行う。回避策が見つからなかった場合 は、手順“エスカレーション”を行う。 エスカレーショ 141 アプリケーションブログラム（以下、アプリケーションという）に関 ン 係する内容は開発課に、それ以外は運用チームにエスカレーションを 行う。エスカレーションの手段として、オペレーターはエスカレーシ ョン先に対して電子メールを発信することで対応する。 解決 151 エスカレーションを行わなかった場合は、解決担当者が見つけた回避 策を適用してインシデントを解決する。 152 エスカレーションを行った場合は，開発課又は運用チームから提示さ れる回避策を適用してインシデントを解決する。 終了 161 インシデントが解決したことを利用者に連絡し、サービスが問題なく 利用できることを確認する。 162 インシデント管理ファイルの記録を更新し終了する。 注記 、発生したインシデントが重大インシデントの場合は、別途規定されている重大インシデント 管理プロセスの手順に従う。 注 1既知の誤りとは、“サービスへの影響を低減又は除去する解決方法がある問題”のことで、問 題管理ファイルに記録されている。既知の誤りは，回避策とともに、問題管理の活動として、 開発課又は運用チームによって記録される。 オペレーターは、手順を効率に実施するために、ソフトウェアツールとしてイン シデント管理システムを使用し、インシデント管理ファイルに対応した内容を登録し ている。インシデント管理ファイルには、データ項目として、インシデント番号，活 動番号，担当者のID， 対応日時（開始日時，終了日時），対応内容などがあり、イン シデントの活動ごとにデータ項目の内容が記録される。オペレーターは、インシデン トの発生を認識した場合，活動番号 111で、“担当者のID”に自らの社員番号を登録 する。社員番号が登録されると、インシデント管理システムは“開始日時”を記録す る。オペレーターは活動ごとに対応した内容を入力していく。インシデント管理シス テムはオペレーターの入力と連動して活動の対応日時を記録していく。なお，活動番 号 141でエスカレーションを行った場合、オペレーターは141の終了日時にエスカレ ーションの電子メールの発信日時を登録する。 サービスデスクからエスカレーションされたインシデントについて、開発課又は運 用チームで，再度，回避策が存在するかどうかを詳細に調査する。調査した結果で回 避策が見つかった場合は、インシデント管理の解決担当者に回避策の内容を提示する。 回避策が見つからなかった場合は，インシデントの原因となる問題を調査する必要が あり、問題管理プロセスの手順を実施する。エスカレーション先におけるインシデン ト管理プロセスの手順を表3に示す。 表3 エスカレーション先におけるインシデント管理プロセスの手順 手順 活動番号 活動の内容 インシデント 171 サービスデスクからエスカレーションされたインシデントを調査す の再調査 る。開発課又は運用チームの担当者は，既知の誤りを調査して回避策 を探す。”回避策が見つかった場合は，活動番号 172 を行う。回避策 が見つからなかった場合は，新たな問題として、問題管理プロセスの 手順を実施する。 172 インシデント管理の解決担当者に回避策の内容を知らせる。 注”活動を開始するときに、担当者はインシデント管理システムを使って，エスカレーションさ れたインシデント番号を基にインシデント管理ファイルを検索し、“担当者の ID”に自らの社 員番号を登録する。“担当者の 1D”が登録されるとインシデント管理システムは“開始日時” を記録する。 〔問題管理の概要］ 問題管理には，インシデント発生に伴って実施するリアクティブな問題管理の作業 だけでなく，ベンダーから公開されるパッチ情報がKシステムのアプリケーションに 影響するかどうかに関する調査などのプロアクティブな問題管理の作業がある。開発 課の場合、パッチ情報の適用時期などを踏まえ、プロアクティブな問題管理の作業は 開発計画に織り込んで実施する。問題管理のうち、リアクティブな問題管理は突発的 な作業であり，計画した作業を中断して実施する必要がある。リアクティブな問題管 理に関連する問題管理プロセスの手順（抜粋）を、表4に示す。 表4 リアクティブな問題管理に関連する問題管理プロセスの手順（抜粋） 手順 活動番号 活動の内容 記録・分類 問題ごとに問題番号を付番し、問題の内容を問題管理ファイルに記録 する。エスカレーションされたインシデントとひも付けて問題管理フ アイルに記録する。 調査と診断 P21 開発課又は運用チームの担当者は、自ら回避策を策定する。 P22 策定した回避策を，インシデント管理の解決担当者に知らせ、既知の 誤りとして問題管理ファイルに記録する。 解決 （省略） 終了 （省略） 注記問題管理ではソフトウェアツールとして問題管理システムを使用する。問題管理ファイルに は、データ項目として、問題番号、インシデント番号、活動番号，担当者の ID、対応日時（開 始日時，終了日時），問題の内容，回避策，対応内容などがあり、活動ごとにデータ項目の内 容が記録される。 〔改善活動の実施］ L氏は、表 2，表3及び表4の活動を可視化，分析し、インシデントを解決する活 動の全体像を捉えて課題を発見し、改善することにした。 〔インシデント対応の分析］ まず，先月発生したインシデントの200件を対象として課題となる活動を特定する ことにした。そこで、インシデントの対応時に記録しているインシデント管理ファイ ルと問題管理ファイルの対応履歴を使って、分析対象の（ア）インシデント対応の業 務フロー図を作成した。作成したインシデント対応の業務フロー図を図1に示す。 •（100%） I11 （100%） 121 （100%） 131 回避策が見つかった場合 （70%） 151 （100%） 161 0（100%） 162 回避策が見つか 5分 5分 15分 らなかった場合 100分 15分 15分 141（30%） 10分 152（30%） 100分 171（30%） 80分 回避策が見つかった場合 172 回避策が見つか （10%） らなかった場合 P11 （20%）5分 10分 P22 （20%） 15分 P21 （20%） 140分 例 111：活動番号，（100%）：200件のインシデントに対する割合，5分：活動の平均実施時間 図 1 インシデント対応の業務フロー図 なお，作成に当たっては，あるインシデントで実施した活動番号ごとの実施時間の 合計が当該インシデントの解決時間となるように工夫した。具体には、I11 の実施 時間は111の開始日時と終了日時の時間差とし、それ以降の活動番号の実施時間は， 一つ前に実施した活動番号の終了日時と当該活動番号の終了日時との時間差とした。 L氏は、図1から、対象の200件のうち、解決担当者が問題管理ファイルから回避 策を見つけることができずエスカレーションを行ったものは 件で、全て アプリケーションに関する内容であり、開発課にエスカレーションされていることを 把握した。また，開発課にエスカレーションされたもののうち、開発課で回避策が見 つからなかったインシデントは、［b 件であることを把握した。 次に、L氏は図1からインシデント対応には次の三つのパスがあることを確認した。 ・パス1：表2の活動だけを行う。 ・パス2：表2及び表3の活動を行う。 ・パス3：表2，表3 及び表4の活動を行う。 -氏は、それぞれのバスにおける活動の平均実施時間を考慮し、三つのパスのうち， （イ）優先的に分析すべきパスを一つだけ特定した。 〔改善策の検討〕 L氏は、図1から，エスカレーションされたインシデントの解決に多くの時間が掛 かっていることについて課題があると認識し、開発課及び運用課の業務に着目して調 査を進めることにした。まず、図1の活動番号 P21の調査を行ったところ、P21は新 しい問題を解決する活動であるため、時間が掛かることが分かった。そこで，表3及 び表4の手順の中で、図1の活動番号P21の次に時間が掛かっている活動番号 I71を 調査した。し氏は、171 の活動は、サービスデスクからエスカレーションされて開発 課が実施する活動となるので，（ウ）インシデント管理ファイルを使って，作業待ち が発生していないかどうかを調査し、その後，開発課にヒアリングすることにした。 また、（エ）図1から、既知の誤りを調査して回避策を探す活動についても課題が あると考えて調査を進めた。 サービスデスクの要員は，開発課が使用しているツール（以下、M ツールという） を使って問題管理ファイルの回避策を検索している。M ツールは，開発課が問題管理 ファイルへの回避策の登録・検索をする目で開発したツールで、サービスデスクで も，そのツールを使用している。そこで，L氏は、サービスデスクの要員構成に着目 し，M ツール操作方法の習熟度合いに差がないかどうかについて，経験豊富なベテラ ンオペレーターと経験の浅い新人オペレーターとに分けてヒアリングした。ベテラン オペレーターはMツールの高度な検索機能を使っていたが，新人オペレーターは検索 機能を使いこなせていなかった。ベテランオペレーターは，インシデント解決手順の 中での開発課要員とのコミュニケーションを通じて、Mツールの検索機能の使い方を 習得していた。そこで、L氏は、オペレーターが使用するツールに関して根本的な対 策が必要と考え、 C 」について、開発課に依頼できないか検討を開始した。 さらに、L氏は、図1を確認し、回避策のあるインシデントが多いことに着目した。 そこで、問題管理の活動について、開発課にヒアリングを行うことにした。

共通の文章

高可用性システムの信頼性向上に関する次の記述を読んで、設問に答えよ。 U社は、一般のインターネット利用者に動画配信サービス（以下、Tサービスとい う）を24時間 365日提供している。「サービスは，W社のパブリッククラウドサービ スを使ったTシステムによって実現されている。稼働環境と試験環境が存在し，稼働 境では高い可用性が求められている。「サービスは、現在 T1からT5の五つのマイ クロサービス（以下、T1〜T5 サービスという）で構成されている。 ［Tサービスの開発と運用における課題］ U 社情報システム部は、開発課と運用課で構成され、開発課は開発課長の下でTサ ービスの開発を，運用課は運用課長の下でTサービスの運用を担当している。情報シ ステム部では，スクラムによるアジャイル開発を採用し、開発課と運用課が連携して リリースサイクルを短縮することを目に DevOpsを推進してきた。スクラム開発に よってリリース頻度が高まる一方で，運用課の受入準備が追い付かないといった事象 が度々発生するようになった。また、停止時間は僅かではあるがサービス停止の事象 も何回か発生しており，システムの信頼性が確保された安定した運用が求められてい る。 そこで，情報システム部の✕部長は、SRE （Site ReliabiLity Engineering）の考 え方を取り入れ，開発から運用までのライフサイクルに関わり，稼働する「サービス の信頼性に責任をもつ組織を作る必要があると考えた。✕ 部長は、U社の経営層から 了承を得て、暫定的なSRE チーム（以下、Sチームという）を作り、3か月後に正式 なサービス開始を予定しているTサービスの一つのマイクロサービス（以下、T6 サ ービスという）を対象として，検証を行うことにした。検証期間の間，情報システム 部は、開発課，運用課及びSチームの三つの組織構成とし、Sチームは×部長が直轄 する。 T6 サービスは，今後も反復アプローチに基づいた開発が継続する状況にあり，開 発課は機能追加の開発に専念する必要がある。✕ 部長は、チームの編成に当たって， 開発課長及び運用課長と調整を行い，開発課と運用課から（ア）開発経験と運用経験 をともに有する要員をSチームに参画させることにし、T6 サービスを含むTサービス に関する役割分担を表1に整理した。 表1 Tサービスの役割分担 役割分担 項番 業務内容 T1～T5 サービス T6 サービス 1 アプリケーションプログラムの機能追加開発 開発課 開発課 2 試験環境を使用したサービスの試験 開発課 開発課 稼働環境及び試験環境におけるサービスの運用作業（リソー 3 ス管理やキャパシティ管理など） 運用課 運用課 4 稼働環境及び試験環境におけるサービスの監視及び障害対応 運用課 Sチーム 5 運用改善（サービス運用作業の自動化など） 運用課 Sチーム 6 稼働環境及び試験環境へのアプリケーションブログラムのリ 運用課 Sチーム リースリと展開 7 稼働環境及び試験境のインフラ運用，保守 運用課 Sチーム 8 稼働しているアプリケーションプログラムの不具合の改修 開発課 Sチーム 9 サービス信頼性向上への取組 未実施 •ナーム 注！ リリースには、機能追加に対応して行う定期リリースと不具合修正を行う緊急リリースがある。両リリ ースとも、展開に先立って、利用者に対して展開に伴う停止連絡を行う。 ［S チームの目標設定］ サービスの信頼性には、スループットや可用性などが該当し、サービスの信頼性を 示す指標には、SLI （Service Level Indicator：サービスレベル指標）と SLO （Service Level Objective：サービスレベル目標）がある。SLIは、信頼性の目標 が守られているかどうかを評価するために使うサービスレベルの計測値のことである。 SLO は、SLI で計測されるサービスレベルの目標値のことである。 Sチームは、T6 サービスにおける SLIとSLOについて検討を行った。その結果を表 2に示す。ここで、稼働率は算出式に基づいて毎日算出することにし、対象期間は対 象日を含む過去30日間とする。 表2T6 サービスにおけるSLI と SLO SLI SLO SLIの算出式 対象期間 标働率1） 99.965% サービス稼働予定時間ーサービス停止時間 対象日を含む （%） サービス稼働予定時間2） 過去30日間 注1働率（%）は、小数第4位を四捨五入して小数第3位まで算出する。 注2）サービス稼働予定時間とは、対象期間の対象日を含む過去 30日間のことであり、分の単位 に変換すると43,200分となる。 また、Sチームは、エラーバジェット（以下、EBという）の運用を採用することに した。EB とは、サービスの信頼性が一定程度損なわれても許容できる時間を示す指 標のことであり，定期リリースや緊急リリースの展開に伴って発生する稼働停止の 時間及びエラー対処に要した時間を EBから消費させていく運用を行う。T6 サービス のEBは SLO が未達状態とならないサービス停止時間の最大値とする。具体には、 SLO が表2の場合、対象日を含む過去 30日間の対象期間の中で15分をEBの最大値 とし，その範囲でのサービス停止を許容した上でサービスを運用する。 EBの消費がひっ迫した場合は，開発課と協議を行い，更なる信頼性低下のリスク を抑えるためにリリース作業と機能追加開発作業を凍結し，サービスの安定性を重 視した信頼性回復のための作業を優先して行うことにする。EBの消費ひっ迫をEBが 3分以下（EBを12分消費）となった場合と定め、信頼性回復作業はSチームと開発 課が主体的に取り組む。Sチームで検討したEBの運用ルール案を表3に示す。 表3 EB の運用ルール案 項番 ルール内容 1 EBは、対象日を含む過去30日間で最大15分とする。 2 EBが3分以下となった場合，S チームと開発課で協議を行って、翌日から働環 境へのリリース作業を凍結し、信頼性回復のための改善活動を開始する。 3 リリース作業の凍結解除については、Sチームと開発課で協議を行い判断する。 Sチームは、✕部長に運用ルール案を報告したところ、項番2について（イ）リリ ース作業の凍結については，例外規定を設けることを検討するように指示を受けた。 Sチームは，検討した結果を✕部長に提案し、✕ 部長は提案内容を含めて運用ルー ル案を承認し、試行運用を開始するようにSチームに指示した。 〔試行運用の開始］ Sチームは，4月1日からEBの試行運用を開始した。T6 サービスは、2月1日から サービス開始に向けた準備を進めて働環境で稼働しており、3月はリリース作業な どによるサービス停止の停止時間は発生していない。したがって、4月1日開始時点 でのSLIの働率は、対象日を含む過去30日間のサービス稼働予定時間である 43,200分から算出された100%となり、EBは15分である。試行運用開始後の結果を 表4に示す。ここで、EBは，次の計算式に基づいて計算される。 当日のEB＝前日のEB-当日のEBの消費＋当日のEBの回復 当日のEBの消費とは“当日発生したサービス停止時間のこと”であり、当日の EB の回復とは“過去に発生したサービス停止事象が対象日（当日）を含む過去 30日間 から外れたので，EBに追加する当該事象のサービス停止時間のこと”である。例え ば、4月2日のEBの計算では，前日のEBが15分，当日のEBの消費が1分，当日の EB の回復が0分であり、計算結果は14分となる。 表4 試行運用開始後の結果 榢働率 停止時間 日付 （%） EB（分） （分） サービス停止の発生した事象 4月1日 100% 15分 0分 無し 4月2日 99.998% 14分 1分 機能追加に伴う定期リリース作業として、T6 サー ビスの停止及び起動を行った。 4月3日 99.998% 14分 0分 無し 4月2日にリリースしたT6 サービスに一部不具合 4月4日 99.995% 13分 1分 があり、改修が発生した。緊急リリース作業とし て、T6 サービスの停止及び起動を行った。 （省略） 4月9日 99.993% 12分 1分 機能追加に伴う定期リリース作業として、T6 サー ビスの停止及び起動を行った。 4月10日 99.993% 12分 0分 浦し 4月9日のリリース後、T6 サービスのエラーが増 4月11日 99.991% 11分 1分 加傾向にあったので、応急措置としてT6 サービス の停止及び起動を行った。 （省略） 4月9日にリリースしたT6 サービスに一部不具合 4月16日 99.988% 10分 1分 があり、改修が発生した。緊急リリース作業とし て、T6 サービスの停止及び起動を行った。 4月17日 99.977% 5分 5分 W 社のパブリッククラウドサービスで障害が発生 し，復旧作業完了までサービスが停止した。 4月18日 99.977% 5分 0分 無し （省略） 1分 機能追加に伴う定期リリース作業として、T6 サー ビスの停止及び起動を行った。 4月25日 99.970% 2分 定期リリース作業後に、改修の一部が正しく行わ 2分 れていないことが判明し、リリース戻し作業、T6 サービスの停止及び起動を行った。 （省略） 5月1日 99.970% 2分 0分 一無し 5月2日 99.972% 1分 0分 無し 注記1 稼働率、EB及び停止時間の値は，該当日付終了時点に算出された値である。 注記2 省略に該当する日付の稼働率とEBの値は、省略直前の日付の値と同じであり、サービス停止に該 当する事象は発生していないものとする。 注記3 定期リリースと緊急リリースは区別せず，サービス停止した場合は，EBを消費する。 また、S チームは、（ウ）4月26日に信頼性回復のための改善活動を開始した。改 善活動を開始するに当たって、S チームは、開発課と、EBの推移を示して議論を行い， T6 サービスの信頼性についての認識を合わせた。改善活動の候補を議論したところ、 〈働環境へのリリース方法について、（エ）T6 サービスを停止することなくリリース 作業が可能となる方式が実現できないかどうかの検討に取り組むことにした。 〔試行運用の振り返り〕 X 部長は、試行運用の振り返りと今後の本格運用に向けた改善点などについて，S チームにヒアリングを行ったところ、次の意見が出された。 ・開発課と の実施判断について，EBを使って効果的な議論を行い， T6 サービスの信頼性低下のリスクを抑えることができた。 ・4月11日は、“数名の利用者が，問合せリクエストへの応答がないので再度リク エストスカしたという報告”を受けた対策をしている。調査したところ、プログ ラムでエラーが発生していて、リクエストが失敗となっていた。「働時間を基に 算出する稼働率の SLI だけでは、十分でないように感じる。そこで、サービス利 用者からの客観的な評価を反映したサービスの信頼性指標として“T6 サービス が受け付けた総リクエスト数に対する の割合”を SLIに追加した方 がよい。 ✕部長は，今後の本格運用に向けて、改善計画を策定することにした。

共通の文章

ITサービス継続管理に関する次の記述を読んで、設問に答えよ。 0社は自動車保険を販売する損害保険会社である。0社の自動車保険部は、全国に 10か所ある損害サービス拠点を統括している。損害サービス拠点では、事故対応サ ービスを利用して，被保険者などから事故発生の連絡を受け付け，損害金見積りなど の事故対応を行っている。事故対応サービスは、Q 社情報システム部で運用される損 害調査システムによって実現されている。情報システム部では，“事故受付リクエス ト全件の95%に対して応答時間を 5秒以内とする”ことを、事故対応サービスのサ ービスレベル目標としている。自動車保険部及び情報システム部は、首都圏にある本 社で業務を行っている。情報システム部が運用している主要システムの概要を表1に 示す。 表1主要システムの概要 項番 システム 提供機能 利用拠点 1 損害調査システム 事故受付，損害金見積り，事故進捗管理， 損害サービス拠点， 保険金支払いを処理する機能 本社 2 契約管理システム 保険契約の見積り、締結，契約の更新，保 本社 険料請求など契約を管理する機能 3 文書管理システム 業務に必要な文書ファイルの登録や参照な 損害サービス拠点， ど文書を管理する機能 本社 各システムの IT インフラ（サーバ、ストレージなど）は、オンプレミスで本社に ある自社データセンター（以下、DC という）に配置している。情報システム部は， システム障害対策として、毎日0時時点で損害調査システム及び契約管理システムの ストレージのデータを 24時間間隔でフルバックアップしている。また、情報システ ム部では災害に備えたバックアップの方針として、フルバックアップを遠隔地にも保 管することとしている。そこで，フルバックアップは DC 内のバックアップ専用の別 ストレージに保存し、災害に備えてクラウド事業者S社のサービス（以下、Sクラウ ドという）のストレージサービスにも転送して保存している。なお、S クラウドは， Q 社本社の遠隔地となる関西のS社データセンターで働しており，サービス対象デ ータのバックアップを常に取り，S社データセンターに保存している。 ［現在のIT サービス継続計画］ 0社では、地震などの自然災害が発生した場合，被保険者に対して損害サービス拠 点で事故対応サービスを継続する方針で，事業継続計画（以下、BCP という）を定め ている。情報システム部は，BCP で想定している規模の災害が発生して DC が被災し た場合の復旧措置を、IT サービス継続計画に定めている。 ITサービス継続計画では，損害調査システムを，被災後 48時間以内に復旧させる 計画である。復旧作業を行う場合に必要な復旧手順書の最新版は、DC の文書管理シ ステムに文書ファイル（以下、Fファイルという）として保存していて、情報システ 4部の要員は、Fファイルに基づいて復旧作業を行う。損害調査システムのストレー ジの復旧作業が必要な場合は、バックアップしてあるストレージのデータをリストア して、更新ログを使って被災時点のファイルの内容に復旧させる手順となる。ここで， 被災によって更新ログが使用不能な場合は、バックアップ時点から被災発生時点まで の更新内容は，自動車保険部による再入力が必要となる。また、DC に保存してある バックアップが被災して使用できない場合は，（ア）S クラウドに保存してあるバッ クアップを使って復旧する。なお，障害復旧後のシステムの正常働については，情 報システム部のシステム担当が自動車保険部へ業務面の確認をして判断している。 ［IT サービス継続計画の見直し〕 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のように整理した。 表2 緊急時対応のフェーズと対応内容 項番 フェーズ 対応内容 ・障害の認知から障害発生の社内通報 1 発動準備 ・情報システム部BCP対策本部設置，被災状況の把握 ・緊急事態発動（暫定復旧の開始） 2 暫定復旧 ・データ回復及び待機系システム起動 ・待機系システム接続及び業務復旧催認 ・待機系システムの運用及び業務の再開 3 代替運用 ・全面復旧の実施判断 4 全面復旧 （省略） 次に、R氏は、ITインフラ担当と実際にSクラウドに待機系システムを準備し、暫 定復旧フェーズ及び代替運用フェーズを想定し待機系システムでの障害からの復旧を テストした。テストの結果は次のとおりであった。 ・データ回復から業務復旧確認までは6時間であり，RTO を達成見込である。ただ し，データ回復作業の一部で、SクラウドのS社担当者と連携して作業を進める 必要がある。 ・復旧後の待機系システムで被災前時点のデータ欠落はなく、RPO を達成できる見 込である。 ・待機系システムは，損害サービス拠点及び本社の PCから問題なく業務利用でき ることを確認できた。 ・S クラウドのサーバサービスの制約から，待機系システムでは、事故受付リクエ スト全件の95%が応答時間10秒以内に収まる結果となった。 R氏は，応答時間についてのテスト結果を踏まえ，S クラウドのサーバサービスの 能力を向上させる検討を、情報システム部長に相談した。R氏は、情報システム部長 から、“能力向上の検討の前に、（エ）代替運用フェーズの目標復旧レベル（以下、 RLO という）について、自動車保険部と協議すること”を指示された。 ［緊急事態発動時の体制整備］ R氏は，検討してきた事項を取り込み，IT サービス継続計画見直し版としてまとめ た。情報システム部及び自動車保険部は、R氏がまとめたIT サービス継続計画見直 し版を、合同でレビューした。レビューの結果，現在の緊急事態発動時の連絡体制を 改定することになった。現在、BCP では自動車保険部にBCP 対策本部及び自動車保険 部事務局を設置し，自動車保険部事務局で業務復旧のコントロールをすることにして いる。また、情報システム部にBCP対策本部及び情報システム部事務局を設置し、自 動車保険部事務局と連携して IT サービスの復旧コントロールをする。ここで，情報 システム部のシステム担当には，自動車保険部の事故対応サービス担当に を依頼する役割をもたせ，情報システム部 BCP 対策本部の対策本部長及 び情報システム部事務局が事故対応サービスにおける復旧状況を判断できるようにし ている。現在の緊急事態発動時の連絡体制を図1に示す。 一 16 一 自動車保険部 BCP対策本部 情報システム部 BCP対策本部 緊急時対応 損害サービス拠点 対策本部長及び の連絡 対策本部長及び 及び本社 業務面の 自動車保険部事務局 システムの 情報システム部事務局 対応 連絡 障害状況 復旧状況 システムの ITインフラの 障害状況 作業指示 障害状況 復旧状況 復旧状況 業務影響確認 業務復旧の確認 事故对応 a 」を依頼 システム 「インフラ サービス担当 担当 担当 図1 現在の緊急事態発動時の連絡体制 情報システム部では，今まで IT サービス継続計画に基づいた緊急事態対応訓練を 年 1回実施することで、IT サービス継続計画の評価を行い、緊急時の連絡を含む確 認を行ってきた。R氏は、IT サービス継続計画の見直しに伴い、（オ）現在の緊急事 態対応訓練の計画に、S社に要請して体制面の内容を追加し、訓練を実施することを 計画した。