ITサービスマネージャ 2018年 午後1 問01

解答の導き方

1. この設問は、財務会計システムを被災後に継続するうえで、データの保管方法にどのような問題があるかを問うています。まず、復旧に必要なデータがどこに保管されているかを確認します。
2. 表2には、バッチ処理の最終工程でフルバックアップを磁気テープに記録し、その磁気テープを「システムが稼働している当該サーバ室に保管している」とあります。つまり、財務会計システムのバックアップは、本社のサーバ室にあります。
3. 一方、オンライン処理で取得するDB更新ログは、財務会計システムのストレージに記録されています。問題文の回復手順では、前日のフルバックアップからデータを復元した後、DB更新ログを使って会計DBを障害発生直前まで回復します。
4. ところが、想定している災害では本社が約1週間使用できず、サーバ室も被災します。フルバックアップの磁気テープとDB更新ログが本社サーバ室に集中しているため、被災によってバックアップも復旧に必要なデータも失われるおそれがあります。関西地区のサーバで財務会計システムを運用できるようにしても、復旧に使うデータを取り出せなければ、会計DBを回復できません。
5. したがって問題の核心は、バックアップや更新データを本番システムと同じ被災場所に保管していることです。サービス継続の観点では、被災時に復旧データまで同時に失う構成が問題になります。

誤りやすいポイント

• 「本社サーバ室が約1週間使用できない」というサービス停止だけに注目し、復旧に必要なデータの保管場所を見落とすことがあります。
• フルバックアップだけでなく、フルバックアップから障害発生直前までの状態に回復するためのDB更新ログも確認する必要があります。
• 支社のサーバで財務会計システムを動かせることと、会計DBを復旧できることは別です。移行先のサーバがあっても、復旧用データが被災場所にしかなければ復旧できません。
• バックアップを取得しているという事実だけでは、災害対策として十分とはいえません。本番データとバックアップの保管場所が同じ災害の影響を受けないかが重要です。

FAQ

解答の導き方

誤りやすいポイント

• 関西地区で財務会計システムを動かすサーバが使えることと、復元に必要なデータが使えることを混同しないようにします。サーバだけ用意しても、バックアップが本社にあれば復元できません。
• バックアップの磁気テープは、システムが稼働しているサーバ室に保管されています。したがって、本社が被災すると、サーバだけでなくバックアップも利用できなくなるおそれがあります。
• DB更新ログの運用上の問題と、バックアップ磁気テープの保管場所の問題は別です。この設問では、災害時にフルバックアップデータを利用できるようにする対策を考えます。

FAQ

解答の導き方

1. まず、生産管理システムのオンライン処理時間帯は、問題で指定された13:00～16:00です。表2ではオンライン起動処理とオンライン停止処理がそれぞれ30分なので、生産管理システムは12:30に起動処理を開始し、16:30に停止処理を終えます。
2. 財務会計システムは、生産管理システムの停止後に運用します。したがって、財務会計システムのオンライン起動処理は16:30から始まり、30分後の17:00からオンライン処理を開始できます。
3. 次に、財務会計システムのオンライン処理を何時まで続けられるかを考えます。本文では「生産管理システムのバッチ処理に続いて財務会計システムのバッチ処理を行う」とあります。次の日も生産管理システムのオンライン処理を13:00に始めるには、その起動処理が始まる12:30までに、両システムのバッチ処理を終えておく必要があります。
4. 表2から、生産管理システムのバッチ処理は6時間30分、財務会計システムのバッチ処理は5時間30分です。合計は12時間です。なお、表2の注記により、これらの時間にはバッチ処理の起動及び停止の時間も含まれます。
5. 財務会計システムのバッチ処理より前には、財務会計システムのオンライン停止処理が必要です。これも表2から30分です。したがって、次の日の12:30から12時間分のバッチ処理と30分の停止処理を逆算すると、財務会計システムのオンライン処理は、その日の24:00までに終える必要があります。よって、17:00に開始し、翌日0:00に終了する時間帯が、オンライン処理を最も長くできる設定です。

誤りやすいポイント

• 財務会計システムを生産管理システムより先に運用すると考えないようにします。本文では、生産管理システムのオンライン停止後に財務会計システムを運用する順序です。
• 財務会計システムのオンライン処理終了後、すぐにバッチ処理を始めるわけではありません。オンライン停止処理の30分も必要です。
• バッチ処理の起動・停止時間を、表2のバッチ処理時間に加えて二重に見積もらないようにします。注記で、バッチ処理時間に含まれると示されています。
• 次の日の財務会計システムの起動時刻ではなく、生産管理システムの起動処理開始時刻である12:30を、バッチ処理の終了期限として考えます。

FAQ

解答の導き方

