［製品レビュー］ 中小規模システムのライフサイクル管理を実現するSystem Center Essentials 2007 第1回　System Center Essentials 2007によるデスクトップのライフサイクル管理 2．デスクトップのライフサイクル管理（2） マイクロソフト株式会社 IT Pro エバンジェリスト 安納 順一 2007/10/18

ソフトウェアの展開

　デスクトップを使用するユーザーは、業務を遂行するためにソフトウェアを使用する。そのために、システム部門では常に最適なアプリケーションおよび業務プログラムがインストールされているかどうかを把握しておかなければならない。例えば新しく開発した業務プログラムを展開する場合、その前提条件となるソフトウェアの展開も必要となる。この分野は専用の製品もあるほど細かな制御への要求が発生しやすく、高機能な運用管理製品はそれぞれに特徴的で魅力的な機能を保持している。しかしながら、そうした機能が操作と運用を煩雑にしている面もあり、中小規模のシステムにおいては突発的な配布に対応できる程度の機能で十分であろうと考えられる。ソフトウェア展開タスクの遂行プロセスは以下に示すとおりとなる。

■手順1．インストールされているソフトウェアの把握
　 インストールされているソフトウェアの把握は、最初のタスクである「環境の評価」で随時行われていなければならない。いざソフトウェアを配布する段階になってあわてて調査するようでは手違いも起こりやすくなるため、日々の運用が重要になる。

■手順2．必要なソフトウェアとハードウェアの判断
　 業務プログラムの実行環境となるソフトウェアは、手順1で収集した情報をベースに判断する必要がある。完全に自動化するには、配信するプログラムに前提条件を付加し、配信時に搭載メモリのチェックやディスクの空き容量、各種プログラムやファイルのバージョンなどをチェックする機構が必須である。しかしながら、こうした機能を保持している管理ソフトは高価なことが多く、操作も複雑になりがちである。費用対効果を考えた場合、チェック機構は必須機能であるとは考えにくく、収集したログをマクロやスクリプトで判断するのが現実的であろうと思われる。

■手順3．インストール・パッケージの作成
　 このタスクの目標はソフトウェアの自動インストールだが、大部分のソフトウェアはインストール時に何らかの応答が必要になるため、自動化の仕組みを検討しなければならない。Office systemをはじめとして、最近では自動インストールを実施するための機構が組み込まれたソフトウェアも増えてきたが、業務パッケージにおいても無人インストールを想定したインストーラを作成しておく必要がある。Visual Studioを使用して開発している業務であれば、標準機能でインストーラを作成することができる。

　このほか、配布ポイントについても考慮が必要だ。配布ポイントとは、インストール資源の格納場所のことである。大容量のソフトウェアを配信する場合、DVDイメージをまるごとパッケージとして配信することはナンセンスであるといえるだろう。インストールの開始に必要なバッチ・ファイルのみを配布し、実際のインストールはネットワーク上に用意された配布ポイントを使用するといった方法も検討しておくべきである。

■手順4．ソフトウェア配信の承認
　 ソフトウェアを配信する場合、どこに配布するかを事前に決定する必要がある。無条件で配布することもあるだろうし、ライセンスを考慮しつつ特定の部門のみに配布することもあるだろう。ただし厳密なチェックを行うようなワークフローは、運用管理製品の価格が高くなるほか、かえって操作を煩雑にしてしまう。事前に配布グループを作成しておく程度の機能があれば十分であると思われる。配信を承認するに当たり、意外と面倒なのは利用者との合意であろう。いつからいつまでの間に配信が行われる旨を徹底しておかないと、思わぬ業務遅延のもととなり得るので気を使わなければならない。

