平成28年度 秋期 午後Ⅰ

本文の根拠

表3 注2

被災時点から災対システムの起動開始までには，被災状況の確認作業などが必要であり，所要時間は 30 分である。また，その後の作業内容は案ごとに異なるが，必要となる場合には，災対システムの起動作業に 30 分，フルバックアップからのデータ復元に 30 分，システムの正常稼働の確認に 30 分掛かる。

〔両システムの運用〕

両システムとも，毎日 4 時から 23 時までオンライン処理を行う。23 時から 24 時までは，テープ媒体にファイルのフルバックアップを取得し，サーバ室に保管している。

表3 案3

案3：災対システムはクラウドサービスを使用して構築し，被災時はフルバックアップからデータを復元する。フルバックアップの取得方式を，データ保管サービスの利用に変更する。取得対象データと取得時期は現在のままとする。

空欄a。案1で必要な作業を注2から拾って足す。被災状況の確認30分，災対システムの起動30分，フルバックアップからのデータ復元30分，正常稼働の確認30分で合計120分。

案2で検算できる。案2はホットスタンバイ構成なので，起動もデータ復元も要らない。確認30分＋正常稼働の確認30分で60分となり，表3の値と一致する。案3も案1と同じ4つの作業を行うので120分で，これも表と合う。

空欄b。案3は「取得対象データと取得時期は現在のままとする」と断っている。現在のフルバックアップは23時から24時に取っている。オンライン処理は4時から23時なので，このバックアップはその日のオンラインが終わった状態である。

24時から翌4時までは何も動かないから，前日のバックアップは翌日（被災当日）のオンラインが始まる直前の状態と同じになる。案1のRPOが「被災当日のオンライン開始時点」と書かれているのと同じ理屈で，案3も同じ時点になる。

本文の根拠

表3 案1

費用 1.3，復旧時間 a，RPO は被災当日のオンライン開始時点。

冒頭

顧客からの注文は，両支店で毎日 8 時から 19 時までの間，電話又はファックスで受け付け，端末から販売管理システムに入力している。

表2 BCP

項番1（販売活動）：関東支店は注文受付と入出庫を停止する。近畿支店は在庫を活用して，注文受付と出庫を通常どおり継続する。

RPOが被災当日のオンライン開始時点ということは，その日に入力した分は戻ってこないということである。

注文の受付は8時から19時まで行っている。オンラインは4時に始まるので，被災が8時以降なら，その日に入れた注文はすべて失われる。しかもBCPでは近畿支店が注文受付を通常どおり続けるので，データが欠けたまま業務が進む。

これは技術で埋められる欠落ではない。入力した本人たち，つまり販売部が入れ直すしかない。その作業が発生することを，案を決める前に販売部と合意しておく必要がある。合意なしに案1を選ぶと，被災時に「誰が入れ直すのか」で止まる。

40字。解答例は「被災日に入力済みのデータを，システム復旧後に再入力する必要があること」で33字。

本文の根拠

〔復旧手順の検討及びクラウドサービスの選定〕

ストレージは，平常時は最低限の容量だけを確保しておき，被災時点のデータ量に応じて，災対システムの起動作業と並行して容量の追加を行う。

〔復旧手順の検討及びクラウドサービスの選定〕

被災状況の確認作業などに 30 分，その後，災対システムの起動作業に 30 分，さらに，フルバックアップからのデータ復元に 30 分掛かる。

表4

項番4 W 社：中部地方，40 分以内，60 分。

容量の追加は「災対システムの起動作業と並行して」行う，と決まっている。起動作業は30分なので，追加に使える時間も30分である。

この30分を超えると何が困るか。次の工程はフルバックアップからのデータ復元で，入れ物が広がっていなければ始められない。つまり復旧時間120分が守れなくなる。

したがって条件は，ストレージ容量の追加が災対システムの起動作業の完了までに終わること。表4ではW社だけが40分以内で，この条件から外れる。

40字。解答例は「ストレージ容量の追加作業が，災対システムの起動作業完了までに終わること」で34字。

