ITSM 心得帖・ITサービス継続性管理の心得。

さて、恒例の心得帖となります。

ITサービス継続性管理の心得です。

ITサービス継続性とくれば、計画に関する内容だという事で、障害時の対策となるのですが、
基本的に、事業継続性計画（BCP)や、ビジネスに影響するインパクト（BIA）とか、そういうものがキーワードで連想すると良いかもしれません。

災害を想定してどれだけの速さでサービス再開できるかを考えるプロセスとでもいいましょうか？

そういう意味では、AM２でよく出るキーワードとして、
災害時のサーバの状態はどうすべきかの指針があり、以下のものがあります。

ホットスタンバイ　⇒　ウォームスタンバイ　⇒　コールドスタンバイ　⇒　相互協定
＜優先度高＞←　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　→＜優先度低＞

で、
ホットスタンバイは、即時復旧なので、災害時即バックアップ切替となり、サーバクラスタなど同じ場所で切替実施で常にデータ同期されている状態。

ウォーム・・・は、ある一定期間の間で復旧とまぁ余裕があるので、災害時まではバックアップ側のデータは更新されていなかったり、不完全なものであるため、最新にしてから再開で良いので、バックアップ側は別場所にある。
あぁ、今回の問題はこれかな？

コールド・・・は、もう余裕あるので、障害後に事前にあらかじめ借りていたデータセンタとかでバックアップサーバ持ち込んで復旧させる方法。

相互に関しては、もう完全に２つサーバ持つ気なしで、同じのを他の会社間で貸し借りしてサービス回復するという物だそうです。

という事で、今回はまぁこんな感じです。
次回はセキュリティ関連問題で、よく出る感じでしかもちょっと難易度個人的に高し！かもしれないです。

まぁそのあたりはまず問題回答編でじっくりと考察してみる事にしますので、本ブログ題意解説編の再開はしばらくお待ちを、というか、問題回答編見て欲しいっす（苦笑）

僕流・高度情報処理試験・勉強日誌～ITSM（題意考察編１１）！！ H22/問1を振り返りながら

さて問題の２セレ方式で選択しなかった方の２問のうちの1問です。
そもそも２セレ方式とは、最初に問題を解くかという観点での独自の非公式な方式です。

で、今回H22では、問2と問3を選択したわけです。
なぜというと、あくまでも個人的な見解ですが、
問題冒頭の～～～に関する・・・という～～部分を抜き出し、

問１：ITサービス継続性管理

問2：可用性管理

問3：サービスデスク

問4：情報セキュリティの運用と管理

とあり、見た感じでなんとなくできそうかな？という問２と問３の選択を行った訳です。
ちなみに２問からの2択方式では、問3　⇒　問2の順に解いたわけです。

で、今回は、問1：ITサービス継続性管理となり、ITIL２０１１では以下のような位置づけです。

前回は可用性でしたので、今回も同じサービスデザインとなります。

可用性の場合は常にサービスをスタンバイさせておく感じでしたが、
ITサービス継続性は、そのサービス継続もサーバダウンなどの障害でサービスをやむを得ず、停止する場合が無いとは言い切れませんので、そんな時のための規約、制約、お約束のようなものをあらかじめ決めておくのかなぁと思います。

さて、それは一体どういうものかといいますと、僕の考えるに、今回の問題の趣旨であった、サービス停止後の復旧のお約束についての事例であったのかなと思います。、

つまり、障害が起こりサービスが停止したら、サービス停止は一体どうやって復旧させるかが観点となります。

そこで、登場するのが、RPO　と、RTO　であるようです。
あと書かれてませんでしたが、RLOというのもあり、これは問われている問題を解答する事でその意味合いを理解してるかが分かるのかなと思います。

RPOの略は、RecoveryPointObjectiveという事ですので、まぁPがPointで、点、つまり、
復旧すべき地点という風に思うと忘れないかなと。

同様にRTOのTはRecoveryTimeObjectiveという事ですから、Timeで時間、つまり、
復旧にかける時間と。

で、特に書かれていなかったRLOは、RecoveryLevelObjectiveという事で、LがLebel、つまり
復旧のレベル（度合）をどうするか？
要するに、最高レベルは、当然ですが、障害時と同じ内容で復旧。です。

とまぁこういう意味で今回の問題の題意について考えると良いのかなと思うわけです。

では、設問1を振り返ります。

