特開 2024-132904 ガイド付き根本原因分析のためのログクラスタリング

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024132904

(43)【公開日】2024-10-01

(54)【発明の名称】ガイド付き根本原因分析のためのログクラスタリング

(51)【国際特許分類】

   G06F 16/90 20190101AFI20240920BHJP

   G06F 16/35 20190101ALI20240920BHJP

   G06F 16/28 20190101ALI20240920BHJP

【ＦＩ】

G06F16/90 100

G06F16/35

G06F16/28

【審査請求】有

【請求項の数】20

【出願形態】ＯＬ

【外国語出願】

(21)【出願番号】P 2024023396

(22)【出願日】2024-02-20

(31)【優先権主張番号】18/123,120

(32)【優先日】2023-03-17

(33)【優先権主張国・地域又は機関】US

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＨＤＭＩ

２．ＰＹＴＨＯＮ

３．ＨＰＵＸ

(71)【出願人】

【識別番号】518249328

【氏名又は名称】サービスナウ， インコーポレイテッド

【氏名又は名称原語表記】ＳｅｒｖｉｃｅＮｏｗ， Ｉｎｃ．

(74)【代理人】

【識別番号】100094569

【弁理士】

【氏名又は名称】田中 伸一郎

(74)【代理人】

【識別番号】100103610

【弁理士】

【氏名又は名称】▲吉▼田 和彦

(74)【代理人】

【識別番号】100109070

【弁理士】

【氏名又は名称】須田 洋之

(74)【代理人】

【識別番号】100067013

【弁理士】

【氏名又は名称】大塚 文昭

(74)【代理人】

【識別番号】100120525

【弁理士】

【氏名又は名称】近藤 直樹

(74)【代理人】

【識別番号】100139712

【弁理士】

【氏名又は名称】那須 威夫

(74)【代理人】

【識別番号】100141553

【弁理士】

【氏名又は名称】鈴木 信彦

(72)【発明者】

【氏名】ユージーン アーロン シュティルキンド

【テーマコード（参考）】

5B175

【Ｆターム（参考）】

5B175FA03

5B175HB03

5B175KA12

(57)【要約】

【課題】コンピュータシステムにおける根本原因分析および欠陥解決を十分に実行する。
【解決手段】例示的な一実施形態は、それぞれが各一連のイベントを含む複数のインシデントログを取得することと、各一連のイベントそれぞれを各イベントクラスに分類することと、各イベントクラスとそれぞれ関連付けられているクラスタ空間を決定することと、複数のインシデントログから、クラスタ空間中の少なくとも一部のクラスタ間の関係を決定することと、場合によりクラスタおよび関係に基づいて、後続インシデントログに見られる症状の根本原因を決定するための１つまたは複数の調査ステップを提案することであって、症状が、ユーザが経験した問題を表す、提案することと、を含んでいてもよい。
【選択図】図９Ａ

【特許請求の範囲】

【請求項1】

それぞれが各一連のイベントを含む複数のインシデントログを取得することと、
前記各一連のイベントそれぞれを各イベントクラスに分類することと、
前記各イベントクラスとそれぞれ関連付けられているクラスタ空間を決定することと、
前記複数のインシデントログから、前記クラスタ空間中の少なくとも一部のクラスタ間の関係を決定することと、
前記クラスタおよび前記関係に基づいて、後続インシデントログに見られる症状の根本原因を決定するための１つまたは複数の調査ステップを提案することであって、前記症状が、ユーザが経験した問題を表す、提案することと、
を含む方法。

【請求項2】

前記各イベントクラスが、症状、調査ステップ、および根本原因を含み、前記症状が、ユーザが経験した問題を表し、前記調査ステップが、対応する症状の前記根本原因の決定に講じられる措置を表し、前記根本原因が、前記対応する症状の観察結果の一義的理由である、請求項１に記載の方法。

【請求項3】

前記各イベントクラスが、解決策も含み、前記解決策が、対応する根本原因の是正に講じられた措置を表す、請求項２に記載の方法。

【請求項4】

前記インシデントログのうちの少なくとも一部が、テキストコンテンツを含み、
前記方法が、前記各一連のイベントそれぞれを分類することに先立って、ストップワード除去、フォームテキスト除去、ステミング、またはレンマ化のうちの１つまたは複数を前記インシデントログに実行することをさらに含む、請求項１に記載の方法。

【請求項5】

前記インシデントログのうちの少なくとも一部が、テキストコンテンツを含み、
前記方法が、前記各一連のイベントそれぞれを分類することに先立って、抽出的要約または抽象的要約を前記インシデントログに実行することをさらに含む、請求項１に記載の方法。

【請求項6】

前記各一連のイベントそれぞれを前記各イベントクラスに分類することが、インシデントログからのラベル付きイベントのコーパスに対して予備トレーニングされた分類器を使用することを含み、前記ラベル付きイベントのラベルが、前記各イベントクラスを示し、前記分類器が、前記インシデントログのコンテンツと前記各イベントクラスとの間の関連を学習済みである、請求項１に記載の方法。

【請求項7】

前記各イベントクラスとそれぞれ関連付けられている前記クラスタ空間を決定することが、前記各イベントクラスそれぞれについて、
分類されている前記イベントを多次元表現に投影することと、
前記多次元表現間の距離または角度に基づいて、前記クラスタ空間中の前記クラスタを構成することと、
を含む、請求項１に記載の方法。

【請求項8】

前記クラスタ空間中の少なくとも一部のクラスタ間の前記関係を決定することが、前記各一連のイベントに基づいて、前記クラスタのうちの２つのうちの第１のクラスタから前記クラスタのうちの前記２つのうちの第２のクラスタに進行するイベントの確率的尤度を決定することを含む、請求項１に記載の方法。

【請求項9】

前記確率的尤度を決定することが、前記クラスタの有向非巡回グラフを構成することを含み、前記有向非巡回グラフのエッジが、前記確率的尤度を表す、請求項８に記載の方法。

【請求項10】

分類されている前記イベントのセマンティックコンテンツに基づいて、前記クラスタそれぞれにラベル付けすることをさらに含む、請求項１に記載の方法。

【請求項11】

前記後続インシデントログに見られる前記症状の前記根本原因の決定後、コンピュータ機器にその構成の変更、実行している１つまたは複数のアプリケーションの変更、あるいは再起動を行わせることをさらに含む、請求項１に記載の方法。

【請求項12】

ユーザが経験した問題を表す症状を示すイベントを含むインシデントログを取得することと、
前記イベントと症状クラスタ空間内の複数の症状クラスタとの間の比較を実行することであって、前記複数の症状クラスタが、複数の過去取得インシデントログ中のイベントと関連付けられている症状を表す、実行することと、
前記比較に基づいて、前記症状クラスタ空間から症状クラスタを識別することと、
前記症状クラスタに基づいて、調査ステップクラスタ空間から調査ステップクラスタを選択することであって、前記調査ステップクラスタが、根本原因クラスタ空間からの１つまたは複数の根本原因クラスタと関連付けられており、前記調査ステップクラスタ空間が、前記複数の過去取得インシデントログ中の前記イベントから導出されたものであり、前記根本原因クラスタ空間も、前記複数の過去取得インシデントログ中の前記イベントと関連付けられている、選択することと、
前記調査ステップクラスタの調査ステップが、前記症状の根本原因の識別に至ったものと判定することであって、前記根本原因が、前記根本原因クラスタのうちの１つからのものである、判定することと、
を含む方法。

【請求項13】

前記イベントと前記複数の症状クラスタとの間の前記比較を実行することが、前記イベントと前記複数の症状クラスタそれぞれとの間の類似性指標を決定することを含む、請求項１２に記載の方法。

【請求項14】

前記症状クラスタ空間から前記症状クラスタを識別することが、前記類似性指標に関して前記イベントに最も類似することから前記症状クラスタを選択することを含む、請求項１３に記載の方法。

【請求項15】

前記イベントと前記複数の症状クラスタとの間の前記比較を実行することに先立って、インシデントログからのラベル付きイベントのコーパスに対して予備トレーニングされた分類器を使用して前記イベントを症状イベントクラスに分類することであって、前記ラベル付きイベントのラベルが、各イベントクラスを示し、前記分類器が、前記インシデントログ中の前記ラベル付きイベントのコンテンツと前記各イベントクラスとの間の関連を学習済みである、分類することをさらに含む、請求項１２に記載の方法。

【請求項16】

前記調査ステップクラスタが、前記調査ステップクラスタ空間内で、前記根本原因クラスタのうちの１つに至る確率が最も高いことから選択される、請求項１２に記載の方法。

【請求項17】

前記調査ステップクラスタが、前記調査ステップクラスタ空間内で、候補根本原因クラスタの数を減らす確率が最も高いことから選択される、請求項１２に記載の方法。

【請求項18】

前記根本原因に基づいて、解決策クラスタ空間から解決策クラスタを選択することであって、前記解決策クラスタが、前記根本原因の是正に講じられた措置を表す解決策を含む、選択することをさらに含む、請求項１２に記載の方法。

【請求項19】

前記解決策が、コンピュータ機器にその構成の変更、実行している１つまたは複数のアプリケーションの変更、あるいは再起動を行わせることを含む、請求項１８に記載の方法。

【請求項20】

コンピュータシステムによる実行に際して、
それぞれが各一連のイベントを含む複数のインシデントログを取得することと、
前記各一連のイベントそれぞれを各イベントクラスに分類することと、
前記各イベントクラスとそれぞれ関連付けられているクラスタ空間を決定することと、
前記複数のインシデントログから、前記クラスタ空間中の少なくとも一部のクラスタ間の関係を決定することと、
前記クラスタおよび前記関係に基づいて、後続インシデントログに見られる症状の根本原因を決定するための１つまたは複数の調査ステップを提案することであって、前記症状が、ユーザが経験した問題を表す、提案することと、
を含む動作を前記コンピュータシステムに実行させるプログラム命令が格納されている、非一時的コンピュータ可読媒体。

【発明の詳細な説明】

【背景技術】

【0001】

コンピュータシステムにおける根本原因分析および欠陥解決は、重要なタスクであるが、十分に実行されないことが多い。結果として、コンピュータ機器のネットワーク、個々のコンピュータ機器、および／またはこれらの上で実行されるソフトウェアアプリケーションに欠陥があると、欠陥の根本原因が決定されるまでの期間、これらのリソースが機能しない状態または機能が制限された状態に放置される可能性がある。このような遅延は、機器、ネットワーク、アプリケーションの性能に悪影響を及ぼし、提供するサービスが遅くなったり、信頼性が低下したり、完全に利用できなくなったりする。

【発明の概要】

【0002】

本明細書の実施形態の使用により、上記および他の技術的課題が克服され得る。特に、これらの実施形態には、ログのコーパスを前処理して問題を識別すること、調査ステップ（ｉｎｖｅｓｔｉｇａｔｏｒｙ ｓｔｅｐ）、根本原因の決定、および最終的な問題の解決策を含んでいてもよい。各ログは、ユーザ提供、エージェント提供、および／もしくは自動生成の問題の説明、問題の性質の決定に講じられる調査ステップ、問題の根本原因、ならびに問題がどのように解決されたか表すテキストを含んでいてもよい。

【0003】

データベースに格納されている数千、数十万、数百万、またはそれ以上のログを処理して、機械学習モデルのトレーニングに使用することができる。これらのモデルには、ログ中の６を１つまたは複数の所定のクラスに分類する分類器のほか、分類されたイベントに見られる類似の症状、調査ステップ、根本原因決定、および解決策を各クラスタ空間としてグループ化するクラスタリングモデルを含んでいてもよい。そして、これらのクラスタ間の確率的関係を見出すことができる。たとえば、症状を所与として、調査ステップが異なれば、根本原因の識別に成功する尤度も異なり得る。

【0004】

これにより、将来の類似問題に関する自動、半自動、またはエージェントベースの調査が上記尤度に従って進行可能となる。言い換えると、新たな問題が識別されるたびに、一連の調査ステップが決定され得る。これらのステップを所与の順序で実行することにより、問題を解決時間が最小限に抑えられる可能性もあるし、少なくとも削減され得る。結果として、コンピュータ機器、システム、ネットワーク、およびアプリケーションのダウンタイムが短くなり、全体的な信頼性が向上する。

【0005】

したがって、第１の例示的な実施形態は、それぞれが各一連のイベントを含む複数のインシデントログを取得することと、各一連のイベントそれぞれを各イベントクラスに分類することと、各イベントクラスとそれぞれ関連付けられているクラスタ空間を決定することと、複数のインシデントログから、クラスタ空間中の少なくとも一部のクラスタ間の関係を決定することと、クラスタおよび関係に基づいて、後続インシデントログに見られる症状の根本原因を決定するための１つまたは複数の調査ステップを提案することであって、症状が、ユーザが経験した問題を表す、提案することと、を含んでいてもよい。

【0006】

第２の例示的な実施形態は、ユーザが経験した問題を表す症状を示すイベントを含むインシデントログを取得することと、イベントと症状クラスタ空間内の複数の症状クラスタとの間の比較を実行することであって、複数の症状クラスタが、複数の過去取得インシデントログ中のイベントと関連付けられている症状を表す、実行することと、比較に基づいて、症状クラスタ空間から症状クラスタを識別することと、症状クラスタに基づいて、調査ステップクラスタ空間から調査ステップクラスタを選択することであって、調査ステップクラスタが、根本原因クラスタ空間からの１つまたは複数の根本原因クラスタと関連付けられており、調査ステップクラスタ空間が、複数の過去取得インシデントログ中のイベントから導出されたものであり、根本原因クラスタ空間も、複数の過去取得インシデントログ中のイベントと関連付けられている、選択することと、調査ステップクラスタの調査ステップが、症状の根本原因の識別に至ったものと判定することであって、根本原因が、根本原因クラスタのうちの１つからのものである、判定することと、を含んでいてもよい。

【0007】

第３の例示的な実施形態は、コンピュータシステムによる実行によって、第１および／または第２の例示的な実施形態に記載の動作をコンピュータシステムに実行させるプログラム命令が格納された非一時的コンピュータ可読媒体を含んでいてもよい。

【0008】

第４の例示的な実施形態において、コンピュータシステムは、少なくとも１つのプロセッサのほか、メモリおよびプログラム命令を備えていてもよい。プログラム命令は、メモリに格納され、少なくとも１つのプロセッサによる実行の際に、第１および／または第２の例示的な実施形態に記載の動作をコンピュータシステムに実行させるようにしてもよい。

【0009】

第５の例示的な実施形態において、システムは、第１および／または第２の例示的な実施形態の動作それぞれを実行するためのさまざまな手段を備えていてもよい。

【0010】

当業者には、必要に応じて添付の図面を参照しつつ、以下の詳細な説明を読むことにより、上記および他の実施形態、態様、利点、および代替案が明らかとなるであろう。さらに、本概要ならびに本明細書に記載の他の説明および図面は、一例として実施形態を示す意図しかないため、多くの変形例が可能である。たとえば、構造要素およびプロセスステップについて、特許請求の範囲のような実施形態の範囲内に維持しつつ、再配置、結合、分配、除去、あるいは変更を加えることができる。

【図面の簡単な説明】

【0011】

【図1】例示的な実施形態に係る、コンピュータ機器の模式図である。

【図2】例示的な実施形態に係る、サーバ機器クラスタの模式図である。

【図3】例示的な実施形態に係る、リモートネットワーク管理アーキテクチャを示した図である。

【図4】例示的な実施形態に係る、リモートネットワーク管理アーキテクチャを含む通信環境を示した図である。

【図5】例示的な実施形態に係る、リモートネットワーク管理アーキテクチャを含む別の通信環境を示した図である。

【図6A】例示的な実施形態に係る、インシデントログからの一連のイベントを示す図である。

【図6B】例示的な実施形態に係る、別のインシデントログからの一連のイベントを示す図である。

【図7A】例示的な実施形態に係る、トレーニング段階を表すフローチャートである。

【図7B】例示的な実施形態に係る、予測段階を表すフローチャートである。

【図8A】例示的な実施形態に係る、クラスタ空間を示す図である。

【図8B】例示的な実施形態に係る、クラスタ間の確率的関係を示す図である。

【図9A】例示的な実施形態に係る、フローチャートである。

【図9B】例示的な実施形態に係る、別のフローチャートである。

【発明を実施するための形態】

【0012】

本明細書には、例示的な方法、機器、およびシステムを記載している。本明細書において、単語「例（ｅｘａｍｐｌｅ）」および「例示的（ｅｘｅｍｐｌａｒｙ）」は、「一例、事例、または実例として機能する」ことを意味するものとして使用していることが了解されるものとする。「例」または「例示的」として本明細書に記載の任意の実施形態または特徴は、その旨の記載のない限り、他の実施形態または特徴よりも好適または有利であるとは必ずしも解釈されない。このため、本明細書に提示の主題の範囲から逸脱することなく、他の実施形態を利用可能であるとともに、他の変更を加えることができる。

【0013】

したがって、本明細書に記載の例示的な実施形態は、何ら限定を意味するものではない。本明細書の全体に記載するとともに図面に示すような本開示の態様は、多種多様な異なる構成での配置、置換、結合、分離、および設計が可能であることが容易に了解される。たとえば、「クライアント」および「サーバ」コンポーネントへの機能の分離は、多くの方法で実行可能である。

【0014】

さらに、文脈上の別段の示唆のない限り、図面それぞれに示す特徴は、相互に組み合わせて使用可能である。このため、図面は一般的に、１つまたは複数の全体的な実施形態の構成要素の態様として捉えるべきであり、図示の特徴のすべてが各実施形態に必要であるとは限らないことが了解される。