「短時間で追加できること」では基準がない。並行して行える時間が30分だ，という前提から具体的な線を引く。

採点講評（IPA）

設問2(1)はストレージの追加作業が可能な時間帯を誤って認識している解答も見受けられた。問題文を落ち着いて読み，作業の前提条件を正しく把握してほしかった。

本文の根拠

〔復旧手順の検討及びクラウドサービスの選定〕

事業継続に関する要求事項として，サービスを提供するデータセンタが，R 社のサーバ室と同じ地方にないこと

〔復旧手順の検討及びクラウドサービスの選定〕

災対システム稼働中にインシデントが発生し，災対システムが停止した場合，クラウド事業者がインシデントの解決及び災対システムの起動を実施する。その後，R 社でフルバックアップからのデータ復元及びシステムの正常稼働の確認を実施し，サービスを再開する。

表4 注3

作業所要時間とは，インシデントの発生から解決までの時間であり，災対システムを起動する時間は含まない。

3つの条件で順にふるいにかける。

1つ目は所在地。R社のサーバ室はD市，つまり関東地方にある。同じ関東地方のU社が落ちる。

2つ目はインシデント発生から120分以内の再開。内訳を積む。クラウド事業者の作業所要時間（注3のとおり起動は含まない）に，災対システムの起動30分，データ復元30分，正常稼働の確認30分が続く。後ろの3つで90分使うので，事業者の作業所要時間は30分以内でなければならない。Q社40分，U社60分，W社60分が落ち，残るのはS社の20分だけである。

3つ目は空欄cのストレージ条件で，容量追加は30分以内。W社の40分が落ちる。

3つすべてを満たすのはS社である。

注3を読み飛ばして起動時間を作業所要時間に含めてしまうと，2つ目の線引きが狂う。表の注記まで読むこと。

本文の根拠

〔両システムの運用〕

システムのオペレーションは，販売管理システム専任の A チームと，生産管理システム専任の B チームの 2 チームに分かれている。部員は自身が担当するシステムについて教育を受け，オペレーションを実施している。

〔両システムの運用〕

部員は自身が担当するシステム以外のオペレーションは実施していない。

〔災害対策用システムの検討〕

販売管理システムの RTO（目標復旧時間）は被災時点から 120 分，生産管理システムの RTO は被災時点から 5 日と設定した。

指摘されたのは，Aチームが動けず非番も呼べない場合である。現場にBチームの部員はいるが，販売管理システムの教育を受けていないので操作できない。人がいないのではなく，できる人がいないという状態である。

そこでBチームにも販売管理システムのオペレーションを教育しておく。被災時，生産管理システムのRTOは5日と長いので，Bチームは当面そちらに追われない。手を貸せる余地がある。

50字。解答例は「Bチームのオペレータを販売管理システムのオペレーションもできるように教育する。」で38字。

Bチームを訓練に参加させる，とだけ書くと足りない。教育を受けていない者が訓練に出ても操作はできないので，教育まで遡って書く。

採点講評（IPA）

設問3(1)は，BチームをAチームとともに災害復旧訓練に参加させるとだけ述べた解答が散見された。ここでは，問題文にあるシステムの運用実態を踏まえ，訓練参加の前提として必要となる運用要員の教育まで遡って考察してほしかった。

本文の根拠

〔災対システムの構築〕

G 氏は変更計画として，災対システムの構築計画，災対システムに関連する既存システムの稼働環境の修正計画，及び既存システムのオペレーションマニュアルの修正計画をまとめた。

〔災対システムの構築〕

災対システムの構築が完了した後，G 氏は災害対策用マニュアル（以下，災対マニュアルという）も作成した。

〔災対システムの構築〕

予備の専用線の追加は，変更管理プロセスに従って承認された後，予備の専用線の敷設作業が実施された。

なぜ漏れたのかを時系列で追う。変更計画に入っていた修正対象は「既存システムのオペレーションマニュアル」で，災対マニュアルはその後に作られた。最初から変更計画の枠の外にある。