ずばり、復旧する方法はどちらが良くてそれがなぜ良いのか？の理解度を見てるのかなと思われます。復旧する方法とかは恐らくいろいろあるわけですが、マネージャたるもの（という視点で常に作成されてます）それら方法についての選択理由について、RTO,もしくはRPOを意識して、RLOをきちんと決定できなくてはいけないという声が勝手に聞こえてきそうです（違ってたら怖いですが（苦笑））

で問われている解答の観点は、RTO、復旧するための時間を早くと意識する事であり、結果的にどちらでもRPO、データの内容は午前０時までのものであり、データ内容が変わらないなら早さを重視という点ではないかと思います。

次の設問2ですが、更に具体的に、データ復旧＝リストアする時間をRPOで表現させるが、３時間で復旧させるというRTOの制約にも影響するため、バックアップの転送方式をRPO,RTOの両方について協議し、どちらにも影響をしてはいけないという観点を見ているようです。


最後の設問3に関しては、障害時のサーバ切替でサービスは継続されるが、その代替サーバ機での運用に対する情報共有やデータ同期状況を可能な限り同一にすべきであり、同一でない場合はその事実やその場合の対応方法などを確立させておくべきである。という観点であるのかと思いました。

という事で、比較的、問題の内容が個人的には分かりやすかったと感じました。
なので２セレ方式で先行漏れしたのはIT継続性＝障害関連＝なんか難しそう・・・という固定概念があったからでしたが、今回に限ってはそう懸念するほどではなかったのかもしれません。
まぁ結果論ですけど・・・

次は心得帖で、問4の題意考察となり、H22年度のPM1はおしまいです。

ITSM 心得帖・可用性管理の心得。

さて、問題のしめくくり、心得帖です。

今回は・・・可用性管理の心得です。

いつでも使える状態というのは、やはり安心するなぁと思います。

ユーザ視点という感覚であるのも特徴ですよね。

まさに、お客様は神様です（古っ！）

え～、次回、乞うご期待♪

僕流・高度情報処理試験・勉強日誌～ITSM（題意考察編１０）！！ H22/問２を振り返りながら今年版のITILで考察・・・

さて、H22の問２を、問題回答編で解答し終えて何思ふかの振り返りです。
問題を一度解いたからと言って終わりでなくリピートして題意をしつこいくらい追求したら
さすがにこの問題も覚えるくらいに慣れたらいいなと思います。

◆プロローグ
まずテーマは何といっても可用性管理です。

可用性といえば・・・で、

①ユーザが使いたいときに使える状態になっている

②サービス停止をさせない

を連想！でしょうか。
まぁ②も結果的には①の状態なら問題ないだろうと思われますが・・・
可用性のキーワードでこの辺りのイメージを浮かべるようになるべきだと思いました。

で、前回のITIL2011Editionのイメージをまたここに登場させてみてみようと思います。

こうしてみると、可用性はサービスデザイン（設計）に位置しているようです。

そもそもサービスデザインとはなんなのか？も知った方がよさそうです。

ちなみに・・・
またITIL2011Editionと同じような位置づけで問題に登場するJIS Q 20000-1も同様、
のプロセスがあり、これがサービス提供プロセスに対応するという事のようです。

したがって、
ITIL2011：サービスデザインプロセス　＝　JIS Q 20000-1：サービス提供プロセス
という事になります。

矢印の最初である１番：サービスストラテジは戦略ですので、何やら戦略を練るという事ですが、その戦略に基づき、ITサービスにおいて具体的な設計を行うプロセスのようです。

という事は、可用性も、ITサービスにおいて具体的な設計を行っているようです。

◆具体的な設計について

という事で、具体的に可用性設計とは今回の問題に置いてなんだったのか？考えてみたいと思います。
まず、可用性というのは、前述の通り、サーバ停止させずにサービス提供し続ける、って感じでした。

それを調べるには問2の図1を見る事になります。
図1には宿泊予約（というのは問題的にもどうでもよいのであるが一応）システムの構成の中で、可用性設計の工夫があると思います。

それは・・・

①FW　二重化
①LB：負荷分散装置　二重化
②２台のWebサーバ１、２：振り分け　
③２台のAPサーバ１，２：振り分け

です。

まぁこのような考察は、結果的に問題解くうえであまり関係ないのですが、まぁいきがかり上プロセスでの意味合いを明確にしたかっただけです。

◆題意の考察
手っ取り早く、というと雑なイメージでありますが、こういう風に出題趣旨が書かれてました。

