チェンジ・マネジメントの自動化を促進せよ──IT環境の変化に効率的に対応するために

現行プロセスを見直し、効率性・管理性・監査性を再検証する

（2006年07月24日）

　「万物は“変化する”ということだけが“不変の”真理である」という格言がある。だが、複雑なIT環境においては、安易な変化が大惨事の引き金になることもある。事実、IT関連の調査会社であるIDCやガートナーの報告によると、IT関係のトラブルの70パーセントから80パーセントが、環境に加えられた変更を直接的な原因にしていたという。

ジョアン・カミングズ
Network World 米国版

問題を生じさせないために

　JPモルガン・チェースで分散コンピューティングのグローバル・ヘッドを務めるマーク・イーサリングトン氏は、そうした“IT環境に加える変更”を指揮する1人である。

　同社では、3,000台のサーバが稼働する環境において、実に毎月数千件もの変更を施しているという。というのも、月末あるいは期末にシステムを停止して、最適化のための変更を行うというのは、同社のような金融機関にとって、ある種、避けることのできない行為だからだ。

　「実行環境において処理能力が著しく低下した場合、システムを停止して変更を加える必要が生じるわけだ」とイーサリングトン氏は説明する。

　「その際、われわれは常に究極の二者択一に迫られることになる。それは、可用性を維持するために変更自体を極力避けるようにしたほうがいいか、それとも膨大な数の変更をうまく管理する方法を考えて変更自体は頻繁に行うべきか、というものだ。いずれにしろ、“安全に変更できるシステムを確立する”というのが最終的な答えになるだろうが」

　仮想化など、新しいデータセンター技術を導入している場合には、この問題はさらに複雑さを増す。「複雑なインフラストラクチャを構築してサーバの仮想化をサポートすれば、多少いい加減でも問題は起きない。なぜなら仮想化がサービスの可用性をある程度保証してくれるからだ」と指摘するのは、エリー生命保険のITオペレーション担当マネジャー、リチャード・ポトキ氏だ。

　確かに、仮想化技術を導入していれば、1,000台のサーバのうち25台がダウンしても、だれも気がつかないだろう。だが、そうしたルーズさを許容する環境は、非常に複雑なものにならざるをえない。そして、その複雑さを管理し、正しく機能させるためには、「優れたチェンジ・マネジメントが不可欠」（ポトキ氏）なのである。ちなみに、エリー生命では285台のサーバをカバーすることのできる自動チェンジ・マネジメント・システムを構築したという。

　優れたチェンジ・マネジメントは、ITIL（Information Technology Infrastructure Library）に記述されたベスト・プラクティスに従いながら、自動化、特にチェンジ・マネジメント・プロセスの自動化を実現する。自動化された厳格なプロセスは、変更の成功率を高め、その結果、必要な変更の絶対数を減らし、最終的にサービス全体のレベルを高める。

　だが実際には、そこまでの自動化を実現するのは容易なことではない。多くのツールがさまざまな自動化をサポートしているものの、チェンジ・マネジメント・プロセス全体をカバーしているツールというのは存在しないからだ。

　もっとも、いずれはエンド・ツー・エンドのチェンジ・マネジメント機能が、BMCソフトウェアやCA、HP、IBM、シマンテックといった大手ベンダーから提供されることになろう。ちなみに、それら各社は現在、企業買収などで取得した技術を積極的に自社製品に統合しているところだ。

チェンジ・マネジメントには
ITILが有効

　チェンジ・マネジメントを成功させるためには、どんなツールを選択するかも重要だが、その前に、現行プロセスを見直し、効率性、管理性、監査性について再検証することがもっと重要だ。10カ所のデータセンターを運営する国際的投資銀行、ドレスナー・クラインオート・ワッサースタインのロンドンCIO、ステファン・アシュトン氏は、「何をしたいかを明確にし、正しいコンテキストの中にそれを位置づけなければならない。そうしなければ、重要なポイントを見失うことになる」と忠告する

　ここにきて多くのユーザーに受け入れられるようになったITILには、ITビジネス・プロセスの主要な6つの領域──すなわち構成管理、インシデント管理、問題管理、変更管理（チェンジ・マネジメント）、サービス/ヘルプデスク、リリース管理──において、効率的な運用を実現するためのベスト・プラクティスが記述されている。つまり、チェンジ・マネジメント・プロセスを完全自動化する際には、これら6つの領域をすべて対象とする必要があるわけだ。それに、それらの要素が、どのように関連しあっているかを理解しておく必要もある。こうした背景から、ITILでは構成管理データベース（CMDB）の利用が推奨されている。

　なお、変更の多くは環境内の問題を解決する目的で行われるため、ITILの6分野の中でも、インシデント管理、問題管理、ヘルプデスク・システムに関連するプロセスやツールがカギとなる。また、変更が承認されたあとは、ロールアウトを自動的に制御／テスト／監査するリリース管理システムの出番となる。ITILのベスト・プラクティスは、チェンジ・マネジメント・システム全体を通してカギとなる機能性と説明責任を提供する。コンプライアンス対策に迫られている企業には、最高のガイドラインだと言えるだろう。