予備の専用線を追加したときも，変更管理プロセスは通っている。それでも災対マニュアルは修正対象に挙がらなかった。個人が書き忘れたのではなく，仕組みの側で拾われないようになっている。

拾われるようにするには，災対マニュアルを構成品目として管理すればよい。構成品目であれば，変更のたびに影響を受けるものとして洗い出され，修正が変更計画に含まれる。

40字。解答例は「災対マニュアルをサービスの構成品目として認識し，変更計画の対象とする。」で34字。「マニュアルを更新する」で止めると，今回の漏れは直っても次の変更でまた漏れる。

採点講評（IPA）

設問3(2)は，正答率が低かった。サービス継続の手順となる災害対策用マニュアルを更新するための変更要求を，変更管理プロセスに提供することに気付いてほしかった。

本文の根拠

〔サービス運用段階のキャパシティ管理〕

オンライン応答時間の測定値が，あらかじめ決められたしきい値を超えた場合は，監視システムがインシデントとして検知する。しきい値には，各サービスの SLA 項目の目標値を設定しており

表1

顧客管理サービスの契約管理サービス：同上，5 秒以内。

しきい値にSLAの目標値をそのまま置いている，というのが問題の所在である。

この置き方だと，しきい値を超えたときにはもうSLAを割っている。検知は「これから危ない」ではなく「すでに違反した」の合図になってしまう。実際，今回も通知を受けてから調査を始め，その間に営業部門からクレームが届いた。

しきい値を目標値より低い値にしておけば，違反する前に気づいて手を打てる。監視の目的は，違反を記録することではなく違反を防ぐことである。

40字。解答例は「SLA違反となる前に対策がとれるよう，しきい値を目標値より下に設定する。」で35字。設問が「SLAとの関連性を含めて」と言っているので，目標値との上下関係を書く。

採点講評（IPA）

設問1(1)は，オンライン応答時間の悪化を検知する監視項目を誤った解答が多かった。しきい値にSLA項目の目標値を設定していることの問題点を的確に指摘してほしかった。

本文の根拠

〔サービスの概要〕

受注分析サービスは毎日 1 回提供されるサービスである。請求・入金サービスのバッチ処理との競合を避けるために 9 時以降に処理を開始する必要があり，毎日 9 時に起動する顧客管理システムのバッチ処理として運用されている。

表1

顧客管理サービスの受注分析サービス：同上，毎日 13 時まで。

〔サービスの概要〕

現在では処理完了までに 1 時間 30 分掛かっている。

表2

受注分析サービス：60，45，0，0。

表2の内訳を見ると，10〜11時の95％のうち45％が受注分析サービスである。オンラインの3サービスを合わせても50％しかない。重いのはバッチのほうである。

受注分析はバッチ処理なので，動かす時刻を選べる。制約は3つ。9時以降に開始すること，13時までに完了すること，処理に1時間30分かかること。

11時開始なら12時30分に終わり，13時に間に合う。しかも表2のとおり11〜12時のオンラインは15％，12〜13時は5％と空いている。ピークを外して空いている時間帯へ移せる。

35字。解答例は「受注分析サービスのバッチ処理開始時刻を11時に変更する。」で27字。

12時開始では13時30分になって完了時刻を守れない。9時より前に動かすのも，請求・入金サービスとぶつかるので不可。動かせる幅は9時から11時30分の間しかない。

本文の根拠

表2

顧客管理サービス全体：85，95，15，5。

〔顧客管理サービスのインシデントとその対策〕

顧客管理サーバの利用状況を調査したところ，1 日のオンライン処理件数のうち約 2 割が 10〜11 時のピーク時間帯に集中していた。

10〜11時はオンライン処理が1日の約2割集中するピークである。そこへ受注分析の45％が重なって，全体が95％まで上がっていた。CPUが飽和すれば応答時間は伸びる。

受注分析を11時以降へ動かすと，ピーク時間帯からバッチの負荷が丸ごと抜ける。オンラインの3サービスだけなら50％程度で，余裕ができる。一方の11〜12時はもともと15％なので，そこへ受注分析が入っても収まる。

