解説

• Hバッチ処理が製造に与える影響に関し、本文中には以下の記述があります。
  • Hバッチの処理結果は，生産管理システムの生産計画案生成バッチ処理（Pバッチ）の入力情報となる
  • Hバッチの処理結果は，翌日の生産計画に反映する必要があるので，当日の13時30分までに生産管理システムに送信している
  今回検討されたインシデント対応は、応答時間の目標値を遵守するためにリソースの使用量を制限しながらHバッチを実行するというものです。この対応では、応答時間の要件は満たせますが、Hバッチの処理時間が長くなり13時30分までに終わらなくなってしまう課題があります。
  
  生産管理システムではPバッチが登録されており、13時30分までにHバッチの処理結果が入力されることが前提となっていると考えられます。今回のインシデント対応を実施した場合、13時30分以降にずれ込む可能性があるため、製造部との間で、Pバッチの実行時刻と翌日の生産計画を策定するタイミングについて事前に擦り合わせておく必要があります。
  
  また、Hバッチの終了が遅れて生産計画案の作成が後ろにずれ込むと、当日から翌日に向けた段取り・指示・資材手配など、製造現場の業務遂行に支障がでる可能性があります。このため、その影響と対策について協議を行うことが考えられます。
  
  ∴・前日の注文情報に基づく翌日の生産計画
  　・バッチ処理遅延による製造部への業務影響と対策
  
  ※模範解答では「生産部」となっていますが、本文中に記述がないため「製造部」の誤りだと思われます。
  
  
• 設問の論点は、「Hバッチ中にSメッセージ（ストレージ使用率しきい値超え）が複数回出る状況」を、従来どおり"警告"のまま扱うのではなく、どのイベントタイプに再定義すべきかです。表2には"例外"・"警告"・"情報"の3つのイベントタイプがあるので、この3つから適切なものを選択します。
  
  今回のインシデントを整理すると、まず12:40と12:50にSメッセージ（"警告"）が発生し、運用側はあらかじめ決められた対応である「バッチを手動で中断→臨時のストレージ割当→再開」の対応を取りました。しかし、その後13:00にCPUが高負荷となり、13:05による応用時間の遅延により"例外"のイベントが出力されてからようやくインシデント解決チームが編成されています。結果として、Hバッチの処理遅延と応答時間が低下が生じています。
  
  JIS Q 20000では、インシデントを「サービスに対する計画外の中断，サービスの品質の低下，又は顧客若しくは利用者へのサービスにまだ影響していない事象」と定義しており、利用者に直接の影響が出ていない段階でも、放置すればサービスに悪影響を及ぼす可能性が高い出来事もインシデントに含まれます。今回の事象を踏まえると、本来はSメッセージが複数回出力されている時点でインシデント（"例外"）として扱い、インシデントチームの編成が必要であったと判断できます。したがって、解答は「例外として設定する」となります。
  
  ∴例外になるように設定する

解説

• 〔aについて〕
  Hバッチのストレージ使用量の増加に起因する正常終了時刻の遅延を防ぐために、ストレージの増強を行うタイミングが問われています。
  
  表3には「運用チームが，ストレージ使用率のしきい値超えを示す"警告"のイベント監視のメッセージ(以下，Sメッセージという)…の出力を認識した」とあります。つまり、Hバッチのストレージ使用量の増加はSメッセージの出力により把握が可能です。このタイミングでストレージの容量を増強すれば、処理の遅延を防ぐことができます。
  
  なお、「Sメッセージを複数回認識のイベント（"例外"）が出力されたとき」という解答も考えられますが、このイベントは現行システムでのワークアラウンド的な対応に過ぎません。クラウドサービス移行後は、Sメッセージが1回出力された段階で対応することが、バッチ処理の遅延と応答時間の低下について根本的な解決につながります。
  
  ∴a＝Sメッセージの出力を認識
  
  
• Fクラウドの概要には次の説明があります。
  • 管理ツールを利用すると瞬時に…リソースが増強され，リソース増強に見合ったクラウド利用料が加算される
  • 増強されたリソースが不要になれば…元のキャパシティに戻すことができる
  Fクラウドに移行後は、Hバッチの処理中にストレージ不足の兆候（Sメッセージ）が出た場合、運用チームがリソースオンデマンド機能によりストレージを増強します。キャパシティ管理の目標は「需要を満たすのに十分な能力を計画・提供すること」ですから、Hバッチ終了後は、不要になったストレージ容量を元に戻す手順を定めておく必要があります。理由は、追加利用料や遊休リソースの発生を回避するためです。
  
  ∴実施内容＝増強したストレージ容量を元に戻す
  　理由＝クラウド利用料が加算されるから
  
  
• 〔bについて〕
  販売管理サービスの需要増加の見込みを受けて、Fクラウドの契約モデルの決定に関して見直すべき事項が問われています。
  
  A社では次の手順でキャパシティ計画を策定しています。
  1. 将来の利用計画を入手し，それを需要予測として求め，オンライン処理とバッチ処理のリソースの使用量を見積もる
  2. 見積もった使用量とサービスレベル目標値を基にキャパシティを計画する
  つまり、需要予測を基にリソースの使用量を算出し、その結果を計画に反映する流れになっています。今回の経営会議の決定により事業環境が変化し、キャパシティ計画の前提となる需要予測も変化するため、それをキャパシティ計画に反映する必要があります。
  
  見直すべき内容としては、需要予測、リソースの使用量、キャパシティ計画の3つが想定されます。ここで空欄bの直前にある「契約モデルを決定していく前提となる」という記載、また「クラウドサービスは，利用者のリソースの使用量に応じて柔軟に…追加・削除できる」点を踏まえると、3つのうち「リソースの使用量」が最も妥当します。したがって、空欄bには「需要予測に基づくリソースの使用量の見積り」が入ります。
  
  ∴b＝需要予測に基づくリソースの使用量の見積り
  
  
• 〔cについて〕
  現在のキャパシティ計画は、オンプレミス環境を前提としたものです。本文中には「C課長は，Fクラウドの導入を決定した」とありますから、クラウドサービスの利用を前提としたキャパシティ計画へ改める必要があります。
  
  オンプレミスの『固定容量＋増強は購買・入替えで』という考え方と、クラウドの『需要に応じて柔軟に容量を増減できる』という考え方では、そもそも計画の立て方が大きく異なってきます。そのため、更新ではなく、新規で両サービスのキャパシティ計画を策定する必要があると読み取れます。これは空欄c直前の「新たな」と合致します。したがって、空欄cには「キャパシティ計画」が当てはまります。
  
  ∴c＝キャパシティ計画