帳票実装モデル　日本アイ・ビー・エムにきく

日本アイ・ビー・エム株式会社

ソフトウェアグループ Tivoli事業部　パートナー営業部　部長
澤英知　氏

●	Tivoliはシステム全体を横断的に監視する
●	「障害の監視」より、障害を防ぐ『攻めの運用』を目指す
●	問題や障害に対してシステム自信が対処するという新しい考え「オートノミックコンピューティング」「オートノミックコンピューティング」
●	パフォーマンスで投資の最適化もチェック
●	新しいユーザーID管理の形であるアイデンティティ管理
●	Tivoliがこれから目指すところ、それは1つのシステム

Tivoliは、

(1)	ITリソースやジョブなどを管理する「コンフィギュレーション＆オペレーション」
(2)	リソースやアプリケーションなどのパフォーマンス管理やネットワークを管理する「パフォーマン＆アベイラビリティ」
(3)	アクセスやプライバシー管理を行う「セキュリティ」
(4)	ストレージおよびSANを管理する「ストレージ」

という4つの枠組みで製品を提供している運用管理のソフトウェアです。
この4つの中ではコンフィギュレーション＆オペレーションつまり「監視系」が主な製品で、特に「アプリケーションの監視」についてはずっと注力してきています。
Tivoliが行う監視では、「きちんとネットワークが接続されているか」、「サーバーが正常に稼働しているか」というような基本的な監視以外に、お客様の業務から見たときにアプリケーション業務などの「エンドユーザーから見えている部分」も監視の対象にしているというのが特長的です。どういうことかと言いますと、エンドユーザーから「きちんと作動しているけど、遅くてアプリケーションが使えない」と言われてしまうと、サービスレベルとしては良くありません。エンドユーザーにとっては、アプリケーションが正常に動作しているかどうかに加えて、パフォーマンスの監視、それからサービスレベル監視も必要だということです。というのは、Tivoliではシステム部門がいろいろなシステムを構築して運用していく中で、「エンドユーザーに対して適切なシステムがサービスとして提供されているかどうかを監視する」というのがいちばんのコンセプトだからです。

障害箇所を見つけるテクノロジー、つまり「ネットワークが機能しなくなりました」、「サーバーが動作していません」といった運用・監視ツールは、結構一般化してきています。しかし、運用している側から言うと「サーバーが動作していません」という警告を見ても、そこから自分で対処していくわけですから、エンドユーザーのサービスレベルにはなかなか貢献できないところがあります。したがって、「いかに問題や障害の予兆を読み取るか」、「マシンが停止してしまうまえに対策を施せるか」というのが、ユーザーの関心事になります。Tivoliでは、この点に主眼において製品の提供を行っています。
また、実際にシステムが停止してしまったという問題が起きたときに、次にこの問題が発生しないようにどう対処していくのか、ということに関しても注意を向けなくてはいけません。このように予兆の読み取りを含め、問題を先に解決しようという『攻めの運用』がシステムの運用・管理には必要になってきます。
IBM全体として『攻めの運用』に関わる考え方の中に「オートノミックコンピューティング（自律型コンピューティング環境）」を推進していこうという動きがあります。
極論を言ってしまいますと、オートノミックコンピューティングとは、「問題が発生したときに人間が対処するのではなくてコンピュータが自動で対処できるようにすることを目指す」ということです。