【0015】

また、本明細書または特許請求の範囲における要素、ブロック、またはステップの如何なる列挙も、明瞭化を目的としたものである。したがって、このような列挙は、これらの要素、ブロック、またはステップの特定の配置の順守または特定の順序での実行の要求または暗示を行うものと解釈すべきではない。

【0016】

Ｉ．導入
大企業は、相互に関連する多くの業務を抱える複雑なエンティティである。これらの中には、人事（ＨＲ）、サプライチェーン、情報技術（ＩＴ）、および財務等、企業の各所で見られるものもある。ただし、各企業は、必要不可欠な能力の提供および／または競争優位性の構築につながるそれ自体の一意の業務も有する。

【0017】

幅広く実施される業務をサポートするため、企業は通常、顧客関係管理（ＣＲＭ）および人材管理（ＨＣＭ）パッケージ等、既製のソフトウェアアプリケーションを使用する。ただし、企業自体の一意の要件を満たすには、カスタムのソフトウェアアプリケーションも必要となる場合がある。大企業では、これらのカスタムソフトウェアアプリケーションを何十または何百と有することが多い。これに対して、本明細書の実施形態が提供する利点は、大企業に限定されず、あらゆる規模の企業または他種の組織に適用可能と考えられる。

【0018】

このような多くのソフトウェアアプリケーションは、企業内の個々の部門により開発される。これらは、単純なスプレッドシートから、特注のソフトウェアツールおよびデータベースにまで及ぶ。ただし、他部門との連携のないカスタムソフトウェアアプリケーションの普及には多くの欠点がある。これは、企業による業務の運営および成長の能力、技術革新、ならびに規制要件への対応に悪影響を及ぼす。企業は、そのサブシステムおよびデータを統合する単一のシステムがないことから、業務の統合、合理化、および強化を困難と感じる場合がある。

【0019】

カスタムアプリケーションを効率的に生成するため、企業は、不要な開発の複雑さを排除するリモートホスト型のアプリケーションプラットフォームから恩恵を受けることになる。このようなプラットフォームの目標は、時間を要する繰り返しのアプリケーション開発タスクを減らして、ソフトウェアエンジニアおよび他の任務の個人が価値の高い一意の機能の開発に専念できるようにすることである。

【0020】

この目標を達成するため、ａＰａａＳ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｌａｔｆｏｒｍ ａｓ ａ Ｓｅｒｖｉｃｅ）の概念の導入によって、企業全体のワークフローを知的に自動化する。ａＰａａＳシステムは、企業からリモートでホストされるが、セキュアな接続によって、企業内のデータ、アプリケーション、およびサービスにアクセス可能である。このようなａＰａａＳ一ステムには、多くの有利な機能および特性がある。これらの利点および特性によって、ＩＴ、ＨＲ、ＣＲＭ、顧客サービス、アプリケーション開発、およびセキュリティに関して、企業の業務およびワークフローを改善可能と考えられる。これに対して、本明細書の実施形態は、企業の用途または環境に限定されず、より広く適用可能である。

【0021】

ａＰａａＳシステムは、モデル・ビュー・コントローラ（ＭＶＣ）アプリケーションの開発および実行をサポートし得る。ＭＶＣアプリケーションは、それぞれの機能を３つの相互接続部（モデル、ビュー、およびコントローラ）に分割して、情報がユーザに提示される様態から情報の表現を分離することにより、効率的なコードの再利用および並行開発を可能にする。これらのアプリケーションは、ウェブベースで、作成、読み取り、更新、および削除（ＣＲＵＤ）の機能を提供し得る。これにより、共通のアプリケーションインフラ上で新たなアプリケーションを構築可能となる。場合によっては、単方向データフローを使用するもの等、ＭＶＣとは異なる構造のアプリケーションが採用され得る。

【0022】

ａＰａａＳシステムは、グラフィカルユーザインターフェース（ＧＵＩ）開発のための標準化された一組のウィジェット等、標準化されたアプリケーションコンポーネントをサポートし得る。このように、ａＰａａＳシステムを用いて構築されたアプリケーションは、外観および雰囲気が共通する。他のソフトウェアコンポーネントおよびモジュールについても同様に、標準化されていてもよい。場合によっては、企業のカスタムロゴおよび／または配色によって、この外観および雰囲気をブランディングまたはスキニングすることも可能である。

【0023】

ａＰａａＳシステムは、メタデータを使用してアプリケーションの動作を設定する機能をサポートし得る。これによって、特定のニーズを満たすように、アプリケーションの動作を素早く適応させることができる。このような手法によって、開発時間が短縮されるとともに柔軟性が増す。さらに、ａＰａａＳシステムは、メタデータの作成および管理を容易化してメタデータのエラーを抑えるＧＵＩツールをサポートし得る。

【0024】

ａＰａａＳシステムは、アプリケーション間の明確に規定されたインターフェースをサポートし得るため、ソフトウェア開発者が不要なアプリケーション間依存関係を回避することができる。このため、ａＰａａＳシステムは、永続的な状態情報等のデータが格納されるサービス層を実装することができる。

【0025】

ａＰａａＳシステムが豊富な一組の統合機能をサポートし得るため、システム上のアプリケーションは、レガシーアプリケーションおよびサードパーティアプリケーションと相互作用可能である。たとえば、ａＰａａＳシステムは、レガシーＨＲ、ＩＴ、および会計システムと統合されるカスタム従業員研修システムをサポートし得る。

【0026】

ａＰａａＳシステムは、企業レベルのセキュリティをサポートし得る。さらに、ａＰａａＳシステムは、リモートでホストされ得ることから、企業のシステムまたは企業の外側でホストされたサードパーティネットワークおよびサービスと相互作用する場合に、セキュリティ手順も利用すべきである。たとえば、ａＰａａＳシステムは、企業等の当事者間でデータを共有することにより、共通のセキュリティ脅威を検出および識別するように構成されていてもよい。

【0027】

また、ａＰａａＳシステムの他の特徴、昨日、および利点も存在し得る。この説明は、例示を目的としており、何ら限定の意図はない。

【0028】

ａＰａａＳ開発プロセスの一例として、ソフトウェア開発者は、ａＰａａＳシステムを使用して新たなアプリケーションを作成するように命じられる場合がある。開発者は最初に、アプリケーションが使用するデータの種類およびそれぞれの間の関係を指定するデータモデルを規定し得る。開発者はその後、ａＰａａＳシステムのＧＵＩを介して、データモデルを入力する（たとえば、アップロードする）。ａＰａａＳシステムは、対応するデータベーステーブル、フィールド、および関係をすべて自動的に作成するが、これらには、オブジェクト指向サービス層を介してアクセス可能となる。

【0029】

また、ａＰａａＳシステムは、クライアント側のインターフェースおよびサーバ側のＣＲＵＤロジックを伴う完全に機能的なアプリケーションを構築可能である。この生成アプリケーションは、ユーザの別途開発の基礎として機能し得る。開発者は、アプリケーションの基本機能に多くの時間を費やす必要がないため都合が良い。さらに、アプリケーションは、ウェブベースであってもよいため、任意のインターネット対応クライアント機器からアクセス可能である。この代替または追加として、たとえばインターネットサービスが利用可能ではない場合に、アプリケーションのローカルコピーへのアクセスが可能となっていてもよい。

【0030】

また、ａＰａａＳシステムは、アプリケーションに追加できる豊富な一組の所定の機能をサポートし得る。これらの機能には、検索、電子メール、テンプレート、ワークフロー設計、レポート、分析、ソーシャルメディア、スクリプト記述、モバイル向けの出力、およびカスタマイズＧＵＩのサポートを含む。

【0031】

このようなａＰａａＳシステムは、さまざまな方法でＧＵＩを表し得る。たとえば、ａＰａａＳシステムのサーバ機器は、ハイパーテキストマークアップ言語（ＨＴＭＬ）およびＪＡＶＡＳＣＲＩＰＴ（登録商標）の組み合わせを使用してＧＵＩの表現を生成するようにしてもよい。ＪＡＶＡＳＣＲＩＰＴ（登録商標）は、クライアント側の実行可能コード、サーバ側の実行可能コード、または両者を含み得る。サーバ機器がこの表現をクライアント機器に送信あるいは提供することにより、ローカルに規定された外観および雰囲気に従って、クライアント機器が画面に表示するようにしてもよい。あるいは、ＧＵＩの表現は、クライアント機器がグラフィック出力を直接生成するのに使用可能な中間形態（たとえば、ＪＡＶＡ（登録商標）バイトコード）等、他の形態であってもよい。それ以外の可能性もある。

【0032】

さらに、ボタン、メニュー、タブ、スライダ、チェックボックス、トグル等のＧＵＩ要素とのユーザ相互作用をそれぞれの「選択」、「起動」、または「作動」と称する場合もある。これらの用語は、ＧＵＩ要素との相互作用がキーボードによるか、ポインティングデバイスによるか、タッチスクリーンによるか、または別の機構によるかに関わらず使用され得る。

【0033】

ａＰａａＳアーキテクチャは、企業のネットワークと統合され、このようなネットワークの管理に用いられる場合に特に効果を発揮する。以下の実施形態では、例示的なａＰａａＳシステムのアーキテクチャおよび機能的態様のほか、それぞれの特徴および利点を説明する。

【0034】

ＩＩ．例示的なコンピュータ機器およびクラウドベースのコンピュータ環境
図１は、コンピュータ機器１００を例示する簡易ブロック図であって、コンピュータ機器に含まれ、本明細書の実施形態に従って動作するように構成された構成要素の一部を示している。コンピュータ機器１００としては、クライアント機器（たとえば、ユーザが能動的に操作する機器）も可能であるし、サーバ機器（たとえば、演算サービスをクライアント機器に提供する機器）も可能であるし、その他何らかの種類の演算プラットフォームも可能である。サーバ機器の中には、特定の操作を実行するために時折クライアント機器として動作するものがあり、クライアント機器の中には、サーバ機能を組み込んだものがある。

【0035】

本例において、コンピュータ機器１００は、プロセッサ１０２、メモリ１０４、ネットワークインターフェース１０６、および入力／出力ユニット１０８を具備しており、これらがすべて、システムバス１１０または類似の機構により結合されていてもよい。いくつかの実施形態において、コンピュータ機器１００は、他の構成要素および／または周辺機器（たとえば、取り外し可能なストレージ、プリンタ等）を具備していてもよい。

【0036】

プロセッサ１０２は、中央演算処理装置（ＣＰＵ）、コプロセッサ（たとえば、数学、グラフィックス、または暗号化コプロセッサ）、デジタル信号プロセッサ（ＤＳＰ）、ネットワークプロセッサ、ならびに／またはプロセッサ動作を実行する集積回路もしくはコントローラの形態等、任意の種類のコンピュータ処理要素のうちの１つまたは複数であってもよい。場合により、プロセッサ１０２は、１つまたは複数のシングルコアプロセッサであってもよい。他の場合に、プロセッサ１０２は、複数の独立した処理ユニットを伴う１つまたは複数のマルチコアプロセッサであってもよい。また、プロセッサ１０２には、実行対象の命令および関連データを一時的に格納するためのレジスタメモリのほか、最近使用された命令およびデータを一時的に格納するためのキャッシュメモリを含み得る。

【0037】

メモリ１０４は、如何なる形態のコンピュータ使用可能メモリであってもよく、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、ならびに不揮発性メモリ（たとえば、フラッシュメモリ、ハードディスクドライブ、半導体ドライブ、コンパクトディスク（ＣＤ）、デジタルビデオディスク（ＤＶＤ）、および／もしくはテープストレージ）が挙げられるが、これらに限定されない。このため、メモリ１０４は、メインメモリユニットおよび長期ストレージの両者を表す。他種のメモリとしては、生物学的メモリが挙げられる。

【0038】

メモリ１０４は、プログラム命令および／またはプログラム命令が動作し得るデータを格納していてもよい。一例として、メモリ１０４は、プロセッサ１０２による実行によって、本明細書または添付の図面に開示の方法、プロセス、または動作のいずれかを実行可能となるように、これらのプログラム命令非一時的コンピュータ可読媒体に格納するようにしてもよい。

【0039】

図１に示すように、メモリ１０４は、ファームウェア１０４Ａ、カーネル１０４Ｂ、および／またはアプリケーション１０４Ｃを含んでいてもよい。ファームウェア１０４Ａは、コンピュータ機器１００の一部または全部の起動あるいは開始に用いられるプログラムコードであってもよい。カーネル１０４Ｂは、メモリ管理、プロセッサのスケジューリングおよび管理、入力／出力、ならびに通信のためのモジュールを含むオペレーティングシステムであってもよい。また、カーネル１０４Ｂは、オペレーティングシステムによるコンピュータ機器１００のハードウェアモジュール（たとえば、メモリユニット、ネットワークインターフェース、ポート、およびバス）との通信を可能にするデバイスドライバを含んでいてもよい。アプリケーション１０４Ｃは、ウェブブラウザまたは電子メールクライアント等の１つまたは複数のユーザ空間ソフトウェアプログラムのほか、これらのプログラムで使用される任意のソフトウェアライブラリであってもよい。また、メモリ１０４は、上記および他のプログラムおよびアプリケーションで使用されるデータを格納するようにしてもよい。

【0040】

ネットワークインターフェース１０６は、イーサネット（たとえば、ファーストイーサネット、ギガビットイーサネット）等の１つまたは複数の有線インターフェースの形態であってもよい。また、ネットワークインターフェース１０６は、同軸ケーブルもしくは電力線等の１つもしくは複数の非イーサネット媒体または同期光ネットワーキング（ＳＯＮＥＴ）もしくはデジタル加入者線（ＤＳＬ）技術等の広域媒体を介した通信をサポートし得る。また、ネットワークインターフェース１０６は、ＩＥＥＥ ８０２．１１（Ｗｉｆｉ）、ＢＬＵＥＴＯＯＴＨ（登録商標）、全地球測位システム（ＧＰＳ）、または広域無線インターフェース等の１つまたは複数の無線インターフェースの形態であってもよい。ただし、他の形態の物理層インターフェースならびに他種の標準もしくは専用通信プロトコルがネットワークインターフェース１０６を介して用いられるようになっていてもよい。さらに、ネットワークインターフェース１０６には、複数の物理インターフェースを含み得る。たとえば、コンピュータ機器１００のいくつかの実施形態には、イーサネット、ＢＬＵＥＴＯＯＴＨ（登録商標）、およびＷｉｆｉインターフェースを含み得る。

【0041】

入力／出力ユニット１０８は、ユーザおよび周辺機器のコンピュータ機器１００との相互作用を容易化し得る。入力／出力ユニット１０８には、１つまたは複数の種類の入力装置（キーボード、マウス、タッチスクリーン等）を含み得る。同様に、入力／出力ユニット１０８には、１つまたは複数の種類の出力装置（画面、モニタ、プリンタ、ならびに／または１つもしくは複数の発光ダイオード（ＬＥＤ）等）を含み得る。この追加または代替として、コンピュータ機器１００は、たとえばユニバーサルシリアルバス（ＵＳＢ）または高精細マルチメディアインターフェース（ＨＤＭＩ）ポートインターフェースを使用することにより他の機器と通信することができる。

【0042】

いくつかの実施形態においては、コンピュータ機器１００等の１つまたは複数のコンピュータ機器の展開によって、ａＰａａＳアーキテクチャをサポートしていてもよい。これらのコンピュータ機器の厳密な物理的位置、接続性、および設定は、クライアント機器に既知および／または重要ではない場合もある。したがって、コンピュータ機器は、さまざまなリモートデータセンタの場所で収容し得る「クラウドベース」機器と称する場合もある。

【0043】

図２は、例示的な実施形態に係る、クラウドベースのサーバクラスタ２００を示している。図２においては、コンピュータ機器（たとえば、コンピュータ機器１００）の動作がサーバ機器２０２、データストレージ２０４、およびルータ２０６間に分散していてもよく、これらがすべて、ローカルクラスタネットワーク２０８により接続されていてもよい。サーバクラスタ２００におけるサーバ機器２０２、データストレージ２０４、およびルータ２０６の数は、サーバクラスタ２００に割り当てられた演算タスクおよび／またはアプリケーションによって決まり得る。

【0044】

たとえば、サーバ機器２０２は、コンピュータ機器１００のさまざまな演算タスクを実行するように構成可能である。このため、１つまたは複数のサーバ機器２０２に演算タスクを分配可能である。これらの演算タスクを並列実行可能な限りにおいて、このようなタスクの分配により、これらのタスクを完了して結果を返すまでの合計時間が短縮され得る。簡素化のため、サーバクラスタ２００および個々のサーバ機器２０２の両者を「サーバ機器」と称する場合もある。この命名は、１つまたは複数の異なるサーバ機器、データ記憶装置、およびクラスタルータがサーバ機器の動作に関与し得ることの暗示として了解されるものとする。

【0045】

データストレージ２０４は、複数群のハードディスクドライブおよび／または半導体ドライブに対する読み書きアクセスを管理するように構成されたドライブアレイコントローラを含むデータストレージアレイであってもよい。また、ドライブアレイコントローラは、１つまたは複数のサーバ機器２０２がデータストレージ２０４のユニットにアクセスできなくなるドライブ故障または他種の故障に対する保護のため、単独またはサーバ機器２０２と併せて、データストレージ２０４に格納されたデータのバックアップまたは冗長コピーを管理するように構成されていてもよい。ドライブ以外の他種のメモリが用いられるようになっていてもよい。