■手順5．ソフトウェアの配信
　 ソフトウェアの配信には2通りの方法が考えられる。プッシュ型とプル型だ。プッシュ型とは、管理部門がソフトウェアのインストールを強制するものであり、「即時」「起動時」「時刻指定」といった、いくつかのトリガーでインストーラを起動する。管理者の意思で開始できるため確実な配布が可能ではあるが、起動や業務プログラムの速度低下や、意図した時間にクライアントが起動していないなどの問題が考えられる。プル型とは、利用者がインストーラアイコンをダブルクリックするなどしてインストールを開始するものである。起動トリガーが利用者のアクションとなることで、確実な配信が妨げられる可能性があるが、管理部門との関係と利用者の精神的な安定を維持することができる。

　どちらの方式がベストであるかは、企業の文化や管理部門の位置付けにより変わってしまうが、少なくとも次のような運用が可能であれば管理部門と利用者両方の立場を立てることができるだろう。

• 期限付きで利用者トリガーによるプル配信
• 期限が過ぎたら管理部門からの強制プッシュ配信

■手順6．配信の確認
　 配信が正しく行われたかどうかを確認するには意外に時間を要する。各クライアントの保有者に内線電話で確認するなどという行為はお互いのコストを増やすことにもなるためあり得ない。かといって、進ちょくが細かく記されたレポートを読むのも面倒だ。1番目のタスクである「環境の評価」を利用し、怪しいと思われるクライアントについてのみ対策を講じればよいだろう。コストを削減するには「うまくいかなかったコンピュータのみに目を向ける」ことが重要だ。（暴言とはとらえていただきたくないのだが）「うまくいったように見えている」ものは、たいていの場合「うまくいっている」ものだと割り切るのも必要なことだ。

修正プログラムと更新プログラムの管理

　マイクロソフトとしてはあまり声高にはいえないが、システムを適切に動作させるには、適切なタイミングで更新プログラムを適用する必要がある。現在ではWindows UpdateやMicrosoft Update、自動更新などを利用すれば、更新プログラムはほぼ自動的に適用することができるようになっている。最近では、サード・ベンダのドライバもアップデートできるようになり、以前と比べて便利度が増した。クライアント数が多く、Windows Update による通信がビジネス上のネックとなる場合には、Windows Server Update Service（WSUS）による社内専用サーバを設置することも可能だ。

Windows Server Update Serviceの管理画面

Windows Server Update Service（WSUS）を利用すれば、必要なセキュリティ修正プログラムや更新プログラムなどを、自動的にデスクトップへ配布、適用できる。

　ただし、これはあくまでもマイクロソフト製品およびパートナー・ベンダの製品に限ったことである。業務の修正プログラムは、当然のことながらマイクロソフトからは提供されないため、必要に応じて修正プログラムを作成し配布する必要がある。すなわち、運用管理ソフトには、マイクロソフト製品の更新プログラムを配布する機能に加えて、独自の修正プログラムを配布する機能が求められる。

　また、「適切なタイミング」についても検討しなければならない。例えば業務プログラムの中にはマイクロソフトが提供するService Packとの不整合で動作が不安定になるものもあるかもしれない。そうした事態を想定して、事前に検証を要する更新ファイルもあるだろう。かといって、すべての更新プログラムの動作検証を待っていたのでは、時間もかかるし、その間の安全性を脅かす可能性もある。よって、緊急を要する更新プログラムは即時配布を行い、機能を変更するものや緊急性を要しないものについては業務プログラムの動作検証を待ってから配布を開始するのがよいだろう。運用管理ソフトには、修正の種類によって適用のタイミングを設定できる機能も必要になる。

デスクトップの監視

　これまでのタスクはどちらかといえばクライアント中心のタスクであったが、監視となるとサーバが主となる。システムを継続的に監視することはシステムが適切に動作しているかどうかを判断するうえで必要なことである。仮に、継続的に監視する時間が取れないとしても、後で追跡することを考慮し、ログを蓄積することはシステムの運用管理上必須である。

　監視タスクにおけるコスト削減のポイントは、3つ考えられる。1つ目は「適切なログの自動蓄積」。2つ目は「信頼できるアラートの生成」。そして3つ目が「適切なアクションの提供」である。いずれも、単なる「自動蓄積」や「アラートの生成」ではないことに注意していただきたい。必要な情報を必要なだけ蓄積し、かつ必要なタイミングで可視化することが重要となる。