このオートノミックコンピューティングの構成要素は、大きく分けると3つあります。
まずは、「センサー」と呼ばれるチェック機能です。システムもしくはハードウェアがちゃんと動作しているかということを監視します。次に「アダプター」と呼ばれる対応機能です。エラーが発生した場合、一般ユーザー向けに返すコマンドを作っておき、対応できるようにします。最後は「ナレッジ」と呼ばれる自己修復機能です。システムにエラーが発生した際に対処法を記録させておいて、実態にコンピュータに対処させるようにします。
ナレッジの部分は、たとえばどこかで障害が発生したときに、「どの程度のレベルの障害だったらバックアップを取る」、「どの程度のレベルになったら停止して予備の装置で動かす」というような「ここまでのレベルであれば安全」というのを判断する機能です。これらは、通常マニュアルに書かれているようなものではなくて経験から生み出されるモノなのですが、ナレッジはそういう情報を取り込んでいくわけです。具体的に言えば、サーバーの中でサーバー自身が「CPUが機能していない」と気づいたとき、予備のCPUに切り替えるということを人間が行わずにサーバー自身が行えるようにする機能です。
IBMの製品では、「自分で解決できる問題はできるだけ自分の中で処理する機能」が備わっています。DB2も然りです。しかし、システムの組み合わせによって起こる問題が、現実には多い。そのシステムの組み合わせによって起こる問題に対してシステム全体を横断的に見て、そこに「ナレッジ」を加えて対処させていこうというのがTivoliの考え方であり、オートノミックコンピューティングです。

パフォーマンスの管理もTivoliの重要な機能の一つです。
「ディスクが足りません」という状況になると、通常は「追加する」という発想の方へ行ってしまいます。「システム全体が遅い」となると、Webから確認したユーザーが「Webのサーバーを通ってSAPを抜けて、データベースでやっている何かが遅いみたい」「ネットワークが遅いのでは？」「では、ネットワークを変えよう」ということになります。でも、その投資は本当に正しい投資ですか。
今のシステムは、それぞれが複雑に絡み合い、こういった問題は見極めるのが非常に困難になってきています。監視、障害だけではなく、「こういうパフォーマンスが出ています」、「ここがネックになっています」という切り分けができれば、投資も最適化していけるのではないでしょうか。

最近、「一つの画面からすべてのアプリケーションにアクセスできるようにしたい」、「毎回ユーザーパスワードを入力しなくてすむ方法は」といった要望がエンドユーザーから出されています。
Tivoliはポータルを作る過程でアクセス管理を一元化しているので、当然ユーザー管理「この人は経理担当でAとBにユーザーIDがあるので、こういう権限を与えます」も集中的に管理しており、パスワードがどういう状態にあるかを監視しています。
Tivoliでは「アイデンティティ管理」と呼んでいますが、人に紐付く組織までを含めてアイデンティティを管理しています。

チェックする手段というのは、世の中の監視ツール全部にある機能です。
今、Tivoliは徹底的に監視ツールの域から一つの運用そのもののシステムに脱却しようとしています。いまや「Tivoliが停止してしまうということはシステム自身を止めてしまうこと」に近いというぐらいの使われ方になっています。単なるツールではないという域まで来ています。特にTivoliは大規模ユーザー向けに作られたわけではないのですが、単純に複雑になればなるほど価値はあるわけです。
メインフレームの時代は、そのマシン1台を見ているだけでよく、エラーの発生する場所もほぼ決まっていました。しかし、今は問題の発生箇所の切り分けが本当に難しいです。ヘルプデスク業務の中で「システムが動きません」と問い合わせがあっても、「ネットワークが接続されていないのか」、「ユーザーの使い方の問題なのか」、「アプリケーションも問題なのか」を切り分けなければなりません。また、「誰がどうやってその問題を対処するか」という問題もあります。
今は会社の大きさやシステムの規模に関わらず、ビジネスやシステムがいかにクリティカルになっているかということです。Webだけでビジネスをやっている企業もたくさんありますし、そのような企業では「システムが動いているのは当たり前」で、パフォーマンスが遅いとシステムを使ってくれなくなります。それは、やはりクリティカルな問題でビジネスに即影響が出るところなので、そういう局面でTivoliはパワーを発揮できるソフトウェアです。
Tivoliでは、各システムを結ぶ神経細胞のような役割を持ってシステム全体をコントロールし、TCOの削減やIT投資の最大効果を得られるようなオートノミックコンピューティングシステムの構築を目指しています。