【0046】

ルータ２０６は、内部および外部通信をサーバクラスタ２００に提供するように構成されたネットワーク設備を含み得る。たとえば、ルータ２０６には、（ｉ）ローカルクラスタネットワーク２０８を介したサーバ機器２０２とデータストレージ２０４との間のネットワーク通信、および／または、（ｉｉ）ネットワーク２１２への通信リンク２１０を介したサーバクラスタ２００と他の機器との間のネットワーク通信を提供するように構成された１つまたは複数のパケットスイッチングおよび／またはルーティング機器（スイッチおよび／またはゲートウェイを含む）を含み得る。

【0047】

また、ルータ２０６の構成は、サーバ機器２０２およびデータストレージ２０４のデータ通信要件、ローカルクラスタネットワーク２０８のレイテンシおよびスループット、通信リンク２１０のレイテンシ、スループット、およびコスト、ならびに／またはシステムアーキテクチャのコスト、速度、耐障害性、回復力、効率、および／もしくは他の設計目標に寄与し得る他の要因に少なくとも部分的に基づき得る。

【0048】

考え得る一例として、データストレージ２０４には、構造化照会言語（ＳＱＬ）データベース等の任意の形態のデータベースを含み得る。このようなデータベースにおいては、さまざまな種類のデータ構造が情報を格納可能であり、テーブル、アレイ、リスト、ツリー、およびタプルが挙げられるが、これらに限定されない。さらに、データストレージ２０４の任意のデータベースがモノリシックであってもよいし、複数の物理的機器に分散していてもよい。

【0049】

サーバ機器２０２は、データストレージ２０４へのデータの送信および／またはデータストレージ２０４からのデータの受信を行うように構成されていてもよい。この送信および読み出しはそれぞれ、ＳＱＬクエリもしくは他種のデータベースクエリの形態ならびにこのようなクエリの出力の形態であってもよい。同様に、テキスト、イメージ、ビデオ、および／またはオーディオが追加で含まれていてもよい。さらに、サーバ機器２０２は、受信データをウェブページまたはウェブアプリケーションの表現として編成するようにしてもよい。このような表現は、ＨＴＭＬ、拡張マークアップ言語（ＸＭＬ）等のマークアップ言語、または他の何らかの標準化フォーマットもしくは専用フォーマットの形態であってもよい。さらに、サーバ機器２０２は、さまざまな種類のコンピュータ化スクリプト言語を実行可能であってもよく、Ｐｅｒｌ、Ｐｙｔｈｏｎ、ＰＨＰ Ｈｙｐｅｒｔｅｘｔ Ｐｒｅｐｒｏｃｅｓｓｏｒ（ＰＨＰ）、Ａｃｔｉｖｅ Ｓｅｒｖｅｒ Ｐａｇｅｓ（ＡＳＰ）、ＪＡＶＡＳＣＲＩＰＴ（登録商標）等が挙げられるが、これらに限定されない。これらの言語で書かれたコンピュータプログラムコードは、クライアント機器へのウェブページの提供のほか、クライアント機器のウェブページとの相互作用を容易化し得る。この代替または追加として、ウェブページの生成の容易化および／またはウェブアプリケーション機能の提供のため、ＪＡＶＡ（登録商標）が用いられるようになっていてもよい。

【0050】

ＩＩＩ．例示的なリモートネットワーク管理アーキテクチャ
図３は、例示的な実施形態に係る、リモートネットワーク管理アーキテクチャを示している。このアーキテクチャには、マネージドネットワーク３００、リモートネットワーク管理プラットフォーム３２０、およびパブリッククラウドネットワーク３４０という３つの主要な構成要素を含み、すべてがインターネット３５０により接続されている。

【0051】

Ａ．マネージドネットワーク
マネージドネットワーク３００は、たとえば演算および通信タスクのほか、データのストレージのためのエンティティが使用する企業ネットワークであってもよい。このため、マネージドネットワーク３００は、クライアント機器３０２、サーバ機器３０４、ルータ３０６、仮想マシン３０８、ファイアウォール３１０、および／またはプロキシサーバ３１２を具備していてもよい。クライアント機器３０２は、コンピュータ機器１００により具現化されていてもよく、サーバ機器３０４は、コンピュータ機器１００またはサーバクラスタ２００により具現化されていてもよく、ルータ３０６は、如何なる種類のルータ、スイッチ、またはゲートウェイであってもよい。

【0052】

仮想マシン３０８は、コンピュータ機器１００およびサーバクラスタ２００のうちの１つまたは複数により具現化されていてもよい。一般的に、仮想マシンは、コンピュータシステムのエミュレーションであり、物理的なコンピュータの機能（たとえば、プロセッサ、メモリ、および通信リソース）を模倣する。サーバクラスタ２００等の１つの物理的なコンピュータシステムが最大で数千もの個々の仮想マシンをサポート可能である。いくつかの実施形態において、仮想マシン３０８は、個々の仮想マシンに対する物理的な演算リソースの割り当てのほか、性能およびエラー報告を容易化する集中サーバ機器またはアプリケーションにより管理されるようになっていてもよい。企業は、仮想マシンを採用することにより、必要に応じて演算リソースを効率的に割り当てることが多い。仮想化コンピュータシステムのプロバイダには、ＶＭＷＡＲＥ（登録商標）およびＭＩＣＲＯＳＯＦＴ（登録商標）を含む。

【0053】

ファイアウォール３１０は、マネージドネットワーク３００を起点とする正規の通信を許可しつつ、内部の機器、アプリケーション、およびサービスへの不正なアクセス試行からマネージドネットワーク３００を保護する１つまたは複数の専用ルータまたはサーバ機器であってもよい。また、ファイアウォール３１０は、侵入検出、ウェブフィルタリング、ウイルススキャン、アプリケーション層ゲートウェイ、ならびに他のアプリケーションもしくはサービスを提供し得る。図３には示していないいくつかの実施形態において、マネージドネットワーク３００は、リモートネットワーク管理プラットフォーム３２０（以下参照）と通信するための１つまたは複数の仮想プライベートネットワーク（ＶＰＮ）ゲートウェイを具備していてもよい。

【0054】

また、マネージドネットワーク３００は、１つまたは複数プロキシサーバ３１２を具備していてもよい。プロキシサーバ３１２の一実施形態は、マネージドネットワーク３００、リモートネットワーク管理プラットフォーム３２０、およびパブリッククラウドネットワーク３４０間のデータの通信および移動を容易化するサーバアプリケーションであってもよい。特に、プロキシサーバ３１２は、リモートネットワーク管理プラットフォーム３２０の１つまたは複数の演算インスタンスとのセキュアな通信セッションを構築および維持可能であってもよい。このようなセッションにより、リモートネットワーク管理プラットフォーム３２０は、マネージドネットワーク３００およびその構成要素のアーキテクチャおよび設定の態様を検出および管理可能となり得る。

【0055】

場合によっては、プロキシサーバ３１２の補助により、リモートネットワーク管理プラットフォーム３２０は、マネージドネットワーク３００が使用するパブリッククラウドネットワーク３４０の態様を検出および管理することも可能となり得る。図３には示していないものの、パブリッククラウドネットワーク３４０のいずれに１つまたは複数のプロキシサーバ３１２を配置することによって、この検出および管理を容易化するようにしてもよい。

【0056】

ファイアウォール３１０等のファイアウォールは通常、上記のようなセッションが最終的にファイアウォールの背後（すなわち、マネージドネットワーク３００上の機器）を起点とするわけでもなく、当該ファイアウォールがセッションをサポートするように明示的に構成されているわけでもない限り、インターネット３５０を経由して着信するすべての通信セッションを拒否する。プロキシサーバ３１２をファイアウォール３１０の背後に配置することにより（たとえば、マネージドネットワーク３００内に配置してファイアウォール３１０で保護することにより）、ファイアウォール３１０を通じて、プロキシサーバ３１２がこれらの通信セッションを開始可能となり得る。これにより、ファイアウォール３１０は、リモートネットワーク管理プラットフォーム３２０からの着信セッションをサポートするように特別な構成とする必要がなくなる可能性もあるため、マネージドネットワーク３００に対する潜在的なセキュリティリスクを回避することができる。

【0057】

場合により、マネージドネットワーク３００は、少数の機器および少数のネットワークから成っていてもよい。他の展開において、マネージドネットワーク３００は、複数の物理的な場所に及び、数百のネットワークおよび数十万の機器を含んでいてもよい。このため、図３に示すアーキテクチャは、桁違いの規模の拡大または縮小が可能である。

【0058】

さらに、マネージドネットワーク３００のサイズ、アーキテクチャ、および接続性に応じて、内部に展開するプロキシサーバ３１２の数を変えることができる。たとえば、プロキシサーバ３１２はそれぞれ、マネージドネットワーク３００の一部に関してリモートネットワーク管理プラットフォーム３２０との通信を担うようにしてもよい。この代替または追加として、このようなマネージドネットワーク３００の部分に対する複数組の２つ以上のプロキシサーバの割り当てによって、負荷分散、冗長性、および／または可用性の向上を図るようにしてもよい。

【0059】

Ｂ．リモートネットワーク管理プラットフォーム
リモートネットワーク管理プラットフォーム３２０は、ユーザ、特に、マネージドネットワーク３００のオペレータにａＰａａＳサービスを提供するホストされた環境である。これらのサービスは、たとえば前述のウェブベースの技術を使用するウェブベースのポータルの形態であってもよい。このため、ユーザは、たとえばクライアント機器３０２または可能性としてマネージドネットワーク３００の外側のクライアント機器から、リモートネットワーク管理プラットフォーム３２０へのセキュアなアクセスが可能である。ウェブベースのポータルにより、ユーザは、アプリケーションの設計、テスト、および展開、レポートの生成、分析の確認、ならびに他のタスクの実行が可能となる。また、リモートネットワーク管理プラットフォーム３２０は、マルチアプリケーションプラットフォームと称する場合もある。

【0060】

図３に示すように、リモートネットワーク管理プラットフォーム３２０は、４つの演算インスタンス３２２、３２４、３２６、および３２８を含む。これらの演算インスタンスはそれぞれ、ａＰａａＳソフトウェアの専用コピーを運用する１つもしくは複数のノードならびに／または１つもしくは複数のデータベースノードを表し得る。物理的なサーバ機器および／または仮想マシン上では、サーバおよびデータベースの柔軟な配置が可能であり、企業のニーズに基づいて変更するようにしてもよい。組み合わせにより、これらのノードは、特定の企業が利用可能な一組のウェブポータル、サービス、およびアプリケーション（たとえば、完全に機能するａＰａａＳシステム）を提供することができる。場合によっては、単一の企業が複数の演算インスタンスを使用するようにしてもよい。

【0061】

たとえば、マネージドネットワーク３００は、リモートネットワーク管理プラットフォーム３２０の企業顧客であってもよく、また、演算インスタンス３２２、３２４、および３２６を使用するようにしてもよい。１つの顧客に複数の演算インスタンスを提供する理由として、顧客は、そのアプリケーションおよびサービスの独立した開発、テスト、および展開を望む場合がある。このため、演算インスタンス３２２がマネージドネットワーク３００と関連するアプリケーション開発専用であってもよく、演算インスタンス３２４がこれらのアプリケーションのテスト専用であってもよく、演算インスタンス３２６がテスト済みアプリケーションおよびサービスのライブ運用専用であってもよい。また、演算インスタンスは、ホストされたインスタンス、リモートインスタンス、顧客インスタンスと称する場合もあるし、他の何らかの呼称となる場合もある。演算インスタンスに展開された如何なるアプリケーションも、演算インスタンス内のデータベースへのアクセスが内部の特定の要素（たとえば、１つもしくは複数の特定のデータベーステーブルまたは１つもしくは複数のデータベーステーブル内の特定の行）に制限され得る点において、スコープアプリケーション（ｓｃｏｐｅｄ Ａｐｐｌｉｃａｔｉｏｎ）と考えられる。

【0062】

簡素化のため、本明細書の開示では、アプリケーションノード、データベースノード、これらの上で実行されるａＰａａＳソフトウェア、および基礎となるハードウェアの構成を「演算インスタンス」と称する。なお、ユーザは口語的に、上記により提供されるグラフィカルユーザインターフェースを「インスタンス」と称する場合がある。ただし、本明細書における別段の定義のない限り、「演算インスタンス」は、リモートネットワーク管理プラットフォーム３２０内に配設されたコンピュータシステムである。

【0063】

リモートネットワーク管理プラットフォーム３２０のマルチインスタンスアーキテクチャは、従来のマルチテナントアーキテクチャとは対照的に、複数の利点を奏する。マルチテナントアーキテクチャにおいては、異なる顧客（たとえば、企業）からのデータが単一のデータベースにおいて混合される。これらの顧客のデータは相互に分離されているが、この分離は、単一のデータベースを運用するソフトウェアによって強制されている。結果として、このシステムにおけるセキュリティ侵害が顧客のすべてのデータに影響を及ぼし、特に政府、医療、および／または金融の規制を受けるエンティティにとっては、付加的なリスクとなる。さらに、１つの顧客に影響を及ぼす任意のデータベース運用は、当該データベースを共有するすべての顧客に影響を及ぼす可能性がある。このため、ハードウェアまたはソフトウェアのエラーに起因する停止の場合、この停止は、このようなすべての顧客に影響を及ぼす。同様に、データベースは、１つの顧客のニーズを満たすようにアップグレードされる場合、アップグレードプロセスにおいて、すべての顧客が利用不可能となる。このような保守時間枠は、共有データベースのサイズに起因して長くなることが多い。

【0064】

これに対して、マルチインスタンスアーキテクチャは、専用の演算インスタンスにおいて、各顧客にそれ自体のデータベースを提供する。これにより、顧客データの混合が防止され、各インスタンスの独立管理が可能となる。たとえば、ある顧客のインスタンスがエラーまたはアップグレードによって停止となった場合でも、他の演算インスタンスは影響を受けない。データベースに１つの顧客のデータしか含まないため、保守のダウンタイムは限られる。さらに、マルチインスタンスアーキテクチャのより簡素な設計によって、各顧客データベースおよびインスタンスの冗長コピーが地理的に多様に展開され得る。これにより、高い可用性が促進され、障害の検出または保守の実行時に、顧客のインスタンスのライブバージョンを移動可能となる。

【0065】

いくつかの実施形態において、リモートネットワーク管理プラットフォーム３２０は、このプラットフォームを動作させるエンティティにより制御される１つまたは複数の中央インスタンスを含んでいてもよい。演算インスタンスと同様に、中央インスタンスは、いくつかの物理的サーバ機器または仮想マシン上に配設されたいくつかのアプリケーションおよびデータベースノードを含み得る。このような中央インスタンスは、演算インスタンスのほか、演算インスタンスの少なくとも一部で共有され得るデータの特定の構成に対するレポジトリとして機能し得る。たとえば、演算インスタンス上で発生し得る一般的なセキュリティ脅威の定義、演算インスタンス上で一般的に検出されるソフトウェアパッケージ、および／または演算インスタンスに展開可能なアプリケーション用のアプリケーションストアが中央インスタンスに存在していてもよい。演算インスタンスは、このデータを得るために明確に規定されたインターフェースによって、中央インスタンスと通信するようにしてもよい。

【0066】

複数の演算インスタンスを効率的にサポートするため、リモートネットワーク管理プラットフォーム３２０は、複数のこれらインスタンスを単一のハードウェアプラットフォーム上で実行するようにしてもよい。たとえば、ａＰａａＳシステムは、サーバクラスタ２００等のサーバクラスタ上で実行されている場合、さまざまな量の演算、ストレージ、および通信リソースをインスタンスに割り当てる仮想マシンを動作させるようにしてもよい。ただし、サーバクラスタ２００の完全な仮想化は必要とされず、他のメカニズムによって、インスタンスを分離するようにしてもよい。いくつかの例において、各インスタンスは、サーバクラスタ２００上に専用アカウントならびに１つもしくは複数の専用データベースを有していてもよい。あるいは、演算インスタンス３２２等の演算インスタンスが複数の物理的機器に及んでいてもよい。

【0067】

場合によっては、リモートネットワーク管理プラットフォーム３２０の単一のサーバクラスタが複数の独立した企業をサポートし得る。さらに、後述の通り、リモートネットワーク管理プラットフォーム３２０は、負荷分散、冗長性、および／または高い可用性を促進するため、地理的に多様なデータセンタに展開された複数のサーバクラスタを具備していてもよい。

【0068】

Ｃ．パブリッククラウドネットワーク
パブリッククラウドネットワーク３４０は、外部委託演算、データストレージ、通信、およびサービスホスティング業務に使用可能なリモートサーバ機器（たとえば、サーバクラスタ２００等の複数のサーバクラスタ）であってもよい。これらのサーバは、仮想化されていてもよい（すなわち、仮想マシンであってもよい）。パブリッククラウドネットワーク３４０の例としては、Ａｍａｚｏｎ ＡＷＳ Ｃｌｏｕｄ、Ｍｉｃｒｏｓｏｆｔ Ａｚｕｒｅ Ｃｌｏｕｄ（Ａｚｕｒｅ）、Ｇｏｏｇｌｅ Ｃｌｏｕｄ Ｐｌａｔｆｏｒｍ（ＧＣＰ）、およびＩＢＭ Ｃｌｏｕｄ Ｐｌａｔｆｏｒｍが挙げられる。リモートネットワーク管理プラットフォーム３２０と同様に、負荷分散、冗長性、および／または高い可用性を目的として、パブリッククラウドネットワーク３４０をサポートする複数のサーバクラスタが地理的に多様な場所に展開されていてもよい。