つまりサーバを増やさずに，負荷の山を時間軸でならすことができる。増強には時間が掛かるので，それまでのつなぎとして有効である。

40字。解答例は「オンライン処理のピーク時間帯のCPU負荷を分散させることができるから」で32字。

採点講評（IPA）

設問1(3)は，正答率が高かった。応答時間の性能を維持するために，現状与えられたキャパシティ制約の中で対応できる方法を見いだすことは実施できるようだった。

本文の根拠

図1 注記

負荷分散サーバ 1 は，同じ処理能力をもった代理店サーバ 1 又は代理店サーバ 2 のどちらかの業務サーバに，負荷が均等になるように処理要求を振り分ける。

〔代理店サービスのオンライン応答時間の悪化〕

変更作業の最後の作業項目として，代理店システムの機能の確認作業を行った。この作業で代理店サービスが利用できることを確認して，8 時までに作業を終了した。

〔サービス運用段階のキャパシティ管理〕

サービスがオンライン処理形態の場合は，サーバの CPU 使用率，サーバの処理件数及びオンライン応答時間を監視項目とする。

T氏が確かめたのは「代理店サービスが利用できること」である。ところが代理店サーバは2台あり，1台だけに寄っていてもサービスは使える。この確認では振分けの誤りを見つけられない。

キャパシティ管理の担当として見るべきは，2台へ均等に振り分けられているかどうかである。図1の注記のとおり，負荷が均等になるように振り分けるのが負荷分散サーバの役目なので，そのとおり動いているかを数字で確かめる。

監視項目にはサーバのCPU使用率とサーバの処理件数があるので，これをサーバごとに見比べればよい。片寄っていれば数字がそろわない。

60字。解答例は「代理店サーバ1と代理店サーバ2が有効に稼働していることを，それぞれのサーバのCPU使用率から確認する。」で50字。

「応答時間を確認する」だけでは足りない。開始直後の数分間は利用がまだ少なく，1台でもさばけてしまうので，応答時間には表れない。

採点講評（IPA）

設問2は，要求を正しく振り分けて処理していることを確認する内容の記載がない誤った解答が多かった。振り分け処理の正常動作を確認できる具体的な内容を解答してほしかった。

本文の根拠

〔サービス運用段階のキャパシティ管理〕

サービスがオンライン処理形態の場合は，サーバの CPU 使用率，サーバの処理件数及びオンライン応答時間を監視項目とする。

〔キャパシティ計画の変更〕

オンライン応答時間は，SLA 項目の目標値は達成しているが，サービス開始時に比べて悪化している。

〔キャパシティ計画の変更〕

インターネット受付システムは Web 型のシステムであって，主にサーバの処理能力がパフォーマンスに影響を与える。

下線（ア）は「サービスの需要」と「達成されているパフォーマンス」の2つを調べよと言っている。監視項目の中から，それぞれに当たるものを選ぶ。

需要に当たるのはサーバの処理件数である。どれだけ要求が来ているかを表す。

パフォーマンスに当たるのはオンライン応答時間である。すでに「サービス開始時に比べて悪化している」と分かっているので，どう推移したかを見る。

この2つを1年分並べれば，処理件数の伸びと応答時間の悪化がどう結び付いているかが読める。将来の需要を予測してキャパシティを見積もる材料になる。

CPU使用率は資源の使われ方を表すもので，需要そのものでもパフォーマンスでもない。

30字。解答例は「サーバの処理件数とオンライン応答時間の推移を調べる。」で25字。

採点講評（IPA）

設問3(1)は，誤った解答が散見された。業務サーバの負荷状況や性能を確認できる具体的な監視項目を解答してほしかった。

本文の根拠

〔キャパシティ計画の策定〕

営業部門から入手した，現在及び将来のサービスに対する需要とサービス利用者の見通しから，データ処理量の増加を見積もる。

〔キャパシティ計画の変更〕

