(57)【要約】【課題】企業構成要素の複雑なシステムの管理を簡素化するための方法、システム、ＧＵＩ、ＡＰＩ、コンピュータ読み取り可能媒体、及びデータ構想を提供する。【解決手段】コンピュータ実行可能な方法論は、企業事象の根本原因を相関付け判定することを含んでいる。従って、企業構成要素管理は、徴候的事象を根本原因事象から自動的に区別することにより簡素化され、それにより適時に適切な保守対策を講じ易くなる。システムは、事象を受信して相関付け、次いでそのように受信され相関付けられた事象の時間に関係付けられたセットから根本原因事象を診断するための、コンピュータベースのシステムを提供する。本システムは、事象を受信し、記憶し、相関付けるためのコンピュータ構成要素と、そのような事象及び関係付けられた相関規則を分析するための根本原因判定部を含んでいる。【選択図】図８
2004535018.tif 000002
【特許請求の範囲】
【請求項１】
企業構成要素管理のためのコンピュータで実施される方法において、
企業事象が生成される元となるコンテキストのセットを確立する段階と、
企業事象が根本原因を識別しているか否かを判定し易くする相関規則のセットを確立する段階と、
企業事象が根本原因を識別しているか否かを判定し易くするために、２つ以上の企業構成要素の間に従属性のセットを確立する段階と、
関係する企業事象の集成と相関付けをやり易くするために、１つ又は複数の相関オブジェクトを例示化する段階と、
企業事象を受信する段階と、
前記企業事象が生成された元となるコンテキストを判定する段階と、
前記企業事象を１つ又は複数の相関オブジェクトに関係付ける段階と、
前記企業事象に適用する１つ又は複数の相関規則を更新する段階と、
前記事象が生成される元となったコンテキストと、相関規則のセットと、従属性のセットと、１つ又は複数の相関オブジェクトに関係する企業事象の１つ又は複数のセット、の内の少なくとも１つに基づいて根本原因を判定する段階と、
前記根本原因に関係付けられたインジケータを生成する段階と、から成ることを特徴とする方法。
【請求項２】
前記企業事象を１つ又は複数の相関オブジェクトに関係付ける段階は、
前記企業事象に適用する１つ又は複数の相関規則に関係付けられた１つ又は複数の相関オブジェクトを識別する段階と、
前記相関規則の更新をやり易くするために、企業事象から情報を抽出する段階と、から成ることを特徴とする請求項１に記載の方法。
【請求項３】
前記企業事象に適用する１つ又は複数の相関規則を識別する段階は、
１つ又は複数の相関規則テキストフィールド、データフィールド、及び識別子シールドに対する比較をやり易くするために、１つ又は複数の企業事象テキストフィールドを構文解析する段階と、１つ又は複数の企業事象データフィールドをパターン照合する段階と、１つ又は複数の企業事象識別子フィールドを照合する段階、の内の少なくとも１つから成ることを特徴とする請求項２に記載の方法。
【請求項４】
前記根本原因を判定する段階は、
１つ又は複数の完成した相関規則が存在するか否かを判定する段階と、
１つ又は複数の完成した相関規則が存在している場合には、前記１つ又は複数の完成した相関規則の間で選択する段階と、から成ることを特徴とする請求項１に記載の方法。
【請求項５】
インパクト分析を実行する段階を更に含んでいることを特徴とする請求項１に記載の方法。
【請求項６】
インジケータに基づいて、事象が下流の構成要素に送られることを特徴とする請求項１に記載の方法。
【請求項７】
インジケータに基づいて、メッセージが下流の構成要素に送られることを特徴とする請求項１に記載の方法。
【請求項８】
インジケータに基づいて、１つ又は複数のフェイルオーバープロセスが実行されることを特徴とする請求項１に記載の方法。
【請求項９】
インジケータに基づいて、１つ又は複数の保守プロセスが実行されることを特徴とする請求項１に記載の方法。
【請求項１０】
前記コンピュータで実施される方法は、１つのコンピュータ構成要素により実行されることを特徴とする請求項１に記載の方法。
【請求項１１】
前記コンピュータで実施される方法は、２つ又はそれ以上のコンピュータ構成要素により実行されることを特徴とする請求項１に記載の方法。
【請求項１２】
根本原因を判定する際に分析されることになる企業事象を収集する期間を測定するタイマーを始動する段階と、
タイマーの作動終了後まで根本原因の判定を遅らせる段階と、を更に含んでいることを特徴とする請求項１に記載の方法。
【請求項１３】
前記タイマーの満了後に、根本原因の判定を変更させそうな企業事象が受信された場合には、タイマー作動中に収集された企業事象のセットから判定された根本原因が取り消され、新しい根本原因が判定されることを特徴とする請求項１２に記載の方法。
【請求項１４】
企業構成要素管理の方法のためのコンピュータ実行可能なインストラクションを記憶するコンピュータ読み取り可能媒体において、前記方法は、
企業事象が生成される元となるコンテキストのセットを確立する段階と、
企業事象が根本原因を識別しているか否かを判定し易くする相関規則のセットを確立する段階と、
企業事象が根本原因を識別しているか否かを判定し易くするために、２つ以上の企業構成要素の間に従属性のセットを確立する段階と、
関係する企業事象の集成と相関付けをやり易くするために、１つ又は複数の相関オブジェクトを例示化する段階と、
企業事象を受信する段階と、
前記企業事象が生成された元となるコンテキストを判定する段階と、
前記企業事象を１つ又は複数の相関オブジェクトに関係付ける段階と、
前記企業事象に適用する１つ又は複数の相関規則を更新する段階と、
前記事象が生成される元となったコンテキストと、相関規則のセットと、従属性のセットと、１つ又は複数の相関オブジェクトに関係する企業事象の１つ又は複数のセット、の内の少なくとも１つに基づいて根本原因を判定する段階と、
前記根本原因に関係付けられたインジケータを生成する段階と、から成ることを特徴とする、コンピュータ読み取り可能媒体。
【請求項１５】
企業事象の根本原因を判定するためのシステムにおいて、
１つ又は複数の企業事象を受信する企業事象受信部と、
企業事象の根本原因の判定をやり易くする１つ又は複数の相関規則を記憶する相関規則データ記憶装置と、
２つ以上の企業構成要素に関係する因果関係であって、企業事象の根本原因の判定をやり易くする１つ又は複数の因果関係を記憶する因果関係データ記憶装置と、
１つ又は複数の相関規則を備えている相関オブジェクトであって、１つ又は複数の根本原因候補に関係付けられた１つ又は複数の相関オブジェクトを記憶する相関オブジェクトデータ記憶装置と、
企業事象の根本原因を判定する時に考慮されることになる企業事象が、根本原因を判定する前に受信されることになる期間を規定するタイマーと、
１つ又は複数の相関オブジェクトを分析することにより、１つ又は複数の企業事象の根本原因を判定する根本原因判定部と、
根本原因を提示するインタフェースと、を備えていることを特徴とするシステム。
【請求項１６】
前記企業事象受信部は、１つ又は複数の企業構成要素と手動による企業事象プロバイダの内の少なくとも一方から、１つ又は複数の企業事象を受信することを特徴とする請求項１５に記載のシステム。
【請求項１７】
前記因果関係データ記憶装置は、１つ又は複数のトランザクションパイプライン従属関係を記憶することを特徴とする請求項１５に記載のシステム。
【請求項１８】
根本原因に関係付けられた企業構成要素以外の企業構成要素が、企業事象の根本原因により影響を受けると考えられるか否かを判定するインパクト分析部を備えていることを特徴とする請求項１５に記載のシステム。
【請求項１９】
前記インパクト分析部は、根本原因の影響を受ける企業構成要素を通知することと、影響を受ける企業構成要素に関係付けられたインパクト処理を初期化することの内の少なくとも一方を選択的に実行することを特徴とする請求項１８に記載のシステム。
【請求項２０】
前記インパクト処理は、フェイルオーバー処理、再起動処理、シャットダウン処理、セキュリティ処理、及び保守処理、の内の少なくとも１つを含んでいることを特徴とする請求項１９に記載のシステム。
【請求項２１】
受信した企業事象を記憶する事象ログデータ記憶装置を更に含んでいることを特徴とする請求項１５に記載のシステム。
【請求項２２】
前記事象ログデータ記憶装置は、受信した企業事象を選択的に記憶し、この選択は企業事象の唯一性に基づいて行われ、重複して記憶される企業事象の数を減らすことにより記憶装置の要件を緩和し易くすることを特徴とする請求項２１に記載のシステム。
【請求項２３】
判定された根本原因を記憶する根本原因ログデータを更に含んでいることを特徴とする請求項１５に記載のシステム。
【請求項２４】
前記根本原因判定部は、１つ又は複数の相関オブジェクトに関係付けられた１つ又は複数の相関規則が完成している度合いを計算することを特徴とする請求項１５に記載のシステム。
【請求項２５】
前記根本原因判定部は、１つ又は複数の根本原因候補をランク付けし、根本原因を選択する手動入力を受け入れることを特徴とする請求項２４に記載のシステム。
【請求項２６】
相関規則の定義づけをやり易くする相関規則作成部を更に含んでいることを特徴とする請求高１５に記載のシステム。
【請求項２７】
因果関係の定義づけをやり易くする因果関係作成部を更に含んでいることを特徴とする請求項１５に記載のシステム。
【請求項２８】
１つ又は複数の根本原因判定部から１つ又は複数の根本原因判定を受信する根本原因判定受信部を更に含んでおり、前記根本原因判定部は、１つ又は複数の企業事象の根本原因を判定する際には１つ又は複数の根本原因判定を考慮することを特徴とする請求項１５に記載のシステム。
【請求項２９】
前記システムは、１つのコンピュータ構成要素で実施されることを特徴とする請求項１５に記載のシステム。
【請求項３０】
前記システムは、２つ又はそれ以上のコンピュータ構成要素の間に分散されていることを特徴とする請求項１５に記載のシステム。
【請求項３１】
前記インタフェースは、グラフィカル・ユーザー・インタフェースであることを特徴とする請求項１５に記載のシステム。
【請求項３２】
企業事象の根本原因を判定するためのシステムのコンピュータ実行可能構成要素を記憶するコンピュータ読み取り可能媒体において、
１つ又は複数の企業事象を受信する企業事象受信構成要素と、
企業事象の根本原因の判定をやり易くする１つ又は複数の相関規則を記憶する相関規則記憶構成要素と、
２つ以上の企業構成要素に関係する因果関係であって、企業事象の根本原因の判定をやり易くする１つ又は複数の因果関係を記憶する因果関係データ記憶構成要素と、
１つ又は複数の相関規則を備えている相関オブジェクトであって、１つ又は複数の根本原因候補に関係付けられた１つ又は複数の相関オブジェクトを記憶する相関オブジェクトデータ記憶構成要素と、
企業事象の根本原因を判定する時に考慮されることになる企業事象が、根本原因を判定する前に受信されることになる期間を規定するタイミング構成要素と、
１つ又は複数の相関オブジェクトを分析することにより、１つ又は複数の企業事象の根本原因を判定する根本原因判定構成要素と、
根本原因を表示する表示装置構成要素と、を備えていることを特徴とするコンピュータ読み取り可能媒体。
【請求項３３】
表示装置と選択装置を備えているグラフィカル・ユーザー・インタフェースを有するコンピュータシステム内で、前記表示装置上にデータ入力のセットを提供し選択する方法において、
それぞれ、根本原因判定と、根本原因を判定する際に分析された相関オブジェクトの一方を表している、データ入力のセットを検索する段階と、
前記データ入力のセットを前記表示装置上に表示する段階と、
選択されるデータ入力を選択する選択装置を示すデータ入力選択信号を受信する段階と、
前記信号に応答して、前記データ入力に関係付けられた付加的データを選択的に提供する段階と、から成ることを特徴とする方法。
【請求項３４】
前記選択されたデータ入力が根本原因判定である場合には、前記付加的データを提供する段階は、事象コンテキストデータ、相関規則、従属性データ、相関オブジェクト識別子、及び根本原因判定部識別子、の内の少なくとも１つを提供する段階を含んでいることを特徴とする請求項３３に記載の方法。
【請求項３５】
前記選択されたデータ入力が相関オブジェクトである場合には、前記付加的データを提供する段階は、タイマーデータ、事象ログデータ、１つ又は複数の相関規則、１つ又は複数の従属性、及び相関オブジェクト統計、の内の少なくとも１つを提供する段階を含んでいることを特徴とする請求項３３に記載の方法。
【請求項３６】
企業事象の根本原因を判定するアプリケーションプログラムと組み合わせてコンピュータ構成要素により実行するためのコンピュータ読み取り可能媒体上に実体化されたアプリケーションプログラムインタフェースのセットにおいて、
企業事象を受信する第１インタフェースと、
企業事象に適用される相関規則を受信する第２インタフェースと、
前記第２インタフェースにより受信される相関規則を含む１つ又は複数の相関規則を備えた相関オブジェクトを受信する第３インタフェースと、
前記第３インタフェースにより受信された１つ又は複数の相関オブジェクトを調べることにより判定される、企業事象の根本原因を戻す第４インタフェースと、を備えていることを特徴とするアプリケーションプログラムインタフェースのセット。
【請求項３７】
相関オブジェクトに関係付けられたデータ構造を記憶しているコンピュータ読み取り可能媒体において、
受信された企業事象の発信元である企業オブジェクトを識別するオブジェクト識別子を記憶する第１フィールドと、
前記企業事象から検索された事象メッセージを記憶する第２フィールドと、
前記企業事象に適用される１つ又は複数の相関規則を記憶する第３フィールドと、
前記第３フィールドに記憶された１つ又は複数の相関規則が完成している度合いを記憶する第４フィールドと、
前記企業事象を受信することのできる期間を記憶する第５フィールドと、
データ構造を提供することのできる１つ又は複数の根本原因判定部を識別する根本原因識別子を記憶する第６フィールドと、を備えていることを特徴とするコンピュータ読み取り可能媒体。
【請求項３８】
事象を相関付けし基本的な事象を判定するためのシステムにおいて、
事象を受信するための手段と、
事象を記憶するための手段と、
１つ又は複数の相関規則を適用するための手段と、
１つ又は複数の相関規則が完成している度合いと相関規則により作成された値を調べることに基づいて基本的事象を判定するための手段と、を備えていることを特徴とするシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本願に記載の方法、システム、グラフィカル・ユーザー・インタフェース（ＧＵＩ）、コンピュータ読み取り可能媒体、及びアプリケーションプログラム用インタフェース（ＡＰＩ）は、概括的には情報及びデータ管理に関し、より具体的には企業事象モニタリング及びフィルタリングに関する。
【背景技術】
【０００２】
本出願は、２００１年７月６日出願の米国仮特許出願第６０／３０３，４４７号「システム及び企業事象の根本原因を相関付けし判定するための方法とシステム」に優先権を主張する。
【０００３】
企業は、多数の企業構成要素（例えば、サーバ、ルータ、データベース、メインフレーム、パーソナルコンピュータ、インテリジェント・エージェント、ビジネス・アプリケーション）を含む大規模で複雑なコンピュータ処理環境を採用している。複雑な企業のコンピュータ処理環境を監視するシステムは当技術では既知である（例えば、米国特許第５，９５８，０１２号の「仮想現実技術を使用してナビゲーションをネットワーク構成要素に表示しシミュレートするネットワーク管理システム」）。監視システムは、企業構成要素が問題（例えば、ディスククラッシュ、サーバクラッシュ、ネットワーク輻輳、データベースアクセス失敗など）に遭遇した場合には、企業構成要素が生成して報告する事象に依存している。しかしながら、第１の企業構成要素が問題（例えば、ディスククラッシュ）に遭遇した場合、その問題には、他の企業構成要素を問題（例えば、データベースアクセス失敗）に遭遇させてしまう波及効果があるかもしれない。従って、従来の監視システムは、企業構成要素から企業事象（企業イベント、エンタープライズ・イベント）を受信するが、事象の多くは根本原因事象（例えば、基本事象）ではなく徴候的な事象（例えば、他のもっと基本的な事象の結果として生成され及び／又は報告された事象）である。徴候的な事象と根本原因事象の区別は、歴史的に見ても困難であり、熟練したオペレータと膨大な時間を費やすことが求められる。
【０００４】
企業のコンピュータ処理環境内のハードウェアとソフトウェア構成要素の間に存在する関係と従属性は、１つの根本原因に繋がっており、これが徴候的事象を生み出し、オペレータを混乱させて根本原因の識別、従ってその解決を遅らせることになる。例えば、データベース管理プログラムのようなソフトウェア構成要素は、プロセッサ及びディスクのようなデータベース管理機能を行なう少なくとも２つのハードウェア構成要素に依存している。従って、ディスク又はプロセッサの何れかに問題が生じると、ディスク及び／又はプロセッサが企業事象（例えば、ディスク書き込み失敗）を生成して報告することに加え、データベース管理プログラムは、データベースアクセスに失敗（例えば、データベース書き込み失敗）したときに、企業事象を生成して報告することになる。このように、企業のコンピュータ処理環境を監視するシステム及び／又は方法は、データベース管理プログラムからの徴候的事象とハードウェアからの根本原因事象の両方を提示されることになる。従来、徴候的事象と根本原因事象を識別するのは困難であった。
【０００５】
【特許文献１】
米国仮特許出願第６０／３０３，４４７号
【特許文献２】
米国特許第５，９５８，０１２号
【発明の開示】
【課題を解決するための手段】
【０００６】
以下の要約では、システムの根本原因と企業事象を相関付け判定する幾つかの態様の基本的理解が得られるようにするため、企業管理方法、システム、ＧＵＩ、コンピュータ読み取り可能媒体、及びＡＰＩの例について、単純化して論じている。本要約は広範囲に亘る概括ではなく、鍵となる或いは重要な要素を確定しようとするものでもなければ、方法の範囲を正確に描くことを意図したものでもない。
而して、本出願の１つの態様は、企業構成要素管理のためのコンピュータ実行方法に関している。本方法は、企業事象が生成される原因となるコンテキストを確立する段階と、企業事象が根本原因を識別しているか否かの判定をやり易くする相関規則を確立する段階と、企業事象が根本原因を識別しているか否かの判定をやり易くするために各企業構成要素の間に従属性を確立する段階を含んでいる。上記項目が確立されると、本方法は、更に、関係する企業事象の集成と相関付けをやり易くするために相関オブジェクトを例示する段階と、企業事象を受信する段階と、企業事象が生成された原因となるコンテキストを判定する段階を含んでいる。事象が受信されると、本方法は、更に、企業事象を相関オブジェクトに関連付ける段階と、企業事象に適用する相関規則を更新する段階と、当該事象が生成された原因となるコンテキスト、相関規則、従属性、及び企業事象と相関オブジェクトの関係に基づいて、事象の根本原因を判定する段階を含んでいる。根本原因が判定されると、本方法は、その根本原因に関係付けられたインジケータを生成する。
【０００７】
本出願の別の態様は、企業事象の根本原因を判定するためのシステムに関する。本システムは、企業事象を受信するための企業事象受信部と、企業事象の根本原因の判定をやり易くする相関規則を記憶するための相関規則データ記憶装置と、企業事象の根本原因の判定をやり易くする、２つ以上の企業構成要素に関係する因果関係を記憶するための因果データ記憶装置を備えている。本システムは、更に、候補となる根本原因に関係付けられた相関オブジェクトを記憶するための相関オブジェクトデータ記憶装置も備えており、その相関オブジェクトは、相関規則と、企業事象の根本原因を判定する際に考慮すべき企業事象が、根本原因の判定に先立ち受信されることになる時間を定義するタイマーを有している。システムは、更に、相関オブジェクトを分析することにより企業事象の根本原因を判定する根本原因判定部を備えている。根本原因が判定されると、その原因はシステムに含まれているインタフェース上に表示されることになる。
【０００８】
本出願の又別の態様は、グラフィカル・ユーザー・インタフェースを具備したコンピュータシステムに関する。グラフィカル・ユーザー・インタフェースは、表示装置と、選択装置と、表示装置へのデータ入力の提供と選択の方法とを備えている。本方法は、根本原因判定と根本原因の判定時に分析された相関オブジェクトとを表すデータ入力を検索する段階と、表示装置上にそのデータ入力を表示する段階を含んでいる。本方法は、更に、選択装置がどのデータ入力を選択したかを示すデータ入力選択信号を受信する段階と、その信号に応えて、データ入力に関係付けられた付加データを選択的に提供する段階も含んでいる。
【０００９】
本発明の更に別の態様は、企業事象の根本原因を判定するアプリケーションプログラムと組み合わせて、コンピュータ構成要素により実行されるコンピュータ読み取り可能媒体上に具体化されたアプリケーション・プログラム・インタフェース（ＡＰＩ）のセットに関係する。ＡＰＩは、企業事象を受信する第１インタフェースと、企業事象に適用する相関規則を受信する第２インテーフェースと、第２インタフェースにより受信された相関規則を含む相関規則の相関オブジェクトを受信する第３インタフェースと、企業事象の根本原因を戻す第４インタフェースとを備えており、根本原因は、第３インタフェースにより受信された相関オブジェクトを調べることにより判定される。
【００１０】
本出願の更に又別の態様は、相関オブジェクトに関係付けられたデータ構造を記憶するコンピュータ読み取り可能媒体に関係する。相関オブジェクトは、企業事象を受信する元となった企業事象を識別するオブジェクト識別子を記憶するフィールドと、当該企業事象から検索された事象メッセージを記憶するフィールドと、当該企業事象に適用する相関規則を記憶するフィールドを含んでいる。相関オブジェクトは、更に、記憶されている相関規則がどの程度まで完成されたかを記憶するフィールドと、企業事象が受信できる期間を記憶するフィールドと、データ構造が提供される根本原因判定部を識別する根本原因判定部識別子を記憶するフィールドも含んでいる。
【００１１】
本出願の上記態様に従い、以下の説明及び添付図面に結び付けて、本方法を説明する例などを記述する。しかしながら、これらの例は、本方法、システム、ＧＵＩ、ＡＰＩ、及び媒体の原理を採用する様々なやり方のほんの数例を示したものであり、従ってその等価物も包含されるものとする。この他の利点及び新規な特徴も、添付図面に結び付けて以下の詳細な説明を考察することにより明らかとなるであろう。
【発明を実施するための最良の形態】
【００１２】
システムと企業事象の根本原因の相関付けに関係付けられた方法、システム、ＧＵＩ、ＡＰＩ、及びコンピュータ読み取り可能媒体について、以下、図面を参照ながら説明するが、各図を通して、同様の要素には同様の符号を付して示している。説明を目的とした以下の記述では、理解を促すために具体的な詳細事項について数多く記載している。しかしながら、根本原因の相関付けは、それら具体的な詳細事項にとらわれずに実施可能なことは自明であろう。その他の点では、記述を簡素化するため、周知の構造及び装置はブロック図の形態で示している。
【００１３】
前書き
根本原因の分析は、企業事象、企業構成要素間の因果関係、事象が生成された原因であるコンテキスト、及び企業事象に関係する規則を分析することにより、複雑な企業のコンピュータ処理環境内の見かけ上の問題群の根底又は基本的原因を識別することに関係している。一例としての根本原因分析は、相関オブジェクト内に集成されている数多くの事象相関規則の完成状態を分析することにより実行される。相関規則は、根本原因事象の診断と区別に関する因果関係セットのモデル化を容易にする。相関規則は、企業構成要素により生成される事象から抽出されたデータ群で構成してもよい。相関規則の相当な数の構成要素が充填されると、根本原因究明時にその規則を考察することができる。規則の構成要素を、限定するわけではないが、ＯＲ、ＡＮＤ、ＸＯＲ、ＮＯＴのようなブール演算を含む方法で組み合わせてもよい。
【００１４】
事象と相関規則は、根本原因判定部により処理することができる。事象が根本原因判定部に到着すると、タイマーが初期化されて、関係事象が収集される期間を決める。期間満了時に、収集された事象とそのような事象が関係する相関規則のセットに基づいて根本原因判定が下される。
【００１５】
根本原因が識別されると、インパクト分析が行なわれる。インパクト分析は、企業事象を調べて、当該根本原因に対してインパクトを受ける可能性のある他の企業構成要素に積極積に警報を出し、フェイルオーバー処理を開始し、保守処理を開始し、及び／又は、例えばオペレーションスタッフに警報を出す。こうして、根本原因判定部は、企業管理オペレータの知識と経験を利用し応用する。
【００１６】
従来、事象管理システムは、企業コンピュータ処理環境内で発生した殆ど全ての企業事象を提示するので、一連の企業事象の根本原因を認識するのが困難になっている。従って、ここに記載する方法、システム、ＧＵＩ、ＡＰＩ及び媒体は、フィルタリングして根本原因的事象から徴候的事象を除き、企業管理診断と管理の簡素化を図っている。フィルタリング技法には、限定するわけではないが、事象再フォーマットと事象抑制が含まれる。フィルタリングにより、例えば、企業管理システムに付帯するコンソールに表示される事象の数と頻度が減る。従って、企業管理機能用のコンソールを採用しているオペレータは、より小さくて焦点の絞られた課題空間に遭遇することになり、企業管理の向上につながる。
【００１７】
或る例では、ソフトウェアオブジェクトは、エージェント、アプリケーション、デバイス、データ記憶装置の様な企業構成要素をモデル化する。オブジェクトには状態があり、従って、限定するわけではないが、管理状態、期待状態、保守状態を含む状態に置かれる。企業オブジェクトは、関係に組み込まれる。こうして、企業オブジェクトは、親／子関係、マスター／スレーブ関係、コレボレーション関係、或いは企業構成要素間の従属性のモデル化をやり易くする従属性（例えば、トランザクションパイプライン）を伴う関係、に関わる。従属性規則と相関規則を記憶するデータ構造は、オブジェクト間の関係を捕捉し易くする。
【００１８】
企業構成要素をドメインに編成し、協調的な根本原因判定をやり易くすることができる。例えば、第１のドメインについて判定された根本原因を、第２のドメインについて判定された根本原因と組み合わせると、例えば、どちらのドメインの根本原因が支配的な根本原因なのか、或いは問題の究極的な根本原因は２つの根本原因の組合わせであるのかどうか、に関する情報を提供することができる。
【００１９】
根本原因判定部は、企業コンピュータ処理環境から事象を受信する。企業事象から検索されたデータは、事象相関規則に充てるのに使用することができる。根本原因判定部は、事象を受信し、事象相関規則に充て、事象を相関付け、集成し、十分な数の事象の後、及び／又は十分な時間が経過した後、関係事象の根本原因を判定する。根本原因判定部は、そこで根本原因事象を報告し、管理局、コンソール、及び／又はオペレータに提示される事象の数を減らすことができることになる。
【００２０】
根本原因判定システムは、受信した事象を記憶する事象ログと、判定された根本原因を記憶する根本原因ログを含むことができる。ログは、根本原因判定部により採用された論理的思考を精査するために用いて、根本原因判定部がどのように根本原因判定に到達したかを理解し、及び／又はこれに適応し易くすることができる。
【００２１】
根本原因判定システムは、更に、限定するわけではないが、根本原因判定部により分析された相関オブジェクトと判定された根本原因とを含むデータ項目を表示するＧＵＩを備えている。相関オブジェクトを表示する際、ＧＵＩは、相関オブジェクトに関係付けられた事象の数、相関オブジェクトにより考察された事象の数、期間満了までの時間、相関オブジェクトに関係付けられた根本原因候補、根本原因候補の信頼レベル、及び相関オブジェクトに対するデータ必要条件の様な、相関オブジェクトに関係付けられた統計を表示することができる。同様に、根本原因を表示する際、ＧＵＩは、限定するわけではないが、事象コンテキストデータ、相関規則、従属性データ、相関オブジェクト識別子、及び根本原因判定部識別子を含む情報を表示することができる。
【００２２】
この様に、根本原因判定部を介して企業管理を簡素化し改善するために、ここに記載する方法その他は、企業コンピュータ処理環境を（企業内の関係を含め）記述すること、企業構成要素間の因果関係を定義すること、企業構成要素に関する問題を示す事象を認識すること、及び潜在的な根本原因候補の中から最も可能性の高い根本原因を識別することをやり易くする。
【００２３】
ここに記載するシステム、ＧＵＩ、及びＡＰＩの各種態様に関するコンテキストを提供するため、図１並びに以下の論議では、一例として、方法、システム、ＧＵＩ、及びＡＰＩを実施できる環境について簡単に一般的説明を行う。コンピュータハードウェア及び／又はコンピュータ実行可能インストラクションの一般的コンテキストを説明してはいるが、１つ又は複数のコンピュータ構成要素により実行されるプログラムモジュールは、他のプログラムモジュールと組み合わせて、及び／又はハードウェアとソフトウェアの組み合わせとして実施することもできる。「コンピュータ構成要素」とは、コンピュータが関係する物理的及び／又は論理的エンティティであり、ハードウェア、ファームウェア、ソフトウェア、それらの組み合わせ、又は実行中のソフトウェアの何れかをいう。例えば、コンピュータ構成要素としては、プロセッサで実行中のプロセス、プロセッサ、オブジェクト、実行可能なもの、実行のスレッド、プログラム、プログラムイメージ、及びコンピュータが挙げられる。１つ又は複数の構成要素を実行のプロセス及び／又はスレッド内に常駐させ、コンピュータ構成要素を１つのコンピュータ上で局所化し、及び／又は２つ以上のコンピュータ間に分散させることもできる。プログラムモジュールには、通常、オブジェクト、プログラム、実行可能なスレッド、データ構造など、特定のタスクを実行するか又はデータタイプを実行するものが含まれる。
【００２４】
図１に示す環境は、システム、方法、ＧＵＩ、及びＡＰＩが機能することのできる環境の一例でしかなく、そのようなシステム、方法、ＡＰＩ、及び／又はＧＵＩの範囲を限定するものではない。本方法、システム、ＧＵＩ、及びＡＰＩに適した周知のコンピュータシステム及び構成には、限定するわけではないが、メインフレーム、マイクロコンピュータ、マイクロプロセッサベースのシステム、マルチプロセッシングシステム、及び分散型コンピュータ処理環境が含まれる。
【００２５】
図１は、コンピュータの一例であるコンピュータ１００を示しており、コンピュータ１００は、プロセッサ１０２、メモリ１０４、ディスク１０６、入／出力ポート１１０、バス１０８により作動的に接続されたネットワークインタフェース１１２を備えている。プロセッサ１０２は、デュアルマイクロプロセッサ及び他のマルチプロセッサアーキテクチャを含む多種多様なプロセッサであってもよい。メモリ１０４は、揮発性メモリ及び／又は非揮発性メモリを含んでいてもよい。非揮発性メモリとしては、限定するわけではないが、読み取り専用メモリ（ＲＯＭ）、プログラム可能読み取り専用メモリ（ＰＲＯＭ）、電気的にプログラム可能な読み取り専用メモリ（ＥＰＲＯＭ）、電気的に消去可能なプログラム可能読み取り専用メモリ（ＥＥＰＲＯＭ）などが挙げられる。揮発性メモリとしては、例えば、ランダムアクセスメモリ（ＲＡＭ）、同期性ＲＡＭ（ＳＲＡＭ）、ダイナミックＲＡＭ（ＤＲＡＭ）、同期性ＤＲＡＭ（ＳＤＲＡＭ）、二倍速データ処理ＳＤＲＡＭ（ＤＤＲ  ＳＤＲＡＭ）、及び直接ＲＡＭバスＲＡＭ（ＤＲＲＡＭ）を挙げることができる。ディスク１０６としては、限定するわけではないが、磁気ディスクドライブ、フロッピィディスクドライブ、テープドライブ、ジップドライブ、フラッシュメモリカード、及び／又はメモリスティック等の装置が挙げられる。更に、ディスク１０６としては、コンパクトディスクＲＯＭ（ＣＤ−ＲＯＭ）、ＣＤ記録可能ドライブ（ＣＤ−Ｒドライブ）、ＣＤ上書き可能ドライブ（ＣＤ−ＲＷドライブ）、及び／又はデジタル汎用ＲＯＭドライブ（ＤＶＤ  ＲＯＭ）が挙げられる。メモリ１０４は、例えば、プロセス１１４及び／又はデータ１１６を記憶する。ディスク１０６及び／又はメモリ１０４は、コンピュータ１００のリソースを制御し割り付けるオペレーティングシステムを記憶することができる。
【００２６】
バス１０８は、１つの内部バス相互接続アーキテクチャ及び／又は他のバスアーキテクチャであってもよい。バス１０８としては、限定するわけではないが、メモリバス又はメモリ制御装置、周辺バス又は外部バス、及び／又はローカルバスを含む多種多様なバスを挙げることができる。ローカルバスとしては、限定するわけではないが、工業規格アーキテクチャ（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（ＭＳＡ）バス、拡張ＩＳＡ（ＥＩＳＡ）バス、周辺機器相互接続（ＰＣＩ）バス、ユニバーサルセリアル（ＵＳＢ）バス、及び小型コンピュータシステムインタフェース（ＳＣＳＩ）バスを含む様々なバスを挙げることができる。
【００２７】
コンピュータ１００は、入／出力ポート１１０を介して入／出力装置１１８と対話する。入／出力装置１１８には、限定するわけではないが、キーボード、マイクロフォン、指針選択装置、カメラ、ビデオカード、表示装置などが含まれる。入／出力ポート１１０には、限定するわけではないが、シリアルポート、パラレルポート、及びＵＳＢポートが含まれる。
【００２８】
コンピュータ１００は、ネットワーク環境内で作動することができ、従ってネットワークインタフェース１１２でネットワーク１２０に接続されている。ネットワーク１２０を通して、コンピュータ１００は、遠隔コンピュータ１２２に論理的に接続することができる。ネットワーク１２０には、限定するわけではないが、ローカルエリアネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）及び他のネットワークが含まれる。ネットワークインタフェース１１２は、限定するわけではないが、ファイバ分散型データインタフェース（ＦＤＤＩ）、銅線分散型データインタフェース（ＣＤＤＩ）、イーサネット（登録商標）／ＩＥＥＥ８０２．３、トークンリング／ＩＥＥＥ８０２．５等を含むローカルエリアネットワーク技術に接続することができる。同様に、ネットワークインタフェース１１２は、限定するわけではないが、二点間リンクや、統合デジタル通信サービスネットワーク（ＩＳＤＮ）、パケット切換ネットワーク及びデジタル加入者回線（ＤＳＬ）の様な回路切換ネットワークを含む広域ネットワーク技術に接続することができる。
【００２９】
図２には、トランザクションパイプラインの例を２つ示している。一例として、企業構成要素のセット２００は、２つの別々のトランザクションパイプラインで構成されている。例えば、第１のトランザクションパイプライン２２０は、アカウントデータベース２３０、メインフレーム２４０、ウェブサーバ２５０、ウェブインタフェース２６０を含んでいる。同様に、第２のトランザクションパイプライン２１０は、アカウントデータベース２３０、メインフレーム２４０、マーケティングサーバ２７０、マーケティングアプリケーション２８０を含んでいる。２つのトランザクションパイプライン２１０と２２０は、両方ともアカウントデータベース２３０とメインフレーム２４０を保有している。従って、アカウントデータベース２３０又はメインフレーム２４０の何れかに関して企業事象が発生した場合、企業事象は、ウェブサーバ２５０、ウェブインタフェース２６０、マーケティングサーバ２７０、及びマーケティングアプリケーション２８０に対しても発生することになる。
【００３０】
企業構成要素間のこの関係は、因果関係として捉えることができる。ウェブインタフェース２６０とマーケティングアプリケーション２８０の間には明確な接続はないが、ウェブインタフェース２６０とウェブサーバ２５０の間、及びマーケティングアプリケーション２８０とマーケティングサーバ２７０の間には明確な関係が存在する。更に、メインフレーム２４０とアカウントデータベース２３０の間には関係が存在し、その他図示の従属関係が存在する。トランザクションパイプラインを因果関係データ記憶装置に捕捉し記憶することにより、徴候的事象を根本原因事象から容易に区別できるようになる。更に、従属性をモデル化することにより、インパクト分析が容易に実行できるようになる。例えば、ウェブサーバ２５０に関わる問題は、ウェブインタフェース２６０にインパクトを与える可能性が高く、一方、マーケティングサーバ２７０に関わる問題は、マーケティングアプリケーション２８０にインパクトを与える可能性が高い。しかしながら、ウェブサーバ２５０に関わる問題は、マーケティングアプリケーション２８０に問題を生じさせる可能性はあまりない。しかしながら、メインフレーム２４０に関わる問題は、企業構成要素２５０、２６０、２７０、２８０に問題を生じさせる可能性が高い。
【００３１】
図３は、根本原因判定部の集合体３００を示している。根本原因判定部は、少なくとも部分的には、事象受信部に受信した事象に基づいて、根本原因判定を生成する。こうして、根本原因判定部３１０は、少なくとも部分的には、事象受信部３４０に受信された事象に基づいて、根本原因判定に到る。同様に、根本原因判定部３２０は事象受信部３５０と対話し、根本原因判定部３３０は事象受信部３６０と対話する。事象受信部３４０、３５０、３６０で受信することのできる企業事象のセットを、他の根本原因判定部で下された根本原因判定を含むように定義することにより、根本原因判定部３１０、３２０及び３３０は、根本原因判定部のネットワークに参加することができる。これにより、柔軟性に富む動的な根本原因判定部のネットワークの作成がやり易くなり、従来のシステムに勝る利点が提供される。利点には、限定するわけではないが、企業をより小さなドメインに分割すること、及び複数の企業からデータを集成し相関付けることが含まれる。更に、この柔軟性があることにより、根本原因判定部間のフェイルオーバー処理が容易になり、第１の根本原因判定部がダウンした場合に、第２の根本原因判定部が、ダウンした根本原因判定部がそれまで行なっていた処理を実行することができるようになり、分散型の企業管理がやり易くなる。
【００３２】
図４は、企業事象の根本原因を判定するためのシステムの一例を示している。企業４００は、各種企業構成要素を含んでおり、そのそれぞれが１種又はそれ以上の企業事象４１０を生成することになる。システムの或る例では、米国特許第５，９５８，０１２号に記載されているような企業監視システムと統合されている。事象４１０は、事象受信部４２０に受信されるが、この受信部としては本願に定義したコンピュータ構成要素が考えられる。事象が事象受信部４００から根本原因判定部４４０に渡されたか否かは、少なくとも部分的には、タイマー４３０のオペレーションにより制御可能である。タイマー４３０は、関係する事象４１０が予期される期間を規定している。ある種の状況では、タイマー４３０により規定された期間外に着信した事象４１０が根本原因判定部４４０に提示される（例えば、根本原因判定オーバーライド事象）。根本原因判定部４４０は、例えば、相関オブジェクトデータ記憶装置４６０に記憶されている相関オブジェクトを分析することにより、１つ又は複数の企業事象４１０に対する根本原因を判定する。相関オブジェクトデータ記憶装置４６０は、例えば、独立型又は分散型データベース、データ構造（例えば、ファイル、アレイ、データベース表）などが考えられる。相関オブジェクトは、１つ又は複数の相関規則及び他の情報（例えば、相関オブジェクト識別子、時間データ、タイマーデータ）を備えている。
【００３３】
根本原因判定部４４０は、１つ又は複数の相関規則を記憶する相関規則データ記憶装置４５０にアクセスする。相関規則データ記憶装置４５０に記憶されている相関規則は、例えば、企業事象のセットに関係付けられた値のセットが企業４００内のエンティティの問題に対して予想される根本原因を示しているか否かを判定するために評価することのできる表現に関する多くの構成要素を備えている。１つの相関規則は根本原因判定のための１つのデータ点を提供し、相関オブジェクト内に集められた相関規則の集合は、信頼度のより高い又はより精密な根本原因判定を提供するデータ点のセットを提供することができる。この様に、相関規則は企業事象の根本原因の判定をやり易くする。企業事象及び／又は相関規則を別々に調べることにより根本原因の判定に有用な情報を提供しつつ、因果データ記憶装置４７０は、２つ又はそれ以上の企業構成要素の間の因果関係を記憶し、それによりデータ点の組み合わせの作成が容易になる。因果データ記憶装置４７０の一例では、トランザクションパイプライン従属関係を記憶することができる。トランザクションパイプライン従属関係の例を２つ図２に示しているが、簡潔さを期してその説明は省略する。
【００３４】
一例としての事象受信部４２０は、企業４００と手動企業事象プロバイダ（図示せず）の両方から事象４１０を受信する。一例として、事象４１０は、企業４００からコンピュータネットワークを通って到着する。同様に、独立型企業構成要素は、人間のオペレータが企業事象として翻訳する信号を生成し、次いで事象受信部４２０にその信号を提供する。独立型企業構成要素は、例えば、ネットワークに接続されていない安全なオフサイト・バックアップシステムである。
【００３５】
インタフェース４８０は、根本原因判定部４４０と通信状態にある様子が示されている。一例としてのインタフェース４８０は、根本原因判定部４４０により判定された根本原因及び／又はその根本原因判定に関係付けられた情報（例えば、判定時に採用された相関オブジェクト、判定時に完成した相関規則、企業事象、因果関係）を表示し易くする。
【００３６】
一例としての根本原因判定部４４０は、相関オブジェクトデータ記憶装置４６０に記憶されている相関オブジェクトに関係付けられた相関規則の完成度を調べる。例えば、根本原因判定部４４０は、完成している相関規則の数及び完成している相関規則の複雑性（例えば、３構成要素相関規則対１２構成要素相関規則）に関する統計を生成する。相関規則の完成度の判定、及び完成した相関規則の種類と複雑度の判定により、根本原因の判定における更に深い分析に向けた相関オブジェクトの選択がやり易くなる。更に、相関規則の完成度を判定することにより、タイマー４３０により確立される期間を構成し直すのがやり易くなる。例えば、相関規則の１００％が１００％完成している場合には、１００％完了未満でも有効な根本原因判定は可能なので、この場合の期間は長すぎると。反対に、相関規則の数パーセント（例えば５％）しか完成していない場合には、タイマー４３０により確立された時間を長くして相関規則の完成度を高める方が有益であろう。
【００３７】
２つ以上の相関規則が完成している場合には、根本原因判定部４４０は、或る例では、完成した相関規則により示される根本原因候補をランク付けする。ランキングが生成されると、根本原因判定部４４０は、或る例では、オペレータからの手動入力を受け入れて根本原因を選択する。１つ又は複数の根本原因候補からどのようにして自動的に根本原因を判定するのか、根本原因判定部４４０を訓練し易くするために、根本原因判定部４４０の訓練期間中に手動によるオペレータ入力が分析される。こうして、事象を事象ログ６００（図６）に記憶し、インタフェース４８０上に根本原因候補を提示するとともに判定された根本原因を根本原因ログ６００（図６）に記憶することにより、根本原因判定部４４０根本原因選択アルゴリズムを適応させる機械学習を監督し易くなる。
【００３８】
異なる企業は、企業事象４１０の異なるミックスを生成する企業構成要素の異なるミックスを有している。更に、異なる企業４００は、異なる視点から管理されることにより利益を受ける。従って、相関規則データ記憶装置４５０には、相関規則の異なるセットが記憶される。多種多様な相関規則の作成をやり易くするために、一例的システムでは相関規則作成部を備えている。作成部は、既存の規則の改造及び／又は新規則の作成を簡素化するグラフィカル・ユーザー・インタフェースを含んでいてもよい。同様に、異なる企業４００は、異なる企業構成要素及び／又は企業構成要素のセットの間に、異なる因果関係を有している。従って、一例的システムは、因果関係データ記憶装置４７０に記憶されることになる因果関係を定義し易くする因果関係作成部を含んでいる。
【００３９】
企業４００は２つ以上のドメインを含んでいてもよい。更に、複数の企業４００が存在していてもよい。複数のドメイン企業又は複数の企業という状況では、最終的な根本原因判定は、別々のドメイン及び／又は企業に対して下された１つ又は複数の初期根本原因判定に基づいて断定されることになる。この様に、一例的システムは、１つ又は複数の根本原因判定部４４０から１つ又は複数の根本原因判定を入力として受け入れる根本原因判定受信部（図示せず）を含んでいる。一例では、根本原因判定は、根本原因判定受信部に企業事象として渡されることになり、これにより根本原因判定部の動的ネットワークを柔軟に作成し易くなる。
【００４０】
一例的ユーザーインタフェース４８０は、表示装置と選択装置を含んでいるグラフィカル・ユーザー・インタフェースである。インタフェース４８０は、インタフェース４８０上にデータ入力のセットを表示すること、並びに表示装置上に表示されるデータ入力のセットから選択するための選択装置を採用することに備えている。データ入力のセットは、各種ソース（例えば、事象ログ６００、根本原因ログ６１０、相関規則データ記憶装置４５０、相関オブジェクトデータ記憶装置４６０、因果関係データ記憶装置４７０）から検索することができる。一例的インタフェース４８０では、データ入力のセットは、根本原因判定への着信時に分析された根本原因判定と相関オブジェクトに限定される。インタフェース４８０は、表示装置上にデータ入力のセットを表示し、表示されたデータ入力のどれが選択装置により選択されたものであるかを示すデータ入力選択信号を受信する。データ入力選択信号に応えて、インタフェース４８０は、選択されたデータ入力に関係付けられた付加データを表示することができる。例えば、データ入力が根本原因判定である場合、インタフェース４８０は、限定するわけではないが、根本原因判定に関係付けられた事象コンテキストデータ、根本原因判定への着信時に分析された１つ又は複数の相関規則、根本原因判定に関わった企業構成要素に関係付けられた従属性データ、根本原因判定への着信時に考察された相関オブジェクトを識別する相関オブジェクト識別子、及び根本原因判定への着信時に採用された根本原因判定部４４０を識別する根本原因判定部識別子、を含む付加的情報を表示することができる。同様に、選択されたデータ入力が相関オブジェクトである場合、インタフェース４８０は、限定するわけではないが、タイマー４３０に関係付けられたタイマーデータ、事象ログ６００から検索された１つ又は複数のデータ、相関オブジェクトに関係付けられた相関規則に充てる際に関わった企業事象を記憶する事象ログ６００を識別する事象ログ識別子、相関オブジェクトに関係付けられた相関規則、従属性、及び相関オブジェクト統計（例えば、考察対象の事象数、考察対象の相関オブジェクト数、考察対象の相関規則数、完成相関規則数）を含む付加データを提供することができる。
【００４１】
インタフェース４８０は、相関オブジェクトを追加、削除、及び／又は一時停止し易くする情報も提示する。更に、インタフェース４８０は、タイマー満了クロックを手動で終了させることにより相関を強制し易くする。
【００４２】
ここに記載するシステム、方法、及びグラフィカル・ユーザー・インタフェースは、各種データ構造にアクセスすることができる。コンピュータ読み取り可能媒体に記憶されている一例的データ構造は、相関オブジェクトに関係付けられている。相関オブジェクトは様々なフィールドを含んでいてもよい。一例的フィールドのセットには、オブジェクト識別子を記憶する第１フィールドが含まれている。オブジェクト識別子は、受信される企業事象の発信源である企業オブジェクトを独自のやり方で識別する。第２フィールドは、企業事象から検索された事象メッセージを記憶する。事象メッセージは、企業事象から直接複製してもよいし、第２フィールドに記憶される前に処理（例えば、構文解析、パターン照合）してもよい。一例的第３フィールドは、企業事象に適用される相関規則を記憶する。この様に、相関オブジェクトは、相関規則を集めて、効率的根本原因判定をやり易くする。一例的第４フィールドは、第３フィールドに記憶されている１つ又は複数の相関規則が完成されている程度に関係付けられたデータを記憶する。例えば、第４フィールドは、相関規則の何パーセントが完成されているのかを表示する、そして相関規則が完成していない場合にはそのような相関規則の完成度の百分率を表示する百分率データを記憶することができる。一例的第５フィールドは、企業事象を受信することができる時間を記憶する。一例的第６フィールドは、コンピュータ読み取り可能媒体に記憶されているデータ構造の提供先である根本原因判定部を独自のやり方で識別する根本原因判定部識別子を記憶する。この様に、一例的第６フィールドは、企業管理に採用される根本原因判定部の柔軟且つ動的なネットワークの構築をやり易くする。
【００４３】
図５は、根本原因判定部４４０及びインタフェース４８０と通信している一例的インパクト分析部５００を示している。インパクト分析部５００は、根本原因に関係付けられた企業構成要素以外の企業構成要素が、根本原因であると判定された問題により影響される可能性が高いかどうかを判定する。例を挙げると、下流のコンピュータ構成要素は、上流のコンピュータ構成要素の失陥による影響を受ける可能性が高いが、上流の構成要素は下流のコンピュータ構成要素の失陥による影響は受けにくい。例えば、バックエンドの銀行業務アプリケーションと多数のフロントエンドの自動窓口機（ＡＴＭ）アプリケーションを備えたコンピュータ処理環境では、１台のＡＴＭ機の失陥がバックエンドの銀行業務アプリケーションに影響することは考えにくいが、バックエンドの銀行業務アプリケーションの失陥は多数のフロントエンドのＡＴＭアプリケーションに影響する可能性が高い。
【００４４】
この様に、インパクト分析部５００は、限定するわけではないが、影響を受ける企業構成要素に根本原因を通知し、影響を受ける企業構成要素に関係付けられたインパクト処理を開始することを含む動作を実行することができる。影響を受ける企業構成要素には、機構を通して、限定するわけではないが、中断、信号、メッセージ、事象を含めて通知される。同様に、インパクト処理は、限定するわけではないが、フェイルオーバー処理、再起動処理、シャットダウン処理、セキュリティ処理、及び保守処理を含んでいてもよい。フェイルオーバー処理は、銀行業務／ＡＴＭの例では、例えば、失陥した銀行業務アプリケーションからのＡＴＭリクエストを、バックアップ銀行業務アプリケーションに再経路付けするために使用することができる。同様に、再起動処理は、銀行業務アプリケーションを再起動するために使用することができる。シャットダウン処置は、例えば、ＡＴＭフロントエンドアプリケーションを一時的にシャットダウンして、バックエンドの銀行業務アプリケーションの再起動及び／又はフェイルオーバー処理を実行する機会を与えるために使用することができる。バックエンドの銀行業務アプリケーションがフェイルオーバーされ或いは再起動されている間に、セキュリティ処理を行って、例えば、フロントエンドのＡＴＭアプリケーションで利用可能なトランザクションの数及び／又は種類を制限してもよい。更に、インパクト分析部５００は、例えば、銀行業務アプリケーションが失陥していなくとも、予期可能な未来に失陥が発生しそうであると判定した場合、保守処理をスケジュールする。
【００４５】
図６は、事象受信部４２０に（例えば、電気的に、物理的に、及び／又はデータ通信により）作動的に接続された事象ログ６００の例を示している。事象ログデータ記憶装置６００は、受信された企業事象を記憶し易くして、バックアップ、判定の再作成、及び解決後の機械の学習をやり易くする。根本原因判定部４４０により考察される事象のログ６００を有することにより、例えば、根本原因判定部４４０がダウンしたことによって中断された根本原因の判定が再起動及び／又は実行し易くなる。事象ログ６００は、更に、根本原因判定部４４０がどの様にして根本原因判定に到ったかの解決後分析もやり易くする。解後分析は、根本原因判定部４４０をもっと精度良く根本原因を究明できるよう再構成及び／又は再プログラムし易くする。或る例では、事象ログ６００は、受信された企業事象を選択的に記憶して、重複した企業事象が記憶される件数の減少を図る。例えば、銀行業務／ＡＴＭの例では、１つのＡＴＭ機は、銀行業務アプリケーションにアクセスできなくなった旨を１千回報告するかもしれない。根本原因を判定し易くするのに１千回のメッセージそれぞれが必要であるとは考えにくい。従って、そのＡＴＭからの最初の企業事象と選択された以後のメッセージ（例えば、或る時間毎に１つのメッセージ）を事象ログ６００に記憶し、その他の重複したメッセージは記憶しないようにすることができる。
【００４６】
図６は、判定された根本原因を記憶する根本原因ログデータ記憶装置６１０も示している。判定された根本原因を根本原因ログデータ記憶装置６１０に記憶することにより、例えば、根本原因の判定がどのように行なわれたかについての解後分析と、下流の根本原因判定部に根本原因を引き渡すスケジュール作成がやり易くなる。更に、根本原因データ記憶装置６１０に根本原因判定を記憶することにより、根本原因判定の評価に基づく企業管理を任されることになるオペレータの訓練がやり易くなる。根本原因の履歴ログを採用して、オペレータ訓練を簡素化するシミュレーションを作成することもできる。
【００４７】
なお、図４−６に記載のシステムは、１つのコンピュータ構成要素及び／又は２つ以上の分散型協働通信コンピュータ構成要素上に実装できる旨理解頂きたい。
【００４８】
図７では、根本原因判定アプリケーション７７０へのアクセスを提供するアプリケーションプログラム用インタフェース（ＡＰＩ）７８０を示している。ＡＰＩ７８０は、例えば、アプリケーション７７０により実行された処理、及び／又は採用されたデータにアクセスするため、プログラマー７５０及び／又はプロセス７６０により用いられる。例えば、プログラマー７５０は、事象７１０、規則７２０、オブジェクト７３０、及び／又は、根本原因判定アプリケーション７７０により採用され及び／又は生成された根本原因７４０にアクセスするためのプログラムを書き込むことができる。根本原因判定プログラム７７０は、ＡＰＩの存在により、プログラマー７５０が根本原因判定アプリケーション７７０の内部オペレーションを理解しなくてもよくなるので、採用し易くなる。プログラマー７５０は、アプリケーション７７０に対するインタフェース７８０を学習するだけでよい。これにより、アプリケーション７７０の機能性を、露出しながらもカプセル化し易くなる。同様に、ＡＰＩ７８０は、根本原因判定アプリケーション７７０に対して値を与え、及び／又はアプリケーション７７０から値を取り出すことができる。例えば、規則７２０を検索するプロセス７６０は、ＡＰＩ７８０を経由してアプリケーション７７０に規則７２０を提供することができる。根本原因判定アプリケーション７７０を示してはいるが、ＡＰＩ７８０は、根本原因判定システム及び／又は方法に対するインタフェースを提供できるものと理解頂きたい。
【００４９】
この様に、ＡＰＩ７８０の一例では、一連のアプリケーションプログラムインタフェースは、コンピュータ読み取り可能媒体上に記憶される。インタフェースは、根本原因判定システム及び／又は方法へアクセスするためにコンピュータ構成要素により実行される。インタフェースは、限定するわけではないが、企業事象を受信する第１インタフェースと、企業事象に関係付けられた相関規則を受信する第２インタフェースと、第２インタフェースにより受信された相関規則を含む相関規則で構成された相関オブジェクトを受信する第３インタフェースと、企業事象の根本原因を戻す第４インタフェースを含むことができる。
【００５０】
ここに示し説明する代表的システムに鑑み、実施される方法論は、図８から図１２のフロー図を参照すると理解し易い。説明を分かり易くするため、図示の方法論は一連のブロックとして示し説明しているが、方法論はこのブロックの順に限定されるものではないと理解頂きたい。ブロックによっては、図示し説明しているブロックと異なる順序で生じるもの及び／又は同時に生じるものもある。更に、図示しているブロック全てが例示の方法論を実施するのに必要なわけではなく、追加の及び／又は代わりの方法論では、図示していない追加のブロックを採用することもある。
【００５１】
方法論によっては、限定するわけではないが、特定用途集積回路（ＡＳＩＣ）、コンパクトディスク（ＣＤ）、デジタル汎用ディスク（ＤＶＤ）、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、プログラム可能読み取り専用メモリ（ＰＲＯＭ）、電気的に消去可能なプログラム可能読み取り専用メモリ（ＥＥＰＲＯＭ）、ディスク、搬送波、及びメモリスティックを含むコンピュータ読み取り可能媒体に記憶されているコンピュータ実行可能インストラクション及び／又はオペレーションにより実施される。
【００５２】
図８では、企業コンピュータ処理環境を管理するための、コンピュータで実施される方法の一例をフローチャートで示している。一例としての企業コンピュータ処理環境は、企業オブジェクトによりモデル化された多数の企業構成要素を含んでいる。企業構成要素としては、例えば、プログラム、スレッド、プロセス、ネットワーク形成構成要素（例えば、ルータ、リピータ、ブリッジ、ゲートウェイ）、コンピュータ（例えば、メインフレーム、ミニコンピュータ、パーソナルコンピュータ、サーバ、ハンドヘルド、ラップトップ）、及びその他の通信機器（例えば、セルラー電話、ページャー、パーソナルデジタルアシスタント（ＰＤＡ））が挙げられる。企業オブジェクトは、企業事象が生成される対象となる企業構成要素を抽出してモデル化する。
【００５３】
企業構成要素は動的で複雑なネットワーク形態に配置される。１つの企業構成要素に問題（例えば、アプリケーションがダウンするなど）が生じると、関係する構成要素にも問題が生じる。例えば、ダウンしたアプリケーションを採用しているトランザクション処理システムは、ユーザーの問い合わせに応答できなくなる。
【００５４】
企業構成要素に問題が生じると、それら構成要素は企業事象を生成し報告する。企業事象は、通常、企業構成要素に関する問題を識別するテキストメッセージ、及び企業事象と問題が生じている企業構成要素を独自に識別する１つ又は複数の識別子を含め、多くの形態を採ることができる。企業事象は、問題の期間、問題に最初に気づいた時期、企業事象が生成された時期、企業事象が報告された時期、及び問題に関係付けられたデータ値（例えば、温度＝８５度）の様な情報を含んでいることもある。この様に、企業事象の相関付け及び判定は、各種フォーマットの各種企業事象を受信する段階と処理する段階を含んでいる。
【００５５】
最初に問題が発生した企業構成要素及び関係する企業構成要素が共に企業事象を生成して報告することになるので、図８にフローチャートで示す方法を使えば、徴候的企業事象と根本原因企業事象を分離し易くなる。
【００５６】
８００では、方法論は、企業事象が生成され及び／又は見られる元となるコンテキストのセットを確立する。コンテキストを判定する場合の規則は、例えば、規則プログラマーにより決められるもので企業毎に異なり、企業の視点（例えば、アプリケーション中心の視点、ハードウェア中心の視点、ビジネスプロセス中心の視点）に基づいて企業内で変化してもよい。コンテキストは、企業事象を相関づけて事象の関係するセットを作り而してフィルタリングを掛けて大量の事象を小さな事象にブレークダウンし易くする、企業が知っている規則のセットにより捕捉される。コンテキストの一例は、トランザクションパイプラインであるが、これはトランザクション処理のために採用された従属型企業構成要素及び／又はオブジェクトをリンクしたセットである。
【００５７】
８１０では、企業事象が根本原因を識別したか否かの判定をやり易くする相関規則のセットが確立される。相関規則は、１つの例では、企業事象データに関するブールの式を含んでいる。本方法により企業事象が受信されると、ブール式の構成要素の項には、企業事象から検索されたデータが当てられる。こうして、ブール式は、完成すると、８１０で確立された相関規則に対して論理真の結果が示されているか否か、而して完成した相関規則が根本原因判定に向う方向を提供しているか否かを判定するために評価される。規則内に存在するのが、規則の採用できるデータの１００％に足りない場合でも、他の例の相関規則では、値を生成することができる。例えば、規則ｘ＝Ａ又はＢ又は（Ｃ及びＤ）は、場合によっては、Ａ又はＢに対する値だけで評価することができる。
【００５８】
８２０では、２つ又はそれ以上の企業構成要素の間の従属性のセットが確立される。従属性は、因果関係をモデル化することにより企業事象が根本原因を識別しているか否か判定し易くする。企業内に存在する因果関係を識別することにより、予想される事象を探索することと、無関係な事象を無視することが簡単になる。例えば、企業構成要素Ａが企業構成要素Ｂに従属しており、企業事象が企業構成要素Ａから受信された場合には、８２０で設定された従属性により、企業構成要素Ｂからの企業事象を探索し易くなり、企業構成要素Ａに生じた問題に対する上流の根本原因（例えば、エンティティＢに関する問題）が存在するか否かの判定中に、企業構成要素Ｃからの企業事象を無視し易くなる。
【００５９】
企業コンピュータ処理環境は、多数の因果関係を備えた企業構成要素の複雑化したネットワークを含んでいるので、或る企業構成要素に関する問題の根本原因の確立には、多数の関係する相関規則を分析することが含まれる。８３０で、関連する相関規則を集成し易くするため、相関オブジェクトが例示化される。企業事象は、到着すると、根本原因を判定する関係相関規則を納めた相関オブジェクトに送られる。相関規則を相関オブジェクトに集成することにより、例えば、別々の相関オブジェクト内の相関規則の並行処理がやり易くなり、而して企業管理に付帯する処理時間を短縮し易くなる。従って、根本原因事象は、従来の信号処理システムよりも迅速に判定される。
【００６０】
８４０で、方法論は企業事象を受信する。企業事象は、様々な企業構成要素で生成され報告されてくる。従って、企業事象は様々な企業事象フォーマットのうちの１つの形態をとる。別個の企業のモニターは、異なる視点（例えば、ハードウェア、ソフトウェア、ビジネスプロセス）から企業コンピュータ処理環境の監視業務を行なうので、８５０では、受信された企業事象の元であり観察対象となるコンテキストが判定される。企業事象生成の元であるコンテキストの判定し、而して企業事象を分析することになる視点を判定することにより、１つ又は複数の相関オブジェクト及び／又は根本原因判定部に対する企業事象の経路指定がやりやすくなる。このような複数の経路指定により、複数のモニターに対する並行処理がやり易くなる。
【００６１】
８６０では、企業事象は１つ又は複数の相関オブジェクトに関係付けられる。企業事象は、例えば、企業事象から検索されたデータが、規則の１つ又は複数のフィールド又は構成要素部分に入れるのに使用できるか否か判定するために、相関オブジェクトに関係付けられた相関規則の構成要素部分を調べることにより、相関オブジェクトに関係付けることができる。企業事象が、データにより、相関オブジェクトに関係付けられた相関規則に関係付けられる場合、８７０で、相関規則が更新される。例えば、相関規則が、ブール式の一部である５つの企業事象データ構成要素を有しており、当該企業事象データが５つの構成要素の内の１つである場合には、企業事象データに対する値を判定して、その値を用いて相関規則内のブール式を更新することができる。更に、相関オブジェクト及び／又は相関規則は、ブール式が完成されている度合いを反映するように更新することができる。例を挙げると、ブール式の構成要素の数とブール式に当てられた要素の数を記録するデータ値を更新することができる。このような完成データは、例えば、相関規則を根本原因判定に適用するか否かを制御することができる。
【００６２】
ブロック８４０から８７０は、例えば図１２に関して説明するタイマーにより制御されるループ内に入れることができる。この様に、ブロック８４０から８７０までのセットは、企業事象のセットが方法論に提示されている間に、１回又はそれ以上繰り返される。時間内の後の点で、プログラム制御（例えば、タイマー終了、受信中の事象の所定の構成可能な個数）の下、ループを出て、８８０で根本原因が判定される。根本原因の判定は、事象が生成される元となったコンテキスト、８１０で設定され８７０で更新された相関規則のセット、８２０で確立された従属性のセット、及び８３０で例示され８６０で更新された相関オブジェクトに関係する企業事象の１つ又は複数のセット、の内の少なくとも１つに基づいている。例えば、相関規則が完成されている相関オブジェクトを分析して、相関規則がブールの真の値を生成したか否か及び幾つの相関規則がブールの真の値を生成したかを判定することができる。１つ又は複数の相関規則がブールの真の値を生成した場合、根本原因の判定には、真の値を報告する１つ又は複数の相関規則を有する相関オブジェクトの間で選択することが含まれる。選択は、限定するわけではないが、ランク付け、ニュートラルネットワーク技術、パターン照合技法、及び線形プログラミングを含む技法により行なうことができる。相関規則について、論理値（例えば、真、偽）を生成するブール式のコンテキストで説明してきたが、相関規則は他の形態（例えば、関数、関係式）を採ることができ、ブール式に限定されない旨理解頂きたい。
【００６３】
８９０では、根本原因に関係付けられたインジケータが生成される。インジケータは、例えば、メッセージ、企業事象、中断、信号、又はオブジェクトであってもよい。インジケータは、解決後の活動（例えば、保守のスケジューリング、フェイルオーバー処理、インパクト分析の開始）を制御することができる。
【００６４】
この様に、図８は、企業コンピュータ処理環境を管理するための一例的方法を示している。本方法は、企業構成要素から受信される企業事象を評価することができるフレームワークを提供し易くする規則、コンテキスト及び従属性を事前に確立する段階を含んでいる。企業構成要素に問題が生じて、企業事象の生成と報告が開始されると、本方法は事象を受信して、それらを相関規則に関係付け、相関規則を集成して最終的には関係付けられた企業事象のセットの根本原因を判定する相関オブジェクトを更新する。根本原因判定は、根本原因判定に基づいて、もしあれば、どの対策を講じるべきかを理解し易くする。方法により生成されたインジケータを評価して、適切な企業コンピュータ処理環境管理機能の実行をやり易くすることができる。
【００６５】
次に図９では、フローチャートにより、或る企業事象を１つ又は複数の相関オブジェクトに関係付ける段階の例を示している。企業事象を相関オブジェクトに関係付ける段階は、８６２で、企業事象に適用する相関規則に関係付けられた相関オブジェクトを識別する段階を含んでいる。例えば、相関規則は、多数の構成要素を式の形で有している。構成要素は、企業事象から入手可能な値を反映する。この様に、企業事象は、企業事象が相関規則の式の構成要素に対する値を提供するか否かに基づき、データによって、相関規則に関係付けられる。
【００６６】
相関規則が企業事象に関係しているか否かの判定は、８６４で、企業事象テキストフィールドを構文解析して、相関規則式の構成要素に当てることのできるテキストが存在するか否かを判定することを含んでいる。同様に、８６４では、企業事象フィールドは、相関規則式構成要素とパターン照合され、企業事象が相関規則式構成要素に当てることのできるデータを保有しているか否かを判定する。更に、企業事象内の固有の識別子を調べて、企業事象が相関規則式構成要素に当てることのできるデータを保有しているか否かを判定する。構文解析、パターン照合及び識別子照合を８６４に示しているが、他の方法も採用できるものと理解されたい。企業事象が相関規則式構成要素に当てることのできるデータを有している旨の判定が下された場合、当該データを企業事象から抽出して、そのようなデータから求めた値を用いて相関規則を容易に更新することができる。
【００６７】
図１０は、根本原因を判定するための一例的方法を説明している。この一例的方法は、相関規則の完成度合いを調べ、完成した相関規則をランク付けする。８８２では、例示化された相関オブジェクトが、例えば、相関オブジェクトデータ記憶装置から検索される。相関オブジェクトに関係付けられた相関規則に関係するデータを含んでいる企業事象が受信されたとき、相関オブジェクトが例示化されることを想起頂きたい。８８３では、８８２で検索された相関オブジェクトに関係付けられた相関規則が入手される。相関オブジェクトは、例えば、１つ又は複数の相関規則を備えている。相関規則は、企業構成要素、及び／又は関係を共有する企業構成要素により生成された企業事象を識別し易くする。一例としての相関規則フォーマットは、規則と、第１の企業事象が起きてから相関根本原因が熟成するまでの期間（例えば、第１の企業事象に関係する実施質的に全て企業事象が到着したと想定するに合理的な時期）である満期時とを独自に識別する識別子を含んでいる。本例の相関規則フォーマットは、例えば、企業構成要素及びそれら構成要素の失陥を示す事象のリストでもよい「トランザクションパイプライン」フィールドも含んでいる。一例的な相関規則フォーマットは、更に、企業事象を定義し、相関規則が完成され相関が根本原因の識別に寄与することを示す値を作るか、を生成する、「生成するための相関事象」フィールドも含んでいる。生成するための相関事象は、１つ又は複数の企業事象から抽出されたテキスト及び／又はデータを有するフィールドを含んでいてもよい。
【００６８】
一例としての相関規則フォーマットは「宛先事象マネジャ」フィールドを含んでいてもよく、このフィールドは、例えば、以前のフィールドで記述された相関事象を送信することのできる根本原因判定部及び／又は事象マネジャのリストでもよい。これにより、企業内の各種ドメインに責任のある根本原因判定部のネットワークが確立し易くなり、その結果、根本原因判定の並行処理及び局所化がやり易くなる。一例としてのフォーマットは、更に、最初に受信された企業事象に関係する殆ど全ての事象が処理された旨を結論付けることにその時期以後責任がもてる時期を記述する「消去前の時期」フィールドを含んでいてもよい。相関規則は動的なので、フォーマットは経時変化することもある。
【００６９】
企業構成要素が企業オブジェクトによりモデル化される場合、相関規則は、企業オブジェクトを独自に識別し易くする「オブジェクト識別子」フィールドのようなフィールドを保有していてもよい。同様に、規則は「オブジェクト記述」フィールドを含んでいてもよい。オブジェクトは、企業構成要素の状態を確立し保守する。この様に、企業オブジェクトは、根本原因であると判定される企業構成要素が、企業オブジェクトが根本原因であると判定されたときに取られる対策に影響する状態にあるか否かを判定するために調べられる状態を有することができる。例えば、「保守」状態にある企業オブジェクトは、多くの企業事象の根本原因であると予想されるが、企業オブジェクトの「保守」状態に基づき取られる対策は、企業オブジェクトの予想状態が「実行中」の状態である場合に取られる対策とは異なる可能性が高い。例を挙げると、企業オブジェクト状態が「実行中」であると予想される場合、企業オブジェクトが根本原因であるとの判定時に取られる対策は、フェイルオーバー処理を含んでいる。しかしながら、企業オブジェクト状態が「保守」である場合、取られる対策は、下流のオブジェクトに、「保守」状態の企業オブジェクトに関係付けられた他の企業事象を報告する前に、保守を完了できるだけの期間待つように知らせることである。
【００７０】
８８４で、相関規則が完成しているか否かに関する判定が行なわれる。例を挙げると、相関規則は、論理的に「論理積をとって」ブールの真又は偽の値を生成する４つの構成要素を有している。上記のように、相関規則構成要素の値は、企業事象データフィールドから抽出することができる。８８４での判定がイエスである場合、８８５で、完成した相関規則がランク付けされ、他の完成された相関規則と比較し易くなる。ランク付けは、例えば、トランザクションパイプライン内の相対位置に基づいて行うことができる。
【００７１】
８８６で、別に調査すべき規則が存在するか否かについて判定が行なわれる。判定がイエスである場合、処理は８８３に戻る。判定がノーの場合、処理は８８７に進み、別に処理すべき相関オブジェクトが存在するか否かについて判定が行なわれる。８８７の判定がイエスの場合、処理は８８２に戻る。判定がノーの場合、処理は８８８に進み、根本原因が選択される。選択は、例えば、ランク付けされた完成した相関規則のセットを調査し、最高ランクの規則を選択することにより行なってもよい。しかしながら、根本原因を選定する他の技術としては、限定するわけではないが、手動選択、パターン照合、及びニューラルネットワーク技術が挙げられる。
【００７２】
次に図１１では、根本原因事象の相関付けと判定のためのコンピュータで実施される方法をフローチャートで示している。処理は、例えば、８９０（図８）で作られたインジケータに基づき選択的に実行される。
【００７３】
１１００では、事象を下流に送るべきか否かについて判定が行なわれる。例を挙げると、根本原因判定部のネットワーク内では、第１ドメインに対して判定された根本原因は、他の根本原因判定部に沿って送られ、共同での根本原因判定をやり易くする。従って、８９０で作られたインジケータは、本方法により判定された根本原因を他の根本原因判定部に送るべきである旨を示す。１１００での判定がイエスの場合、１１１０で、企業事象は、根本原因判定に採用されている他の方法及び／又はシステムに送られることになる。１１２０で、メッセージを下流に送るべきか否かの判定が下される。メッセージは、例えば、コンソールアプリケーション及び／又はオペレータに送られる。根本原因判定が根本原因を解決する為の自動化処理（例えば、一時停止したプロセスの再起動）をトリガする場合、再起動が発現した旨をオペレータに通知する際には目的が限定される。しかしながら、根本原因判定がオペレータの注意を求める場合、オペレータにメッセージが表示される。こうして、１１２０での判定がイエスである場合、１１３０で、メッセージは下流に送られる。
【００７４】
１１４０では、フェイルオーバー処理を開始するか否かについて判定が行なわれる。例を挙げると、独立したディスクの冗長アレイ内の１つのディスクが失陥したが、冗長アレイの故障耐性機能を実行する独立したディスクが十分な数、残っている場合、フェイルオーバー処理は要求されない。しかしながら、冗長アレイ内の多数の独立したディスクが失陥し、故障耐性が脅かされている場合は、１つ又は複数の失陥したディスクを冗長アレイから取り除き、異なる独立したディスクを冗長アレイに挿入するという処置が取られる。従って、１１４０での判定がイエスであれば、１１５０で、フェイルオーバー処理が開始される。
【００７５】
１１６０では、保守処理を開始するか否かについて判定が行なわれる。例えば、８８０の根本原因判定と８９０のインジケータは、ディスクがディスク断片化に関係付けられた閾値に近づいていることを示す。ディスクが違えば、影響を受け及び／又は失陥するディスク断片化のレベルは異なるので、熟練したオペレータは、ディスク毎に違うディスク断片化レベルで保守を選択的に実行する。従って、本方法は、８８０の根本原因判定と８９０のインジケータに基づいて保守を自動的に開始するよう構成される。こうして、１１６０の判定がイエスの場合、保守処理は１１７０で開始されることになる。
【００７６】
次に図１２では、根本原因判定に先立ち企業事象が収集される期間を制限することに関係付けられた処理をフローチャートで示している。根本原因判定の方法は、企業事象に応答するための冗長な可能性のある応答時間に合理的な制限を課すと共に、企業事象の重要なセットを収集するのに十分な時間を割り当てることによって、関係する可能性のある企業事象が収集される期間を制限することにより利益を享受することができる。
【００７７】
８４０で、企業事象が受信される。１２００では、その事象が企業事象問題に関係する最初の事象であるか否かについて判定が行われる。１２００の判定がイエスの場合、１２１０でタイマーが開始される。タイマーが起動している期間は、企業コンピュータ処理環境管理システムのオペレータが設定することのできる構成可能時間である。例えば、大規模企業及び／又はドメインの場合、タイマーは第１期間にセットされるが、小規模の企業及び／又はドメインの場合、タイマーはより短い第２期間にセットされる。同様に、長い従属性チェーンが存在する企業は、期間が長いほど恩恵を受けるが、比較的単純な従属性が存在する企業では、期間が短い方が有益である。
【００７８】
１２２０では、或る企業事象又は関係する企業事象のセットに関係付けられた期間が満了したか否かについて判定が行われる。１２２０での判定がノーである場合、１２７０で企業事象は処理される。処理には、限定するわけではないが、企業事象をログすること、事象に適用する相関規則を更新すること等が含まれる。しかしながら、１２２０での判定がイエスの場合、１２３０で、受信された企業事象が、タイマー満了後に行われる根本原因判定を変更させる可能性が高いか否かについて判定が行われる。１２３０で行なわれた判定は、タイマー満了時に、例えば１２５０で根本原因判定が行なわれるはずであると仮定する。１２３０の判定がノーである場合、１２６０で、根本原因は、タイマーの開始から満了までの間に収集された企業事象のセットに対して判定されたか否かについて判定が行われる。１２６０での判定がイエスである場合、処理は８４０に戻る。しかしながら、１２６０での判定がノーである場合、１２５０で根本原因が判定される。１２５０での根本原因の判定は、ここに記載の方法及び／又は装置により実行される。
【００７９】
１２３０での判定がイエスである場合、即ち、タイマーは１２００で満了しているが、８４０で受信された企業事象が先に１２５０で判定されている根本原因を変える可能性が高いという場合は、１２４０で、それまでに判定されている根本原因が取り消される。その後、１２５０で、根本原因が再度求められる。根本原因の判定を変更させそうな事象を説明するため、何千というユーザーがゲートウェイを通して１つのデータベースにアクセスするウェブベースのアプリケーションから受信される企業事象のセットを考えよう。データベースがダウンすると、ウェブブラウザ及び／又は当該ウェブベースのアプリケーションに関係付けられた顧客のアプリケーションは、ゲートウェイが応答しなかったことを示す数多くの企業事象を生成すると考えられる。大量の企業事象は、企業コンピュータ処理環境の帯域を容易に圧倒し、その結果データベースにより生成された企業事象の送信が妨げられることになりかねない。顧客のアプリケーションから最初の企業事象が受信されると、タイマーが起動する。タイマーの作動中、顧客のアプリケーションから多くの（例えば、１０，０００の）企業事象が受信されることになる。しかしながら、データベースがダウンした際にデータベースにより生成された企業事象は受信されない。それは、例えば、事象管理システムへの送り出しを待っているルータの待ち行列に入れられることになる。そして、時間が満期になった後、ダウンしているデータベースに関係付けられた企業事象が受信される。１０，０００個の企業事象が、ゲートウェイが応答していないことを示しており、１つの送れて到着した企業事象が、ゲートウェイが読み取りを試行して失敗したデータベースがダウンしたことを示している場合は、１０，０００のゲートウェイ関係企業事象から下された判定は、データベースがダウンしていることに関係付けられた企業事象により容易にオーバーライドされる。
【００８０】
なお、ここに記載の根本原因を判定するための方法は、１つのコンピュータ構成要素上で実行してもよいし、及び／又は２つ以上の協働し通信しているコンピュータ構成要素の間に分散してもよいものと理解頂きたい。更に、ここに記載の方法は、可能な場合には、複数のコンピュータ構成要素で並行して実行してもよい。
【００８１】
根本原因が判定されると、一例としての企業構成要素管理の方法は、インパクト分析を行なう。インパクト分析は、根本原因判定に到る企業事象を始動した問題による衝撃を受けると考えられる企業構成要素があれば、それらを判定することに関係する。例を挙げると、安全サーバ、安全及び安全でないバックエンドのアプリケーション、及び安全及び安全でないフロントエンドのアプリケーションは、安全サーバがダウンする際のインパクト分析により利益を享受する。例えば、安全でないバックエンドのアプリケーションも安全でないフロントエンドのアプリケーションも、安全サーバのダウンにより影響を受けないと考えられるが、バックエンドの安全なアプリケーションと安全なフロントエンドのアプリケーションは共に影響を受けると考えられる。従って、インパクト分析は、安全なサーバがダウンしたとの根本原因判定に基づいて、通知されるべき、実行不能にされるべき、企業構成要素等を識別することに繋がる。
【００８２】
上記内容は幾つかの例を含んでいる。無論、システムと企業事象の根本原因を相関づけ判定する際に採用されるシステム、方法、ＧＵＩ、及びＡＰＩの説明に当って、構成要素と方法論の考えられるあらゆる組み合わせを説明することは不可能である。しかしながら、当業者には、更なる組合わせ及び置換えが可能であることが認識頂けよう。従って、本出願は、特許請求の範囲に述べる範囲に当てはまる変更、修正、及び変形例を包含することを意図している。更に、「含む」という用語を詳細な説明又は請求項に使用している点については、本用語は、請求項で使用する「備える、成る、含んでいる」という用語と同様な意味を有しているもの理解されたい。
【図面の簡単な説明】
【００８３】
【図１】企業管理用の一例としてのシステム及び／方法を支援することができるコンピュータ処理環境例の概略ブロック図である。
【図２】トランザクションパイプラインの例を２つ示している。
【図３】根本原因判定システム及び／又は方法の協働セットのネットワーク構成の一例を示している。
【図４】企業事象の根本原因を判定するためのシステムの例を説明する概略ブロック図である。
【図５】企業事象の根本原因を判定するシステムの例であって、インパクト分析部を備えているシステムの概略ブロック図である。
【図６】企業事象の根本原因を判定するためのシステムに付帯するログデータ記憶装置の一例を説明する概略ブロック図である。
【図７】企業管理用のシステム及び／又は方法に採用されるアプリケーションプログラム用インタフェースの一例を示している。
【図８】企業管理用の方法の一例を説明するフローチャートである。
【図９】企業事象を相関オブジェクトに関係付けるための方法の一例を説明するフローチャートである。
【図１０】相関規則が完成しているか否かの判定に付帯する処理の一例を説明するフローチャートである。
【図１１】根本原因判定部により生成されたインジケータの分析に基づく処理の一例を説明するフローチャートである。
【図１２】根本原因判定例に関係付けられたタイマー処理を説明するフローチャートである。
【図１】
2004535018.tif 000003
【図２】
2004535018.tif 000004
【図３】
2004535018.tif 000005
【図４】
2004535018.tif 000006
【図５】
2004535018.tif 000007
【図６】
2004535018.tif 000008
【図７】
2004535018.tif 000009
【図８】
2004535018.tif 000010
【図９】
2004535018.tif 000011
【図１０】
2004535018.tif 000012
【図１１】
2004535018.tif 000013
【図１２】
2004535018.tif 000014
【国際公開パンフレット】
2004535018.tif 000015
2004535018.tif 000016
2004535018.tif 000017
2004535018.tif 000018
2004535018.tif 000019
2004535018.tif 000020
2004535018.tif 000021
2004535018.tif 000022
2004535018.tif 000023
2004535018.tif 000024
2004535018.tif 000025
2004535018.tif 000026
2004535018.tif 000027
2004535018.tif 000028
2004535018.tif 000029
2004535018.tif 000030
2004535018.tif 000031
2004535018.tif 000032
2004535018.tif 000033
2004535018.tif 000034
2004535018.tif 000035
2004535018.tif 000036
2004535018.tif 000037
2004535018.tif 000038
2004535018.tif 000039
2004535018.tif 000040
2004535018.tif 000041
2004535018.tif 000042
2004535018.tif 000043
2004535018.tif 000044
2004535018.tif 000045
2004535018.tif 000046
2004535018.tif 000047
2004535018.tif 000048
2004535018.tif 000049
2004535018.tif 000050
2004535018.tif 000051
2004535018.tif 000052
2004535018.tif 000053
2004535018.tif 000054
2004535018.tif 000055
2004535018.tif 000056
2004535018.tif 000057
2004535018.tif 000058
2004535018.tif 000059
2004535018.tif 000060
2004535018.tif 000061
【国際調査報告】
2004535018.tif 000062