【0069】

マネージドネットワーク３００は、１つまたは複数のパブリッククラウドネットワーク３４０を使用して、アプリケーションおよびサービスをそのクライアントおよび顧客に展開するようにしてもよい。たとえば、マネージドネットワーク３００がオンライン楽曲ストリーミングサービスを提供している場合、パブリッククラウドネットワーク３４０は、楽曲ファイルを格納するとともに、ウェブインターフェースおよびストリーミングの機能を提供するようにしてもよい。このように、マネージドネットワーク３００の企業は、これらの業務に対して、それ自体のサーバを構築および保守する必要がない。

【0070】

リモートネットワーク管理プラットフォーム３２０は、パブリッククラウドネットワーク３４０との統合によって、内部の仮想マシンおよびマネージドサービスをマネージドネットワーク３００に公開するモジュールを具備していてもよい。これらのモジュールによれば、ユーザは、仮想リソースの要求、割り当てられたリソースの検出、およびパブリッククラウドネットワーク３４０への柔軟な報告が可能となり得る。この機能を確立するため、マネージドネットワーク３００のユーザは、最初にパブリッククラウドネットワーク３４０でアカウントを開設し、一組の関連するリソースを要求する可能性もある。その後、ユーザは、アカウント情報をリモートネットワーク管理プラットフォーム３２０の適当なモジュールに入力するようにしてもよい。その後、これらのモジュールが自動的に、アカウントの管理可能なリソースを検出するとともに、使用、性能、および課金と関連するレポートを提供するようにしてもよい。

【0071】

Ｄ．通信サポートおよび他のオペレーション
インターネット３５０は、グローバルなインターネットの一部を表し得る。ただし、インターネット３５０は代替として、プライベートワイドエリアまたはローカルエリアパケット交換ネットワーク等、異なる種類のネットワークを表し得る。

【0072】

図４は、マネージドネットワーク３００と演算インスタンス３２２との間の通信環境をさらに示しており、付加的な特徴および代替実施形態を紹介するものである。図４においては、演算インスタンス３２２の全部または一部がデータセンタ４００Ａおよび４００Ｂの両者で複製されている。これらのデータセンタは、地理的に相互に離れていてもよく、おそらくは異なる都市または異なる国にある。各データセンタは、マネージドネットワーク３００のほか、リモートユーザとの通信を容易化するサポート設備を具備する。

【0073】

データセンタ４００Ａにおいては、外部機器に対するネットワークトラフィックがＶＰＮゲートウェイ４０２Ａまたはファイアウォール４０４Ａを通じて流れる。ＶＰＮゲートウェイ４０２Ａは、インターネットプロトコルセキュリティ（ＩＰＳＥＣ）またはトランスポート層セキュリティ（ＴＬＳ）等のセキュリティプロトコルによって、マネージドネットワーク３００のＶＰＮゲートウェイ４１２とピアリングされていてもよい。ファイアウォール４０４Ａは、ユーザ４１４およびリモートユーザ４１６等の正規のユーザからのアクセスを許可するとともに、不正なユーザのアクセスを拒否するように構成されていてもよい。ファイアウォール４０４Ａによって、これらのユーザは、演算インスタンス３２２および場合により他の演算インスタンスにアクセスすることができる。負荷分散器４０６Ａは、演算インスタンス３２２をホストする１つまたは複数の物理または仮想サーバ機器間でのトラフィックの分配に用いられるようになっていてもよい。負荷分散器４０６Ａは、クライアント機器からデータセンタ４００Ａの内部構成（たとえば、演算インスタンス３２２）を隠すことにより、ユーザアクセスを簡素化することができる。たとえば、複数のデータベースへのアクセスを共有する複数の物理または仮想コンピュータ機器を演算インスタンス３２２が含む場合、負荷分散器４０６Ａは、あるコンピュータ機器またはデータベースがその他よりも著しく忙しい、ということがないように、これらのコンピュータ機器およびデータベース間でネットワークトラフィックおよび処理タスクを分配するようにしてもよい。いくつかの実施形態において、演算インスタンス３２２は、ＶＰＮゲートウェイ４０２Ａ、ファイアウォール４０４Ａ、および負荷分散器４０６Ａを含んでいてもよい。

【0074】

データセンタ４００Ｂは、データセンタ４００Ａの構成要素に関するそれ自体のバージョンを具備していてもよい。このため、ＶＰＮゲートウェイ４０２Ｂ、ファイアウォール４０４Ｂ、および負荷分散器４０６Ｂがそれぞれ、ＶＰＮゲートウェイ４０２Ａ、ファイアウォール４０４Ａ、および負荷分散器４０６Ａと同一または同様の動作を実行するようにしてもよい。さらに、リアルタイムまたは準リアルタイムのデータベース複製および／または他の動作によって、演算インスタンス３２２がデータセンタ４００Ａおよび４００Ｂにおいて同時に存在していてもよい。

【0075】

図４に示すようなデータセンタ４００Ａおよび４００Ｂは、冗長性および高い可用性を促進し得る。図４の構成においては、データセンタ４００Ａがアクティブで、データセンタ４００Ｂがパッシブである。このため、データセンタ４００Ａがマネージドネットワーク３００に対するすべてのトラフィックをサーブする一方、データセンタ４００Ｂの演算インスタンス３２２のバージョンは、準リアルタイムに更新される。両データセンタがアクティブである構成等、他の構成がサポートされていてもよい。

【0076】

データセンタ４００Ａが何らかの故障を起こしたり、ユーザが利用できなくなったりした場合は、データセンタ４００Ｂがアクティブなデータセンタとして引き継ぐことができる。たとえば、演算インスタンス３２２のドメイン名をデータセンタ４００Ａの１つまたは複数のインターネットプロトコル（ＩＰ）アドレスと関連付けるドメインネームシステム（ＤＮＳ）サーバは、ドメイン名をデータセンタ４００Ｂの１つまたは複数のＩＰアドレスと再度関連付けるようにしてもよい。この再関連付けが完了した後（１秒または数秒未満と考えられる）、ユーザは、データセンタ４００Ｂによって演算インスタンス３２２にアクセス可能となる。

【0077】

また、図４は、マネージドネットワーク３００の考え得る構成を示している。上述の通り、プロキシサーバ３１２およびユーザ４１４は、ファイアウォール３１０を通じて演算インスタンス３２２にアクセス可能である。また、プロキシサーバ３１２は、設定項目４１０にもアクセス可能である。図４において、設定項目４１０は、クライアント機器３０２、サーバ機器３０４、ルータ３０６、および仮想マシン３０８のいずれかまたはすべて、これらの任意の構成要素、そこで実行される任意のアプリケーションまたはサービスのほか、機器、構成要素、アプリケーション、およびサービス間の関係を表し得る。このため、用語「設定項目（ｃｏｎｆｉｇｕｒａｔｉｏｎ ｉｔｅｍ）」は、任意の物理的もしくは仮想的機器、演算インスタンス３２２によるリモート検出または管理が可能な任意のアプリケーションもしくはサービス、または検出された機器、アプリケーション、およびサービス間の関係の一部または全部を表す略記であってもよい。設定項目は、演算インスタンス３２２の設定管理データベース（ＣＭＤＢ）において表され得る。

【0078】

格納または送信に際して、設定項目は、当該設定項目が表すハードウェアまたはソフトウェアを特性化する属性のリストであってもよい。これらの属性には、製造者、ベンダー、場所、所有者、一意の識別子、説明、ネットワークアドレス、動作状態、シリアル番号、最終更新時間等を含み得る。設定項目のクラスは、設定項目に対して存在する属性の部分集合を決定し得る（たとえば、ソフトウェアおよびハードウェアの設定項目は、異なる属性リストを有し得る）。

【0079】

上述の通り、ＶＰＮゲートウェイ４１２は、専用のＶＰＮをＶＰＮゲートウェイ４０２Ａに提供し得る。このようなＶＰＮは、マネージドネットワーク３００と演算インスタンス３２２との間に大量のトラフィックが存在する場合、あるいは、セキュリティポリシーがこれらのサイト間でのＶＰＮの使用を示唆または要求する場合に役立ち得る。いくつかの実施形態において、ＶＰＮを介して直接通信するマネージドネットワーク３００および／または演算インスタンス３２２の任意の機器には、パブリックＩＰアドレスが割り当てられる。マネージドネットワーク３００および／または演算インスタンス３２２の他の機器には、プライベートＩＰアドレス（たとえば、１０．０．０．０～１０．２５５．２５５．２５５または１９２．１６８．０．０～１９２．１６８．２５５．２５５の範囲から選択されたＩＰアドレスであって、それぞれがサブネット１０．０．０．０／８および１９２．１６８．０．０／１６として略記される）が割り当てられ得る。種々代替案において、プロキシサーバ３１２等のマネージドネットワーク３００の機器は、セキュアなプロトコル（たとえば、ＴＬＳ）を使用して、１つまたは複数のデータセンタと直接通信するようにしてもよい。

【0080】

ＩＶ．例示的な検出
リモートネットワーク管理プラットフォーム３２０は、マネージドネットワーク３００の機器、アプリケーション、およびサービスを管理するため、マネージドネットワーク３００に存在する機器、これらの機器の構成、構成要素、および動作状態、ならびに機器が提供するアプリケーションおよびサービスを最初に決定するようにしてもよい。また、リモートネットワーク管理プラットフォーム３２０は、検出された機器、それぞれの構成要素、アプリケーション、およびサービス間の関係を決定するようにしてもよい。各機器、構成要素、アプリケーション、およびサービスの表現を設定項目と称する場合がある。マネージドネットワーク３００内の設定項目および関係を決定するプロセスを検出と称するが、これは、プロキシサーバ３１２によって少なくとも部分的に容易化され得る。設定項目および関係の表現は、ＣＭＤＢに格納される。

【0081】

本項では、マネージドネットワーク３００に実行される検出を記載するが、パブリッククラウドネットワーク３４０上でも同一または同様の検出手順が用いられるようになっていてもよい。このため、いくつかの環境において、「検出」は、マネージドネットワークならびに／または１つもしくは複数のパブリッククラウドネットワーク上での設定項目および関係の検出を表し得る。

【0082】

本明細書の実施形態のため、「アプリケーション」は、１つもしくは複数のプロセス、スレッド、プログラム、クライアントソフトウェアモジュール、サーバソフトウェアモジュール、または機器もしくは機器群上で実行されるその他任意のソフトウェアを表し得る。「サービス」は、相互に連携して作用する１つまたは複数の機器上で実行される１つまたは複数のアプリケーションが提供する高度な機能を表し得る。たとえば、ウェブサービスには、ある機器上で実行され、別の機器上で実行されるデータベースアプリケーションからの情報にアクセスする複数のウェブアプリケーションサーバスレッドを含み得る。

【0083】

図５は、設定項目および関係が検出され得る様子のほか、これらと関連する情報が格納され得る様子の論理的な描写である。簡素化のため、リモートネットワーク管理プラットフォーム３２０、パブリッククラウドネットワーク３４０、およびインターネット３５０は示していない。

【0084】

図５においては、ＣＭＤＢ５００、タスクリスト５０２、および識別・調停エンジン（ＩＲＥ）５１４の配設および／または動作が演算インスタンス３２２内で行われる。タスクリスト５０２は、演算インスタンス３２２とプロキシサーバ３１２との間の接続点を表す。タスクリスト５０２は、キューと称する場合もあるし、より詳細には、外部通信チャネル（ＥＣＣ）キューと称する場合もある。タスクリスト５０２は、キュー自体のみならず、キューの情報の追加、削除、および／または操作等、任意の関連する処理も表し得る。

【0085】

検出が行われると、演算インスタンス３２２は、プロキシサーバ３１２が１つまたは複数のバッチでこれらのタスクを要求するまで、プロキシサーバ３１２が実行すべき検出タスク（ジョブ）をタスクリスト５０２に格納するようにしてもよい。タスクをタスクリスト５０２に配置することは、プロキシサーバ３１２がそれぞれの検出動作を開始することのトリガあるいはきっかけとなり得る。たとえば、プロキシサーバ３１２がタスクリスト５０２を定期的または随時ポーリングするようにしてもよいし、その他何らかの方法でタスクリスト５０２の検出コマンドをプロキシサーバ３１２に通知するようにしてもよい。この代替または追加として、検出がトリガイベントに基づいて手動または自動でトリガされるようになっていてもよい（たとえば、１日に１回、特定の時間に、検出が自動的に開始となってもよい）。

【0086】

それにも関わらず、演算インスタンス３２２は、要求に応じて、これらの検出コマンドをプロキシサーバ３１２に送信するようにしてもよい。たとえば、プロキシサーバ３１２は、タスクリスト５０２を繰り返し問い合わせ、その中の次のタスクを取得し、タスクリスト５０２が空になるか、または、別の停止条件が達成されるまで、このタスクを実行するようにしてもよい。検出コマンドの受信に応答して、プロキシサーバ３１２は、マネージドネットワーク３００中のさまざまな機器、構成要素、アプリケーション、および／またはサービス（簡略化のため、図５においては機器５０４、５０６、５０８、５１０、および５１２で表される）への問い合わせを行うようにしてもよい。これらの機器、構成要素、アプリケーション、および／またはサービスは、それぞれの構成、動作、および／または状態に関する応答をプロキシサーバ３１２に与えるようにしてもよい。これに対して、プロキシサーバ３１２はその後、この検出情報をタスクリスト５０２に提供するようにしてもよい（すなわち、タスクリスト５０２は、プロキシサーバ３１２により要求されるまで検出コマンドを保持するための送信キューと、検出情報を読み出されるまで保持するための受信キューと、を有し得る）。

【0087】

ＩＲＥ５１４は、タスクリスト５０２から検出情報を取り出し、この検出情報を（たとえば、マネージドネットワーク３００上で検出された機器、構成要素、アプリケーション、および／またはサービスを表す）設定項目およびそれぞれの間の関係として編成するソフトウェアモジュールであってもよい。そして、ＩＲＥ５１４は、これらの設定項目および関係を格納のためＣＭＤＢ５００に与えるようにしてもよい。ＩＲＥ５１４の動作については、以下により詳しく説明する。

【0088】

このように、ＣＭＤＢ５００に格納された設定項目は、マネージドネットワーク３００の環境を表す。一例として、これらの設定項目は、一組の物理および／または仮想機器（たとえば、クライアント機器、サーバ機器、ルータ、または仮想マシン）、これら（たとえば、ウェブサーバ、電子メールサーバ、データベース、またはストレージアレイ）の上で実行されるアプリケーションのほか、複数の個々の設定項目を含むサービスを表し得る。関係は、設定項目間の配置または依存関係のペア定義であってもよい。

【0089】

上述のような検出が行われるように、プロキシサーバ３１２、ＣＭＤＢ５００、ならびに／または１つもしくは複数の認証情報ストアには、検出対象の機器の認証情報が設定されていてもよい。認証情報には、機器へのアクセスに必要な任意の種類の情報を含み得る。これらには、ユーザＩＤ／パスワードのペア、証明書等を含み得る。いくつかの実施形態において、これらの認証情報は、ＣＭＤＢ５００の暗号化フィールドに格納されていてもよい。プロキシサーバ３１２は、認証情報を用いた検出対象の機器へのログオンあるいはアクセスが可能となるように、これらの認証情報の復号キーを含んでいてもよい。

【0090】

検出には、水平および垂直（トップダウン）という２つの一般的な種類が存在する。それぞれを以下に論じる。

【0091】

Ａ．水平検出
水平検出は、マネージドネットワーク３００をスキャンし、機器、構成要素、および／またはアプリケーションを探索した後、これらの機器、構成要素、および／またはアプリケーションを表す設定項目をＣＭＤＢ５００に入力するのに用いられる。また、水平検出では、設定項目間の関係を生成する。たとえば、ソフトウェアアプリケーションを表す設定項目とそれが実行されるサーバ機器を表す設定項目との間の「実行」関係が可能である。通常、水平検出ではサービスを認識しておらず、動作するサービスに基づいて設定項目間の関係を生成することはない。

【0092】

水平検出には２つのバージョンが存在する。一方がプローブおよびセンサに依拠する一方、他方はパターンも採用する。プローブおよびセンサは、機器上で検出情報を収集および処理した後、これに応じてＣＭＤＢ５００を更新する（たとえば、ＪＡＶＡＳＣＲＩＰＴ（登録商標）で書かれた）スクリプトであってもよい。より具体的には、プローブがマネージドネットワーク３００上の機器を探索または調査し、センサがプローブから返された検出情報を分析する。

【0093】

パターンもスクリプトであって、１つまたは複数の機器上のデータを収集および処理して、ＣＭＤＢを更新する。パターンは、特定の検出プログラミング言語で書かれており、より一般的なプローブおよびセンサでは確実な検出が不可能である（または、一切検出できない）ことが多い特定の機器、構成要素、および／またはアプリケーション上で詳細な検出手順を実行するのに用いられる点において、プローブおよびセンサと異なる。特に、パターンは、特定の配置の機器、構成要素、および／またはアプリケーションの検出方法と、使用する認証情報と、この検証の結果としての設定項目を入力するＣＭＤＢテーブルと、を規定する一連の動作を指定することができる。

【0094】