オンライン応答時間の SLA 項目の目標値を達成するために，将来の需要の予測が必要である。

冒頭

これらのサービスは F 社の営業部門が統括している。

監視データから分かるのは，これまでどうだったかだけである。これから利用者がどれだけ増えるかは，運用の記録には残っていない。

答えはキャパシティ計画の策定手順にそのまま書いてある。営業部門から現在及び将来のサービスに対する需要とサービス利用者の見通しを入手し，そこからデータ処理量の増加を見積もる，という流れである。サービスを統括しているのが営業部門なので，見通しを持っているのもそこになる。

40字。解答例は「将来のサービスに対する需要とサービス利用者の見通しを営業部門から入手する。」で36字。設問が「入手先を含めて」と言っているので，営業部門を落とさない。

本文の根拠

表2 段階的取扱い

段階的取扱い：優先度が“高”及び“中”の場合は，開発チームに直ちに緊急連絡を行う。

表2 解決

解決：サービスを早期に回復させるために，回復を試みる。KEDB を参照して，サービスを早期に回復させる回避策を探し，必要な回復処理を行う。

〔販売サービスのインシデント〕

Y 氏は，サービス継続の観点から，利用者への影響は小さいと判断し，インシデントの原因を調査することにした。

表2の手順とY氏の行動を，上から突き合わせる。

手順は，記録 → 優先度の割当て → 分類 → 記録の更新 → 段階的取扱い → 解決 → 終了の順である。ところがY氏は，記録の更新の次にいきなり解決へ進んでいる。優先度は“中”なので，本来はその前に開発チームへ直ちに緊急連絡をしなければならない。これが1つ目の問題点である。

2つ目は解決の中身である。KEDBには回避策が2つ書かれていた。バッチ処理プログラムの強制終了と，Webサーバの再起動である。バッチ処理は動いていなかったが，再起動のほうは試せた。それをせずに原因の調査へ移っている。手順“解決”の目的は「サービスを早期に回復させる」ことであって，原因を突き止めることではない。

各30字。「利用者への影響は小さい」という判断自体が，早期回復より調査を選ばせた原因になっている。

採点講評（IPA）

設問1(1)では，Y氏の実施した記録から解決までのインシデント対応手順の中で，段階的取扱い及び解決に関する問題点を的確に指摘してほしかった。

本文の根拠

〔システム部のインシデント管理〕

サービスを早期に回復させるために，既知の誤りのデータベース（以下，KEDB という）を利用している。KEDB には，過去のインシデントの発生原因と，サービスの回復方法又はサービスへの影響を低減する有効な回避策が登録されている。

〔販売サービスのインシデント〕

Z 氏は，CMDB に登録されていないプログラムが稼働していた場合に強制終了する手順を回避策として整備し，後日 KEDB に登録することにした。

今回なぜ時間がかかったかを振り返る。KEDBに該当する回避策がなかったので，Y氏は原因の調査に入り，開発チームのZ氏の調査結果を待って，ようやく強制終了にたどり着いた。

登録しておけば，次に同じことが起きたときはKEDBを見るだけで手順が分かる。運用チームだけで，開発チームの調査を待たずに回復できる。

KEDBの目的そのものが本文に「サービスを早期に回復させるために」と書いてあるので，そこに沿って答える。

40字。解答例は「同類のインシデントが再発した場合に，サービスを早期に回復させるため」で32字。「記録を残すため」では，KEDBを使う意味が言えていない。

本文の根拠

〔標的型攻撃メールの検出〕

メールサーバのログには，不審なファイルが添付された Web 管理者宛ての電子メールの受信記録があった。また，同じファイルが添付された電子メールが社内の他部署の社員にも送信されている記録があった。

他部署の社員にも同じファイルが送られている，という事実は，直前のZ氏の調査でメールサーバのログから分かったものである。

宛先を洗い出すのにも，同じログを使えばよい。誰に何が届いたかは，受信の記録が持っている。

15字。解答例は「メールサーバのログ」で9字。

採点講評（IPA）

