<< November 2018 | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 >>
<< アイテック 合格ゼミ | main | いる資格いらない資格 2010 >>

ITサービスマネージャ 午後1解答の見直し

合格発表まで、あと1か月を切った
アイテックやタックの解答例と違うところを中心に見直しをしておく。

問2
設問1(1)
私の解答:基準値を超えるとパフォーマンスの急激な悪化のおそれがあるから
アイテック:基準値に近づきつつある状況を知って早めに対応するため
タック:パフォーマンスが悪化する前に検知し、適切な対策を取るため

私の解答では、設題に答えられていない。アイテックやタックの解答が妥当である。

設問1(2)
私の解答:負荷分散装置のリソースが十分であるかの計測・監視がなされていない。
アイテック:負荷分散装置やインターネット回線のキャパシティを考慮に入れていない
タック:オンラインレスポンスの遵守率について、警告値による監視を行っていない

「キャパシティ計画の方針に照らして、考慮不足の内容を答えよ」という設題である。〔キャパシティ計画〕の(3)に、「リソース面では、ITインフラストラクチャの個々の構成要素の使用状況について定常的に測定・監視を行う。」とあるにもかかわらず、表2では、負荷分散装置のリソース管理を行っていないので、これが考慮不足と考えられる。
アイテックの解答のように、インターネット回線についても記述すべきかどうかだが、〔キャパシティ計画〕の(3)では、後半で、「必要に応じてハードウェアやソフトウェアのリソースを増強する」との記述があることから、インターネット回線については解答に含めるべきではないと考える。
タックの解答は、設題趣旨に合致していないだろう。

設問1(3)
私の解答:変更を行う際に、キャパシティ面の問題がないか検討する。
アイテック:予測に基づき必要となるリソースの増強策を提案する。
タック:ハードウェアやソフトウェアのリソース増強の変更要求を提案する。変更実装後のパフォーマンスを測定し、変更のレビューに役立てる。変更管理に出された新たな変更要求に対するリソース見積りを行う。

変更管理のプロセスと連携して行うべきことが2点あり、1点が「パフォーマンス改善の変更要求を提案する」という「キャパシティ管理」から「変更管理」への提案であるので、その逆の「変更管理」から「キャパシティ管理」への要求に対して対応することであると考えた。ただ、私の解答では、キャパシティ面での問題があった場合は、「変更不可」という結果になってしまうので、「変更要求に対してリソース見積を行う」旨のタックの解答が妥当と思う。
アイテックの解答は、「予測に基づき」の部分が、変更要求についてのものかが不明確である気がする。

設問2(1)
私の解答:片寄せ運用の際にバッチ処理を実行しても、必要なオンラインレスポンスが確保できるか
アイテック:片寄せ運用を行った場合における運用変更後のピーク時オンラインレスポンス性能
タック:片寄せ運用でのオンライン業務中にバッチ処理を実行しても問題がないかどうか

片寄せ運用とでもピーク時のトランザクション予測値を処理できるように計画されていたが、運用を変更してバッチ処理が重なったためにレスポンスが悪化したので、片寄せ運用とバッチが重なった際に問題がないかを確認すべきであった。
アイテックの解答では、バッチ処理が重なったことについて記述がなく、不適切だろう。

設問3(2)
私の解答:販売管理システムの運用変更によるピーク時のトランザクションの平準化の検討
アイテック:販売キャンペーン実施に備えてキャパシティ確保のために必要なリソースを増強する。
タック:変更後の予測値に基づいて性能テストを実施し、必要に応じてリソースの増強を行う。

キャパシティ管理の項目として、需要管理があり、ここではそれが問われているのだと思いこんでしまった(販売キャンペーンは1年間に2回だけだということも、その予断を後押しした)。しかし、D社のITサービス部にその権限(需要をコントロールする)が与えられているとの記述はなく、私の解答は不適切である。
〔キャパシティ計画〕(1)「ITサービスに対するビジネス要件を検討し、キャパシティを確保するために必要なリソースを適切なタイミングで実装する。」に基づき、設問3(1)で「キャンペーン実施に伴うトランザクション数増加を予測」し、設問3(2)で「必要なリソース増強を行う」のが、妥当である。性能テストは必須でないと思われるので、アイテックの解答が適切と思う。