以下抜粋

業務システム運用に当たっては、ITサービスに影響を与えないよう、高い可用性を維持する事が重要。
本問で、
可用性の監視能力、
可用性を確保するためのシステム構成や
運用方式に関する能力、
計画的な保守時間の管理などの可用性管理能力
を問う

との事でした。

これで、なぁるほど！って言える人はもうこんなブログ見なくてどんどん先逝ってください（笑）
え？ようわからんぞ、なにをいってんのぉおおおお？？って人はこの先どうぞ（笑）

◆出題趣旨の考察（といっても勝手な所感です）

まず、可用性の監視能力についてです。
くどいようですが、可用性というのは、サービス停止せずにいつでもユーザが使いたいときに使える状態。でした。
で、そのようないつでもスタンバイOK状態かどうかを監視する能力という事かなと思われます。

といっても監視ソフトを入れて常時監視している。の、監視ではなく、
ここでは負荷分散やサーバダウン時の複数サーバ同時起動（冗長化）などを構成として考えられているかという感じに見えます。

また、そのような状態にするためのシステム構成になってるかの確認です。
で、そのシステム構成でのリスク管理というか、もし障害になってもサービス使用は大丈夫です！っていう事が言えるかって事で、LBとその配下にWebサーバ１，２の振り分けと、さらにその下に、APサーバ１，２の振り分けも考慮しているというところに気づくかという事ですね。

で、このAPサーバ１，２の他に、APサーバ３というのもあたかも同じような位置で存在する。
結果的にチャプタ〔予約方式１の処理概要〕でAPサーバ１，２が次いで、チャプタ〔予約方式2、予約方式3の処理概要〕にて、APサーバ３だけで処理されている。と、同じAPサーバでも３は単独ですよと判明する。

それで、運用方式に関する能力という点、そもそも運用というのは、チャプタ〔宿泊予約システムの運用〕というところで、運用というキーワードが出て、文の中心は、保守作業という名の、パッチ実装（変更）作業と、その前で行うフルバックアップが重要な観点となり、これが結果的に保守を行う時間帯という点で、出題趣旨である、可用性管理能力につながります。

つまり、可用性をさらに改善するために考えられた対策案が、これまた現行で可用性管理している時間帯とバッティングしてしまい、それを考慮すると対策案は破たんするという事を慎重に見抜けるかといった点、まさに冷静な判断ができるITサービスマネージャといえるのかなと思いました。

で、ここまでが設問1～設問３までの題意となります。

また最後の設問4に関しては、サービスレベルの見直しというものが発生しています。
なぜ見直し発生となったかについては、予約件数が増加したからというわけですが、
さらにもっというと、増加の引き金となったのがバナー広告なんぞ出すことにしたから
です。

つまり、サービスレベルというものは、日々の状況によって見直しが必要となり、
またサービスの運用方法などが変更されそうだと感じたら、必ず、サービスレベルが
遵守されているか？そのサービスレベルだけで現状にマッチした内容かを確認すべき
であるという事かなと思われました。

で、この考えは、次回、心得帖に記録すべき事とおもわれます。

ということで、これにて、御免。

ITSM 心得帖・サービスデスク管理の心得。

さて、今回の心得は、サービスデスクについての心得となります。

いつものように巻物にしたためて記録するでござる。



今回の問題で思ったのが、
やはりITILを意識した流れをイメージすべきであるなと思いました。

例えば、
サービスデスクで受け付けたインシデントは、
至急！サービス使える状態にすべく、解決・復旧を最優先
で頑張る。

①その場で回答可能だよといっても・・・

　①－１：暫定的な対応（ワークアラウンド）による再発あるカモ的な一時解決

　①－２：恒久的で再発はまぁないかな的な対応による恒久解決

②その場で回答不可能なのは、

　各インシデント関連スペシャリスト方面にエスカレーション

③　②での即答がダメな場合、①－１や、②による問題管理。
ただし、ここでは問題に対する原因究明だけ≪ここポイントやる。
・変更要求（RFC)

④問題管理で原因究明が終わったら、変更管理。
ここでは、以下を実施
・実装計画だけ
・影響有無（インパクト分析）←（あくまでも助言！）CAB/ECAB

⑤変更管理で承認が得られれば、リリース管理。
ここでは以下を実施
・リリース設計
・リリーステスト←ここで判明したインシデントなどをサポートデスクに報告！！
・他部署にアナウンス。周知徹底
・障害時の切戻し
・CMDBメンテ
・リリース実装

