図1. Tivoli Integrated PortalのTBSMインターフェース
最初の実装から長年にわたって、サービス管理システムの機能は大幅に拡大しました。 事故によって強調された補助画像から、実際のサービス管理プラットフォームになりました。場合によっては、サービスモデルを自動的に作成し、SLAコンプライアンスのリアルタイムモニタリングの機能を備えています。 当然、さまざまなメーカーが市場でさまざまな成功と認知を達成しています。
Tivoli Business Service Manager（TBSM）は、このような迅速な機能開発の良い例、さらには例として役立ちます。 （図1を参照）
TBSMの技術的な説明に入ることなく、主な機能をリストします。
-アラームメッセージを収集および処理するための包括的なシステム（障害管理システム）としてのNetcool OMNIbusのリソースに基づいて、TBSMはすべての技術ドメインのオブジェクトの動作を例外なく接続および表示できます。 そして、ハードウェアとソフトウェアの両方のレベルのオブジェクトについて話します。 サービスモデルの状態を考慮するこの方法は、動作中のコンポーネント内で正確に何が起こっているのかという質問に対する答えを提供します。 これは、勤務シフトオペレーターに故障に関する正確なデータを提供し、できるだけ早くそれを解決するための鍵となります。 これは技術レベルの情報です。
-実際には、さまざまなDBMSに保存され、時間とともに変化するデータはすべて、サービスモデル要素の状態の決定に参加できます。 たとえば、TBSMは、専門のビジネスレベルのソフトウェアが直前のトランザクション数を絶えず更新するデータベーステーブルを調べることができます。 彼はこれを指定されたしきい値と比較し、モデル内のサービスオブジェクトのステータスを変更します。 原則として、このレベルの情報は本質的にビジネスです。
-TBSMのサービスモデルの任意のオブジェクトに対して、SLAコンプライアンス監視機能を有効にできます。これにより、事後だけでなくリアルタイムでコンプライアンスを監視できます。 SLAには次の3つのタイプがあります。時間枠ごとの停止時間の長さ、障害の数（または期間ごとのSLA違反）、最後に、レポート期間のすべてのサービス停止の合計時間です。 3つのタイプはすべて一緒に、または任意の組み合わせで使用できます。 サービスのシンボルは、サービスの現在の状態を視覚的に示すだけでなく、SLAの各タイプに準拠するために個別に提供します。 さらに、SLAの非準拠の価格をルーブルで直接設定することもできます。 オペレーターとマネージャーは、リアルタイムでTBSMインターフェースでSLA違反までの残り時間を確認します。 問題が現在修正されている場合のパフォーマンス指標は何ですか？ 違反後のペナルティーの実行方法。 これは、ITクラッシュの優先順位付けと優先順位付けに便利です。 当然、インジケータに加えて、SLA違反の事実について詳細な「報告」を行うことができる履歴レポート機能があります。 この機能は、最初の製品名によく反映されており、SLAMまたはSLA Managerと呼ばれていました。
-この後、製品はRADまたはRealtime Active Dashboardsと呼ばれ、この名前では、リアルタイムで状況を表示するパーソナルダッシュボードを構築する機能が強調されました。 これらのビューには、美しいサービスモデル、選択したオブジェクトのコンテキストでのアラーム出力ウィンドウ、図の要約、状態の動的な表示と数値の出力を備えたサービスの便利なナビゲーションツリー、経時的なサービス状態の変更と比較のためのプロッター（Timewindow Analyzer）、最後に、履歴レポートのライブラリ。 個々のキャンバス（カスタムキャンバス）では、ダッシュボードを構築するときに、速度計や温度計の列などの「測定機器」を使用できます。 （図2）サービスの要素は、関心のあるパラメーターの数値を持つブロックとして表すこともできます。 これは、TBSMを使用するプレゼンテーションの側面に関するものです。
図2 TBSMダッシュボードの補助インジケーター
-サービスモデルの構築を自動化し、更新を外部データの変更にバインドできます。 ObjectServerと呼ばれるOMNIbusコアは、基本的にはアラームがオンラインで保存および処理されるデータベースです。 ObjectServerを使用したTBSMアルゴリズムと外部データベースのレコードは類似しています。 緊急メッセージまたは外部データベースのテーブルのエントリに、サービスモデルでのオブジェクトの正しい作成および配置に必要なすべての情報が含まれている場合、サービスモデルの自動入力（自動入力）機能を構成できます。 緊急メッセージがTBSMで不明なオブジェクトから送信されたことを想像してください。TBSMメッセージフィールドに基づいて、それが属するテンプレート（オブジェクトのタイプ）を決定し、作成されたオブジェクトの名前を作成し、モデルの親オブジェクトを決定できます。 同様に、外部データベースに記録すると、新しいオブジェクトが表示される場合があります。 外部データベースを使用すると、モデルを実際に同期できます。 この機能は、サービスモデルをインベントリデータベースおよびCCMDBにリンクするときによく使用されます。 これがなければ、変化するITシステムの最新モデルを多数の要素で維持することは不可能です。
サービスの生成のために動作するオブジェクトを評価するための幅広い「センサー」が必要であるということについては、上記で言及しました。 しかし、ユーザーの観点からサービスの品質を客観的に監視できることも、サービスの質の評価を伴うサービスへの人工的な呼び出しの一種です。 Tivoliでは、これはTCAM（Tivoli Composite Application Manager）です。 これら2つのタイプの「センサー」を共有するロジックは非常に単純です。 たとえば、TCAMは、不十分なサービス応答時間またはその失敗さえも登録します。 彼はこれをクリティカルアラーム形式でOMNIbusに報告します。オブジェクトはデバイスやサーバーではなく、サービスそのものです。
TBSMでは、このようなアラームはモデルの最上位のサービスに直接結び付けられています。 同時に、「フィールドセンサー」はインフラストラクチャ施設の誤動作を検出し、メッセージも送信しました。 TBSMは、これらのメッセージをモデルの基本要素にリンクし、モデルのトポロジに対する影響の分布を計算（および表示）しました。 サービスモデルは問題の状況を明確に示しており、最も重要なのはその原因です。 「赤くなった」サービスからツリーを下って行き、色の指示に従って、スペシャリストは最も可能性の高い原因のポイントにすぐに気づきます。 TBSM自体がオブジェクトのアスタリスクをマークすることは注目に値します-問題の論理的な原因です。 根本原因の視覚的な分析のようなものになります。
結論として、TBSMはNetcoolファミリーに属しているため、キャリアクラスのソフトウェアの要件を完全に満たしています。 ビジネスクリティカルなOSSシステムで使用できます。 OMNIbus Web GUIとTivoli Network Managerのインターフェースを備えた単一ポータル内で機能する、フォールトトレランススキーム、負荷分散またはスケーリング、外部認証、およびシングルサインオンをサポートします。 Tivoli Integrated Portalは、これらの製品間のコンテキスト相互作用を提供します。これにより、ネットワークと通信機器、サーバーとそのオペレーティングシステム、ストレージとデータベース、Webサーバーとアプリケーションサーバーのモニタリングコンテキスト間の高速移行により、便利なツール環境を作成できます。監視の対象としてのサービス。