平成26年度 秋期 午後Ⅰ

本文の根拠

図 1

情報システム部サーバルームでは，IP-VPN からルータを経て SW につながり，SW に確認用 POS レジ，確認用検索端末，Web サーバ，AP サーバ①，AP サーバ②，DB サーバが接続されている。

〔新規 IT サービスの概要〕

確認用 POS レジ及び確認用検索端末（以下，これらを確認用端末という）は，店舗でインシデントが発生した場合，情報システム部がインシデントを再現して確認するための機器である。

表 2 注1）

IP-VPN，ルータ，SW 及びストレージは省略している。

店舗の POS レジや検索端末は，ルータから IP-VPN を通ってサーバにつながっている。一方，確認用端末はサーバルームの SW に直接つながっていて，IP-VPN もルータも通らない。

店舗のインシデントには，IP-VPN やルータが原因のものもある。確認用端末は店舗と同じ経路を通らないので，そうしたインシデントを再現できないおそれがある。講評のとおり，図 1 の構成を店舗側と比べると気付ける。

60字。解答例は「確認用端末がサーバとIP-VPNを介して接続されていないので，確認用端末でインシデントを再現できないおそれがある。」で55字。構成の違い（IP-VPN を通らない）と，その結果（再現できない）の両方を書く。

採点講評（IPA）

設問1は，正答率が低かった。設問が求めている内容を正しく把握すれば図1のシステム構成上の観点から問題点を導けるので，落ち着いて題意を読み取ってほしい。

本文の根拠

表 1

サービス回復時間 1 時間以内（障害発生の検知からサービスの回復まで）。

表 1

サービス回復時間 2 時間以内（障害発生の検知からサービスの回復まで）。

表 3

AP サーバ①：50，a，－。AP サーバ②：50，－，b。

〔サービスの可用性を考慮した構成検討〕

ルータ及び SW は，当該機器の復旧完了によってサービス回復となるが，Web サーバ及び AP サーバは，当該機器の復旧完了後にアプリケーションの動作確認のために 15 分必要である。

冗長化が要るのは，壊れた機器を直してサービスを戻すまでが，回復時間の目標を超える場合である。AP サーバは復旧に 50 分，そのあと動作確認に 15 分で，合わせて 65 分掛かる。

a の AP サーバ①は販売支援サービスで使い，目標は 1 時間（60 分）。65 分は超えるので冗長化が要り，「○」。b の AP サーバ②は情報検索サービスで使い，目標は 2 時間（120 分）。65 分で間に合うので「×」。

記号を答える。ルータと SW は 20 分で動作確認も要らないので，どちらのサービスでも「×」になっていることと合う。

本文の根拠

〔バックアップ方式の検討〕

ストレージ機器が故障した場合には，機器の復旧に 40 分，リストア後の確認などの回復作業に 20 分掛かる。

表 4

案1：フルバックアップ方式。バックアップ：毎日 1 時のバッチ処理が完了した後に，フルバックアップを取得する。フルバックアップの所要時間 40 分。リストア：最新のフルバックアップから復元する。フルバックアップのリストア所要時間 40 分。

表 4

障害発生当日までの増分バックアップを順次復元する。1 日分の増分バックアップのリストア所要時間 5 分。

情報検索サービスの回復時間の目標は 2 時間（120 分）。ストレージの故障では，機器の復旧 40 分と確認 20 分で 60 分掛かり，リストアに使えるのは 60 分である。

案 1 は毎日フルを戻すだけで 40 分，合計 100 分で，いつ壊れても間に合う。案 2 はフル 40 分に増分を足す。日曜日のフルのあと月曜日から毎日 5 分ずつ増え，4 日分（20 分）までは 60 分に収まるが，金曜日は 5 日分で 65 分，土曜日は 6 日分で 70 分となり，超える。

答えは「案 1」。バックアップの取得時間は案 2 のほうが短いが，設問は回復時間の目標を守れるかで比べる。

本文の根拠

表 1

サービス回復時間 2 時間以内（障害発生の検知からサービスの回復まで）。

(1)の計算のとおり，案 1 は故障した日に関係なく 100 分で回復でき，目標の 120 分に収まる。