と、まぁこんな流れでインシデント発生～最高はリリース実装解決までとなるようです。

という事で、今回はここまで。

僕流・高度情報処理試験・勉強日誌～ITSM（題意考察編９）！！ H22/問３を振り返りながら今年版のITILで考察・・・

さて、僕流・高度情報処理試験・勉強日誌～H25・ITSM（問題回答編）！！において、
イメージ書いたりと結構楽しんだのですが、この問題の題意についても
ちょっと考えてみようと思います。

◆サービスデスクに関する問題の題意の前に流れを知ろう。
さて、今回のサービスデスクというキーワードについて、
やはりフローで流れを理解すべきではないかと思います。

ITILV2の時は、以下のように
サービスサポートと呼ばれるものが６つで構成されていました。
他にはサービスデリバリというものがあり、それだけでした。
ITILV3ではそれは、以下の５つのプロセスに分かれます。
サービスストラテジ
↓
サービスデザイン→サービストラジション→サービスオペレーション
　　　　　　　　　　　　　　　　　　　　　　　　　　　　↓
　　　　　　　　　　　　　　　　　　　　　　　　　　継続的サービス改善

もちろん、この年の問題はH22で、まだITILV2の考え方で良いのかもしれません。
しかしながら、今年の場合は、ITILV3で考えるのではなく、
次のUpdate改善版、ITIL2011（シラバス2011）で考えておけるようにしておくべきです。
ITILV2でもITILV3でもなく、要注意です！！

で、肝心なのは、試験範囲を記すシラバスを標準で考える必要があり、
それによると、要求される知識群には、
・JIS Q 20000 規格群（ISO/IEC 20000） 
・ITIL 
とありました。
で、このITILは、ITIL2011という事です。
もうほんと、ITLV2→ITILV3に続きITIL2011と変わりすぎではないですか？
まぁそうはいっても仕方ないので、正式には、ITIL 2011 Editionだそうです。

で、何がUpdateされたのかって事ですがまぁこの際それは置いといて。
ITIL2011イメージ書いてみます。
基本的にITILV３同様５つの構成でした。

で、図の★が、今回のキーワード：サービスデスクです。

サービスデスクの基本的な流れは上記のようだという事ですが、

一応僕が知る限り、

まずインシデント勃発→サービスデスク問合せ→一次切り分けを実施　だと思われます。

とにかくサービスデスクのミッションは、どんなことをしてもまずは障害復旧大優先で考える

事が先決であると思います。

そのための一次切り分けという事です。

◆一次切り分けへの道

ユーザから色々な問合せを一手に引き受けるのがまずはサービスデスクです。

色々な問合せが多方面に散らばらないように窓口を1本化するのも重要な事です。

で、いろいろな問合せをまとめる工夫もしておかないと乱雑な管理になってしまい大変です。

まとめる工夫という点では、今回のFAQの管理は重要となります。

つまり、色々な問合せは数はたくさんあっても同じような内容の問合せでは、今回回答した

時間よりも当然同じであるわけはなく、もっと少ない時間で回答できるからです。

そうはいっても、今受けた問合せが先ほど受けた問合せと同じような内容であればよいのですが

なかんかそうはいきません。

え～と、たしかあれは、、、、どうしたっけ？っていう風にならないために、質問に対する回答集を

手順化して登録しておけば、そういった迷いもなく、同じ質問ほど短時間回答できるからです。

しかしながら、この問合せを記録したものをインシデント記録と呼び、これらの履歴をDB化して、

キーワード検索などできれば、回答（に要した）時間の短縮も可能となります。

設問の趣旨は、キーワードだけ抽出してみると、

FAQ、インシデント履歴、対応経路、１次窓口解決という事のようで、

これらを見て、まずサポートデスクは何をするのかを理解しているか？

といったところを見たかったのではないかと思われます。

文章の中では至る所で、サポートデスクに対する役割や目標などを

事例を混ぜて説明しているようにも見えます。

問題回答編でも書いたイメージの改善版です。

結果的に、問合せに対しての回答を出すためにどうするかという点がポイントで、

回答も迅速にしなければいけないのに、色々と手順などが悪くて、改善すべき点を課題として、

現状は時間が掛かりすぎているという点に対する、回答の目標時間を設定するべきといった、