■ポイント1――適切なログの自動蓄積
　 ログを蓄積することは、実はさほど難しくない。Windows OSにはイベント・ログのほか、パフォーマンス・モニタによって各種プロセスの詳細な状況をロギングする機能が用意されている。市販のアプリケーションを使用してさまざまなイベントを取得することも可能だ。問題は、その中のログが本当に役に立つのかどうかという点である。ただやみくもにログを蓄積することはたやすいが、大量すぎるログは資源を圧迫するし、追跡の邪魔にもなる。よって、サーバにインストールされているソフトウェアやサービスから、必要なカウンタ値のみを選別して蓄積できる機能は、監視のコストを削減するだけでなく、管理者のナレッジ（知識）を大きくサポートすることになる。

パフォーマンス・モニタ

システム（特にサーバ）の状態を継続的に監視するには、このパフォーマンス・モニタなどの利用が欠かせない。

■ポイント2――信頼できるアラートの生成
　 パフォーマンス・ログやサービスの状態は目で見ることができるため、知識さえあればシステムに何が起こっているのかを判断することができる。しかしながら、その「知識」がネックとなって正しい監視ができないことが多い。マイクロソフトがWebサイトなどを通じて提供しているドキュメントは膨大であり、かつその中には英語でしか提供されてないものもある。多忙なシステム管理者にとって、それらを読破することは明らかに不可能であり、それは今後どんなに業務が改善されたところで実現は不可能だろう。そもそも、「各サービスがどのような状態ならば問題である」などといったナレッジは、それぞれの開発者が一番よく知っているのだから、最初からシステムに組み込んでおいてほしいと思うのは筆者だけではないはずだ。信頼できるアラートとは、管理者が暗中模索することなく、システムが自ら発する警告のことである。こうした要望の実現は、ハードウェアの分野では実現されているものが多く、多くのサーバ機器では、CPUやメモリの状態などを検知してアラートを発する機構を備えている。管理者の負担を低減するためには、ソフトウェアにもこうした機能が望まれている。

■ポイント3――適切なアクションの提供
　 仮に各種サービスがアラートを自動的に出すことができたとしても、それだけでは十分ではない。「だからこうしろ」という指針が示されなければ、結局は現場のエンジニアが苦労することは目に見えている。確かに、同じアラートであってもシステムによって対処方法は異なるかもしれない。それでも一定の指針が提示されれば、やみくもに調査を行うよりはるかに容易に問題を解決することができるだろう。適切なアクションは、信頼できるアラートとともに提供されるべきものであるが、もしシステムに適切なアクションではなかった場合には、ローカル・ルールを追記する機能もあるとよい。スーパー・エンジニアがスーパーたるゆえんは、どれだけ不測の事態への対応力を持っているかで測られることが多い。ただし、その対応内容が引き継がれることは少なく、エンジニアの世代交代によって同じ苦労を繰り返すことになる。アラートに対応した作業内容を追記できる機能は部門のナレッジ蓄積であり、長期的に見れば人材育成のコストを削減することにもなる。

　以上3つのポイントは、既成のサービスやプロダクトに適用されるだけでは十分でない。例えば、独自のWebアプリケーションを構築した場合やサービス・プログラムを開発した場合には、その監視も必要となる。しかしながら、コツを知らなければ適切な監視が行えないというのでは本末転倒だ。そこで、既成のサービスに適用される監視項目がテンプレートとして提供され、それを業務アプリケーションにも適用できれば監視をスムーズに開始することができるだろう。

INDEX
	［製品レビュー］中小規模システムのライフサイクル管理を実現するSystem Center Essentials 2007
	第1回　System Center Essentials 2007によるデスクトップのライフサイクル管理
	1．デスクトップのライフサイクル管理（1）
	2．デスクトップのライフサイクル管理（2）
	3．System Center Essentials 2007の機能概要

製品レビュー

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）