案 2 は増分がたまる週の後半に故障すると，120 分を超えてしまう。サービスレベル目標はいつ壊れても守る必要があるので，案 1 を選ぶ。講評のとおり，顧客が求めるサービスレベル目標を達成できるかが判断の軸になる。

60字。解答例は「案1は，障害発生日時に関係なく，サービスレベル目標で定めているサービス回復時間内に回復できるから」で47字。「いつ壊れても」と「サービス回復時間内」の2点を入れる。

採点講評（IPA）

設問3(2)は，正答率が高かった。ITサービスマネージャとして，顧客の要求するサービスレベル目標を達成することの重要性については，理解されていると思われる。

本文の根拠

〔応答性能確保に向けた方策の検討〕

当日に実施が決定されるセールの開催で突発的に業務量が増加すると，AP サーバ②の CPU 使用率が安定稼働の基準値を超え，販売支援サービスの応答性能が急激に悪化することが予想された。

〔サービスの可用性を考慮した構成検討〕

検索の際には，AP サーバ②の DB 検索アプリケーションを使用する。

お得意様割引機能を入れると，販売支援サービスも AP サーバ②を使うようになる。セールで業務量が急に増えると，AP サーバ②の CPU 使用率が基準値を超え，販売支援サービスの応答が急に悪くなると予想されている。

悪化の手前で気付くには，その原因である AP サーバ②の CPU 使用率を見張ればよい。

20字。解答例は「APサーバ②のCPU使用率」で13字。「CPU 使用率」だけでなく，どのサーバかまで書く。

本文の根拠

〔応答性能確保に向けた方策の検討〕

AP サーバ②の CPU 使用率が安定稼働の基準値を超え，販売支援サービスの応答性能が急激に悪化することが予想された。

〔応答性能確保に向けた方策の検討〕

H 氏は，AP サーバ②の CPU 能力が増強されるまでの間，販売支援サービスの応答性能悪化の兆候が見られる場合には，情報検索サービスの使用を中止するよう，各店舗に対して通知するという暫定対策を策定した。

基準値を超えると応答が急激に悪くなるので，基準値で気付いたのでは暫定対策が間に合わない。基準値より手前に，暫定対策を打つためのしきい値を別に置く。

業務量が急に増えるのは当日に決まるセールのときである。セールを行うときに AP サーバ②の CPU 使用率がしきい値を超えていないかを見て，超えていれば店舗に情報検索サービスの中止を通知する。講評のとおり，悪化が始まる水準にしきい値を置くのは遅い。

60字。解答例は「基準値を超過する前に対策が実施できるようにしきい値を設定し，セール実施時に監視項目のしきい値超過の有無を判断する。」で56字。しきい値の位置と，判断するタイミングの両方を書く。

採点講評（IPA）

設問4(2)は，正答率が低く，性能悪化が始まる水準にしきい値を設定するなどの誤った解答が散見された。サービスレベル目標が達成できなくなる前に予防的対策を講じるための管理の仕組みを設計することの重要性を認識してほしい。

本文の根拠

〔加盟店向けサービス〕

加盟店では顧客との対面販売が中心で短時間での応答が求められるので，システム部は加盟店決済サービスの応答時間については特に考慮し，営業部と合意している。

〔加盟店向けサービスの応答時間悪化〕

オンラインサイト数の増加に伴って，オンラインサイトでの一括決済サービスのデータ量が多くなっていることから，データセンタと IP-VPN を接続する回線が遅延の原因になっていることが分かった。

回線を分けるのは，一括決済のデータに押されて加盟店の決済が遅くなっているからである。加盟店決済サービスの応答時間は，営業部と合意したサービス目標である。

サービスのキャパシティ管理は，合意したサービス目標を満たす容量を確保することを見る。一括決済を新しい回線に逃がせば，加盟店決済サービスの応答時間を守れる。講評のとおり，応答時間などサービス目標の達成を観点に書く。

40字。解答例は「営業部と合意した加盟店決済サービスの応答時間を保証する必要があるから」で33字。「合意した」「応答時間」の2語で，サービス目標を守るためだと示す。

採点講評（IPA）

設問1(1)は，正答率が低かった。サービスのキャパシティ管理の観点として，応答時間などサービス目標の達成が重要であることを認識してほしかった。