いずれのバージョンも、スキャン、分類、識別、および探索という４つの論理的な段階を踏むことができる。また、いずれのバージョンも、検出が行われるマネージドネットワーク３００上のＩＰアドレスの１つまたは複数の範囲の指定を要する場合がある。各段階には、マネージドネットワーク３００上の機器とプロキシサーバ３１２との間のほか、プロキシサーバ３１２とタスクリスト５０２との間の通信を含み得る。いくつかの段階では、一部または予備の設定項目をＣＭＤＢ５００に格納し得るが、これは、後の段階で更新され得る。

【0095】

スキャン段階において、プロキシサーバ３１２は、オープンな伝送制御プロトコル（ＴＣＰ）および／またはユーザデータグラムプロトコル（ＵＤＰ）ポートについて、ＩＰアドレスの指定された範囲内の各ＩＰアドレスをプローブすることにより、機器の一般的な種類およびそのオペレーティングシステムを決定するようにしてもよい。このようなオープンポートがＩＰアドレスに存在することは、当該ＩＰアドレスが割り当てられた機器上で特定のアプリケーションが動作していることを示し、これによって、当該機器が使用するオペレーティングシステムを識別可能である。たとえば、ＴＣＰポート１３５がオープンな場合、この機器は、ＷＩＮＤＯＷＳ（登録商標）オペレーティングシステムを実行している可能性が高い。同様に、ＴＣＰポート２２がオープンな場合、この機器は、ＬＩＮＵＸ（登録商標）等のＵＮＩＸ（登録商標）オペレーティングシステムを実行している可能性が高い。ＵＤＰポート１６１がオープンな場合、この機器は、簡易ネットワーク管理プロトコル（ＳＮＭＰ）を通じて別途識別可能となり得る。それ以外の可能性もある。

【0096】

分類段階において、プロキシサーバ３１２は、各検出機器をさらにプローブして、そのオペレーティングシステムの種類を決定するようにしてもよい。特定の機器に使用されるプローブは、スキャン段階に当該機器に関して収集された情報に基づく。たとえば、ＴＣＰポート２２がオープンな機器が見つかった場合は、一組のＵＮＩＸ（登録商標）固有のプローブが用いられるようになっていてもよい。同様に、ＴＣＰポート１３５がオープンな機器が見つかった場合は、一組のＷＩＮＤＯＷＳ（登録商標）固有のプローブが用いられるようになっていてもよい。いずれの場合も、適当な一組のタスクがタスクリスト５０２に配置され、プロキシサーバ３１２がこれを実行するようになっていてもよい。これらのタスクにより、プロキシサーバ３１２は、特定の機器からの情報にログオンあるいはアクセス可能となる。たとえば、ＴＣＰポート２２がオープンな場合、プロキシサーバ３１２は、特定の機器に対するセキュアシェル（ＳＳＨ）接続を開始し、ファイルシステムの特定の場所から、機器上のオペレーティングシステムの特定の種類に関する情報を取得するように指示され得る。この情報に基づいて、オペレーティングシステムが決定されるようになっていてもよい。一例として、ＴＣＰポート２２がオープンなＵＮＩＸ（登録商標）機器は、ＡＩＸ（登録商標）、ＨＰＵＸ、ＬＩＮＵＸ（登録商標）、ＭＡＣＯＳ（登録商標）、またはＳＯＬＡＲＩＳ（登録商標）として分類される。この分類情報は、１つまたは複数の設定項目としてＣＭＤＢ５００に格納されていてもよい。

【0097】

識別段階において、プロキシサーバ３１２は、分類された機器に関する具体的詳細を決定するようにしてもよい。この段階において使用されるプローブは、分類段階に特定の機器に関して収集された情報に基づいていてもよい。たとえば、機器がＬＩＮＵＸ（登録商標）として分類された場合は、一組のＬＩＮＵＸ（登録商標）固有のプローブが用いられるようになっていてもよい。同様に、機器がＷＩＮＤＯＷＳ（登録商標）１０として分類された場合は、一組のＷＩＮＤＯＷＳ（登録商標）１０固有のプローブが用いられるようになっていてもよい。分類段階の場合と同様に、適当な一組のタスクがタスクリスト５０２に配置され、プロキシサーバ３１２がこれを実行するようになっていてもよい。これらのタスクにより、プロキシサーバ３１２は、特定の機器から、基本入力／出力システム（ＢＩＯＳ）情報、シリアル番号、ネットワークインターフェース情報、これらのネットワークインターフェースに割り当てられた媒体アクセス制御アドレス、特定の機器が使用するＩＰアドレス等の情報を世読み出し可能となる。この識別情報は、１つまたは複数の設定項目として、両者間の任意の関連する関係と併せてＣＭＤＢ５００に格納されていてもよい。この際、ＩＲＥ５１４を通じて識別情報を受け渡すことにより、曖昧性解消を目的とした重複設定項目の生成の回避および／または検出情報を書き込むべきＣＭＤＢ５００のテーブルの決定を行うようにしてもよい。

【0098】

探索段階において、プロキシサーバ３１２は、分類された機器の動作状態に関する別途詳細を決定するようにしてもよい。この段階において使用されるプローブは、分類段階および／または識別段階に特定の機器に関して収集された情報に基づいていてもよい。この場合も、適当な一組のタスクがタスクリスト５０２に配置され、プロキシサーバ３１２がこれを実行するようになっていてもよい。これらのタスクにより、プロキシサーバ３１２は、特定の機器から、プロセッサ情報、メモリ情報、実行プロセス（ソフトウェアアプリケーション）のリスト等の付加的な情報を読み出し可能となる。ここで再度、検出情報は、１つまたは複数の設定項目および関係として、ＣＭＤＢ５００に格納されていてもよい。

【0099】

スイッチおよびルータ等の特定の機器上で水平検出を実行する場合は、ＳＮＭＰを利用するようにしてもよい。実行プロセスまたは他のアプリケーション関連情報のリストの決定の代替または追加として、検出では、ルータが既知の付加的なサブネットおよびルータのネットワークインターフェースの動作状態（たとえば、アクティブ、非アクティブ、キュー長、脱落パケット数等）を決定するようにしてもよい。付加的なサブネットのＩＰアドレスは、他の検出手順の候補となり得る。このため、水平検出は、反復的または再帰的に進行し得る。

【0100】

パターンは、識別段階および探索段階においてのみ使用される。パターンベースの検出では、プローブおよびセンサが使用される場合のようにスキャン段階および分類段階が作用する。分類段階の完了後は、識別に使用するプローブとしてパターンプローブが指定される。その後、パターンプローブおよびそれが指定するパターンが起動される。

【0101】

パターンは、検出プログラミング言語によって、プローブおよびセンサを使用する検出では利用不可能または実現困難な多くの機能をサポートする。たとえば、パターンベースの検出を使用することにより、パブリッククラウドネットワークにおける機器、構成要素、および／またはアプリケーションの検出のほか、設定ファイルの追跡の実現がはるかに容易となる。さらに、これらのパターンは、プローブおよびセンサよりも容易に、ユーザがカスタマイズ可能である。また、パターンは、特定の機器、構成要素、および／またはアプリケーションにより焦点を合わせているため、プローブおよびセンサが使用するより一般的な手法よりも高速に実行可能である。

【0102】

水平検出が完了となったら、ＣＭＤＢ５００において、各検出機器、構成要素、および／またはアプリケーションの設定項目表現が利用可能となる。たとえば、検出後は、マネージドネットワーク３００中のクライアント機器、サーバ機器、およびルータのオペレーティングシステムバージョン、ハードウェア構成、およびネットワーク構成詳細のほか、それらの上で実行されるアプリケーションが設定項目として格納されるようになっていてもよい。これらの収集情報は、さまざまな方法でユーザに提示されることにより、機器のハードウェア構成および動作状態をユーザが確認可能となり得る。

【0103】

さらに、ＣＭＤＢ５００は、設定項目間の関係に関するエントリを含んでいてもよい。より具体的には、サーバ機器が多くのハードウェアコンポーネント（たとえば、プロセッサ、メモリ、ネットワークインターフェース、ストレージ、およびファイルシステム）を含み、これらにおいて複数のソフトウェアアプリケーションがインストールまたは実行されるものとする。構成要素とサーバ機器との間の関係（たとえば、「包含」関係）およびソフトウェアアプリケーションとサーバ機器との間の関係（たとえば、「実行」関係）は、ＣＭＤＢ５００においてそのように表され得る。

【0104】

より一般的に、ハードウェア設定項目においてインストールまたは実行されるソフトウェア設定項目の関係は、ホスティング、実行、または依存等のさまざまな形態であってもよい。このため、サーバ機器にインストールされたデータベースアプリケーションは、サーバ機器と「ホスティング」の関係を有することにより、当該データベースアプリケーションがサーバ機器にホストされていることを示し得る。いくつかの実施形態において、サーバ機器は、データベースアプリケーションと「使用」の相互関係を有することにより、当該サーバ機器がデータベースアプリケーションにより使用されることを示し得る。これらの関係は、上述の検出手順を使用して自動的に見つけられるようになっていてもよいが、関係を手動で設定することも可能である。

【0105】

このように、リモートネットワーク管理プラットフォーム３２０は、マネージドネットワーク３００上で展開されて提供されるハードウェアおよびソフトウェアを検出して一覧化することができる。

【0106】

Ｂ．垂直検出
垂直検出は、ウェブサービス等の全体サービスの一部である設定項目の探索およびマッピングに用いられる技術である。たとえば、垂直検出では、ウェブサーバアプリケーション、ＬＩＮＵＸ（登録商標）サーバ機器、およびウェブサービス用のデータを格納するデータベース間の関係を示すことによって、ウェブサービスをマッピングすることができる。通常は、設定項目およびそれらの間の基本的関係を見出すために水平検出が最初に実行された後、サービスを構成する設定項目間の関係を確立するために垂直検出が実行される。

【0107】

パターンの使用によって、特定の種類のサービスを検出することができる。これらのパターンは、サービスの展開の様子に関する記述に適合するハードウェアおよびソフトウェアの特定の配置を探索するようにプログラム可能なためである。この代替または追加として、トラフィック分析（たとえば、機器間のネットワークトラフィックの調査）の使用により、垂直検出を容易化することも可能である。場合によっては、垂直検出の補助となるように、サービスのパラメータを手動で設定することも可能である。

【0108】

一般的に、垂直検出では、機器、構成要素、および／またはアプリケーション間の特定の種類の関係を見つけようとする。これらの関係のうちのいくつかは、設定ファイルから推測され得る。たとえば、ウェブサーバアプリケーションの設定ファイルは、それが依拠するデータベースのＩＰアドレスおよびポート番号を表し得る。垂直検出パターンは、このような参照の探索およびそれによる関係の推測を行うようにプログラム可能である。また、機器間のトラフィックから関係を推測することも可能である。たとえば、負荷分散器とウェブサーバをホストする機器との間で大量のウェブトラフィック（たとえば、ＴＣＰポート８０または８０８０）が往来している場合は、負荷分散器およびウェブサーバが何らかの関係を有すると考えられる。

【0109】

垂直検出により見出される関係は、さまざまな形態であってもよい。一例として、電子メールサービスは、それぞれが異なるハードウェア機器設定項目にインストールされた電子メールサーバソフトウェア設定項目およびデータベースアプリケーションソフトウェア設定項目を含み得る。電子メールサービスがこれらのソフトウェア設定項目との「依存」関係を有し得る一方、ソフトウェア設定項目は、電子メールサービスと「使用」の相互関係を有する。このようなサービスは、水平検出手順では完全に決定できない可能性もあるため、代わりに、垂直検出および場合によりある程度の手動設定に依拠していてもよい。

【0110】

Ｃ．検出の利点
検出情報は、取得方法に関わらず、マネージドネットワークの運用に有益となり得る。とりわけ、ＩＴ担当者は、特定のソフトウェアアプリケーションが展開されている場所およびサービスを構成する設定項目を迅速に決定することができる。これにより、サービスの停止または劣化の根本原因を迅速に突き止めることができる。たとえば、２つの異なるサービスの応答時間が遅い場合は、（可能性として数ある行為の中でもとりわけ）ＣＭＤＢへの問い合わせによって、両サービスが使用するデータベースアプリケーションのプロセッサ利用率が高いことが根本原因であるものと判定することができる。このため、ＩＴ担当者は、サービスを構成する他の設定項目の健全性および性能の検討に時間を浪費することなく、データベースアプリケーションに対処することができる。

【0111】

別の例においては、データベースアプリケーションがサーバ機器上で実行されており、また、このデータベースアプリケーションが従業員研修サービスのほか、給与計算サービスで使用されるものとする。このため、サーバ機器が保守のため稼働を停止した場合は、従業員研修サービスおよび給与計算サービスが明らかに影響を受けることになる。同様に、設定項目間の依存および関係は、特定のハードウェア機器が故障した場合に影響を受けるサービスを表し得ると考えられる。

【0112】

一般的に、設定項目および／または設定項目間の関係は、ウェブベースのインターフェースに表示され、階層として表され得る。このインターフェースによって、ＣＭＤＢにおける上記のような設定項目および／または関係の修正が達成され得る。

【0113】

さらに、マネージドネットワーク３００のユーザは、検出された複数の機器にわたる特定の調整済み行為の実行を可能にするワークフローを開発することができる。たとえば、ＩＴワークフローによって、ユーザは、検出されたすべてのＬＩＮＵＸ（登録商標）機器の共通管理者パスワードを単一の操作で変更可能となる可能性もある。

【0114】

Ｖ．ＣＭＤＢ識別ルールおよび調停
ＣＭＤＢ５００等のＣＭＤＢは、設定項目および関係のレポジトリを提供する。適正に規定された場合は、演算インスタンス内で展開されたより高位のアプリケーションまたは演算インスタンスを含むより高位のアプリケーションにおいて、重要な役割を担うことができる。これらのアプリケーションは、企業のＩＴサービス管理、業務管理、資産管理、設定管理、法令順守等に関連し得る。

【0115】

たとえば、ＩＴサービス管理アプリケーションは、ＣＭＤＢの情報を使用して、機能不全、機能停止、または高負荷の構成要素（たとえば、サーバ機器）の影響を受ける可能性があるアプリケーションおよびサービスを決定するようにしてもよい。同様に、資産管理アプリケーションは、ＣＭＤＢの情報を使用して、特定の企業アプリケーションのサポートに使用されるハードウェアおよび／またはソフトウェアコンポーネントを決定するようにしてもよい。ＣＭＤＢの重要性の結果として、そこに格納される情報は、正確で一貫性があり、最新であることが望ましい。

【0116】

ＣＭＤＢへの入力は、さまざまな方法で行うことができる。上述の通り、検出手順では、設定項目および関係を含む情報をＣＭＤＢに自動的に格納するようにしてもよい。ただし、ＣＭＤＢへの入力の全部または一部は、手動入力、設定ファイル、およびサードパーティデータソースにより行うことも可能である。複数のデータソースがいつでもＣＭＤＢを更新可能となり得る点を所与として、あるデータソースが別のデータソースのエントリを上書き可能である。また、２つのデータソースがそれぞれ、同じ設定項目に対してわずかに異なるエントリを生成するようにしてもよく、その結果、ＣＭＤＢが重複データを含むことになる。これらのいずれかが発生すると、ＣＭＤＢの健全性および有用性が低下し得る。

【0117】

この状況を緩和するため、これらのデータソースは、設定項目を直接はＣＭＤＢに書き込まない可能性もある。代わりに、ＩＲＥ５１４の識別・調停アプリケーションプログラミングインターフェース（ＡＰＩ）に書き込むようにしてもよい。その後、ＩＲＥ５１４が一組の設定可能な識別ルールを使用することにより、設定項目を一意に識別するとともに、ＣＭＤＢへの書き込みの有無およびその方法を判定するようにしてもよい。

【0118】

一般的に、識別ルールは、この一意の識別に使用可能な一組の設定項目属性を指定する。また、識別ルールには優先順位があり、優先順位の高いルールが優先順位の低いルールの前に考慮されるようになっていてもよい。また、ルールは、設定項目を他の設定項目とは独立に識別する点において、独立したものと考えられる。あるいは、ルールは、最初にメタデータルールを使用して依存する設定項目を識別する点において、依存したものと考えられる。

【0119】

メタデータルールは、特定の設定項目に含まれる他の設定項目または特定の設定項目が展開されるホストを記述する。たとえば、ネットワークディレクトリサービス設定項目がドメインコントローラ設定項目を含み得る一方、ウェブサーバアプリケーション設定項目は、サーバ機器設定項目にホストされていてもよい。

【0120】

各識別ルールの目標は、設定項目を他のすべての設定項目から明確に区別することができ、設定項目の存続期間に変化しないと予想される属性の組み合わせを使用することである。例示的なサーバ機器に対して考え得る属性としては、シリアル番号、場所、オペレーティングシステム、オペレーティングシステムバージョン、メモリ容量等が挙げられる。設定項目を一意に識別しない属性をルールが指定する場合は、ＣＭＤＢにおいて、複数の構成要素が同じ設定項目として表される可能性もある。また、特定の設定項目に対して変化する属性をルールが指定する場合は、重複設定項目が生成される可能性もある。

【0121】

したがって、データソースが設定項目に関する情報をＩＲＥ５１４に提供する場合、ＩＲＥ５１４は、この情報を１つまたは複数のルールと照合しようとする可能性がある。一致が見られる場合は、設定項目がＣＭＤＢに書き込まれるか、ＣＭＤＢに既存の場合は更新される。一致が見られない場合は、設定項目が別途分析のため保持され得る。

【0122】