自動化の切り札「CMDB」

　「変更の自動化は、CMDBなしには進めることができない」とは、多くのユーザーが口をそろえて指摘するところである。自動化を進める際には、環境全体を俯瞰できるマップが不可欠だからだ。つまり、CMDBはルータなどのハードウェアからアプリケーション・リリースなどのソフトウェアまで、特定の環境のコンフィギュレーション情報を包括的に管理する巨大なデータベースなのである。また、それぞれのアイテムの依存性に関するマップも備えている。

　例えば、あるサーバ上で実行するアプリケーションが他のサーバ上のデータベースに依存しており、なおかつどこかで稼働しているセキュリティ・アプライアンスも利用している場合、CMDBはそれらすべての接続状況を表示するわけである。

　ただし、CMDBは、それらの情報を単一の画面で表示したり、リアルタイムで更新したりすることはできない。コンフィギュレーション・アイテムを自動的に検出し、アプリケーションの依存性を自動的にマッピングするCMDBウェアは、現在いくつか提供されている。主なベンダーとしては、BMC、CA、センデュラ、HP、IBM、エヌレイヤーズ、マーキュリ･インタラクティブ、シマンテック、タイドウェイ・システムズなどがある。

　こうしたツールは、ベンダーごとに動作や手法が異なる。例えば、CMDBの検出機能にも、エージェントを用いるものと用いないものがある。エージェント・ベースのシステムは、より詳細な診断結果を集めることができるため、クリティカルなインフラにはこちらのほうが適していると、JPモルガンのイーサリングトン氏は言う。

　しかし、事業部門がIT部門の許可を得ずにアイテムを追加できるようになっている場合には、エージェント・ベースでは問題が発生する。そのため、JPモルガンでは結局、エージェントレスのタイプを選択し、タイドウェイのFoundationを用いて大規模な検出を行うことにしたという。

　こうしたことからすると、エージェントを用いながら、同時にエージェントレスでも機能するようなハイブリッド製品があればベストだということになる。

　例えば、IBMのChange and Configuration Management Database（CCMDB）では、コレーションのエージェントレス検出機能によって検出したデータを他のエージェント・ベースのエンタープライズ監視システムの情報と組み合わせて利用するようになっている。これによって、ユーザーは、インフラを構成する重要なアイテムについて詳細な情報を得ると同時に、その他のアイテムもすべて検出できるようになるわけだ。

　もっとも、それでもフル機能のエージェントレス・システムのほうが使いやすいとする声は多い。というのも、そうすれば、環境内のさまざまなアイテムにエージェントをインストールするというIT部門の手間が省けるからだ。

　そうした意見を持つ関係者の1人であるVAファームビューローの技術サービス・マネジャー、ポール・シャープマン氏は、「ほとんどのCMDBが、サーバ・ベースのソフトウェアを検出／マップすることができる。とはいえ、検出できないアプリケーションがまったくないわけではない。特にレガシー・アプリケーションには、そうしたケースが多い」と指摘する。

　一方、IBMは、エージェント・ベースの技術とコレーションのエージェントレス検出機能を組み合わせることで、あらゆるアイテムをカバーすることができるとしている。また、BMCは今年5月、ストレージ検出機能の強化を発表するとともに、今秋にもメインフレームをサポートする製品をリリースする計画があることを明らかにした。

“完全自動化”も視野に

　CMDBを導入すれば、チェンジ・マネジメント・プロセスの自動化が可能になる。自動化には、CMDBのアプリケーション依存性マッピング機能によって分析した個々の変更に関する情報を、影響を受けるアイテムの管理者に提供することで、彼らを変更承認プロセスに関与させるといったことも含まれる。

　なかでも、最初の要求から最後の承認まで、プロセス全体を自動化できるツールがあればベストだ。サーバ専業ベンダーのツールの中には、実際に、最後の承認がソフトウェア自動配布コンポーネントをキックオフし、変更をロールアウトさせるようなものが存在する。変更のロールアウトやその成否をチェックできる監査機能のようなものまで備わっていれば、さらに申し分ない。

　エリー生命保険ではBMCのSupport Magicツールを利用することで、アイテムの検出からアプリケーションのマッピング、さらには変更の承認までを完全に自動化した。変更が承認されると、ツールは担当者にロールアウトが可能になったことを通知する。ロールアウトが完了したあと、担当者がツールからの簡単な質問に答えると、その回答をベースにツールは変更の成功率を算出する。

　「これにより、担当者には公平な評価が下され、会社は信頼性の高い監査証跡を得ることができる」と、同生保のポトキ氏は説明する。

　重要なのは、簡単かつ信頼性に優れたやり方で変更をドキュメント化し、承認とロールアウトを追跡し、その成否を監視するということだ。これにより、サービス・デリバリーの方法全体を改善することが可能になるのである。そして、チェンジ・マネジメント（の自動化）の真の目的は、「自分たちの仕事を評価し、改善していくこと」（VAファームビューローのシャープマン氏）にあるのだ。

(Computerworld.jp)