問3
設問1
すでに述べたとおり。
ただし、7人と考えられなくもないと言うだけのことで、JITECの用意している解答は12人だろう。
あと、今回読み返してみて、「各チームの余裕というのは出勤するのか否かがどちらともとれるな」と思った。
私は、「余裕の人間は出勤なし。出勤予定者が休みの時や、ピーク時の時だけ出勤する(この場合のピークは「月末」とか「○月」とかの期間を指す)」と解釈していたが、「余裕の人間も出勤する。1人休んでも仕事は十分回せる(ピーク時というのは「○時」とかの期間を指す)」と解釈することもできる。後者の場合は、7人という答えはあり得ないだろう。

設問3(2)
私の解答:しきい値超過のうち、ジョブ制御や臨時処理を要するメッセージ
アイテック:CPU使用率のしきい値を実情に合わせて緩和できる可能性
タック:CPU使用率のしきい値が適正な値に設定されているか

しきい値超過のメッセージが出たもののうち、ほとんどが「連絡だけ」で対応がすんでいることが表から読み取れる。また、「連絡だけ」ですんだのは、ほとんどがCPU使用率のしきい値超過メッセージである。このことから、一見、CPUのしきい値の設定が適切でなく、これを見直すことで、「連絡だけ」の対応が削減できると考えられる。
ただし、運用管理者に連絡した場合、運用管理者がどのように「ジョブ制御や臨時処理は必要ない」と判断しているかは、問題中からは判断できない。例えば、「CPU使用率のしきい値を70%に設定してあるが、75%まではジョブ制御や臨時処理は必要ない」という状態であれば、しきい値を75%に変更するだけで、問題なく出力メッセージの対応工数を削減できる。しかし、「○時〜○時の間は70%を超えても異常でないので問題はないが、その時間以外は問題である」とか、「○○処理が実行されている際は、70%を超えると問題がある」などの場合は、単なるしきい値の変更では対応できない。
したがって、「本当に対応が必要なCPU使用率のしきい値」というような解答は不適切であると思う。アイテックやタックの解答も、現在のCPU使用率のしきい値が不適切であるとは断定できていないように見受けられる。ただ、それ故、調査した結果、「緩和できる可能性がなかった」とか、「適正な値に設定されている」という場合には工数が削減できなくなってしまう(私の解答でも、「メッセージだけでは判断できない」場合、工数が削減できないのだが)。
これらのことを踏まえると、正しい解答は、「しきい値超過のメッセージが出力された場合、対応が必要な条件」といった感じになると思われる。

設問4
私の解答:バックアップを磁気ディスク上に取得することとし、遠隔地への保管はファイル転送により行う。
アイテック:バックアップ取得作業を夜間バッチ処理終了後に移動し、1人のオペレータで処理できるようにする。
タック:20時からのバックアップを1人で磁気ディスク上に取得し、それを予備時間に1人で磁気テープに移す。

この問題では特に記述されていないが、バッチ処理時に障害が発生した場合、バックアップから復元する場合がある。オンライン終了後にバックアップを取得するのには、そういう意味があるのはシステム運用技術者として当然想定しておかなくてはいけない。したがって、アイテックの解答は不適切。
システム変更やバッチ処理のトラブルなどへの対応のため、予備時間が確保されている。オンラインサービス提供時間を拡大した際でも、予備時間は維持するようにした。したがって、予備時間に作業を設定するタックの解答は不適切である(アイテックの解答も×)。
問題を整理すると、
設問3までの対策を講じた結果、9時〜20時はオペレータ1人、21時〜6時も1人。20時〜21時のバックアップ処理は2人の体制になってしまっている。その上で、省人化を目指すのだから、バックアップ処理は1人で行うしかない。また、20時〜21時の間に作業を行うのは、すでに述べたように、オンライン終了後バッチ開始までの間に取る必要があること、予備時間に作業を設定してはいけないことから、変更することはできない。
1人で1時間を実現するためには、磁気テープでなく磁気ディスクにバックアップを取得するしかない。また、磁気ディスクから磁気テープに書き出す時間も当然ないので、その他の手段で配送するしかない。ファイル転送の仕組みがあることは設題中に示されているので、それを使用するとしか考えられないのである。

以上を踏まえると、得点は65前後といったところか。
ss2004 * ITサービスマネージャ * 22:33 * comments(0) * trackbacks(0)

コメント

コメントする









トラックバック

このページの先頭へ