ITサービスマネージャ 2016年 午後1 問02

解答の導き方

1. 問われているのは、監視システムがインシデントとして検知するためのしきい値を、SLAの目標値とどのような関係に設定するかです。
2. 本文には、しきい値に「各サービスのSLA項目の目標値を設定」しており、オンライン応答時間がそのしきい値を超えるとインシデントとして検知するとあります。つまり、しきい値が目標値と同じ場合、SLAの目標値を超えた後に検知されます。
3. これでは、検知した時点で既にSLA違反となっている可能性があります。違反になる前に状況を確認し、対策を取れるようにするには、しきい値をSLAの目標値より低く設定する必要があります。具体的にどれだけ低くするかは本文からは決められないため、目標値との大小関係を答えます。

誤りやすいポイント

• しきい値をSLAの目標値と同じにすると、目標値を超えてから検知することになります。
• しきい値を目標値より高くすると、検知がさらに遅れ、SLA違反の予防につながりません。
• 変更するのは監視上のしきい値であり、SLAの目標値そのものではありません。
• 本文に設定値を決める情報はないため、具体的な秒数ではなく、目標値より低くするという関係を示します。

FAQ

解答の導き方

1. インシデントが起きた時間帯の負荷を確認します。顧客管理サーバのCPU使用率は、10～11時に全体で95%となっています。この時間帯はオンライン処理件数が集中するピーク時間帯であり、オンライン応答が遅くなったことと、サーバのCPU負荷が高くなったことが結び付いています。
2. 負荷の内訳を見ると、10～11時には受注分析サービスのバッチ処理もCPUを45%使用しています。受注分析サービスは毎日9時に処理を開始し、現在は完了までに1時間30分掛かるため、処理が10時台にも続いています。つまり、オンライン処理が集中する時間帯にバッチ処理が重なり、サーバのCPUを圧迫しています。
3. そこで、暫定対策として受注分析サービスのバッチ処理開始時刻を11時に変更します。これにより、オンライン処理件数が集中する10～11時とバッチ処理の重なりを避けられます。また、処理時間が1時間30分のままであれば、11時に開始しても12時30分に完了するため、SLAの目標である毎日13時までにも間に合います。

誤りやすいポイント

• CPU使用率が高いことだけを述べても、具体的な暫定対策にはなりません。CPU負荷の原因となっている処理を特定します。
• 顧客管理サーバのキャパシティ増強は根本対策ですが、増強には時間が掛かるため、この設問ではすぐに実行できる暫定対策を答えます。
• バッチ処理を遅らせるだけでなく、受注分析サービスのSLAである毎日13時までの完了を守れるかも確認します。

FAQ

解答の導き方

誤りやすいポイント

• 問題の原因をオンライン処理だけに求めないことが重要です。表2では、受注分析サービスのバッチ処理も10～11時にCPUを使用しています。
• CPU使用率の合計だけでなく、サービス別の内訳を確認します。10～11時はオンライン処理分が50%、受注分析サービス分が45%です。
• 暫定対策の効果は、サーバのCPU能力を増やすことではなく、処理時刻をずらしてピーク時の負荷の重なりを避けることにあります。
• 「分散」は複数のサーバに処理を振り分ける意味ではなく、ここでは負荷が集中する時間帯を分けることです。

FAQ

解答の導き方

1. 下線（ア）では、キャパシティ計画の変更に先立ち、「サービスの需要」と「達成されているパフォーマンス」の状況を調べます。つまり、需要を表す情報と、実際の性能を表す情報の両方が必要です。
2. 需要については、本文に「将来の需要の予測が必要」とあります。インターネット受付サービスで、サーバにどれだけの処理が発生しているかを把握する指標が、サーバの処理件数です。その件数が時間とともにどう変化しているかを確認すれば、需要の増加傾向を捉えられます。
3. パフォーマンスについては、本文に「オンライン応答時間は、SLA項目の目標値は達成しているが、サービス開始時に比べて悪化している」とあります。目標値を達成しているかだけでなく、実際のオンライン応答時間がどう推移しているかを調べる必要があります。
4. さらに、インターネット受付システムはWeb型で、「主にサーバの処理能力がパフォーマンスに影響を与える」とされています。そこで、サーバの処理件数とオンライン応答時間の推移を合わせて調べれば、需要の増加と性能の変化を把握し、将来の需要を見越したキャパシティ計画の変更につなげられます。

誤りやすいポイント

• SLAの目標値を達成していることだけで判断しないようにします。目標内でも、サービス開始時に比べて応答時間が悪化しているなら、性能の推移を調べる必要があります。
• CPU使用率だけを調べるのではなく、設問が求める「需要」と「パフォーマンス」に対応する情報を選びます。需要は処理件数、パフォーマンスはオンライン応答時間で捉えます。
• 現時点の値だけでなく、値の推移を確認します。推移を見ることで、需要の増加や応答時間の悪化の傾向を把握できます。

FAQ

解答の導き方

1. この設問では、キャパシティ計画を変更するときに、監視データ以外で必要な情報と、その入手先を考えます。
2. 本文では、監視データによってオンライン応答時間などの実績を確認できる一方、キャパシティ計画の策定では「現在及び将来のサービスに対する需要とサービス利用者の見通し」からデータ処理量の増加を見積もるとしています。監視データは現在のパフォーマンスを把握する材料ですが、将来の需要や利用者数の見通しは、監視データだけでは分かりません。
3. また、その需要と利用者の見通しは「営業部門から入手した」と記されています。したがって、計画変更に当たっては、営業部門から将来のサービス需要とサービス利用者の見通しを入手します。

誤りやすいポイント

• オンライン応答時間やCPU使用率など、監視データから分かる実績だけで計画を変更できると考えることです。将来の需要を予測する情報も必要です。
• 情報の入手先を情報システム部門やサービス利用者とすることです。本文では、需要と利用者の見通しの入手先を営業部門としています。
• 「将来の需要」だけに注目し、サービス利用者の見通しを含めないことです。どちらもデータ処理量の増加を見積もるための情報です。

FAQ