1. まず、財務会計業務では「会計伝票を入力し、会計DBを更新している」とあります。したがって、オンライン処理で入力した会計伝票は、会計DBに反映されるデータです。
2. 現在のRPOは「前日の終業時点」です。この時点までしかデータを戻せない場合、当日のオンライン処理で入力した会計伝票は、復旧後の会計DBに反映されません。そのため、利用者が改めて入力する必要があります。
3. 要望どおりRPOを「障害発生時点」とし、障害発生直前までのDB更新ログを使って会計DBを回復できれば、当日のオンライン処理で入力した会計伝票も復旧後のデータに反映されます。よって、財務会計サービスの利用者は、障害発生時点までに入力した会計伝票を再入力せずに済みます。

誤りやすいポイント

• RPOは、復旧にどの時点のデータまで反映させるかを示す目標です。サービスを何日後に再開するかを示すRTOと混同しないようにします。
• 利点を「会計DBを復旧できる」とだけ述べると、利用者にとって何が改善するのかが不明確です。再入力が不要になる点まで結び付けます。
• 障害発生後の入力まで復旧できるわけではありません。対象となるのは、障害発生時点までに入力された会計伝票です。

FAQ

解答の導き方

1. この設問で問われているのは、財務会計システムのオンライン処理で、DB更新ログの扱いをどう変更するかです。まず、会計DBをどの時点まで回復させる必要があるのかを確認します。
2. 本文では、前日のフルバックアップデータで会計DBを当日のオンライン起動処理直前まで戻し、「障害発生直前までのDB更新ログ」を使って回復するとしています。したがって、障害発生時点まで回復するには、障害直前までに記録されたログが必要です。
3. 一方、通常のオンライン処理では、DB更新ログは財務会計システムのストレージに記録されています。大規模地震では本社のサーバ室を使えないため、そこにしかログがないと、回復に必要なログを利用できなくなるおそれがあります。
4. 業務再開フェーズでは、財務会計システムを関西地区の支社にある生産管理サーバで運用します。そのサーバのストレージには必要な容量を確保できるとあります。そこで、障害前のログも支社側で利用できるよう、オンライン処理中からDB更新ログを支社の生産管理サーバのストレージにも取得する構成にします。元の保存先をやめるのではなく、「にも」取得する点がポイントです。

誤りやすいポイント

• 障害発生後にログを支社へ移せばよいと考えることです。障害後は本社のサーバ室を利用できないため、障害前に記録されたログを取り出せない可能性があります。
• フルバックアップデータだけで障害発生時点まで回復できると考えることです。前日のバックアップから当日分の更新を反映するには、DB更新ログが必要です。
• DB更新ログの保存先を支社側に変更し、元の保存先には取得しないと考えることです。通常運用でも必要になるため、支社側のストレージにも取得する構成にします。

FAQ

解答の導き方

誤りやすいポイント

• 電話番号を定期的に確認することだけを答えると、連絡先が代表者1名に限られている問題への対応になりません。
• 代表者の電話番号を最新化するだけでは、その代表者に連絡がつかない場合の代替手段がありません。
• 連絡表の配付方法や保存場所ではなく、記載する連絡先の範囲を見直す設問です。

FAQ

解答の導き方

1. 訓練では、本社サーバ室が被災してサーバが稼働できない事態を想定しています。そのため、本社ファイルサーバにだけ連絡表の情報を保存していると、被災時に情報を参照できません。
2. 本文では、連絡表の情報を本社ファイルサーバに保存している一方、「本社ファイルサーバを利用できないときでも最新の連絡表の情報を参照できる」ようにする対策を求めています。したがって、本社とは別の場所にある装置を使って、連絡表の情報を参照できるようにする必要があります。
3. 図1には、関西地区の支社に支社ファイルサーバがあります。今回想定しているのは関東地区の大規模地震なので、本社のファイルサーバが使えない場合でも、関西地区の支社ファイルサーバを利用できるようにしておけば、連絡表の情報を参照できます。
4. そこで、最新の連絡表の情報を本社ファイルサーバだけでなく支社ファイルサーバにも保存します。情報を更新した際には支社側の保存内容も最新化しておけば、被災時に古い連絡先を参照することを避けられます。

誤りやすいポイント

• 本社ファイルサーバ内で保存場所を変えるだけでは、本社サーバ室が被災した場合の対策になりません。
• 連絡表を紙で配付するだけでは、本文で問題となった「代表者の電話番号が最新化されていなかった」という問題が残ります。
• 図1に示されている装置を使う対策なので、磁気テープへの保存ではなく、関西地区にある支社ファイルサーバを活用します。
• 支社ファイルサーバに保存するだけでなく、連絡表の情報を更新したときに、その内容も最新に保つことが重要です。

FAQ