本文の根拠

〔オンラインサイト向けサービス〕

業務サーバでは，一括決済サービスのためのバッチ処理を 1 時間に 1 回起動し，全てのカード利用者の決済処理終了後に，送信元の全てのオンラインサイトに一括して処理結果を回答している。

〔加盟店向けサービスの応答時間悪化〕

0 時から 12 時までに受け付けた要求は 18 時までに，12 時から 24 時までに受け付けた要求は翌日 6 時までに回答すればよいことが分かった。

〔オンラインサイト向けサービス〕

特に，昼休み，夜間などの繁忙時間帯に，オンラインサイトで大量の決済処理が集中する場合を考慮して

今は一括決済のバッチを 1 時間に 1 回動かし，結果を回線に流している。遅延は昼休みの時間帯に起きている。

回答期限は，午前の受付分が 18 時まで，午後の受付分が翌朝 6 時までで，1 時間ごとに返す必要はない。昼休みや夜間など繁忙な時間帯にはバッチを起動せず，空いている時間にまとめて処理しても，期限は守れる。

40字。解答例は「一括決済サービスのためのバッチ処理は，繁忙時間帯には起動しない。」で31字。「運用方法を工夫して」とあるので，いつ動かさないかという運用のルールで書く。

本文の根拠

表 1

カード利用者数：200 万人，500 万人，650 万人，750 万人。加盟店数：150 店，200 店，250 店，300 店。オンラインサイト数：10 サイト，20 サイト，60 サイト，80 サイト。

表 2

ディスク装置：1 台当たり 10G バイト（10,000M バイト）の容量のデータを保管できる。要求基準：会員情報：カード利用者 1 万人当たり 20M バイトを確保。利用履歴（注1）：加盟店は 1 店舗当たり 100M バイトを確保，オンラインサイトは 1 サイト当たり 500M バイトを確保。注1）利用履歴は，カード利用者の利用頻度に比例して増加する。

〔大口オンラインサイトの追加〕

大口オンラインサイトは，多数のカード利用者の利用が見込まれており，サービス要求数とカード利用者の利用頻度は，それぞれ既存オンラインサイトの 1 サイト当たりのサービス要求数と利用頻度の 5 倍であることが分かった。

2013 年 12 月末で，構成品目ごとに当初計画と見直し後を比べる。業務サーバは，当初 200 × 0.1 ＋ 20 × 1 ＝ 40 件／秒，見直し後は大口の 5 件を足して 45 件／秒。2 台で 60 件／秒なので増設は要らない。DB サーバは 500 万人で 750 万人以下なので要らない。

ディスクは，当初 会員 500 × 20 ＝ 10,000，加盟店 200 × 100 ＝ 20,000，サイト 20 × 500 ＝ 10,000 で合計 40,000M バイト，4 台。見直し後は大口の利用履歴が 5 倍の 2,500 増えて 42,500M バイト。4 台では 2,500M バイト（2.5G バイト）足りないので，もう 1 台増やす。

50字。解答例は「2013年12月末にストレージ容量が2.5Gバイト不足するので，ディスク装置を1台増設する。」で45字。講評のとおり，根拠の数字を示さずに「余裕を持って増強する」と書くのは誤り。

採点講評（IPA）

設問2では，与えられた要求基準を利用して計算すれば正答を導くことができるが，明確な根拠を示さずに単に余裕を持った増強を行うなどの誤った解答が多く見られた。

本文の根拠

〔電子サインサービスの開始〕

“当初は加盟店の 1 割程度と見込んでいる。今後は 2014 年 6 月に需要予測を行い，詳細計画を策定する。”

〔電子サインサービスの開始〕

1 割の加盟店が利用する想定でデータ量を算出して 2014 年 1 月のキャパシティ計画の見直しに反映し，2014 年 5 月に電子サインを保管するディスク装置を増設することにした。

〔電子サインサービスの開始〕

電子サインサービス開始に当たり，営業部では電子サイン導入キャンペーンを実施し，多数の加盟店に対して積極的に営業活動を行い，導入を拡大していく予定である。

L 氏は，加盟店の 1 割が使う想定でディスクの増設量を決めた。この 1 割は営業部が「当初は」と言った目安で，詳しい需要予測は 2014 年 6 月に行う予定である。