権限のあるデータソースのみがＣＭＤＢの設定項目データの上書きを許可されるように、設定項目調停手順が用いられるようになっていてもよい。この調停についても、ルールベースであってもよい。たとえば、特定の設定項目種別および一組の属性に対して特定のデータソースが権限を有するように調停ルールが指定してもよい。そして、この権限のあるデータソースによる特定の設定項目への書き込みのみをＩＲＥ５１４が許可する可能性もあり、不正なデータソースによる書き込みが防止され得る。このように、正規のデータソースは、特定の設定項目に関する唯一の真実の情報源となる。場合によっては、不正なデータソースが設定項目を生成している場合、または、書き込んでいる属性が空である場合に、設定項目への書き込みを許可される可能性がある。

【0123】

また、複数のデータソースが同じ設定項目またはその属性に対する権限を有する場合もある。明瞭化のため、これらのデータソースには、設定項目の書き込み時に考慮される優先権が割り当てられていてもよい。たとえば、第１位の権限を有するデータソースが設定項目の属性に書き込むまで、第２位の権限を有するデータソースがこの属性に書き込み可能となっていてもよい。その後は、第２位の権限を有するデータソースによる属性へのさらなる書き込みが阻止されるようになっていてもよい。

【0124】

場合によっては、重複設定項目のＩＲＥ５１４による自動検出または別の方法での検出が可能である。これらの設定項目は、手動での重複排除のため消去されるようになっていてもよいし、フラグ付けされるようになっていてもよい。

【0125】

ＶＩ．インシデントの報告および解決
本明細書に記載の大規模なネットワークを所与として、任意所与の時点では、一部のコンポーネント（たとえば、コンピュータ機器、システム、アプリケーション、サービス、および／またはネットワーク）の不適正な動作が避けられない。これらの欠陥は、設定不備、非互換性、ソフトウェアバグ、ハードウェア障害、またはリソース需給間の不一致（たとえば、機器のＲＡＭまたはディスクストレージの不足）に起因すると考えられる。これらの欠陥は、ユーザが依存するサービスの遅延、信頼性の低下、および／または停止の原因となる。明確に言うなら、これらは、１つまたは複数のハードウェアまたはソフトウェアコンポーネントが設計通りに動作しないため、システムのほかユーザにも悪影響が及ぶ点において、技術的課題である。

【0126】

これらのような欠陥は、「問題」と称する場合もあり、インシデントログ（「インシデント」、「ＩＴトラブルチケット」、または「チケット」と称する場合もある）により報告、調査、および解決がなされ得る。インシデントログは、コンピュータシステム、ソフトウェア、およびネットワークインフラと関連する問題の報告および追跡に用いられるドキュメントまたはレコードである。これらのインシデントログは通常、技術的困難を経験しているユーザにより生成された後、仮想エージェント（たとえば、チャットボット）および／または人間のエージェントに割り当てられて解決される。インシデントログは通常、ユーザの連絡先情報（たとえば、電子メールアドレスおよび電話番号）、ユーザが書いた問題の説明、インシデントが生成された日時、ならびに任意の関連するシステム詳細（たとえば、ユーザのクライアント機器および／もしくはローカルネットワーク）等の情報を含むことになる。エージェントが問題を解決しようとすると、講じられる調査ステップ、問題の状態等の付加的な情報がインシデントログに追加される場合もある。

【0127】

本明細書の実施形態は、インシデントログの背景において説明するが、他種のログでも同様に使用可能である。このため、後述の例は、例示を目的としたものであって、何ら限定的ではない。

【0128】

通常、インシデントログは、ユーザおよびエージェントによる各措置のタイムスタンプ付きレコードのほか、ユーザとエージェントの間の任意の相互作用を含む１つまたは複数の関連するテキストファイルまたはデータベースエントリの形態である。このテキストコンテンツには、ユーザの問題の説明、ユーザとエージェントとの間の会話、エージェントの調査メモ（エージェントによる診断ステップの出力を含む場合がある）、問題の根本原因の説明（該当する場合）、および問題への対処（対応）に講じられる解決ステップの説明を含んでいてもよい。

【0129】

問題が報告されても、その根本原因は明らかとなっていない可能性がある。インシデントログに現れる問題の最初の説明は、曖昧な場合もある。たとえば、ユーザは、「ネットワークに接続できません」という問題の説明を含むインシデントログを生成する場合もある。すると、この問題を調査するエージェントは、ユーザが利用しているクライアント機器の種類（たとえば、ラップトップ、携帯電話、もしくはタブレット）、この機器で使用されているオペレーティングシステム、ならびにユーザがアクセスしようとしているネットワークを決定しようとする。

【0130】

このため、エージェントは、ユーザの運用環境が識別されるように、（たとえば、電話、電子メール、および／またはチャットセッションによって）一連の質問をユーザに投げかける場合もある。その後、エージェントは、インターフェースのリセット、構成設定の変更、または再起動等の１つまたは複数のステップの機器に対する実行をユーザに求める場合もある。また、エージェントは、ユーザの近くのルータまたはＷｉｆｉアクセスポイントにリモートアクセスしてこれらの機器およびこれらの機器を一部とするネットワークの状態を確認すること等、多くのステップを実行する場合もある。ユーザまたはエージェントの措置の一部には、問題の詳細な洞察を提供し得る診断ツール（たとえば、アプリまたはスクリプト）の実行を伴う可能性もある。

【0131】

最終的に、エージェントは、問題の根本原因を識別し得る。たとえば、ユーザがそれぞれのローカルのＷｉｆｉアクセスポイントを使用できないものと仮定する。考え得る根本原因としては、他の機器からの無線干渉、アクセスポイントまでの距離、ユーザのクライアント機器の不正確なＷｉｆｉ設定、アクセスポイントにインストールされているファームウェアの期限切れ、アクセスポイントのハードウェア障害、Ｗｉｆｉネットワークまたはダウンストリームネットワークの過負荷等が挙げられる。これらのうちのいずれが実際の根本原因であるかを判定するため、エージェントは、潜在的に多くの調査ステップを要する可能性がある。

【0132】

上述の通り、各調査ステップの結果は、根本原因の決定に成功するか否かに関わらず、インシデントログに記録されるようになっていてもよい。また、任意の診断ツールからの出力も同様に、記録されるようになっていてもよい。

【0133】

根本原因が識別されると、通例は解決策が明確になる。たとえば、あまりにも遠く離れた（そのため、ユーザの場所では信号強度が低い）Ｗｉｆｉアクセスポイントにユーザが接続しようとしていることが根本原因である場合は、解決策として、ユーザがアクセスポイントの近くに移動することも考えられるし、より近いアクセスポイントに接続することも考えられる。（おそらくはファームウェアのメモリリーク欠陥による）アクセスポイントのメモリ不足が根本原因である場合は、解決策として、エージェントがアクセスポイントを再起動することも考えられる。いずれにしろ、問題を解決する任意の関係者による措置もまた、インシデントログに記録されるようになっていてもよい。

【0134】

ユーザが解決策に満足した場合あるいは問題によって阻害されなくなった場合には、インシデントログが閉じられるようになっていてもよい。ただし、閉じられたインシデントログは、監査のほか、将来的な類似問題の解決の補助を目的として、データベースに保持される。このため、中程度の規模の組織であっても、データベースが時間とともに大きくなって、数万以上のインシデントログを含む場合がある。

【0135】

本明細書の実施形態の一般的背景が潜在的に多くのユーザを含むエンタープライズネットワークの背景であるにも関わらず、記載の技術は、ユーザがより少ない小さな環境にも適用可能である。たとえば、住宅、ホームオフィス、または小規模オフィスのユーザが経験する問題に対して同様に対処することも可能である。したがって、これらの実施形態の適用可能性は、本明細書に記載の実施形態に限定されない。

【0136】

図６Ａは、一連のイベントを含むインシデントログからの例示的な抜粋を示している。このシーケンスは、ユーザが報告した問題、エージェントによる調査ステップ、根本原因の決定、および問題のその後の解決に焦点を当てている。各イベントは、タイムスタンプ、当事者（イベントを起こした人物もしくはエージェント）、ならびにイベントを記述するテキストを有する。

【0137】

イベント６００では、ユーザＪｏｈｎ Ｄｏｅがインシデントログ（チケット００００００１）を開く。このイベントは、ユーザの連絡先情報および経験している問題の簡単な説明を含む。この場合、報告されている問題の症状は、ユーザがネットワークに接続できないことである。

【0138】

イベント６０２では、インシデントログがエージェントＪａｎｅ Ｓｍｉｔｈに割り当てられる。

【0139】

イベント６０４には、エージェントがユーザと話し合い、ユーザのラップトップのブランドおよびモデルのほか、そのオペレーティングシステムを決定する調査ステップを含む。

【0140】

イベント６０６には、ユーザのラップトップが良好な信号強度でＷｉｆｉアクセスポイントに接続されているものとエージェントが判定する調査ステップを含む。

【0141】

イベント６０８には、使用するウェブブラウザに関係なく、ユーザが如何なるウェブサイトにもアクセスできないものとエージェントが判定する調査ステップを含む。

【0142】

イベント６１０には、エージェントがユーザのラップトップに対して「ｐｉｎｇ」トランザクションを実行しも応答がない調査ステップを含む。ｐｉｎｇは、あるコンピュータから別のコンピュータにパケットを送信し、コンピュータ相互間のレイテンシの推定値と併せて対応する応答を受信するアプリケーションである。

【0143】

イベント６１２には、エージェントがＷｉｆｉアクセスポイントに対して「ｐｉｎｇ」トランザクションを実行し、ｐｉｎｇ時間が不規則で長いことから、エージェントのコンピュータとＷｉｆｉアクセスポイントとの間にパケットロスが存在するものと判定する調査ステップを含む。

【0144】

イベント６１４では、根本原因を識別する。エージェントは、Ｗｉｆｉアクセスポイントのメモリ利用が非常に高く（９８％）、約６カ月間にわたって再起動されていないことを根本原因として決定する。

【0145】

イベント６１６では、問題を解決する。エージェントは、Ｗｉｆｉアクセスポイントを再起動して、ユーザがネットワークにアクセス可能となり、Ｗｉｆｉアクセスポイントが正常に動作しているものと判定する。

【0146】

イベント６１８では、エージェントがインシデントログを解決済みとしてマークする。

【0147】

とりわけ、イベント６００は、ユーザが経験している問題の症状を表す。イベント６０４、６０６、６０８、６１０、および６１２は、調査ステップを表す。イベント６１４は、問題の根本原因を表し、イベント６１６は、問題の解決策を表す。この一連のイベントは、根本原因の決定前に複数の調査ステップが存在する点において典型的である。イベント６０２および６１８は、問題、調査、根本原因、または解決策とは厳密に関連しないインシデントログ管理ステップである。

【0148】

図６Ｂは、インシデントログからの別の例示的な抜粋を示している。

【0149】

イベント６５０では、ユーザＴｅｒｉ Ｄａｃｔｙｌがインシデントログ（チケット００００００４）を開く。このイベントは、ユーザの連絡先情報および経験している問題の簡単な説明を含む。この場合、報告されている問題の症状は、ユーザがＷｉｆｉにアクセスできないことである。

【0150】

イベント６５２では、インシデントログがエージェントＢｏｂ Ｊｏｎｅｓに割り当てられる。

【0151】

イベント６５４では、問題の症状に関する別途詳細を追加するようにインシデントログが更新される。

【0152】

イベント６５６には、エージェントがユーザに更新パスワードを提供するものの、この新たなパスワードでも上手くいかないことが分かる調査ステップを含む。

【0153】

イベント６５８には、認証サーバがユーザにＷｉｆｉの使用を許可していなかったものとエージェントが判定した後、この許可を与える調査ステップを含む。

【0154】

イベント６６０では、根本原因を識別し、問題を解決する。エージェントは、認証サーバのユーザの認証情報が古くなっていたものと判定し、アクセスを許可するように更新して、ユーザがＷｉｆｉを使えるようにした。また、このイベントでは、インシデントログが解決済みとマークされる。

【0155】

イベント６６２では、インシデントログが閉じられる。

【0156】

とりわけ、イベント６５０および６５４は、ユーザが経験している問題の症状を表す。イベント６５６および６５８は、調査ステップを表す。イベント６６０は、問題の根本原因のほか、問題の解決策を表す。イベント６５２および６６２は、問題、調査、根本原因、または解決策とは厳密に関連しないインシデントログ管理ステップである。図６Ａの一連のイベントと異なり、この一連のイベントは、症状を表す２つの別個のイベントと、根本原因および解決策の両者を表す１つのイベントと、を有する。

【0157】

これら２つの例だけでも、症状、調査ステップ、根本原因の決定、および解決策を実行するとともにインシデントログに表示し得るさまざまな方法を示している。一方、インシデントログにおいては、このコンテンツの他の構成も可能である。このため、図６Ａおよび図６Ｂの例は、例示を目的としたものであって、何ら限定的ではない。

【0158】

インシデントログには豊富な情報が存在する。また、上述の通り、多くの組織では、毎週、毎月、毎四半期等に、このようなログを大量に（たとえば、数十、数百、または数千）生成する。組み合わせとして、インシデントログには、組織の記憶（組織が経験した問題およびその解決方法のレコード）を含むことができ、これは将来、類似問題を解決しようとする際に有益となり得る。

【0159】

したがって、組織は、そのインシデントログのマイニングによって、所与の問題を最も迅速かつ効率的に解決する可能性が最も高い調査ステップを決定し得る恩恵を享受することができる。そして、エージェントは、根本原因を決定して新たな問題を解決しようとする際に、この洞察の使用またはこの洞察によるガイドが可能である。潜在的に重要な観察結果の１つとして、すべての調査ステップが等しく、根本原因の決定に至る可能性が高いわけではない。

【0160】

たとえば、図６Ａのインシデントログの場合、イベント６０４においてユーザのラップトップのブランド、モデル、およびオペレーティングシステムを取得することは、根本原因の決定に寄与していない。一方、イベント６１２においてＷｉｆｉアクセスポイントにｐｉｎｇを実行すること、および、イベント６１４においてアクセスポイントへのリモートアクセスによりメモリ利用を決定することは、問題の根本原因および解決策の確認に直接つながっている。

【0161】

本明細書の実施形態は、さまざまな種類の機械学習ベースの自然言語処理ツールを使用してインシデントログを処理するための技術を提供する。これらの技術は結果として、将来的に遭遇する類似インシデントに対処しつつ、エージェントの進め方のガイドとして使用可能な過去のインシデントログの要約および特性化となる。まず、既存のインシデントログのコーパスの使用によって、インシデントログモデルをトレーニングする。その後、このモデルの使用により、後続インシデントの根本原因の決定に至る可能性が最も高い調査ステップを予測する。

【0162】

図７Ａは、トレーニング段階を示している。これらのブロックについてはそれぞれ、以下により詳しく規定する。

【0163】

ブロック７００では、インシデントログを前処理して、モデルのトレーニングへの使用に備える。ブロック７０２では、インシデントログからのイベントを要約して、より短く、なおかつ関連するテキスト表現を取得する。ブロック７０４では、要約したイベントを症状、調査ステップ、根本原因、および解決策に分類する。ブロック７０６では、イベントのクラスごとにクラスタ空間を決定する。ブロック７０８では、イベントのクラスタ間の確率的関係を決定する。これらの確率的関係は、任意特定の調査ステップが所与の問題の根本原因の決定に至る尤度を提供する。

【0164】

図７Ｂは、予測段階を示している。これらのブロックについてはそれぞれ、以下により詳しく規定する。

【0165】

ブロック７５０では、新たなインシデントログの前処理、要約、および／または分類によって、モデルとの併用に備える。ブロック７５２では、症状クラスタ空間から、新たなインシデントログに類似する１つまたは複数の症状を決定する。ブロック７５４では、調査ステップクラスタ空間から、根本原因の決定に至る可能性が最も高い調査ステップを選択する。ブロック７５４は、２つ以上の調査ステップに対して実行され得るため、未選択の調査ステップのみが考慮される。ブロック７５６では、選択した調査ステップに基づいて根本原因が決定されたかを判定する。決定されていない場合は、制御がブロック７５４に返る。決定された場合は、制御がブロック７５８に進む。ブロック７５８では、決定された根本原因に対して、解決策を適用するようにしてもよい。

【0166】

これらの実施形態は、技術的課題に対する技術的解決手段を提供する。解決すべき技術的課題の１つとして、コンピュータ機器、システム、および／またはネットワークの問題を以下に素早く解決するか、がある。実際、このような問題を迅速に解決することが重要である。停止が生じると、このような機器、システム、およびネットワークの性能に悪影響が及び、仕様または期待を下回ってしまうためである。結果として、提供されるサービスは、稼働するにしても、信頼性が低下したり、遅延が生じたりする可能性がある。

【0167】

従来技術においては、個々のエージェントが予備構築スクリプトまたはそれぞれの経験および知識に基づいて、調査ステップの順序を決定していた。ただし、これらのスクリプト化された場当たり的な技術では、必ずしも解決に至るとは限らず、ましてや妥当な期間で解決に至るとは限らない。さらに、従来技術は、個々のエージェントの主観的な判定および経験に依拠しており、事例ごとに結果が大きく異なってしまう。したがって、従来技術は、機器、システム、またはネットワークの性能低下の迅速な解決への対処にはほとんど対応していない。

【0168】

