明日が合格発表日なので、その前に自己採点結果を載せておきます。
【午前2】
結果は76点でした。無事午前は通過できていそうです。
【午後1】
61点で、だいぶギリギリのところです。最初に解いた問2はわりと正解率が良いのですが、時間が足りなくなってしまった問3は正解率が悪いです。設問3(2)などは、時間があれば解けたっぽいので、悔やまれます。やはりセキュリティ系の問題がなくなったことが、手痛いですね。
ちなみに、解答は公式を参照し、配点はTACを参照しています。
【午後2】
例によって自己採点は難しいので、論文骨子だけ載せておきます。
設問ア
ITサービスの概要
- 旅行代理店で、販売管理サービス。
- システム運用部で、設計から運用まで担当するチームリーダー。
- サービスは、8時から23時まで稼働。それ以外はバッチ処理やメンテナンスに当てている。
- システム構成は、アプリサーバ2台、DBサーバ1台
- 4名で運用。サービスデスク業務やモニタリング業務。
- クライアントサーバシステムで、利用者である営業部員は、各自のPCから専用アプリ経由でアクセスしている。
- 業務の中核となるので、SLAとして可用性99.9%以上を、営業部長と締結している。
兆候管理
- 利用者からの問い合わせ内容の分析。
- システムのモニタリング状況。
- 上記のように、幅広い情報の分析が必要。
設問イ
兆候
- 操作の応答時間に関する問合せが増えている。
- 原因として、一時的なネットワーク負荷上昇を考えたが、システム資源のモニタリングには異常なし。
- 問合せ内容は、データベース化しメタ情報を付与して管理している。そこから、過去の問合せ履歴を分析した。すると、9か月前に似た問合せ傾向あり。
- 上記の理由から、操作の応答時間に関する問合せを、兆候と認識した。
対策
- 前回の原因は、アプリサーバのミドルウェアの設定値ミスによるDBサーバの過負荷。
- 今回も同原因を疑いメンバに調査指示したが、設定値に異常なし。システム資源の異常検知もなかったので、別問題と考える。
- 追加調査の結果、ミドルウェアのバグ情報がつい先日上がっており、それが原因と判明した。
- パッチ適用により現象改善。問合せも来なくなったので、改善したと判断した。
設問ウ
効果的な兆候管理の工夫
- 利用部門や開発部門と連携する。今回の兆候の問題も、利用部門の情報がトリガとなり、開発部門に関連する内容が解決策となった。
- 幅広い情報を集めて分析することで、より効果的な兆候管理に繋げていく。
仕組みの改善
- 問合せによる兆候検知はある意味問題が利用者に顕在化していると言える。
- システム資源の状況から、兆候を読み取る診断スクリプトを用意し、さらに事前に兆候を検知できるようにしたい。
コメント
合格おめでとうございます。
論文骨子を拝見しましたが、必要な点を網羅できており、確かに合格に足る内容でした。
↑失礼しました。
名前を失念していました。
Cobby22cです。
To: Cobby22c さん
ありがとうございます!
前回いただいたコメントを活かすことができました。
どうしても自分では見落としてしまう部分があるので、
第三者視点はありがたいですね。