ような内容にしたかったのかもしれない。

◆題意について

という事で、今回の問題の公式サイトにて、出題趣旨を見てみます。

以下抜粋。

ITサービスにおいては、

・サービスデスクの対応が、利用者の満足度に影響を与えるので重要

・作業パフォーマンスを適切に管理することも重要

・サービスデスク業務の計画と実施を行うリーダを想定

・FAQなどのサポートツール使用に関する能力

・インシデント管理プロセスを遂行する能力

・管理指標を設定し評価分析する能力

・顧客満足度を向上していくための管理能力

を問う。

というのは、これらすべてが出題者の思いであるようで、

今回は何も言う事はないくらいの題意ではないかと思い

ましたので、そのまま抜粋させて頂きました。

次回はこれを受けての公式サイトよりのコメントから、心得を頂戴します。

ITSM 心得帖・サービスレベル管理の心得。

ITSM　心得帖　２巻。という事で、ここに記録しておきます。

今回はサービスレベル管理の心得です。

この心得帖を印刷して壁に貼るなり、枕に敷くなり（笑）、床の間に飾るなり・・・
まぁ魔除けには決してならないかもしれませんが（苦笑）

今回は、いやというほど、サービスレベルの達成しかないのかぃ！って感じでしたが、
まぁお客との合意した内容なんで、何が何でも死守してやるぞ～っていう位の心掛け
が、結果的に安心安全なサービス（システム）になるのかもしれません。

って、見たら、余白余ってしまったので、ちょっと落書きしてしまいましたが深い意味はないです。
次回からイメージは意味のあるものを目指すよう頑張ります。
（すいません）


という事で、、僕流・高度情報処理試験・勉強日誌～H25・ITSM（問題回答編）！！


でまた次回の問題から、武者修行？です（笑）。

題意考察はまたその時に。。。ですかねぇ。

僕流・高度情報処理試験・勉強日誌～ITSM（題意考察編７）！！ H24/問1・設問３を振り返って・・・

今回は問1の設問３となります。
前回のように（１）単位で１ブログの様なことが無いといいのですが・・・

■設問３（１）の題意
障害時のルール規定という事がテーマのようです。
問題も確かに、障害が発生した時問題が生じる恐れがあるが、その問題の内容を答えさせていますから。

題意を感じるのはやはり、問題が発生しそうなので、その事前対策方法は？と質問が来るのではなく、、障害が発生したらどうする？などというのでも当然なく、単なる、どんな問題か？である。

問題の内容なので、対策などを解答してはいけないというところです。

こういう類はわりとあるようで、障害が発生しそう。というのをリスクと呼び、リスクの意味を解答させるパターンのようです。

今回の場合、下線スキップ法は使えそうもないほど、下線イにしか書かれていないため、真っ先にスキップをやめて読まなければいけない機転を利かしたフットワークを必要とするなぁと思いました。
ただし、下線イに書かれているのは、対処方法、つまり、リスク対策法のため、まぁそのリスクは何なの？っていうように置き換える必要があります。

つまり、下線イのリスク対策の肝は、一部のオペレーション自動化で確認を1時間以内に改善。との事です。

で、これら対応を行わなかったら、やばい！という事なので、なにがやばくなるのか？っていう観点で考えると、自動化することで時短する事に注目すべきというフットワークが必要と思われます。
またここで、”サービスレベル目標守ってやぁ～”という声が聞こえてくるべきです。
（本当に聞こえたらちょっと怖いですが）

よって、４時間以内で復旧しますよ～などと言ってるけど、実際目標は５時間以内であるため、実質は１時間くらいしか余裕がないのに、作業後の確認で１時間30分もかかってたらNGですよ。って事で、１時間以内に改善したんだねぇっていう流れを目標達成の観点で考慮できるか？っていうのを見ようとしたのかなって思いました。

■設問３（２）の題意
今度は応答性能でありますが、確認したかった事なので、３秒応答かかったか？という点かな？と思ってしまうのですが、模範解答では、リソースの使用状況と応答時間の実測値が合ってるか？とう観点となり、文章内で、初期提供期間というキーワードサーチで、利用者数に見合ったリソースで運用を開始する方針とした。とありますが、なかなか解答のような記述になるかどうかは、？だなぁって個人的に思ったので、ちょっと深く掘り下げて考えてみました。