しかも営業部はキャンペーンで導入を積極的に広げる。1 割より多くの加盟店が使い始めれば，電子サインのデータが増えて，5 月に増設したディスクでは足りなくなる。

40字。解答例は「加盟店の1割を想定して計画しているので，ディスク装置の容量が不足する。」で34字。計画の前提（1 割）と，起こること（容量不足）をつなげる。

本文の根拠

〔キャパシティ計画〕

システム部の IT サービスマネージャである L 氏は，営業部が策定する業務計画に合わせて，毎年 1 月にキャパシティ計画を作成している。

〔電子サインサービスの開始〕

今後は 2014 年 6 月に需要予測を行い，詳細計画を策定する。

キャパシティ計画は毎年 1 月にしか作っていない。営業部の需要予測は 6 月に出るので，次の見直しは翌年 1 月まで待つことになり，その間に容量が足りなくなるおそれがある。

年に 1 回の定期の見直しにこだわらず，営業部が需要予測を出したときなど，必要なタイミングでキャパシティ計画を見直す。

40字。解答例は「営業部の需要予測に基づいて適切なタイミングでキャパシティ計画を見直す。」で34字。見直しの根拠（需要予測）と時期（適切なタイミング）を入れる。

本文の根拠

〔電子サインサービスの開始〕

電子サインサービスを利用するためには，加盟店が営業している日中時間帯にプログラムを決済端末に配付する。

〔電子サインサービスの開始〕

決済端末に配付するプログラムのサイズは，1 台当たり 5M バイトである。

〔加盟店向けサービス〕

加盟店でのカードの利用頻度と決済処理時の通信データ量を考慮して，加盟店と IP-VPN 間は 64k ビット／秒の回線で接続している。

加盟店の回線は 64k ビット／秒で，決済の小さなデータに合わせた細い回線である。そこへ 1 台 5M バイトのプログラムを，営業している日中に流す。

5M バイトは 40,000k ビットで，64k ビット／秒だと 1 台でも 10 分以上掛かる。その間，同じ回線を使う決済の通信が詰まり，加盟店決済サービスの応答時間が悪くなる。講評のとおり，リリースを展開する前にこうした影響とリスクを評価する。

40字。解答例は「配付を開始すると，加盟店向けサービスの応答時間に影響を与える。」で30字。サービス運用の観点なので，配付の失敗ではなく，サービスへの影響を書く。

採点講評（IPA）

設問3(2)は，正答率が高かった。リリースを稼働環境に展開する際は，計画立案段階で，リリースの影響，関連するリスクのアセスメントを行うことは，おおむね理解されているようであった。

本文の根拠

表 1

①〜③のいずれかの状況が発生した場合は，専門部署に回復処理を依頼する。①障害対応マニュアルに，表示メッセージに対応した処理の指示がない。②障害対応マニュアルに従って処理したが，回復しない。③目標復旧時間内に回復できないおそれがある。

〔空調機に発生したインシデントとその対応〕

オペレータは，障害対応マニュアルを参照したが，当該メッセージについての対応指示の記載はなかった。

〔空調機に発生したインシデントとその対応〕

データセンタでは，毎日 8 時に運用管理者主催の運用会議を行っている。

マニュアルに対応の指示がなかった時点で，表 1 の①に当たり，専門部署（ファシリティ担当）に回復処理を頼むべきだった。

さらに，警告は優先度「低」で目標復旧時間は 8 時間。22 時の発生なので翌朝 6 時までに解決が要るが，報告したのは翌朝 8 時の会議だった。何もしなければ間に合わないので③にも当たる。①と③が起きているのに依頼しなかったことが問題である。

50字。解答例は「表1の段階的取扱いで示した①及び③の状況が発生しているのに，専門部署に回復処理を依頼しなかった。」で46字。「理由を含めて」とあるので，どの条件に当たるかを番号で示す。

本文の根拠

表 2

通知：運用状態の通知，例 定期的な温度状況の表示（注1），インシデントとしては扱わない。

表 2

異常：正常に運用されていない状態を表す事象，例 サーバルームの温度がデータセンタで定めた温度基準値超えの表示