本明細書の実施形態は、組織が利用可能となっているインシデントログを使用して新たな問題の解決速度を高めることにより、これらの制限を克服する。このように、より迅速、正確、かつ堅牢に問題解決が達成され得る。この結果として、いくつかの利点が得られる。第一に、さまざまな種類の症状が現れた場合のエージェント用の何十ものスクリプトを開発する必要がない。第二に、これらの技術は、エージェントの個々の性癖および先入観に依拠せず、代わりに根本原因決定のための客観的プロセスを採用する。第三に、これらの実施形態の結果として、コンピュータ機器、システム、およびネットワークの劣化および停止に起因するダウンタイムは短くなり、提供されるサービスがはるかに高い信頼性でアクセス可能となり得る。これらの実施形態からは、他の技術的改良も導かれ、他の技術的課題も解決され得る。

【0169】

Ａ．トレーニング段階
本節では、トレーニング段階と関連付けられているブロックを詳細に開示する。一方、使用するブロックの数を増やしてもよいし、減らしてもよく、文字が同じであってもよいし、異なっていてもよい。たとえば、いくつかの実施形態においては、前処理および要約のブロックを省略可能である。

【0170】

１．インシデントログの前処理
トレーニング自体の開始に先立って、インシデントログのコーパスが前処理されるようになっていてもよい。これには、たとえば任意の種類の正規化または外れ値除去を含み得る。場合によっては、インシデントログからのボイラープレートまたはフォームテキストの除去を含むことも可能である。ボイラープレートまたはフォームテキストの一例としては、「このインシデントは、エージェントによる検討のため、キューに入れられています」等、一部または全部のインシデントログイベントに自動的に追加されるコンテンツも可能である。エージェントは、インシデントの調査中に質問がある場合、問い合わせることになります。このようなテキストはインシデント間で共通であり、根本原因の決定には役立たないことから、根本原因の予測に至りやすいと考えられる残りのコンテンツにモデルを集中させるため、安全に削除可能である。他種の前処理としては、句読点および／またはストップワードの除去、ステミング、レンマ化（ｌｅｍｍａｔｉｚａｔｉｏｎ）等が挙げられる。場合により、前処理ステップでは、ユーザおよびエージェントの名称をそれぞれ、「ユーザ」および「エージェント」等の一般名称に置き換えることも可能である。

【0171】

たとえば、イベント６１６を前処理したものは、「ＮｅｔｗｏｒｋＳｏｕｔｈを再起動しました。ユーザは、ＮｅｔｗｏｒｋＳｏｕｔｈを使用してインターネットにアクセスしています。彼のＩＰアドレスおよびＮｅｔｗｏｒｋＳｏｕｔｈのＩＰアドレスに対する低レイテンシでのｐｉｎｇが可能であり、ＮｅｔｗｏｒｋＳｏｕｔｈのメモリ利用が５０％前後であることを確認しました」であってもよい。

【0172】

２．イベントの要約
任意の処理の後は、コーパス中の各イベント（前処理の有無を問わず）が変換または要約されるようになっていてもよい。このブロックの実行には、抽出的要約（ｅｘｔｒａｃｔｉｖｅ ｓｕｍｍａｒｉｚａｔｉｏｎ）または抽象的要約（ａｂｓｔｒａｃｔｉｖｅ ｓｕｍｍａｒｉｚａｔｉｏｎ）等のさまざまな技術が用いられるようになっていてもよい。抽出的要約では、イベントから最も関連する文または句を選択し、より短くなるように組み立てる。抽象的要約では、イベントの主要な意味論的意味を捉える新たな文を生成することによって、イベントをより短くする。

【0173】

たとえば、前処理したイベント６１６を要約したものは、「ＮｅｔｗｏｒｋＳｏｕｔｈを再起動し、インターネットアクセスを確認しました。ＩＰアドレスおよびＮｅｔｗｏｒｋＳｏｕｔｈのＩＰアドレスに対するｐｉｎｇは、低レイテンシです。ＮｅｔｗｏｒｋＳｏｕｔｈのメモリ利用は、５０％前後です」であってもよい。

【0174】

３．イベントの分類
要約後は、各イベントが１つまたは複数のクラスに分類される。これらのクラスは、問題の症状であってもよいし、調査ステップであってもよいし、根本原因の決定であってもよいし、問題の解決であってもよい。多くの場合、各イベントは厳密に、これらのクラスのうちの１つに置かれることになる。ただし、一部のイベントについては、２つ以上のクラスと関連するコンテンツを含むため、２つ以上のクラスに分類される可能性もある。

【0175】

この分類の実行には、さまざまな種類の予備トレーニングされた分類器が用いられるようになっていてもよい。たとえば、ラベル付きグラウンドトゥルース分類を含む一組のイベントに対して、単純ベイズ、サポートベクターマシン、決定木、ランダムフォレスト、またはニューラルネットワーク分類器をトレーニングすることも可能である。ここでは、多くのイベントに手動でラベル付けした後、このような分類モデルのトレーニングにより、それぞれのテキストコンテンツに基づいて新たなイベントのクラスを予測することも可能である。たとえば、イベント６１６を要約したものは、調査ステップを表す類似種類のイベントで分類器がトレーニングされていることに基づいて、調査ステップクラスに分類される場合もある。

【0176】

場合によっては、付加的なヒューリスティックスの使用によって、ユーザからのテキストを含むすべてのイベントが問題の症状と関連するものと最初に仮定すること、および／または、用語「根本原因」および「解決策」を使用してイベントをそれぞれのクラスに配置すること、といった分類を強化あるいは実行するようにしてもよい。一部の分類器は、上記４つのクラスのうちの１つに分類不可能なイベントが配置されるデフォルトまたはキャッチオールクラスである５番目のクラスを有する可能性もある。このクラスには、イベント６０２および６１８等、管理ステップと関連するイベントが配置されるようになっていてもよい。

【0177】

４．クラスタ空間の決定
そして、各イベントクラス内のイベントがクラスタリングされるようになっていてもよい。言い換えると、イベントのクラスに対して一組のクラスタ（たとえば、症状、調査ステップ、根本原因、および解決策）が存在していてもよい。このクラスタリングは、クラスごとに独立して実行されるようになっていてもよいし、半ば独立して実行されるようになっていてもよい。クラスごとのクラスタリングプロセスには、特徴選択と、その後の実際のクラスタリングと、を含んでいてもよい。本明細書に示す実施形態において、クラスタリングは教師なしであるが、何らかの形態の教師ありも可能と考えられる。

【0178】

特徴選択では、クラスタリングの基準として使用される各クラスのテキスト内の測定可能な品質を決定する。これらの品質は、単語の選定、単語の頻度、単語の長さ、単語の意味、文の感情、またはその他何らかの特徴に関連し得る。最終的に、これらの特徴はそれぞれ、１つまたは複数の次元にマッピングされるようになっていてもよい。このため、クラスの各イベントについて、特徴の組み合わせが（通常は数値の）多次元ベクトルを構成する。

【0179】

実際のクラスタリングでは、ｋ平均法（ベクトルに基づいてイベントを所定数のクラスタに分割する（各イベントが最も近い平均値のクラスタに割り当てられる））、階層モデリング（クラスタのツリー状構造を構築する（ベクトルの類似性に基づいてイベントが一体的にグループ化される））、トピックモデリング（たとえば、単語の分布に基づいてイベントの基礎となるトピックまたはテーマを識別し、それに応じてイベントをクラスタにグループ化する）、および／またはスペクトルモデリング（イベントのテキストを高次空間に投影した後、当該空間中のイベント間の類似性に基づいてクラスタを識別する）等のさまざまな技術を使用することができる。

【0180】

クラスタリングをさらに説明すると、ワードベクターモデリングは、スペクトルモデリングの一例であり、共起することが多い文脈語に基づいて、イベント中の各単語をベクトル表現に割り当てるようにニューラルネットワークがトレーニングされている。単語ごとにベクトルが確立されると、イベント内の単語に対するベクトル演算（たとえば、何らかの形態の平均化）の使用によって、イベントの文脈の意味を全体として表すことができます。この態様の実行には、段落ベクトル、ＢＥＲＴ（Ｂｉｄｉｒｅｃｔｉｏｎａｌ Ｅｎｃｏｄｅｒ Ｒｅｐｒｅｓｅｎｔａｔｉｏｎｓ ｆｒｏｍ Ｔｒａｎｓｆｏｒｍｅｒｓ）、またはさまざまな種類の大規模言語モデル等、他の技術が用いられるようになっていてもよい。

【0181】

図８Ａは、クラスタリングプロセスの一例を示している。ここでは、例示を目的として、各イベントが２次元クラスタ空間８００にマッピングされている。種々実施形態においては、より大きなクラスタ空間（たとえば、ｎ空間）が用いられるようになっていてもよい。図８に記載の通り、クラスタ空間８００は、症状クラスに対するものである。他のクラス（たとえば、調査ステップ、根本原因、および／または解決策）には、別個のクラスタ空間（図示せず）が用いられるようになっていてもよい。

【0182】

イベント１、２、および３のベクトルが与えられている。特に、特徴選択プロセスでは、イベント１のベクトルが（－０．７４６１，０．８８５４）、イベント２のベクトルが（－０．４６５３，０．７２２２）、イベント３のベクトルが（－０．３８１５，０．６８３７）であるものと決定している。これらのイベントはそれぞれ、クラスタ空間８００においてＸにより表される。同様に、図８でベクトルが明示されていない他のイベントについても、クラスタ空間８００においてＸにより表される。

【0183】

クラス内のすべてのイベントがベクトルに投影され、これらのベクトルがクラスタ空間にマッピングされたら、クラスタリング技術の使用によって、近くのイベントのグループをクラスタに関連付けることができる。このｎ次元クラスタリングの目的は、クラスタ空間における相互の近接性に基づいて、イベントを一体的にグループ化することである。このような技術は、一組の重心（クラスタの中心を表す点）を最初に初期化することにより作用する。その後、この技術では、最も近い重心への各データ点の割り当てを反復的に行い、割り当てられたすべてのデータ点の平均となるように重心を更新するようにしてもよい。このプロセスは、重心が収束し、クラスタが安定するまで続く。最終的に、各重心は、たとえばクラスタ中のすべての点と重心自体との間の平方距離の和を最小化する点であってもよい。場合により、このクラスタリング技術では、如何なるクラスタにも属さない１つまたは複数の残留点が生じ得る。残留点は、データセットのノイズが多い場合に生じ得る。

【0184】

図８Ａは、３つのクラスタおよび１つの残留点を示している。クラスタ８０２がイベント２および３を含む一方、クラスタ８０４および８０６は、他のイベントを含む。イベント１は、如何なるクラスタのメンバーでもない残留点である。クラスタリングがイベントのセマンティックコンテンツに基づいて発生することから、各クラスタ中の（たとえば、同一または類似トピックの）すべてのイベントが意味論的には相互に類似する可能性が高い。異なるクラスタのイベントは、意味論的には相互に類似しない（または、意味論的に異なる）ため、異なるトピックになる可能性が高い。

【0185】

場合によっては、人間による判読および／または人間による理解が可能な名称またはラベルがクラスタに与えられるようになっていてもよい。このようなラベルは、クラスタに割り当てられたイベントの種類を意味論的に記述または要約する単一の単語または短い単語列であってもよい。いくつかの実施形態において、これには、（たとえば、最も一般的なキーワードまたは句を抽出するための特徴重要度または頻度分析、トピックモデリング、感情モデリング等の技術によって）クラスタ中の最高頻度の特徴または意味論的に代表的な特徴を識別することを含み得る。たとえば、ユーザがＷｉｆｉネットワークにアクセスできないことに関連するすべての症状のクラスタには、テキスト「Ｗｉｆｉが使えません」がラベル付けされていてもよい。

【0186】

５．クラスタ間の確率的関係の決定
クラスタ空間および内部のクラスタが確立された後は、クラスタ間の確率的関係が決定されるようになっていてもよい。これには、イベントのクラスタごとに、イベントの後続のクラスタのうちで従う可能性が最も高いものを識別することを含んでいてもよい。たとえば、症状クラスタを所与として、根本原因クラスタとなったトレーニングデータには、比較的限られた一組の調査ステップクラスタが存在していてもよい。言い換えると、特定の症状を所与として、根本原因の識別に至る可能性が最も高い１つまたは複数の種類の調査ステップが存在する。

【0187】

図８Ｂは、少数のクラスタ（症状、調査ステップ、根本原因、および解決策それぞれに対して一組のクラスタ）に対して、上記のようなマッピングを示している。症状クラスタ８５０はそれぞれ、ブロック７０６で決定したような異なる種類の症状を対象とする。調査ステップクラスタ８５２はそれぞれ、ブロック７０６で決定したような異なる種類の調査ステップを対象とする。根本原因クラスタ８５４はそれぞれ、ブロック７０６で決定したような異なる種類の根本原因を対象とする。解決策クラスタ８５６はそれぞれ、ブロック７０６で決定したような異なる種類の解決策を対象とする。

【0188】

これらのクラスタを所与として、それぞれの内部のイベントの解析により、図８Ｂのパスの確率を決定することができる。図示のように、症状クラスタＡ（特定の種類の症状と関連付けられているイベントを含む）の後には、調査ステップクラスタＢおよびＣに見られる種類の調査ステップしか続かない。同様に、調査ステップクラスタＢおよびＣの後には、根本原因クラスタＤ、Ｅ、Ｆ、およびＧに見られる種類の根本原因しか続かない。上述の通り、根本原因が識別されると、通例は解決策が明確になる。このため、根本原因クラスタＤ、Ｅ、Ｆ、およびＧはそれぞれ、比較的少数の考え得る解決策に至る。したがって、本明細書の手順を使用して根本原因を識別可能であるなら、ほとんどの場合、適当な解決策も識別されることになるため、一般的に許容される。

【0189】

確率に関して、調査ステップクラスタＢおよびＣと根本原因クラスタＤ、Ｅ、Ｆ、およびＧとの間の関係を考える。調査ステップクラスタＢおよびＣはそれぞれ、関連する症状の根本原因を識別する特定の尤度（確率）を有する。たとえば、調査ステップクラスタＢの調査ステップは、３０％の確率で根本原因クラスタＤの根本原因に至り、６０％の確率で根本原因クラスタＦの根本原因に至る。残り１０％の確率では、調査ステップクラスタＢの調査ステップが根本原因に至らない。同様に、調査ステップクラスタＣの調査ステップは、１０％の確率で根本原因クラスタＥの根本原因に至り、２０％の確率で根本原因クラスタＦの根本原因に至り、１０％の確率で根本原因クラスタＧの根本原因に至る。残り６０％の確率では、調査ステップクラスタＣの調査ステップが根本原因に至らない。

【0190】

この情報のみを所与とすると、調査ステップクラスタＢの調査ステップの方が、調査ステップクラスタＣの調査ステップよりも根本原因に至る可能性が高いことが明らかである。あるいは、これらの確率は、症状クラスタに条件付けされていてもよい。すなわち、症状クラスタＡの症状を所与として、調査ステップクラスタＢの調査ステップが根本原因に至る可能性が９０％となる一方、調査ステップクラスタＣの調査ステップが根本原因に至る可能性は４０％となる。症状が異なるクラスタに由来する場合は、これらの確率が異なり得る（図８Ｂには示さず）。

【0191】

これらの確率は、さまざまなクラスタ間の有向非巡回グラフ（ｄｉｒｅｃｔｅｄ ａｃｙｃｌｉｃ ｇｒａｐｈ）の形態で表されるようになっていてもよく、エッジは、あるクラスタから別のクラスタに進む確率を表す。ただし、他のグラフ表現も可能である。

【0192】

いずれの場合も、図８Ｂは、例示を目的とした一例に過ぎない。本明細書の実施形態においては、各種の数十、数百以上のクラスタが種々複雑に相互接続されていてもよい。これらの確率的関係を使用して調査ステップを推奨する方法については後述する。

【0193】

Ｂ．予測段階
本節では、図７Ｂの予測と関連付けられているブロックを詳細に開示する。一方、使用するブロックの数を増やしてもよいし、減らしてもよく、文字が同じであってもよいし、異なっていてもよい。また、本節では、インシデントログのコーパスからイベントが識別されており、これらのイベントの使用によって、図８Ｂに示すようなイベントのクラスタ間の確率的関係が生成されているものと仮定する。

【0194】

図７Ｂのブロックは通常、症状が解決される前の新たなインシデントログからのデータに対して実行される。特に、症状を所与とする場合、図７Ｂのブロックは、根本原因の識別に至る可能性が最も高い特定の調査ステップを推奨するための技術を提供する。この推奨は、人間に与えられるようになっていてもよいし、仮想エージェントに与えられるようになっていてもよい。

【0195】

１．新たなインシデントログの前処理、要約、および分類
上述の通り、前処理では、任意の種類の正規化または外れ値除去を新たなインシデントログに適用することができ、句読点および／またはストップワードの除去、ステミング、レンマ化、単語または句の置換、単語または句の消去等が挙げられるが、これらに限定されない。ブロック７５０の一部として行われる前処理は、ブロック７００と同一または同様であってもよい。

【0196】

また、上述の通り、要約では、前処理されたインシデントログに対して、たとえば抽出的要約または抽象的要約を適用することができる。ブロック７５０の一部として行われる要約は、ブロック７０２と同一または同様であってもよい。

【0197】

同じく上述の通り、分類では、前処理および要約がなされた新たなインシデントログに対して、トレーニング済み分類器を適用することができる。トレーニング済み分類器としては、単純ベイズ、サポートベクターマシン、決定木、ランダムフォレスト、またはニューラルネットワーク分類器も可能である。ブロック７５０の一部として行われる分類は、ブロック７０４と同一または同様であってもよい。ブロック７５０の目的がインシデントログから１つまたは複数の症状を識別することであるため、以下のステップの対象となるのは、症状として分類されたイベントのみであってもよい。