まず利用者数に見合ったリソースって、具体的に何のことか？です。
リソースは設問２（１）で触れたように、CPU,メモリ、およびディスク容量でしたので、これらと応答時間の関係はというと、CPU性能が低く、メモリも少なくてディスク容量がすくなければ、最悪はフリーズしてしまうかもしれません。つまりはその点を心配してるのです。
しかもフリーズしなくても応答時間が３秒を越えても、基本NG気味です。

そのため、初期提供期間の懸念するところは利用者数に見合ったリソースで運用を開始して３秒ルールが守れてるか？となり、模範解答のような言い回しができるゆに後は”慣れ”ですかね。

■設問３（３）の題意
結果的にここでもサービスレベル目標の関係ですね。
もう徹底的に、サービスレベル目標を忘れないで的な気持ちが込められていますけど、かなりしつこい感じですかねぇ。

顧客（ユーザ）の感想をアンケートで知るためにずばり、サービスレベル目標と関係してるものは、応答性能しかないのですが、もしかしたら３秒超えても満足と答えてくれるかもしれないのです。
まぁそういう点は解答ではどうでもよく、顧客が応答性のに満足してるか？をやはり知りたいし、サービスレベル目標の顧客に最も近い内容が質問にすべきという題意も含んでるのでしょうか？

という事で、淡々と？少ししたかもしれませんが、比較的ストレートに少し一般知識を文章内で一致しないかを見ながら読んでも裏切られない感じであったのではと思いました。

さて、次回は心得帖でござるが、まぁサービスレベルは達成すべし！的な事ばかりかも（笑）

僕流・高度情報処理試験・勉強日誌～ITSM（題意考察編８）！！ H24/問1・設問２（2）を振り返って・・・

え～前回からの続きですが、ちょっと焦ってきたかもしれません。
７月に入ってあと３か月とちょっとですからねぇ～
って思ったんですが、それで淡々と題意を開設してしまうと、ただの解説ブログとなって、
おもしろくもなんともないので、焦るながらもマイペースで頑張る所存です（って誰にいってるんでしょうか？）

■設問２（２）プロローグ
それでは問題のあらすじとなります。（って、やっぱり淡々としそうです（苦笑））

で、まず、ここの問題って、A社はダメなんで、B社はどうなのか？って感じでのコンペを審査する立場で考えると結構いい感じで感情移入できます。

そうするとどうなるかといいますと、まず、最初のサービスレベル目標の達成度として、リソース追加となりますが、なんと！依頼日から１営業日って・・・・なめとんのかぁって感じで、速攻でNGとなって、もうそれ以降の言葉が入ってしまわないかもしれないような内容です。

しかしです。B社にはとっておきの営業があって、A社亡き後、もうB社もだめじゃんって思わせておいて、実は、オプションがあります。そのオプションは表３の、依頼から３０分以内にできるというものです。（なんだ、やればできるのにわざとだなきっと）って思ってもまぁ達成はしてるので、とりあえず、OKとなりました。

しかしです、そのくらいなら、A社でも同じ３０分以内でしたので、まぁ達成と言っても多少金払わなければいけないし、まだこれだけでは、納得できないぞって思ってる事を察知してか、次にだめだった稼働率について、９９．９９％という恐るべし数字を提案したのです。

これはA社では到底できない数字であり、当初９９．９％と言っても結構これでも最低の値であったのに対してさらにそれを上回る値を出したので、まぁOK！採用！！！って事になったという話ですね。

■題意を考える。
結果的になぜB社にしたのか？というのではなく、なぜオプションを選択する必要があったのか？という風に問われていることを的確にキャッチしないとちょっと回答がずれる感じです。

しかも２つのオプションのうち、リソース追加の所要時間オプション選択理由だけを解答しなければいけない事は、意外なところでプチ注意な感じと思われます。

解答の仕方が、応答時間３秒を過ぎた時にどうなるからという形で回答を求めているからです。
要はオプション選択しないと間に合わないって事なんです。

題意はやはりここでもサービスレベル目標は達成するべし！！という格言を守ってますか？というところなのかなと思いました。

■解答アプローチについて
今回は、基本的に、表2と表3を見比べて解答できるのですが、どうしても気になってしまう稼働率については全く何の関係もなかったのに、問題に載せているところがプチトラップなので、そこさえ引っ掛からなければストレートに間に合わないからオプション選んだんじゃん！って思えなよいのでした。

という事で、まぁ比較的直球な感じでしたかも。

次回・設問３はどうですかねぇ。