設問2は，正答率が高く，標的型攻撃メール受信などセキュリティインシデントが発生した際の緊急対応方法は理解されているようだった。

本文の根拠

〔標的型攻撃メールの検出〕

社員が添付ファイルを開封していた場合，開封操作を行った機器を LAN から切り離す。その後，指示に従って不正プログラムの確認をすること。

〔標的型攻撃メールの検出〕

そして，K 氏は，社内に今回の標的型攻撃メールに対する注意喚起を行った。

開封していないなら，その機器に不正プログラムは入っていない。だからLANから切り離す必要はないし，確認も要らない。

ただし電子メール自体は受信箱に残ったままである。残しておけば，あとで気づかずに開いてしまう恐れがある。危険はまだ去っていない。

だから削除させる。開封した人には切り離しと確認を，していない人には削除を，と指示を分けているのはこのためである。

20字。解答例は「標的型攻撃メールの削除」で11字。

採点講評（IPA）

設問2は，正答率が高く，標的型攻撃メール受信などセキュリティインシデントが発生した際の緊急対応方法は理解されているようだった。

本文の根拠

表1

通知：運用状態の通知，インシデントとして扱わない。警告：調査が必要なことを示す事象，インシデントとして扱う。

〔システム部のインシデント管理〕

発生したインシデントが情報セキュリティインシデントに該当するおそれがある場合，運用チームの担当者は，システム部の情報セキュリティ担当要員に連絡して，指示に従って対応する。

〔標的型攻撃メールの対策〕

防御システムで，特定の基準以上の危険性がある不正な通信を検出した場合は監視システムに通知する。

表1の区分が効いてくる。“通知”はインシデントとして扱わないので，表示されても運用チームは対応手順に乗せない。“警告”ならインシデントとして扱う。

インシデントとして扱えば，運用チームが記録し，情報セキュリティインシデントに該当するおそれがあるとして情報セキュリティ担当要員へ連絡が回る。担当要員は対応策を実施して被害を最小限に抑える役目をもっている。

不正な通信は情報の持ち出しにつながるので，止めるのが早いほど被害が小さい。“通知”のままにすると，誰の手も動かないまま流出が続く。

40字。解答例は「情報セキュリティ担当要員に連絡して，早期に対応する必要があるから」で31字。

「記録を残すため」では弱い。記録が目的なのではなく，担当要員へ渡して手を打たせるのが目的である。

採点講評（IPA）

設問3は，“記録を残すためにインシデントとして管理する”などの誤った解答が多かった。セキュリティインシデントの可能性がある場合の影響範囲の確認や被害拡大防止のための対応手順を理解した上で解答してほしかった。

本文の根拠

〔配送管理サービスの変更〕

システム障害による配送業務の停止は，サービスの低下につながるので，システム停止を伴うインシデントが発生した場合には，インシデントの対応手順に従って，30 分以内に回復させる。

表4

項番1：異常，中。項番2：警告，低。

表5

項番1：高，30 分。項番2：中，2 時間。項番3：低，12 時間。

求められているのは30分以内の回復である。表5で30分に当たるのは優先度“高”だけなので，該当するインシデントを“高”に上げる必要がある。

該当するのは「システム停止を伴うインシデント」で，表1の“異常”（正常に運用されていない状態）がこれに当たる。ところが表4では，配送管理サービスの“異常”は“中”，つまり2時間になっている。これでは要求を満たせない。

そこで表4の優先度判定ルールを変え，“異常”を“高”にする。“警告”は調査が必要な事象でシステム停止ではないので，“低”のままでよい。

40字。解答例は「配送管理サービスの優先度判定ルールで“異常”の優先度を“高”に変更する。」で36字。表5の目標復旧時間のほうを書き換える答えは誤りで，そちらは全サービス共通なので，販売サービスの目標まで一緒に変わってしまう。

採点講評（IPA）

設問4は，正答率が高かった。ITサービスマネージャとして，サービスの変更に対応したサービス目標について合意し，優先度に基づくインシデントの解決目標時間を見直す方法や必要性は，理解されているようであった。