【0198】

２．類似症状の決定
類似症状の決定では、症状として分類された１つまたは複数のイベントを取得し、上述の通り、特徴選択を適用するようにしてもよい。上述の通り、特徴選択では、症状のテキストを多次元ベクトルに投影するようにしてもよい。そして、トレーニング段階で確立された症状クラスタの特性に対して、このベクトルを比較することができる。たとえば、このベクトルと各症状クラスタの重心との間のユークリッド距離（ｎ空間における２点間の直線距離）またはコサイン類似度（ｎ空間における２つのベクトル間の角度のコサイン）が計算されるようになっていてもよい。すると、新たなインシデントログからの症状は、（ユークリッド距離の観点で）最も近い症状クラスタまたは（コサイン類似性の観点で）最も類似した症状クラスタのメンバーである可能性が高いと考えられる。それ以外の可能性もある。たとえば、場合によっては、最も近い２つ以上の症状クラスタが識別されるようになっていてもよい。

【0199】

３．調査ステップクラスタの選択
症状および類似症状クラスタが識別された後は、この調査ステップクラスタが根本原因に至る尤度に基づいて、調査ステップクラスタが選択される。この症状の場合は、複数の調査ステップクラスタが１つの根本原因に至る可能性があるため、ブロック７５４および７５６に示すように、この選択は本質的に反復的であってもよい。

【0200】

図８Ｂを説明のための一例として考え、新たなインシデントログは、症状クラスタＡの症状に類似する症状を含むように決定されるものとする。この場合は、推奨すべき２つの考え得る調査ステップクラスタとして、調査ステップクラスタＢおよび調査ステップクラスタＣが存在する。上述の通り、根本原因クラスタ８５４のうちの１つまたは複数に対する確率的関係に基づいて、これらのクラスタの一方または両方が人間に推奨されるようになっていてもよいし、仮想エージェントに推奨されるようになっていてもよい。

【0201】

これらの調査ステップクラスタを提案する順序の決定には、さまざまな技術が使用され得る。たとえば、根本原因に至る確率が最も高い調査ステップクラスタ（すなわち、調査ステップクラスタＢ）が最初に提案されるようになっていてもよい。このクラスタは、エージェントが実行する１つまたは複数の調査ステップを表すラベルまたは関連テキストを含んでいてもよい。ブロック７５６において、これらのステップが症状の根本原因を識別した場合は、制御がブロック７５８に進む。それ以外の場合は、制御が７５４に返り、根本原因に至る確率が次に高い調査ステップクラスタ（すなわち、調査ステップクラスタＣ）が提案されるようになっていてもよい。このプロセスは、根本原因が識別されるか、または、試行する調査ステップクラスタがなくなるまで続く。他の提案基準は、候補根本原因クラスタの数を減らす可能性が最も高い調査ステップクラスタであってもよい。

【0202】

言い換えると、このシステム（たとえば、リモートネットワーク管理プラットフォーム）は、トレーニング済みモデルに基づいて、一連の調査ステップをエージェントに提案する。エージェントは、根本原因が識別されるか、または、システムの提案がなくなるまで、提案された各調査ステップを実行する。後者の場合、エージェントは、主観的な経験に基づいてインシデントログに対処する。

【0203】

たとえば、症状が「Ｗｉｆｉが使えません」の場合、第一に提案される調査ステップは、ユーザが接続しようとしているＷｉｆｉアクセスポイントの識別であってもよく、第二に提案される調査ステップは、ユーザが適正なＷｉｆｉパスワードを使用しているかの確認の識別であってもよく、以下同様である。場合によっては、数十以上の調査ステップが提案に利用可能となり得る。

【0204】

４．解決策の適用
根本原因が識別されると、通常は解決策が明らかとなるか、または、少なくとも考え得る解決策の数が少なくなる（たとえば、多くても２つまたは３つになる）可能性がある。エージェントが仮想の場合は、実行可能となった時点で解決策（たとえば、パスワードの再設定、ユーザへの必要な情報の提供、機器の再起動等）を自動的に実行するようにしてもよい。エージェントが人間の場合は、彼／彼女らが解決策を実行するようにしてもよい。

【0205】

ＶＩＩ．例示的なオペレーション
図９Ａおよび図９Ｂは、例示的な実施形態を示すフローチャートである。図９Ａおよび図９Ｂにより示されるプロセスは、コンピュータ機器１００等のコンピュータ機器および／またはサーバクラスタ２００等のコンピュータ機器のクラスタにより実行されるようになっていてもよい。ただし、これらのプロセスは、他種の機器または機器サブシステムによっても実行可能である。たとえば、これらのプロセスは、リモートネットワーク管理プラットフォームまたはラップトップもしくはタブレット機器等の携帯型コンピュータの演算インスタンスにより実行することも可能である。

【0206】

図９Ａおよび図９Ｂの実施形態は、そこに示される特徴のいずれか１つまたは複数を除去することによって簡略化することができる。さらに、これらの実施形態は、相互および／または上記図面のいずれかあるいは本明細書に記載の特徴、態様、および／または実施態様と組み合わされるようになっていてもよい。

【0207】

図９Ａにおいて、ブロック９００では、それぞれが各一連のイベントを含む複数のインシデントログを取得するようにしてもよい。ブロック９０２では、各一連のイベントそれぞれを各イベントクラスに分類するようにしてもよい。ブロック９０４では、各イベントクラスとそれぞれ関連付けられているクラスタ空間を決定するようにしてもよい。ブロック９０６では、複数のインシデントログから、クラスタ空間中の少なくとも一部のクラスタ間の関係を決定するようにしてもよい。ブロック９０８では、クラスタおよび関係に基づいて、後続インシデントログに見られる症状の根本原因を決定するための１つまたは複数の調査ステップを提案するようにしてもよく、症状は、ユーザが経験した問題を表す。

【0208】

いくつかの実施形態において、各イベントクラスは、症状、調査ステップ、および根本原因を含み、症状は、ユーザが経験した問題を表し、調査ステップは、対応する症状の根本原因の決定に講じられる措置を表し、根本原因は、対応する症状の観察結果の一義的理由である。

【0209】

いくつかの実施形態において、各イベントクラスは、解決策も含み、解決策は、対応する根本原因の是正に講じられた措置を表す。

【0210】

いくつかの実施形態において、インシデントログのうちの少なくとも一部は、テキストコンテンツを含み、本実施形態は、各一連のイベントそれぞれを分類することに先立って、ストップワード除去、フォームテキスト除去、ステミング、またはレンマ化のうちの１つまたは複数をインシデントログに実行することをさらに含む。

【0211】

いくつかの実施形態において、インシデントログのうちの少なくとも一部は、テキストコンテンツを含み、本実施形態は、各一連のイベントそれぞれを分類することに先立って、抽出的要約または抽象的要約をインシデントログに実行することをさらに含む。

【0212】

いくつかの実施形態において、各一連のイベントそれぞれを各イベントクラスに分類することは、インシデントログからのラベル付きイベントのコーパスに対して予備トレーニングされた分類器を使用することを含み、ラベル付きイベントのラベルは、各イベントクラスを示し、分類器は、インシデントログのコンテンツと各イベントクラスとの間の関連を学習済みである。

【0213】

いくつかの実施形態において、各イベントクラスとそれぞれ関連付けられているクラスタ空間を決定することは、各イベントクラスそれぞれについて、分類されているイベントを多次元表現に投影することと、多次元表現間の距離または角度に基づいて、クラスタ空間中のクラスタを構成することと、を含む。

【0214】

いくつかの実施形態において、クラスタ空間中の少なくとも一部のクラスタ間の関係を決定することは、各一連のイベントに基づいて、クラスタのうちの２つのうちの第１のクラスタからクラスタのうちの２つのうちの第２のクラスタに進行するイベントの確率的尤度を決定することを含む。

【0215】

いくつかの実施形態において、確率的尤度を決定することは、クラスタの有向非巡回グラフを構成することを含み、有向非巡回グラフのエッジは、確率的尤度を表す。

【0216】

いくつかの実施形態は、分類されているイベントのセマンティックコンテンツに基づいて、クラスタそれぞれにラベル付けすることをさらに含む。

【0217】

いくつかの実施形態は、後続インシデントログに見られる症状の根本原因の決定後、コンピュータ機器にその構成の変更、実行している１つまたは複数のアプリケーションの変更、あるいは再起動を行わせることをさらに含む。

【0218】

図９Ｂにおいて、ブロック９５０では、ユーザが経験した問題を表す症状を示すイベントを含むインシデントログを取得するようにしてもよい。ブロック９５２においては、イベントと症状クラスタ空間内の複数の症状クラスタとの間の比較を実行するようにしてもよく、複数の症状クラスタは、複数の過去取得インシデントログ中のイベントと関連付けられている症状を表す。ブロック９５４においては、比較に基づいて、症状クラスタ空間から症状クラスタを識別するようにしてもよい。ブロック９５６においては、症状クラスタに基づいて、調査ステップクラスタ空間から調査ステップクラスタを選択するようにしてもよく、調査ステップクラスタは、根本原因クラスタ空間からの１つまたは複数の根本原因クラスタと関連付けられており、調査ステップクラスタ空間は、複数の過去取得インシデントログ中のイベントから導出されたものであり、根本原因クラスタ空間も、複数の過去取得インシデントログ中のイベントと関連付けられている。ブロック９５８においては、調査ステップクラスタからの調査ステップが症状の根本原因の識別に至ったものと判定するようにしてもよく、根本原因は、根本原因クラスタのうちの１つからのものである。

【0219】

いくつかの実施形態において、イベントと複数の症状クラスタとの間の比較を実行することは、イベントと複数の症状クラスタそれぞれとの間の類似性指標を決定することを含む。

【0220】

いくつかの実施形態において、症状クラスタ空間から症状クラスタを識別することは、類似性指標に関してイベントに最も類似することから症状クラスタを選択することを含む。

【0221】

いくつかの実施形態は、イベントと複数の症状クラスタとの間の比較を実行することに先立って、インシデントログからのラベル付きイベントのコーパスに対して予備トレーニングされた分類器を使用してイベントを症状イベントクラスに分類することであって、ラベル付きイベントのラベルが、各イベントクラスを示し、分類器が、インシデントログ中のラベル付きイベントのコンテンツと各イベントクラスとの間の関連を学習済みである、分類することをさらに含んでいてもよい。

【0222】

いくつかの実施形態において、調査ステップクラスタは、調査ステップクラスタ空間内で、根本原因クラスタのうちの１つに至る確率が最も高いことから選択される。

【0223】

いくつかの実施形態において、調査ステップクラスタは、調査ステップクラスタ空間内で、候補根本原因クラスタの数を減らす確率が最も高いことから選択される。

【0224】

いくつかの実施形態は、根本原因に基づいて、解決策クラスタ空間から解決策クラスタを選択することであって、解決策クラスタが、根本原因の是正に講じられた措置を表す解決策を含む、選択することをさらに含んでいてもよい。

【0225】

いくつかの実施形態において、解決策は、コンピュータ機器にその構成の変更、実行している１つまたは複数のアプリケーションの変更、あるいは再起動を行わせることを含む。

【0226】

ＶＩＩＩ．結論
本開示は、種々態様の説明を意図した本願に記載の特定の実施形態の観点で限定されるものではない。当業者には明らかなように、その範囲から逸脱することなく、多くの改良および変形が可能である。以上の説明から、本明細書に記載したもののほか、本開示の範囲内の機能的に同等な方法および装置が当業者には明らかとなるであろう。このような改良および変形についても、添付の特許請求の範囲に含まれることになる。

【0227】

上記詳細な説明では、添付の図面を参照しつつ、開示のシステム、機器、および方法のさまざまな特徴および動作を記述している。本明細書および図面に記載の例示的な実施形態は、何ら限定を意味するものではない。本明細書に提示の主題の範囲から逸脱することなく、他の実施形態を利用可能であるとともに、他の変更を加えることができる。本明細書の全体に記載するとともに図面に示すような本開示の態様は、多種多様な異なる構成での配置、置換、結合、分離、および設計が可能であることが容易に了解される。

【0228】

図中のメッセージフロー図、シナリオ、およびフローチャートのいずれかまたはすべてに関して、本明細書に論じる通り、各ステップ、ブロック、および／または通信は、例示的な実施形態に係る情報の処理および／または情報の伝送を表し得る。これらの例示的な実施形態の範囲には、代替実施形態が含まれる。これらの代替実施形態において、たとえば、ステップ、ブロック、伝送、通信、リクエスト、応答、および／またはメッセージとして記述された動作は、関与する機能に応じて、図示または説明の順序から外れて実行可能である（実質的に同時または逆順を含む）。さらに、本明細書に論じるメッセージフロー図、シナリオ、およびフローチャートのいずれにおいても、使用するブロックおよび／または動作の数を増やすことも減らすことも可能であり、これらのメッセージフロー図、シナリオ、およびフローチャートの一部または全部を相互に結合可能である。

【0229】

情報の処理を表すステップまたはブロックは、本明細書に記載の方法または技術の特定の論理的機能を実行するように構成され得る回路に対応可能である。この代替または追加として、情報の処理を表すステップまたはブロックは、プログラムコード（関連データを含む）のモジュール、セグメント、または一部に対応可能である。プログラムコードは、上記方法または技術における特定の論理的操作または動作を実行するためにプロセッサによって実行可能な１つまたは複数の命令を含み得る。プログラムコードおよび／または関連データは、ＲＡＭ、ディスクドライブ、半導体ドライブ、または別の記憶媒体を含む記憶装置等の如何なる種類のコンピュータ可読媒体にも格納可能である。

【0230】

また、コンピュータ可読媒体には、レジスタメモリおよびプロセッサキャッシュ等、データを短期間にわたって格納する非一時的コンピュータ可読媒体等の非一時的コンピュータ可読媒体を含み得る。非一時的コンピュータ可読媒体には、プログラムコードおよび／またはデータを長期間にわたって格納する非一時的コンピュータ可読媒体をさらに含み得る。したがって、非一時的コンピュータ可読媒体には、たとえばＲＯＭ、光もしくは磁気ディスク、半導体ドライブ、またはコンパクトディスクリードオンリーメモリ（ＣＤ－ＲＯＭ）等の二次的または永続的な長期ストレージを含み得る。また、非一時的コンピュータ可読媒体としては、その他任意の揮発性または不揮発性記憶システムも可能である。非一時的コンピュータ可読媒体は、たとえばコンピュータ可読記憶媒体または有形の記憶装置と考えられる。

【0231】

さらに、１つまたは複数の情報伝送を表すステップまたはブロックは、同じ物理的機器におけるソフトウェアおよび／またはハードウェアモジュール間の情報伝送に対応し得る。ただし、他の情報伝送としては、異なる物理的機器におけるソフトウェアモジュールおよび／またはハードウェアモジュール間も可能である。

【0232】

図面に示す特定の配置は、何ら限定的なものと捉えるべきではない。他の実施形態では、所与の図面に示す各要素の数を増やすことも減らすことも可能であることが了解されるものとする。さらに、図示の要素の一部の結合も可能であるし、省略も可能である。さらには、図面に示していない要素を例示的な一実施形態が含むことも可能である。

【0233】

本明細書においては、種々態様および実施形態を開示しているが、当業者には他の態様および実施形態も明らかとなるであろう。本明細書に開示の種々態様および実施形態は、例示を目的としたものであって、何ら限定を意図せず、真の範囲は以下の特許請求の範囲により示される。

【符号の説明】

【0234】

１００ コンピュータ機器
１０２ プロセッサ
１０４ メモリ
１０４Ａ ファームウェア
１０４Ｂ カーネル
１０４Ｃ アプリケーション
１０６ ネットワークインターフェース
１０８ 入力／出力ユニット
１１０ システムバス
２００ サーバクラスタ
２０２ サーバ機器
２０４ データストレージ
２０６ ルータ
２０８ ローカルクラスタネットワーク
２１０ 通信リンク
２１２ ネットワーク
３００ マネージドネットワーク
３０２ クライアント機器
３０４ サーバ機器
３０６ ルータ
３０８ 仮想マシン
３１０ ファイアウォール
３１２ プロキシサーバ
３２０ リモートネットワーク管理プラットフォーム
３２２ 演算インスタンス
３２４ 演算インスタンス
３２６ 演算インスタンス
３２８ 演算インスタンス
３４０ パブリッククラウドネットワーク
３５０ インターネット
４００Ａ データセンタ
４００Ｂ データセンタ
４０２Ａ ＶＰＮゲートウェイ
４０２Ｂ ＶＰＮゲートウェイ
４０４Ａ ファイアウォール
４０４Ｂ ファイアウォール
４０６Ａ 負荷分散器
４０６Ｂ 負荷分散器
４１０ 設定項目
４１２ ＶＰＮゲートウェイ
４１４ ユーザ
４１６ リモートユーザ
５００ ＣＭＤＢ
５０２ タスクリスト
５０４ 機器
５０６ 機器
５０８ 機器
５１０ 機器
５１２ 機器
５１４ ＩＲＥ
８００ ２次元クラスタ空間
８０２ クラスタ
８０４ クラスタ
８０６ クラスタ
８５０ 症状クラスタ
８５２ 調査ステップクラスタ
８５４ 根本原因クラスタ
８５６ 解決策クラスタ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6A】

【図6B】

【図7A】

【図7B】

【図8A】

【図8B】

【図9A】

【図9B】

【外国語明細書】