システム管理とは、共通で使われている稼働中の設備を円滑に運用するために行なう仕事である。 管理というよりは、世話という気がする。事実、このページのエスペラント名には、 zorgo という「世話」を意味する単語を当てている。
ITIL, JIS Q 20000-1も参照のこと。
システム管理の試験は何回か受けたが落ちた。IT サービスマネージャに名前が変わったので、 この試験の午前Ⅱ問題を集めてみた。
対象者像は、次の通りである。 「高度IT人材として確立した専門分野をもち、 情報システム全体について、安定稼働を確保し、障害発生時においては被害の最小化を図るとともに、 継続的な改善、品質管理など、安全性と信頼性の高いサービスの提供を行う者」
役割と業務は次のようである。
「ITサービスの品質とコスト効率の継続的な向上を目的としてITサービスをマネジメントする業務に従事し、次の役割を主導的に果たすとともに、下位者を指導する。」情報処理技術者試験では、(以前規定されていた)システム管理担当者は、テクニカルスペシャリスト「システム管理」で 役割と業務を次のように規定されていた。
情報システム基盤(業務システム共有のシステム資源)を企画・構築・運用する業務に従事し、 次の役割を果たす。
以下、内容を考えよう。
構成管理とは、情報システム基盤を構成する各種コンピュータのハードウェア、 ソフトウェア、ネットワーク、設備の「もの」とその連係を明らかにすることである。
そんなの当り前じゃないか、と思うでしょう。なかなかその当り前ができないのだ。 みなさんは、自分の持ち物をすべて列挙できますか。どこにあるかわかりますか。 買ってから何年立っているかわかりますか。 私は、胸を張って「わかりません」と言える。 しかし、システム管理の世界では、そのような開き直りは許されない。
こんな例があった。あるシステムは、コンピュータA、コンピュータB、コンピュータC の 3つからなっている。コンピュータA はバックアップ装置P に、 コンピュータB とコンピュータC はバックアップ装置Q につながれている。
+------------+ +----------+ | Computer A +---+ Backup P | +------------+ +----------+ +------------+ | Computer B +-+ +------------+ | +----------+ +-+ Backup Q | +------------+ | +----------+ | Computer C +-+ +------------+
あるとき、システム管理者がコンピュータAのバックアップが取れない、 といって悩んでいた。結局構築時の業者に来てもらったら、あっけなく原因がわかった。
コンピュータAのバックアップは取れていた。ただ、システム管理者が気づいていなかった。 気づかなかった理由は、 システム管理者はコンピュータAのシステムはバックアップ装置Qが取るものとばかり、 思い込んでいた。なぜそういう誤った思い込みがあったかというと、次の理由があった。 バックアップ装置Qは、以前はコンピュータAのバックアップ装置であり、 システム更新時に新たにバックアップ装置Pを購入し、コンピュータAに付け替えた。 そして、付け替え担当者は構成管理情報にこの付け替えを記していなかったのである。 システム管理者は、この事情を知らずに引き継いだ。そこで、先の事件が起こった。
ということでシステム管理の試験を受けたのだけれど、不合格だった。 また出直そう。
障害は勤務先の人生でずっとつきまとう。最初から最後まで障害だらけだ。花の障害とか、障害現役とか、障害学習というぐらいである。 このような誤字はよいとして、障害管理はひとたび障害が起こったとき、他に影響を与えないよう、早期の復旧ができるようにする管理である。 もっとも、他に影響を与えないとか、早期の復旧とかは相対的なものだが、心がけとしてはそういうものです、ということである。 最近は「インシデント管理」というなまえになっている。紛らわしいのは、問題管理との棲み分けだ。問題管理は根本的な解決だったり、予防策の考案だったりするのだが、 障害管理は障害が出ることが前提となっていることなので、根本解決や予防策は二の次、三の次なのだ。
かつて、こんなシステムがあった。500 人が使う WEB システムで、ときどき「他の人が使っています。管理者に連絡してください」というエラーが出ていた。 このシステムは、競合状態を回避するしくみを持っていなかったのだ。そこで競合状態が出ると必ず上記のエラーを表示していたというわけだ。 競合を回避するしくみはシステムレベルの改造を必要とするので、根本解決はできなかった。わたしは管理側だったから、 上記のエラーが出てきたという連絡があれば、まず競合が起こっているかを疑い、実際起こっていたら競合状態を解除するという操作をただしく行なえるよう、 マニュアル化した。 競合エラーを生じたそのときに電子メールなどで連絡できればいいのだろうが、そのような融通ができるシステムならそもそも競合状態を回避することなど当たり前にできるだろう。
このエラー連絡を受けるたびに、開発側でよくいうセリフ「運用でカバーします」を思い出す。
自分のはずかしい障害管理を例にだそう。私は全文検索システムNamazu を自分のページで運用しているのだが、あるときからページ更新が反映されていないことに気づいた。 調べてみると、ある文書フィルターがエラーとなっていてそれから先に進めないことがわかった。なぜそのエラーが起きたのかわからない。ただ、 その文書は私のページには使わないタイプであることは確認した。そこで、そのフィルターを適用しないことにしてサービスを再開した。
今では性能ということばよりパフォーマンスということばのほうがなじみがあるのかもしれない。 IT サービスでは、レスポンスタイムやバッチ処理時間に気をつけないといけない。 時間に影響を与えるものとして、CPU 使用率、磁気ディスク使用率、通信回線使用率などがある。 運用側の努力や工夫でなんとかなるものもあれば、どうしようもないものもある。
あるとき、運用管理のかたがこぼしていたことがある。あるサービスを提供するにあたって、そのサービスを提供することは容易なのだが、 そのサービスに付随して発生する課金管理が難しいのだそうだ。
今の試験ではあまり課金管理については意識する必要はなさそうだ。
今は情報処理安全確保支援士があるのでこちらは対策がなおざりにされやすいのだが、運用からのアプローチとしてまだまだ考慮しないといけないだろう。
最初に受けたのは10年前。午後1まで通ったが、午後2の論文はB判定だった。
次に受けたのは 2017 年 10 月。午後Ⅰの得点が恥ずかしいほど低い。 棒高跳びに例えると、体がバーに触れて、バーが揺れていたがかろうじて落ちなかった、という状態だろう。 まあ「何で勝っても勝ちは勝ち」。
午前Ⅰ得点 | 81.60点 |
午前Ⅱ得点 | 80.00点 |
午後Ⅰ得点 | 62点 |
午後Ⅱ評価ランク | A |
満点,合格基準は次のとおりです。 |
||
---|---|---|
時間区分 |
満点 |
基準点 |
午前Ⅰ試験 |
100点 |
60%以上
|
午前Ⅱ試験 |
100点 |
60%以上
|
午後Ⅰ試験 |
100点 |
60%以上
|
午後Ⅱ試験 |
- |
ランクA |
評価ランク |
内容 |
---|---|
A |
合格水準にある |
B |
合格水準まであと一歩である |
C |
内容が不十分である |
D |
出題の要求から著しく逸脱している |
まりんきょ学問所 > コンピュータの部屋 > システムの部屋 > システム管理