〔空調機に発生したインシデントとその対応〕

報告を受けて，ファシリティ担当の S 氏がサーバルームの温度変化の状況を調査した。その結果，想定以上の上昇傾向がみられた。

今の温度のメッセージは，定期的な表示（通知）と，基準値を超えたとき（異常）の 2 つしかない。上がり始めても基準値を超えるまでは通知のままで，インシデントとして扱われない。

温度基準値より手前に警告用のしきい値を置き，定期表示のときに測った温度がそれを超えていたら，メッセージの種類を警告にする。警告は優先度「低」のインシデントになるので，異常になる前に対応が始まる。

60字。解答例は「温度警告用のしきい値を設定し，定期的な温度状況表示の際，測定値がしきい値を超えた場合は種類を警告に変更する。」で53字。しきい値の追加と，メッセージの種類を変えることの両方を書く。

採点講評（IPA）

設問1(2)は，正答率が高かった。サービスの運用段階に入って，作業者が正確に対応可能となるように，“しきい値を設定し異常のメッセージを表示する”などの方法をとることについては，理解されているようであった。

本文の根拠

表 3

④入室受付票の確認 入室管理者は，記入された入室受付票と，入室管理システムの承認済申請内容を照合する。入室管理者は，a。

表 3

③入室受付票の記入 作業を行う訪問者は，入室受付で入室受付票に次の内容を記入し，入室管理者に提出する。

④では，入室受付票の内容が承認済みの申請と合っているかを照合している。しかし受付票は訪問者が自分で書くもので，申請内容を知っていれば誰でも同じように書ける。

書かれた作業者氏名の人が，目の前にいる本人かどうかを確かめなければ，許可された人だけを入れることにならない。身分証などで，作業者が本人であることを確認する。

30字。解答例は「作業者が本人であることの確認を行う。」（17字）と「作業者の識別情報を認証する。」（14字）の2つ。講評のとおり，申請者への確認やアクセス権の確認では，本人かどうかは分からない。

採点講評（IPA）

設問2では，事前申請者への確認，アクセス権の設定内容確認といった誤った解答も散見されたが，情報セキュリティ管理における物理的入退管理策としての本人確認の必要性は理解されているようであった。

本文の根拠

〔新規システムの受入れに伴う変更〕

V 氏は承認された変更内容に基づき，新規に収容する機器の情報をラック収容情報として CMDB に登録し，更新した。

〔構成監査の実施〕

運用管理者が変更管理の記録を調査したところ，W 氏の変更要求については，変更を展開する作業で作業ミスが発生し，保守端末のラック収容も中止され，元に戻されていた。

V 氏は，変更が承認された時点で，これから収容する機器をラック収容情報として CMDB に登録した。まだ機器を実際にラックに入れる前である。

そのあと展開の作業でミスがあり，保守端末の収容は中止されて元に戻された。CMDB は先に更新済みなので，実物はないのに登録だけが残った。

50字。解答例は「変更の展開前に，新規に収容する機器の情報をラック収容情報として登録し，CMDBを更新したから」で44字。「展開前に」更新したという順序を必ず書く。

本文の根拠

〔構成監査の実施〕

運用管理者は調査を進め，W 氏の変更要求に伴う V 氏の作業が，変更管理に関わるサービスマネジメントのプロセス規定どおりに実施されていないことを発見した。

〔構成監査の実施〕

データセンタに構築されている構成品目と構成情報とで不一致が発生する事象の再発防止に向けて

構成品目（実物）と構成情報（CMDB）がずれたのは，変更の展開より前に CMDB を書き換えたからである。

変更は展開で失敗することがある。CMDB は，変更が実際に展開されて成功したあとで更新すれば，実物と記録が食い違わない。これは変更管理と構成管理をつなぐときの決まりごとである。

30字。解答例は「CMDBの記録は，変更の展開の成功後に更新する。」で23字。講評のとおり，プロセス間のつなぎ目（いつ構成情報を更新するか）を答える設問である。

採点講評（IPA）

設問3(2)は，正答率が低かった。サービスマネジメントのプロセス間のインタフェースについて，正しく理解できていなかったようである。JIS規格を確認するなどして理解を深めてほしい。