JP2019536185A - コンピュータおよびネットワーク活動を監視および分析するためのシステムおよび方法 - Google Patents

Abstract

生産環境を監視し、報告するシステムは、前記生産環境の１つ以上のコンピューティングシステム上に常駐する１つ以上のアプリケーションプログラミングインターフェイス（ＡＰＩ）を介して生産環境からのデータを取得する。前記システムは、メトリックを計算するように前記取得されたデータを使用し、前記システムはその後、所定のインシデントが発生したか否かを判定するために、前記取得されたデータおよび前記計算されたメトリックを使用する。所定のインシデントが発生した場合、その発生が速やかに報告され、または、前記インシデントが報告されるべきか否かを判定するために、二次分析が第１に実行され得る。

Description

発明の詳細な説明

〔背景〕
本出願は、ビジネスがコンピュータベースの生産環境を効率的かつ良好な性能で動作させ続けるのを補助するように使用される技術を開示する。「生産環境」は、多くの異なるもののいずれであってもよい。いくつかの例では、生産環境は、オンライン小売動作を実行するように使用されるコンピュータサーバのネットワーク化されたシステムとすることができる。別の例では、生産環境は、コンピュータソフトウェアアプリケーションを生成するように使用されるコンピュータシステムであってもよい。さらに他の実施形態では、生産環境は、コンピュータ制御製造システムとすることができる。コンピュータ、コンピュータソフトウェア、および／またはコンピュータネットワークに依存する実質的に任意の種類の生産環境は、本出願に開示されるシステムおよび方法から利益を得ることができる。

コンピュータベースの生産環境がスケールアップし、より大きくなるにつれて、性能は低下する可能性がある。システムのすべての部分を効率的に動作させ続けることは、ますます困難になる。生産環境を監視し、主要なメトリックおよびイベントについて報告するように設計された多くのソフトウェアアプリケーションが存在する。しかし、そのような監視アプリケーションによって生成されたデータおよび報告は、それ自体理解するのが困難な場合がある。そのようなデータおよび報告を有意義な方法で使用して、ピーク性能を回復することは困難であり得る。また、このような生産環境において課題（problem）または問題（issue）が発生した場合、システム管理者は、このような監視アプリケーションによって提供されたデータや報告に基づいて、課題または問題の根本原因を同定する（identify）ことが非常に困難になる可能性がある。

上記のすべての理由から、生産環境における活動を監視し、課題および問題が発生したときにそれらの根本的な原因を同定することができる追加の技術が必要である。また、課題が発生したときに、それらを能動的に同定することができ、人間の介入を必要とせずに、課題を軽減または解決するための措置をとることができる技術が必要とされている。

〔図面の簡単な説明〕
図１は、生産環境アシスタントの様々な要素を図示するブロック図である。

図２は、データ収集ユニットの様々な要素を図示するブロック図である。

図３は、データ収集および変換ユニットの様々な要素を図示するブロック図である。

図４は、メトリックユニットの様々な要素を図示するブロック図である。

図５は、評価ユニットの様々な要素を図示するブロック図である。

図６は、インシデントユニットの様々な要素を図示するブロック図である。

図７は、通知ユニットの様々な要素を図示するブロック図である。

図８は、能動インスペクタシステムの様々な要素を図示するブロック図である。

図９は、改善ユニットの様々な要素を図示するブロック図である。

図１０は、ユーザインタフェースシステムの様々な要素を図示するブロック図である。

図１１は、クライアントシステムからデータを収集する方法のステップを図示するフローチャートである。

図１２は、受信したクライアントデータを様々なデータリポジトリに格納する方法のステップを図示するフローチャートである。

図１３は、収集されたクライアントデータから様々なメトリックを計算する方法のステップを図示するフローチャートである。

図１４は、インシデントが発生したか否かを判定するためにデータを分析する方法のステップを図示するフローチャートである。

図１５は、発生したインシデントを報告する方法のステップを図示するフローチャートである。

図１６は、データを取得し、所定のインシデントが発生したか否かを判定するためにクライアントのシステムを能動的に監視する方法のステップを図示するフローチャートであり、図１７は、クライアントのシステムに関する課題または問題を修正するように改善措置（remediation action）をとる方法のステップを図示するフローチャートである。

〔詳細な説明〕
図１に、クライアントの生産環境からデータを受信または取得する生産環境アシスタントであって、課題または問題が発生しているか否かを判定するためにそのデータを分析し、任意の同定された課題または問題の報告を行う生産環境アシスタント１００の、様々な要素を図示する。

生産環境アシスタント１００はまた、そのような課題または問題を治癒または軽減するように、改善措置をとることができる。前記生産環境アシスタントは、クライアントの生産環境からデータを受信または取得する役割を担うデータ収集ユニット２００を含む。データ収集ユニット２００は、典型的には、前記クライアントのシステムにインストールされ、構成されたアプリケーションプログラミングインタフェース（ＡＰＩ）を介してデータを受信する。ＡＰＩは、定期的または連続的に、特定のタイプのデータをデータ収集ユニット２００に自動的に発信するように構成される。前記ＡＰＩによってデータ収集ユニット２００に発信されるデータは、クライアントの生産環境の様々な測定値を表すデータポイント、ならびに前記クライアントの生産環境上で発生したイベントに関連するイベントデータを含むことができる。

前記データは、コンピュータアプリケーションまたはプログラムによって実行される動作、コンピュータシステムおよびネットワーク自体、ならびに前記クライアントのビジネスに関連する他のデータにも関連し得る。例えば、データ収集ユニット２００に報告されるデータは、統計データ、または前記クライアントの生産環境の販売または使用に関連する情報など、前記クライアントの生産環境上で生じるビジネス活動に関連する情報を含むことができる。前記クライアントのシステムにインストールされた１つ以上のＡＰＩを介して、クライアントの生産環境に関連する実質的に任意のタイプのデータをデータ収集ユニット２００に報告することができる。生産環境アシスタント１００はまた、データ変換および記憶ユニット３００を含む。

データ変換および記憶ユニット３００は、クライアントの生産環境からデータを受信し、データを変換および拡充（enrich）し、そのデータをデータキューにロードする。データ変換および記憶ユニット３００はまた、受信または取得されたクライアントデータを１つ以上のデータリポジトリに記憶するように動作することもできる。

生産環境アシスタント１００はまた、メトリックユニット４００を含む。メトリックユニット４００は、クライアントの生産環境に関連するデータを受信または取得し、その後、その生の（raw）データを使用して様々なメトリック（metrics）を計算する。このような計算は、異なる統計方程式およびアルゴリズム、ならびにアウトライアーおよび異常アルゴリズムを含むことができる（ただし、これらに限定されない）。次いで、前記メトリックデータは、メトリックリポジトリに記憶される。

生産環境アシスタント１００は、評価ユニット５００をさらに含む。前記評価ユニットは、クライアントの生産環境に関連するデータを取得または取得し、前記データを分析して、所定のインシデントが前記クライアントの生産環境で発生したか、または発生しているか否かを判定する。評価ユニット５００は、従来の分析技術、ならびに人工知能ベースの分析技術を適用することができる。

生産環境アシスタント１００はまた、インシデントユニット６００を備える。所定のインシデントが発生したと判定されるたびに、インシデントユニット６００は、前記評価ユニットによって通知される。このようなインシデントは、インシデントデータベースに格納され、クエリユニットを介して検索することができる。

生産環境アシスタント１００は、インシデントをクライアントおよびシステム管理者に報告する通知ユニット７００をさらに含む。通知ユニット７００は、クライアントまたはシステム管理者に通知を送達するように、様々な異なる通信チャネルを介して動作することができる。

生産環境アシスタント１００は、能動インスペクタシステム８００をさらに含む。能動インスペクタシステムシステム８００は、個々の能動インスペクタを構成し、実行し、そのそれぞれは、特定の課題または問題の発生について単一のクライアントの生産環境を監視するように設定される。能動インスペクタはまた、同定された課題または問題を修正すべく試みるように、改善措置をとるように構成されてもよい。生産環境アシスタント１００は、改善ユニット９００をさらに含む。

改善ユニット９００は、そのような課題または問題が同定された場合に、前記クライアントの生産環境に関する課題または問題を修正または軽減するための措置をとるように構成される。生産環境アシスタント１００はまた、ユーザインタフェースシステム１０００を含む。ユーザインタフェースシステム１０００は、データを取得するように、または様々な動作を生じさせるように、クライアントが生産環境アシスタント１００と対話することができる様々な異なる方法を提供する。前記ユーザインタフェースシステムは、自然発話ベースの、または所定の発話ベースのコマンドを使用してクライアントと対話するように、発話認識技術を利用することができる。ユーザインタフェースシステム１０００はまた、コンピュータシステムを介して提示されるグラフィカルユーザインタフェースを含む、より伝統的な方法で、様々なクライアントユーザと対話することができる。

生産環境アシスタント１００の上述の要素のそれぞれについて、以下でより詳細に説明する。さらに、図１１〜１７は、クライアントの生産環境を監視し、課題または問題がいつ発生したかを判定し、それらの課題または問題について報告し、ならびに改善措置をとるように、生産環境アシスタント１００の要素によって実行される様々な方法のステップを示す。

図２に、生産環境アシスタント１００の一部とすることができるデータ収集および変換ユニット２００の様々な要素を図示する。データ収集ユニット２００は、受動収集ユニット２０２を含み、受動収集ユニット２０２は、クライアントの生産環境の前記様々なシステムから報告されたデータを受信する。受動収集ユニット２０２に報告されたデータは、前記クライアントの生産環境にインストールされた様々なＡＰＩを介して報告することができる。あるいは、またはさらに、専用エージェントをクライアントサーバまたはネットワーキング機器にインストールすることができる。そのようなエージェントは、１つ以上の別個のＡＰＩ収集方法を利用することができる。前記ＡＰＩは、定期的に、または継続的に、前記クライアントの生産環境上のオペレーションに関する様々な情報項目を報告するように構成される。

受動収集ユニット２０２は、ＡＰＩ構成ユニット２０４を含むことができ、ＡＰＩ構成ユニット２０４は、クライアントの生産環境にインストールされる前記様々なＡＰＩを構成するのを補助するように使用することができる。特に、ＡＰＩ構成ユニット２０４は、クライアントの生産環境内にインストールされたＡＰＩに、１つ以上のクライアント固有の暗号化コード、トークン、または鍵を提供するように使用することができる。次いで、ＡＰＩは、この暗号化コード、トークン、または鍵を、それらが受動収集ユニット２０４に報告するデータと共に含む。

受動収集ユニット２０２はまた、データ受信ユニット２０６を含み、データ受信ユニット２０６は、クライアントの生産環境にインストールされたＡＰＩから報告されたデータを実際に受信する。データ受信ユニット２０６は、前記受信されたデータが適切なクライアント固有の暗号鍵、トークンまたはコードを含むことを確実にするために、前記受信されたデータをチェックする。そうである場合、データ受信ユニット２０６は、受信されたデータを受け入れる。受信されたデータが適切な暗号化コード、トークン、または鍵を含まない場合、データ受信ユニットは、受信されたデータを無視する。これは、悪意のある第三者が人為的および／または不正確なデータを偽装することを非常に困難にする。クライアント固有の暗号化コード、トークン、または鍵は、受信されたデータを特定のクライアントから発信されたものとして同定するように動作することもできる。

データ収集ユニット２００は、能動収集ユニット２０８を含むことができる。能動収集ユニット２０８は、クライアントの生産環境内にインストールされたＡＰＩにそのようなデータのリクエストを発信することによって、クライアントの生産環境から特定の情報項目を能動的に探し出し、取得する。能動収集ユニット２０８は、クライアントの生産環境内にインストールされたＡＰＩを、そのようなリクエストに応答するように構成するのを補助するように使用されるＡＰＩ構成ユニット２１０を含むことができる。これは、クライアントの生産環境内のＡＰＩに、それらのＡＰＩからクライアントの生産環境に関する情報を取得するために能動収集ユニット２０８によって使用されなければならない様々な暗号鍵またはコードを提供するステップを含むことができる。言い換えれば、能動収集ユニット２０８は、クライアントの生産環境内のＡＰＩからデータを取得するように、これらのＡＰＩに暗号鍵またはコードを提供することを必要とし得る。ＡＰＩ構成ユニット２１０は、クライアントの生産環境内のＡＰＩから情報を取得するように能動収集ユニット２０８によって使用される暗号鍵またはコードを確立するのに役立つ。

能動収集ユニット２０８はまた、能動収集ルールユニット２１２を含むことができる。能動収集ルールユニットは、システム管理者またはクライアントが、能動収集ユニット２０８がいつどのようにクライアントの生産環境から情報を求めるかを判定する所定のルールを設定することを可能にする。そのようなルールが確立されると、能動収集ユニット２０８は、ルールに従うように動作する。

能動収集ユニット２０８は、クライアント通信監視ユニット２１４をさらに含むことができる。クライアント通信監視ユニット２１４は、特定のクライアントによって使用されるか、または関連付けられる様々な個人によって生成されるか、または受信される通信を監視する通信収集ユニット２１６を含むことができる。これは、電子メールメッセージ、テキストメッセージ、インスタントメッセージ、他の形式の書面通信のコピー、ならびに特定の個人間を通過する音声通信のコピーを収集するステップを含むことができる。次に、通信分析ユニット２１８は、通信収集ユニット２１６によって収集されたクライアント通信を分析して、特定の活動がクライアントのシステムまたは生産環境内で発生しているか否かを判定するのを補助する。

クライアント通信を収集し、分析する目的は、クライアントの生産環境内で課題または問題が発生したか否かを判定することである。そのために、通信分析ユニット２１８は、特定の課題または問題に関連付けられる特定のキーワードを求めてクライアント通信を検索することができる。特定のタイプの課題または問題に関連する１つ以上のキーワードがクライアント通信で見つかった場合、通信分析ユニット２１８は、システムによって受信された他の信号との深い相関のために、その情報を評価ユニット５００に発信することができる。それは、潜在的な課題または問題についての通知を、システム管理者に、またはおそらく、より詳細なチェックを実行することができるように、または改善措置をとることができるように、前記生産環境アシスタントの他の要素に発信することができる。

通信分析ユニット２１８は、クライアント通信におけるキーワードを、特定のコンテキストにおいて適用可能性を有する既知の情報技術ワードと比較することができる。分析の目的は、クライアントの意図を判定し、特定のタイプの課題または問題に関して行動することである。この目的のために、情報技術またはコンピュータ語の辞書を参照することができる。さらに、通信分析ユニット２１８は、ある種のキーワードがある種の課題に関連づけられるようになる、そのようなキーワードの辞書またはデータベースを経時的に構築することができる。そのような辞書またはデータベースは、特定のクライアントに特有であってもよく、または複数のクライアントに対するより広い適用性を有してもよい。この種のヒストリカルナレッジは、課題がいつ再発したかを同定するのに非常に価値がある。

通信分析ユニット２１８は、まず、ＩＴシステム意図およびＩＴシステム資産のコーパス（corpus）を構築するように、NLP（自然言語処理）アルゴリズムを使用することができる。例えば、意図は、システム上で自動的にまたは手動でとることができる動作である。「再起動」、「増加」、「リブート」、「シャットダウン」、「削除」、「追加」、「スケール」、「同調」はすべて、ＩＴシステム上でとられ得る意図または動作の実施例である。「ＣＰＵ」、「メモリ」、「サブネット」、「ネットワークインタフェース」、「ガベージコレクション」、「I／O」、「ディスク」はすべてＩＴタームである。番号およびパーセンテージ、ならびに名詞は、文全体のセマンティクス（semantics）を生成するバウンディングピースである。例えば、人間がコンピュータメッセージングシステムを介して「ＣＰＵ使用量が多いため、名称『ａｂｃ１２３』のサーバを再起動する必要がある」と報告している場合、文を分析する通信分析ユニット２１８は、「ため」、「多い」、「ＣＰＵ」、「再起動」、「ａｂｃ１２３」などのキーワードを同定する。これらのキーワードを同定し、それらを評価ユニット５００に発信するステップは、特定の環境に適合させることができるか、またはより広範なＩＴシステム環境において一時的に使用することができる一般的なＩＴコンポーネント間の、因果関係および修復（remediation）接続を構築するのに役立つ。

上述のように、データ収集ユニット２００によって収集することができるデータのタイプは、クライアントの生産環境内に存在する個々のコンピュータシステムまたはネットワークに関する様々なデータポイントを含むことができる。また、データポイントは、クライアントの生産環境内で実行されている個々のソフトウェアアプリケーションの動作に関連することもできる。さらに、データ収集ユニット２００によって取得されるデータは、財務情報、販売データ、オンライン小売システム内のトラフィック、通信システム内のトラフィック、ならびにクライアントの生産環境の動作に関連する実質的に任意の他のタイプのデータなど、ビジネスがどのように実行されているかに関する情報を含むことができる。

多くのクライアントは、前記クライアントの生産環境の動作を監視するように、様々な監視システムまたは監視ソフトウェアアプリケーションをすでにインストールしている。データ収集ユニット２００は、多くの場合、これらの監視システムまたは監視ソフトウェアアプリケーションに提供されるＡＰＩを介して、これらの別個の監視システムによって報告される情報を取得することができる。そのような監視システムまたは監視ソフトウェアプリケーションの実施例には、Ｇｒａｐｈｉｔｅ、Ｎｅｗ Ｒｅｌｉｃ、Ａｐｐｄｙｎａｍｉｃｓ、Ｄａｔａｄｏｇ、Ｒｕｘｉｔ（Ｄｙｎａｔｒａｃｅによる）、Ｔａｋｉｐｉ、Ｒｏｌｌｂａｒ、Ｓｅｎｓｕ、Ｎａｇｉｏｓ、Ｚａｂｂｉｘ、ＥＬＫ Ｓｔａｃｋ、ならびに、実質的に任意の他の生産環境監視ツールが含まれる。

生産環境アシスタント１００のデータ収集および変換ユニット３００は、データキュー３０２を含む。データ収集ユニット２００によって取得されたデータおよび情報は、最初にデータキュー３０２にロードされる。データキュー３０２は、データポイントキュー３０４およびイベントキュー３０６を含むことができる。データキュー３０２は、様々なクライアントの生産環境から受信された大量のデータを保持するように構成される。例えば、データキュー３０２は、複数の異なるクライアント生産環境から報告された１週間分までのデータを保持するように構成することができる。前記データを直ちにデータキュー３０２に入れることによって、受信したデータが決して失われていないことを確実にすることができる。

次いで、ストレージ最適化ユニット３１４は、データキュー３０２内のデータを分析し、受信したデータのすべてまたは様々な部分を、短期リポジトリ３０８、中期リポジトリ３１０、および長期リポジトリ３１２に記憶する。ストレージ最適化ユニット３１４は、データ記憶コストを最小限に抑えるように、高度に効率的な方法で前記データを格納するように動作することができる。さらに、ストレージ最適化ユニット３１４は、受信されたデータをコンポーネント部分に分割し、受信されたデータを、後の時点でそのデータを分析することをより容易にする所定のフォーマットで記憶する役割を担うことができる。

ストレージ最適化ユニット３１４は、異なる記憶タイプおよび記憶期間の拡張をサポートする構成テンプレートを実装する。例えば、テンプレートは、最初に、メモリのみの記憶によって極めて短時間のリポジトリを利用するカテゴリを含むことができる。これは、各ノード上のｔｍｐｆｓファイルシステムとして、またはキャッシュ層（Ｒｅｄｉｓ、Ｍｅｍｃａｃｈｅ、ＲａｂｂｉｔＭＱ、ＡｃｔｉｖｅＭＱ、または任意の他の関連技術）などの任意の他のメモリ内タイプ技術によって実装することができる。前記テンプレートは、それに応じて、短期、中期、および長期の記憶層も含み得る。設定テンプレートはまた、各ストレージ層優先度、フォールバックポリシー判定（書き込みまたは読み出し失敗の場合）、および記憶されるべきオブジェクトタイプを含み得る。

ストレージ最適化ユニット３１４は、まず、構成テンプレートをチェックすることにより、ストレージオブジェクト毎に、使用する最適なストレージレイヤをリアルタイムに計算し、ポリシーに基づいて階層化されたストレージメカニズムを実現する。一旦オブジェクトが取り出されることが必要になると、オブジェクトのタイプおよび時間が既に知られているので、サーチ動作をスキップし、関連する階層を直接指し示すことが可能である。これは、記憶コストおよび性能に関して大きな利点を提供する。

ストレージ最適化アルゴリズムは、実際のデータを異なる階層間で分割し、それを別々のファイルに分割することもできる。例えば、データストリームが１ヶ月のデータポイントを含む場合、最適化ストレージユニット３１４は、前記ポリシーテンプレートを読み取り、時間、優先順位、コスト、または任意の他の属性に基づいて、前記１ヶ月のデータポイントをより小さいセクションに分割することができ、また、異なる記憶タイプにわたって分割することもできる。読み出しリクエスト時に、各特定のピースは、完全な結果として返送される前に、取り出され、メモリに集約される。

生産環境アシスタント１００の一部であるメトリックユニット４００は、クライアントの生産環境から受信または取得されたデータに基づいて様々なメトリックを計算する役割を担う。メトリックユニットは、システム管理者および／またはクライアントが、どのタイプのメトリックが前記クライアントデータから計算されるべきかを判定することを可能にするメトリック構成制御ユニット４０４を含む。次いで、メトリック計算ユニット４０６は、メトリック構成制御ユニット４０４によって確立された構成に基づいてメトリック計算を実際に実行する。

クライアントの生産環境から受信したデータポイントから計算することができるメトリックの例には、平均値、平均、分散、共分散、および実質的に任意の他のタイプのメトリックが含まれる。そのようなメトリックは、ＤＢＳＣＡＮ、ハンペル（Ｈａｍｐｅｌ）フィルタ、ホルト・ウィンタースなどの複数のアウトライアー検出アルゴリズムを使用して計算することができる。これらのメトリック値は、ある期間にわたって、または他の何らかのタイプのグループ化に基づいて計算することができる。メトリック計算ユニット４０６は、データ収集および変換ユニット３００のデータキュー３０２から直接引き出されたデータ、または短期リポジトリ３０８、中期リポジトリ３１０および長期リポジトリ３１２から引き出されたデータ、またはこれらのソースの組合せからのデータを利用することができる。計算されたメトリックは、メトリックリポジトリ４０７に格納される。

メトリックユニット４００は、システム管理者、ユーザ、および生産環境アシスタント１００の他の要素がクエリを実行し、メトリックリポジトリ４０７内の前記計算されたメトリック情報から情報を取得することを可能にするメトリッククエリインタフェース４０８を含む。メトリッククエリインタフェースは、単一のクライアントの生産環境について計算されたメトリック、または複数の異なるクライアント生産環境について計算されたメトリックを取得することを可能にする。その結果、１つの生産環境からのメトリックを、異なる生産環境におけるメトリックと比較して、傾向、課題、および問題を同定するのを補助することができる。

メトリック計算ユニット４０６は、メトリックのメトリックを計算することもできる。言い換えると、複数の異なる類似の生産環境について計算された生産環境変数の平均値を、メトリック計算ユニット４０６によって計算して、その変数のグローバル平均を作成することができる。次いで、このグローバル平均値は、メトリックリポジトリ４０７に格納される。次いで、グローバル平均値を、特定のクライアントの平均値が判断される基準として使用することができる。その変数についての特定のクライアントの平均メトリック値は、その変数について計算されたグローバル平均値と比較され、特定のクライアントの生産環境がグローバル平均とどのように比較されるかが確認される。

個々の生産環境メトリックをグローバル平均と比較する能力は、多くの個々の企業が実行することができないものである。典型的には、企業は、自分自身のメトリックにアクセスするだけである。したがって、１つのクライアントの生産環境からのメトリックを同じメトリックの平均値と比較する能力は、個々の生産環境内の課題および問題を同定するのに役立つ強力なツールとなり得る。さらに、メトリックユニット４００は、生のデータポイントだけでなく、イベントも格納することができるので、複数の属性の集約、ならびにイベントおよびデータポイントの組み合わせが可能である。この強力な組み合わせにより、管理者は、計算されたデータポイントを照会し、相関するイベントを同時に検査することができる。そのメカニズムは、イベント、システム／サーバ、および時間、の間の潜在的な相関を同定するように自動的に使用することもできる。

イベント相関は、複雑なシステムにおける例外イベントの発生を検出し、どの特定のイベントが発生し、どこで発生したかを同定するための方法および手段である。発生するイベントのセットは、ある期間にわたるイベントストリームとしてシステム内で検出することができる。

前記環境アシスタント１００の評価ユニット５００は、受信されたクライアントデータ、ならびに計算されたメトリックを利用して、課題または問題がクライアントの生産環境内で発生しているか否か、ならびにそれらがどのように互いに関連しているかを判定するために設計された様々な分析を実行する。イベント相関は空間次元および時間次元の両方で起こり得るので、イベントは、タイムラインおよび依存性に基づいて関連することが多い。

評価ユニット５００は、各個々のクライアントに合わせてカスタム調整される個々のルールを設定するように使用される評価ルールユニット５０２を含む。評価ルールユニット５０２は、システム管理者およびクライアントが、クライアントの生産環境に対してどのタイプの評価が実行されるべきかを判定する様々なルールを設定することを可能にするルール設定ユニット５０４を含む。また、ルールは、特定のタイプの評価がどの程度頻繁に、および／またはどのような状況下で実行されるべきかを確立することもできる。ルールはまた、特定の分析がどのように実行されるべきかの様々な他の態様を確立することができる。

評価ルールユニット５０２はまた、個々のカスタマーが評価ルールユニットにアクセスして、発生している評価の種類を監視し、クライアントに対して設定された評価ルールを変更することを可能にするカスタマーインタフェース５０６を含む。評価ルールユニット５０２は、評価ルールが実際に格納されるルールデータベース５０８も含む。

評価ユニット５００の分析ユニット５１２は、ルールデータベース５０８に格納されたルールを用いて様々な分析を行う。分析ユニット５１２は、従来の分析、ならびに人工知能ベースの分析を実行することができる。例えば、分析ユニット５１２は、「もし−ならば」または「条件−動作」ルールの形態で専門知識を含むルールベースに基づいてデータを分析するように、ＤＲＯＯＬＳベースのエンジンを利用することができる。各ルールの条件部分は、ワーキングメモリの現在の状態に基づいてルールを適用できるか否かを判定する。ルールの動作部分は、条件が満たされたときにルールから引き出すことができる結論を含む。ワーキングメモリは、各ルールの条件部分を満たすように使用され得る事実を常にスキャンされる。条件が見つかると、ルールが実行される。ルールを実行することは、ワーキングメモリがルールに含まれる結論に基づいて更新されることを意味する。

あるいは、分析ユニット５１２は、ＮＡＳＡによって開発されたオープンソースシステムであるＣＬＩＰＳシステムなどの様々なタイプのルールベースの人工知能エンジンを利用することができる。様々な他の種類の人工知能技術および評価エンジンを分析ユニット５１２によって使用して、クライアントデータおよびメトリックを分析し、相関およびノイズ低減を適用して、課題または問題がクライアントの生産環境内で発生しているか否かを判定することもできる。分析ユニット５１２は、推論に基づいて問題の根本原因を判定することもできる。

分析ユニット５１２によって使用されるＡＩアプローチは、異なるＩＴ監視ソリューション／センサ／エージェントから、ならびにエンドユーザフィードバックから、様々なイベントを通して取得されたナレッジを利用する。推論は、イベントのセマンティクスを検出するためのルール、ならびに、システムアーキテクチャおよびそのコンポーネントの要約（abstraction）に基づいてイベントを相関させるように、専門知識ではなく、汎用アルゴリズムに依存する汎用モデルを適用することによって達成される。

一例として、イベントＡとＢが検出され、イベントＡが課題n１、n２、またはn３によって引き起こされた可能性があり、イベントＢが課題n２、n４、またはn６によって引き起こされた可能性があることが知られている場合、診断は、課題n２が、イベントＡとＢの可能なソースの共通部分を表すので、課題n２が発生したことである。動作または推奨が適用される前に、システム全体の状態および条件を解析することによって、立案が成し遂げられる。学習は、教師あり学習および教師なし学習のファミリーにおいて、複数の機械学習アルゴリズムを適用することによって達成される。

とられ得る別の学習アプローチは、バージョン空間アルゴリズムである。仮説空間Ｈおよび訓練データＤが与えられると、バージョン空間は、Ｄと一致するＨの完全なサブセットであり、バージョン空間は、すべての仮説を列挙し、不一致の仮説を除去することによって、任意の有限なＨについて単純に生成することができる。別の学習例では、まずデータベースをスキャンして頻繁な項目を見つける。例えば、｛ａ，ｂ，ｃ，ｄ…｝である。そのような項目の各ペアについて、２つの項目だけでルールを作成しようとする。例えば、｛ａ｝⇒｛ｂ｝である。次に、データベースを再帰的にスキャンして、各ルールの左または右の部分（左および右の拡張）に一度に１つの項目を追加することによって、より大きなルールを見つける。例えば、｛ａ，ｃ｝⇒｛ｂ｝、次に｛ａ，ｃ，ｄ｝⇒｛ｂ｝等。

作成された各ルールは、それが有効であるか否かを調べるためにテストされる。これは、ルール生成および調節に対する自動化された一定の学習アプローチを提供する。それはまた、異なるカスタマー間でルールおよび推論を転送する能力を提供する。ＩＴ生産環境は、正確な（exact）または同様の技術で同定することができるので、使用することができる特定の技術シグネチャーがある。例えば、カスタマーＡは、Ｄｏｃｋｅｒなどのコンテナ技術の内部に展開されるその環境に関連するルールを設定することができる。コンテナ技術自体は十分に認識されているので、コンテナ技術は、いかなる展開においても常に関連する１組のセンサおよびパラメータを有する。基本シグネチャーがカスタマーＢで検出されると、システムは、同じ一般ルールを注入し、ユーザに、ユーザ自身のニーズに関連する調節を行うように推奨することができる。

最後に、自然言語処理（通信）、知覚、および行動する能力も、修復エンジンの一部として実施される。予防監視アプローチのいくつかは、統計分析（主にベイジアンネットワーク）、ニューラルネットワーク、およびファジー論理を含む。

評価ユニット５００はまた、データ取得ユニットを含むことができ、データ取得ユニットは、分析ユニット５１２によって、特定のタイプの分析を実行するために必要とされるデータを取得するように使用される。データ取得ユニット５１０は、メトリックリポジトリ４０７から、また、データ収集および変換ユニット３００によって提供されるデータソースのいずれかからも、データを取得することができる。場合によっては、データ取得ユニット５１０は、能動収集ユニット２０８のサービスに関与して、分析を実行するのに必要な特定のデータを取得することができる。

分析ユニット５１２が、最終的に、課題または問題が発生しているか、またはクライアントの生産環境内で発生している可能性があると結論付けた場合、前記分析ユニットは、「インシデント」が発生したことを示す。「インシデント」というタームは、クライアントの生産環境の課題または問題と見なすことができる任意の種類の活動、トレンド、発生、またはイベントに適用することを意図した広義のタームである。評価ユニット５００によって特定の条件が確認されると、インシデントを掲げる（raise）ことができる。条件は、検出された異常、閾値を上回るかまたは下回る特定のメトリック計算またはデータポイント、イベント（新たなコード展開、検出された新たなスケーリング活動または検出された構成変更など）、変化率などの複雑な計算、または上記のすべての組合せでもあり得る。次の評価サイクルで、インシデントは分析され得、同様に、考慮に入れられ得る。

インシデントが発生したと判定された場合、前記インシデントはインシデントユニット６００に報告される。インシデントユニット６００は、そのようなインシデントが記録されるインスタントデータベース６０２を含む。インシデントユニット６００は、インシデントデータベース６０２内の情報を照会するように使用することができるインシデントクエリユニットを含む。クエリは、単一のクライアントの生産環境に対して実行することができる。あるいは、インシデントクエリユニット６０４は、ユーザが、複数の異なるクライアント生産環境にわたって発生した同じまたは同様のインシデントについてクエリを実行することを可能にすることができる。

例えば、新たな特定のタイプのインシデントが第１のカスタマーの生産環境について初めて発生した場合、インシデントデータベース６０２において、他のクライアント生産環境で同一のまたは同様のインシデントが発生したか否かを判定することができる。その場合、他のクライアント生産環境を調べて、どのような種類の改善措置がインシデントを治癒または軽減したかを判定することができる。このように、すべてのクライアント生産環境にわたってインシデントを問い合わせる能力は、問題を解決または軽減する方法を迅速に判定するのに役立つ、価値のあるツールを提供する。

複数のクライアント生産環境から監視し学習するこの能力は、ただ１つの生産環境専用のシステムと比較して、ナレッジベースを劇的に増加させる。また、複数のクライアント生産環境から生成されたデータをレビューする能力は、推論および因果関係の推論に役立つ。クライアント、環境、イベント、およびデータポイントにわたるインシデントのナレッジベースを含む共有高速データストア内で索引付けをする能力は、時間、セマンティクス、キーターム、およびシステム間の依存性に基づく類似性アルゴリズムを可能にする。

例えば、特定のシーケンスの後に同一のイベント名が発生した場合、前記システムは、そのシーケンスを割り当て、各ステップに対して、表現として番号を割り当てる。シーケンス一致、ハミング距離、ＢＭ２５、ＤＦＲ、ＤＦＩ、ＩＢ類似性、ＬＭディリクレ、ＬＭジェリネクマーサー（Jelinek Mercer）類似性などの類似性アルゴリズム、ならびに優先アルゴリズムを適用することにより、最良の可能性のある一致を判定し、各関連性をスコア付けすることができる。ここでも、もしクライアントが自分の過去のインシデントのみに依存していれば、この能力は存在しない。

通知ユニット７００は、課題または問題が発生したときにクライアントに通知する役割を担う。前記通知ユニットは、いつおよび／またはどのようにインシデントがクライアントに報告されるべきかを判定するためにシステム管理者およびクライアントによって利用される通知ルール設定ユニット７０２を含む。次に、通知ルール設定ユニット７０２によって確立されたルールは、通知ルールデータベース７０４に格納される。通知分析ユニット７０６は、通知ルールデータベース内のルールを利用して、評価ユニット５００によって同定されたインシデントがクライアントに報告されるべきか否か、またはいつ報告されるべきかを判定する。以下でより詳細に説明するように、通知分析ユニット７０６は、インシデントが発生したと判断された場合、インシデントがクライアントに実際に報告される前に、二次分析または調査を実行する必要があると判断することができる。

通知送信ユニット７００は、インシデントおよび他の情報をクライアントに報告する役割を担う通知送信ユニット７０８を含む。通知送信ユニット７０８は、様々な異なる通信チャネルを利用して、そのような通知をクライアントに発信することができる。例えば、通知は、電子メール、テキストメッセージング、インスタントメッセージング、電話呼び出し、ページャ、またはクライアントに接続することができる実質的に任意の他の通信チャネルを介して発信することができる。同様に、通知送信ユニット７０８は、クライアントおよび生産環境アシスタント１００のシステム管理者の両方に通知を発信するように構成することができる。典型的には、通知ルールデータベース７０４内のルールは、誰がそのような通知を受信すべきか、およびどのように通知が送信されるべきかを示す。

生産環境アシスタント１００は、能動インスペクタシステム８００も含む。能動インスペクタシステム８００は、特定のクライアントに対して個々の能動インスペクタを構成するように使用される能動インスペクタ構成ユニット８０２を含む。言い換えれば、特定のクライアントは、複数の能動インスペクタを有することができ、これらはすべて同時に動作可能である。個々の能動インスペクタのそれぞれは、特定のタイプの課題または問題を探すか、または分析するように構成される。

前記能動インスペクタシステム８００は、データ取得および分析ユニット８０４を含む。データ取得および分析ユニット８０４は、データ収集および変換ユニット３００のデータキュー３０２から、短期リポジトリ３０８、中期リポジトリ３１０および／または長期リポジトリユニット３１２から情報を取得することができる。データ取得および分析ユニット８０４はまた、メトリックユニット４００によって計算され、メトリックリポジトリ４０７に格納された情報を求めることができる。さらに、データ取得および分析ユニット８０４は、データ収集ユニット２００の能動収集ユニット２０８のサービスを利用して、クライアントの生産環境上に構成されたＡＰＩを介して、クライアントの生産環境から直接、様々な情報項目を能動的に取得することができる。

必要であれば、データ取得および分析ユニット８０４は、取得されたデータからメトリックを計算するように、メトリックユニット４００のサービスを利用することができる。データ取得および分析ユニット８０４はまた、取得された情報およびメトリックを評価するように、評価ユニット５００のサービスを利用し得る。最終的に、データ取得および分析ユニット８０４は、監視するように構成された課題、イベント、問題、またはインシデントが発生したか否かを判定する。そうである場合、能動インスペクタシステム８００の報告ユニット８０６は、その課題、問題、イベント、またはインシデントの発生について報告する。報告ユニット８０６は、報告を達成するように、通知ユニット７００のサービスを利用することができる。

生産環境アシスタント１００は、改善ユニット９００も含む。改善ユニット９００は、クライアントの生産環境内で発生した可能性のある課題または問題を修正または軽減すべく試みるように、能動的なステップをとるように構成される。改善ユニット９００は、通知分析インタフェース９０２を含む。通知分析インタフェース９０２は、通知ユニット７００を介して発信された、発生したインシデントに関する通知を受信する。そして、キーワード分析ユニット９０４は、通知を分析し、通知内に特定のキーワードが存在するか否かを判定する。課題同定ユニット９０６は、キーワード分析ユニット９０４からの出力信号を利用して、報告されたインシデントが所定のタイプの課題を示すか否かを判定する。

通知分析インタフェース９０２が、最終的に、所定のタイプの課題または問題が発生したと判定した場合、改善推奨ユニット９０８は、同定された課題または問題を修正、軽減、または別様に対処するための確立されたプロトコルが存在するか否かを判定するために、様々な情報項目をレビューする。改善推奨ユニット９０８は、課題または問題を軽減するのに役立つ所定の方法を探すように、改善措置データベース９１０を調査することができる。改善推奨ユニット９０８はまた、様々なユーザが改善措置データベース９１０に寄与することを可能にするユーザポータル９１２を含むことができる。

１つの特定の実装形態では、改善措置データベース９１０は、ＡｎｓｉｂｌｅＰｌａｙｂｏｏｋｓを利用することができる。セキュアシェル（ＳＳＨ）上のリモート実行モデルは、各ホスト上でプロシージャを実行するように、またはインフラ上でＡＰＩ命令のセット、例えばAmazon Web Services Public Cloud提供者、Google Cloud、Microsoft Azure Cloud、もしくはアプリケーションプロトコルインタフェース（ＡＰＩ）をサポートする限り、他の任意のパブリックもしくはプライベートクラウドサービス（Cloud Foundry, OpenStackなど）を実行することによって、使用され得る。単一のリポジトリを提供し、改善キーワード、システム、および動作に基づいてリポジトリを公開することによって、誰でも特定のユースケースを検索し、関連するプレイブックまたは改善スクリプトを見つけることができる。コントリビュータは、所定のテンプレートに従って改善スクリプトを書き込み、それを共有リポジトリにアップロードすることによって、自分の経験から共有することができる。次いで、システムは、予め定義されたテンプレートから各キーワードおよび動作用語を索引付けし、誰でもそれを実行できるようにすることが可能である。システムおよび改善ナレッジの共有は、改善の信頼性を高め、実行エラーを低減する。

場合によっては、改善推奨ユニット９０８は、同定された課題または問題に対処するために使用することができる複数の改善措置が、改善措置データベース９１０内に存在することを見出すことができる。これが発生すると、クエリユニット９１４を使用して、前記同定された課題または問題を軽減または解決すべく試みるように、改善措置のいずれをとるべきかに関する入力を、システム管理者またはクライアントから取得することができる。システム管理者またはクライアントが１つの改善措置を選択することを可能にすることに加えて、システム管理者またはクライアントは、同定された課題が解決または軽減されるまで、特定の順序でとられるべき複数の改善措置を同定することもできる。

改善措置または改善措置のグループが同定されると、改善措置ユニット９１６は、課題または問題を軽減または解決すべく試みるように、改善措置を実行するように、クライアントの生産環境と対話する。

図１０にユーザインタフェースシステムを図示する。ユーザインタフェースシステム１０００は、カスタマイズ可能であり、様々な異なるユーザ環境に適応することができる。ユーザカスタマイズユニット１００２は、カスタマーおよびそのコンピューティングデバイスとどのように最良に対話するかを判定し、そのユーザカスタマイズ情報をユーザプロファイルデータベース１００４に格納する。前記ユーザカスタマイズ情報は、ユーザが通常、生産環境アシスタント１００と対話するために使用する、特定のデバイスおよび表示画面に関する情報を含むことができる。前記ユーザカスタマイズ情報は、ユーザがテキスト、音声、および／またはビデオを介して対話するか否かについての情報も含むことができる。さらに、前記ユーザカスタマイズ情報は、ユーザの音声コマンドを処理するときに考慮されなければならないユーザのアクセントに関する知識など、ユーザインタフェースシステム１０００が特定のユーザ特性または特色に適応することを可能にする情報を含むことができる。ユーザプロファイルデータベース１００２に格納された情報は、ユーザインタフェースシステム１０００が、特定のディスプレイ画面、特定のスマートフォン、タブレット、および他のモバイルデバイスなどの特定のユーザコンピューティングデバイス上に効果的に表示できるように、情報をフォーマットすることを可能にする。

ユーザインタフェースシステム１０００はまた、様々な異なる形態のユーザ対話を実行することができる。前記ユーザがテキストを介して対話することを選択した場合、テキストインタフェース１００６は、前記ユーザ対話を実行する。テキストインタフェースは、ユーザと通信するように１つ以上のチャットボットコンポーネントまたはサービスを利用することができる。チャットボットは、基本的には、特にインターネットを介して人間のユーザとの対話をシミュレートするように設計されたコンピュータプログラムである。チャットボットは、通常、ユーザが別の人間と対話していると当該ユーザが知覚するように、ルールおよび人工知能によって動力供給（power）される。テキストインタフェース１００６は、それ自体のチャットボットコンポーネントまたはサービスのうちの１つまたは複数を含むことができ、あるいはテキストインタフェース１００６は、他のサービスプロバイダによって提供されるチャットボットコンポーネントまたはサービスを利用することができる。例えば、テキストインタフェースは、Ｆａｃｅｂｏｏｋ（登録商標）メッセンジャ、Ｓｌａｃｋ、ＨｉｐＣｈａｔ、Ｔｅｌｅｇｒａｍ、および他のオンライン提供者によって提供されるチャットボットを利用することができる。

典型的なテキストベースの対話では、ユーザは、質問をするか、またはテキストを介してコマンドを発行し、テキストインタフェース１００６は、前記テキストを解釈し、適切な動作を生じさせる。例えば、ユーザは、テキストベースの質問を発することができ、テキストインタフェース１００６は、質問を解釈し、回答を取得させ、次いで、テキストベースの回答を介して前記ユーザに回答を提供する。テキストインタフェース１００６は、ユーザのテキスト質問またはコマンドを解釈するように、自然言語処理アルゴリズムを利用することができる。

前記テキスト対話に加えて、ユーザインタフェースシステム１０００は、オーディオおよびビデオを介するなど、ユーザ対話の他の手段をサポートする。音声インタフェース１００８は、音声質問またはコマンドの形態でユーザ入力を受信することができる。次いで、音声インタフェース１００８は、前記ユーザの発話された音声入力を解釈し、適切な動作を生じさせる。例えば、ユーザは、発話された音声質問を発行することができ、次いで、音声インタフェースは、質問を解釈し、質問に対する回答を取得し、その回答を前記ユーザに提供する。回答は、音声回答として、テキストベースの回答として、ユーザ表示画面上に提供されるグラフィカル応答として、またはこれらの応答フォーマットの組み合わせとして提供され得る。

ユーザの発話された音声入力は、マイクロフォンを含む任意の種類のユーザインタフェースによって取り込むことができる。そのようなデバイスには、コンピュータ、スマートフォン、またはアマゾンＥｃｈｏおよび関連するアレクサスキルＳＤＫなどの専用音声インタフェースが含まれ得る。あるいは、ユーザは、Ａｐｐｌｅ ＳｉＲｉインタフェースおよび関連するＳｉＲｉ ＳＤＫを介して、ユーザインタフェースシステム１０００の音声インタフェース１００８と対話することができる。

ユーザが、アマゾンＥｃｈｏおよびアレクサ音声サービスなどの別個の音声インタフェースを利用している場合、生産環境アシスタント１００のユーザインタフェースシステム１０００に提供されるユーザ対話は、実際には、テキストインタフェース１００６によって解釈されるテキストの形態で提供され得る。例えば、ユーザの音声コマンドは、Ｅｃｈｏデバイスによってキャプチャされることができ、前記Ｅｃｈｏデバイスまたは関連するアレクサスキルは、前記発話された入力をテキストに変換することができる。次に、前記テキストは、テキストインタフェース１００６に提供され、テキストインタフェース１００６は、ユーザの発話された入力を解釈し、適切な動作をとる。次に、テキストインタフェース１００６は、Ｅｃｈｏデバイスに提供されるテキストベースの応答を提供することができ、Ｅｃｈｏデバイスは、前記テキスト応答を、前記Ｅｃｈｏデバイスによって前記ユーザに再生される音声に変換する。この場合、音声−テキスト変換およびテキスト−音声変換は、ユーザインタフェースシステム１０００によって実行されるのではなく、別個のエンティティによって実行される。

ユーザがビデオカメラを有する場合、ユーザは、ビデオ入力を使用してユーザインタフェースシステム１０００と対話することもできる。ビデオインターフェイス１０１０は、前記ユーザからビデオを受信し、ビデオ入力を解釈する。これは、前記ユーザ提供ビデオに描かれた異なる身体の動きおよびジェスチャを解釈するステップを含むことができる。例えば、前記ユーザは、はいまたはいいえの質問を尋ねられ、前記ユーザは、サムズアップまたはサムダウンでジェスチャして、質問に対する応答を提供することができる。ビデオインターフェイスは、前記ユーザの応答を解釈し、質問を提示した生産環境アシスタント１００の部分に応答を提供することができる。

ユーザがビデオカメラを有する場合、ビデオインターフェイス１０１０はまた、ユーザ認証を達成するのを補助するような、ユーザ提供ビデオであってもよい。この場合、ユーザに従来のユーザ名およびパスワードを入力させる代わりに、ユーザは、ビデオカメラを直接見るだけでよく、ユーザの画像が取り込まれ、ユーザ認証の目的で使用される。ユーザが同定されると、ユーザのプロファイルにアクセスして、後続するユーザ対話への当該ユーザの好みを判定することができる。

ビデオインターフェイス１０１０は、「キャラクタ」または「ペルソナ」をユーザ表示画面上に表示させるように使用することもできる。キャラクタまたはペルソナは、抽象的な人間のような顔、身体、または他の描写を有することができ、キャラクタまたはペルソナは、ユーザ対話における生産環境アシスタント１００を表すことになる。ユーザと対話するシステムキャラクタまたはペルソナは、特定の名前または外観を有するようにカスタマイズすることができる。次いで、前記ユーザは、質問をするとき、またはコマンドを発行するときに、キャラクタまたはペルソナの名前を使用することができる。例えば、ユーザは、「サム、生産システムでＣＰＵ使用率が５０％を超えるすべてのサーバを同定し、逐次再起動した後に報告してください」と言うことによって、情報を求めるリクエストを発行することができる。そのようなコマンドには、当該ユーザの意図（同定、報告、再起動）、名詞、メトリック、および特性（specifics）（生産システム）が含まれる。

対話型フィードバックシステムは、ユーザインタフェースシステム１０００を介して実装されてもよい。音声、ビデオ、または従来の画面操作インタフェースを介して提示される各イベントについて、ユーザはフィードバックを提供する能力を有する。このフィードバックは、前記システムに対する学習入力の１つを形成するので、システムの重大な（critical）部分である。システムは、いくつかのフィードバックタイプを処理することができる。例えば、ユーザは、イベントまたはインシデントが偽陽性であることを示すことができる。ユーザは、推奨が有用であるか否かを示すこともできる。また、ユーザは、特定の課題を解決するためにどのステップを前記ユーザが行ったかに関する入力を提供することもできる。ユーザが、索引付けおよび将来の参照のために、ファイルをシステムにアップロードすることも可能であり得る。このようなユーザフィードバックは、次いで、生産環境アシスタント１００の性能を改良するように使用される。

図１１に、クライアントの生産環境からデータを取得し、そのデータを１つ以上のデータキューに格納するように実行される方法のステップを図示する。方法１１００は開始後、ステップＳ１１０２に進み、ここでクライアントの生産環境にインストールされたＡＰＩによって報告されたデータは、データ収集ユニット２００の受動収集ユニット２０２によって受信される。前記受信されたデータは、データポイントおよびイベントを含み得る。これらのデータポイントおよびイベントは、コンピュータ機器、ネットワーキング機器、および前記クライアントの生産環境上で実行されているソフトウェアアプリケーションの個々の要素にも、関連し得る。上述のように、前記受信されたデータは、金融データまたはトラフィックデータなどのビジネス関連データも含むことができる。

前記方法１１００はまた、任意のステップＳ１１０４を含み、データ収集ユニット２００の能動収集ユニット２０８は、前記クライアントの生産環境にインストールされたＡＰＩを介して、クライアントの生産環境から特定のデータを能動的に取得する。ステップＳ１１０６において、前記受信されたデータポイント情報は、データポイントキューにロードされる。本方法はまた、ステップＳ１１０８を含み、受信されたイベント情報がイベントキューにロードされる。そして、本方法は終了する。

図１２に、データを格納する（store）ようにデータ収集および変換ユニット３００によって実行されるであろう方法のステップを図示する。方法１２００は開始後ステップＳ１２０２に進み、ここでデータ収集および変換ユニット３００のストレージ最適化ユニット３１４は、データポイントキュー３０４またはイベントキュー３０６に格納されているクライアントデータを取得する。ステップＳ１００４において、ストレージ最適化ユニット３１４は、前記受信したデータを様々な方法で操作して、格納のためにデータを準備する。これは、受信されたデータを非直列化するステップ、および前記受信されたデータを、前記データの後の分析を実行することをより容易にする予め定義されたフォーマットに再フォーマットするステップ、を含むことができる。次に、本方法はステップＳ１２０６に進み、ストレージ最適化ユニット３１４は、短期リポジトリ３０８にデータのいくつかのアイテムを格納する。ステップＳ１２０８において、ストレージ最適化ユニット３１４は、中期リポジトリ３１０に特定のデータのアイテムを格納する。ステップＳ１２１０において、前記ストレージ最適化部３１４は、長期リポジトリに特定のデータのアイテムを格納する。そして、本方法は終了する。

図１３に、生産環境アシスタント１００のメトリックユニット４００によって実行される方法のステップを図示する。方法１３００は、開始後ステップＳ１３０２に進み、ここで、クライアントの生産環境に関連するデータが、データポイントキュー３０４から、および／またはイベントキュー３０６から、および／または（短期記憶リポジトリ３０８、中期記憶リポジトリ３１０、および長期記憶リポジトリ３１２などの）データ記憶リポジトリから取得される。ステップＳ１３０４では、特定のクライアントのＡＰＩから受信されたことを確実にするように、前記データが検証される。これは、前記データと共に提供されたクライアント固有の暗号鍵、トークンまたはコードの存在について、前記データを検査するステップを含むことができる。

次に、前記方法はステップＳ１３０６に進み、前記データが構文解析（parse）される。ステップＳ１３０８において、前記データは、所定のデータフォーマットに配列（arrange）される。前記構文解析ステップ、および配列ステップＳ１３０６、１３０８は、任意のデータステップであって、使用されているデータの特定の種類および計算される当該メトリックに依り、実行されてもされなくてもよい。

次に、ステップＳ１３１０において、メトリクス計算ユニット４０６は、前記取得したデータを用いて様々なメトリクスを計算する。次に、ステップＳ１３１２において、前記計算されたメトリックは、メトリックリポジトリ４０７に格納される。そして、本方法は終了する。

図１４に、特定のインシデントが発生したか否かを判定するために評価ユニット５００によって実行される方法のステップを図示する。方法１４００は開始後ステップＳ１４０２に進み、ここで評価ユニット５００のデータ取得ユニット５１０は、特定のクライアントの生産環境に関連するデータを取得する。ステップＳ１４０４において、前記取得されたデータは、評価ユニット５００の分析ユニット５１２によって分析される。ステップＳ１４０６において、分析ユニット５１２は、ステップＳ１４０４で実行された前記分析に基づいて、所定のインシデントが発生したか否かを判定する。所定のインシデントが発生したと判定された場合、ステップＳ１４０８において、前記インシデントは、インシデントユニット６００および／または通知ユニット７００に報告される。そして、本方法は終了する。

図１５に、生産環境アシスタント１００の通知ユニット７００によって実行される方法の様々なステップを図示する。方法１５００は開始後、ステップＳ１５０２に進み、ここで通知ユニット７００は、所定のインシデントが特定のクライアントの生産環境について発生したことを示す報告を受信する。次に、本方法は、通知分析ユニット７０６が通知ルールデータベース７０４をチェックして、そのようなインシデントを処理するためのルールが通知ルールデータベース７０４内に存在するか否かを判定するステップＳ１５０４に進む。前記インシデントに対するルールが存在しない場合、本方法はステップＳ１５０６に進み、ここで、前記インシデントは、標準報告手順に従ってクライアントおよび／またはシステム管理者に報告される。

前記インシデントを処理するためのルールが存在する場合、通知送信ユニットは、そのルールに従って前記インシデントを報告する。場合によっては、前記ルールは、単に、前記インシデントの発生が、１つ以上の通信チャネルを介してクライアントまたはシステム管理者に報告されるべきであることを示す。そうである場合、通知送信ユニット７０８は、前記ルールに従って前記通知を行う。

他の場合では、インシデントを報告するための前記ルールは、前記インシデントがクライアントまたはシステム管理者に報告される前に、何らかの追加の調査または分析が実行されるべきであることを示す。その場合、本方法はステップＳ１５０８に進み、ここで通知ユニット７００の通知分析ユニット７０６によって二次分析が実行される。前記二次分析は、付加的情報を取得するステップ、または前記インシデントが持続するか否かを判定するために所定の期間待機するステップ、を含み得る。次に、本方法はステップＳ１５１０に進み、ここで、ステップＳ１５０８で実行された前記二次分析が前記インシデントを報告すべきであることを示している場合にのみ、前記インシデントは報告される。そして、本方法は終了する。

図１６に、前記能動インスペクタシステム８００によって構成された能動インスペクタによって実行される方法のステップを図示する。上述したように、能動インスペクタは、特定の課題または問題の発生を監視するように、クライアントの生産環境内のデータまたはイベントを能動的にチェックする。

方法１６００は開始後ステップＳ１６０２に進み、ここで、前記能動インスペクタのデータ取得および分析ユニット８０４が、クライアントの生産環境内にインストールされたＡＰＩを使用して、前記クライアントの生産環境からデータを能動的に収集する。次いで本方法はステップＳ１６０４に進み、ここで、様々なメトリックが前記取得されたデータを利用して計算される。ステップＳ１６０４は、メトリックユニット４００のサービスを利用して実行することができる。

次に、本方法は、ステップＳ１６０６に進み、ここで、前記取得されたデータおよび／または前記計算されたメトリックが分析されて、所定のインシデントが発生したか否かが判定される。この分析は、上述したように、評価ユニット５００のサービスを用いて実行することができる。次に本方法はステップＳ１６０８に進み、ここで、前記インシデントが発生したと判定された場合、前記インシデントの発生が報告される。ここでも、前記インシデントについての前記報告は、上述したように、通知ユニット７００のサービスを用いて実行することができる。

図１７に、クライアントの生産環境内で発生した課題または問題を修正または軽減すべく試みるように、改善ユニット９００によって実行される方法のステップを図示する。本方法１７００は開始後ステップＳ１７０２に進み、ここで、クライアントのシステムに関連する通知が改善ユニット９００によって受信される。次いで、本方法はステップＳ１７０４に進み、ここで、改善ユニット９００の通知分析インタフェース９０２は、１つ以上のタイプの改善措置によって修正または軽減され得る課題または問題に関連するか否かを判定するために、前記受信された通知を分析する。この分析は、改善ユニット９００の改善推奨ユニット９０８のサービスを用いて実行することもできる。

次に、本方法はステップＳ１７０６に進み、ここで、前記同定された課題を修正または軽減するように実行することができる複数の異なる種類の改善措置があるか否かを判定するために、チェックが実行される。複数のタイプの改善措置が同定された場合、本方法はステップＳ１７０８に進み、ここで、どのタイプの改善措置を実行すべきかについての入力が取得される。これは、システム管理者またはクライアントにクエリを発信する改善推奨ユニット９０８のクエリユニット９１４を含むことができる。次に、ステップＳ１７０８で受信または取得された前記入力は、どのタイプの改善措置が実行されるべきかを判定するために使用され、ステップＳ１７０１で、改善措置ユニット９１６によって改善措置がとられる。

ステップＳ１７０６で実行された前記チェックが、改善措置が同定されなかったこと、または単一のタイプの改善措置のみが同定されたことを示す場合、本方法は、セットＳ１７１２に進む。ステップＳ１７１２において、単一のタイプの改善措置のみが同定されたか否かを判定するためにチェックが実行される。そうである場合、本方法はステップＳ１７１４に進み、ここで、改善措置ユニット９１６が改善措置をとる。ステップＳ１７１２で実行された前記チェックが、改善措置が同定されなかったことを示す場合、前記方法は単に終了する。

方法およびシステムは、その特定の実施形態に関して説明されてきたが、それらは、そのように限定されない。したがって、上記の教示に照らして、多くの修正形態および変形形態が明らかになる可能性がある。本明細書に記載され、図示されている、詳細、材料、および部品の配置における多くの追加の変更を、当業者は行うことができる。したがって、本明細書で提供される方法、デバイス、およびシステムは、本明細書で開示される実施形態に限定されるべきではなく、具体的に説明される以外の実施を含むことができ、法律の下で許容される限り広く解釈されるべきであることが理解されるであろう。

本明細書に記載された主題および動作の実装は、デジタル電子回路、または、本明細書に開示された構造およびそれらの構造的同等物を含むコンピュータソフトウェア、ファームウェア、もしくはハードウェア、または、それらの１つ以上の組み合わせにおいて実装することができる。本明細書で説明される主題の実施形態は、データ処理装置による実行のために、またはデータ処理装置の動作を制御するために、コンピュータ記憶媒体上に符号化された、１つ以上のコンピュータプログラム、すなわち、コンピュータプログラム命令の１つ以上のモジュールとして実施することができる。代替的にまたは追加的に、プログラム命令は、データ処理装置による実行のために適切な受信機器に送信するための情報を符号化するように生成される、人工的に生成された透過信号、例えば、機械によって生成された電気信号、光信号、または電磁信号上に符号化されてもよい。コンピュータ記憶媒体は、コンピュータ読み取り可能記憶デバイス、コンピュータ読み取り可能記憶基板、ランダムまたはシリアルアクセスメモリアレイまたはデバイス、あるいはそれらの１つ以上の組合せとすることができ、またはそれらに含まれることができる。さらに、コンピュータ記憶媒体は伝播信号ではないが、コンピュータ記憶媒体は、人工的に生成された伝播信号に符号化されたコンピュータプログラム命令のソースまたは宛先とすることができる。コンピュータ記憶媒体はまた、１つ以上の別個の物理的コンポーネントまたは媒体（例えば、複数のCD、ディスク、または他の記憶デバイス）であってもよく、またはそれらに含まれてもよい。

本明細書で説明される動作は、１つ以上のコンピュータ読み取り可能記憶デバイス上に格納されたデータ上で、または他のソースから受信されたデータ上で、データ処理装置によって実行される動作として実装することができる。

「データ処理装置」というタームは、例として、プログラマブルプロセッサ、コンピュータ、システムオンチップ、または複数のもの、またはこれらの組み合わせを含む、データを処理するためのすべての種類の装置、デバイス、および機械を包含し、前記装置は、専用論理回路、例えば、FPGA（フィールドプログラマブルゲートアレイ）またはASIC（特定用途向け集積回路）を含み得る。前記装置は、ハードウェアに加えて、問われているコンピュータプログラムの実行環境を生成するコード、例えば、プロセッサファームウェア、プロトコルスタック、データベース管理システム、オペレーティングシステム、クロスプラットフォームランタイム環境、仮想マシン、またはそれらの１つ以上の組み合わせを構成するコードを含むこともできる。前記装置および実行環境は、ウェブサービス、分散コンピューティング、およびグリッドコンピューティングインフラストラクチャなどの様々な異なるコンピューティングモデルインフラストラクチャを実現することができる。

コンピュータプログラム（プログラム、ソフトウェア、ソフトウェアアプリケーション、スクリプト、またはコードとしても知られる）は、コンパイル言語またはインタプリタ言語、宣言型言語または手続き型言語を含む任意の形態のプログラミング言語で書くことができ、スタンドアロンプログラムとして、またはモジュール、コンポーネント、サブルーチン、オブジェクト、またはコンピューティング環境での使用に適した他のユニットとして含む任意の形態で展開することができる。コンピュータプログラムは、必須ではないが、ファイルシステム内のファイルに対応することができる。プログラムは、他のプログラムまたはデータを保持するファイルの一部（例えば、マークアップ言語リソースに格納された１つ以上のスクリプト）、問われている課題専用の単一のファイル、または複数の協調ファイル（例えば、１つ以上のモジュール、サブプログラム、またはコードの一部を格納するファイル）に格納することができる。コンピュータプログラムは、１つの部位に展開されるか、または複数の部位にわたって分散され、通信ネットワークによって相互接続される、１つのコンピュータ上または複数のコンピュータ上で実行されるように展開することができる。

本明細書で説明するプロセスおよび論理フローは、１つ以上のコンピュータプログラムを実行する１つ以上のプログラマブルプロセッサによって実行して、入力データを操作し、出力信号を生成することによって動作を実行することができる。プロセスおよび論理フローは、FPGA（フィールドプログラマブルゲートアレイ）またはASIC（特定用途向け集積回路）などの専用論理回路によっても実行することができ、装置は、専用論理回路として実装することもできる。

コンピュータプログラムの実行に適したプロセッサには、例として、汎用マイクロプロセッサおよび専用マイクロプロセッサの両方、ならびに任意の種類のデジタルコンピュータの任意の１つ以上のプロセッサが含まれる。一般に、プロセッサは、読み出し専用メモリまたはランダムアクセスメモリ、あるいはその両方から命令およびデータを受信する。コンピュータの本質的な要素は、命令に従って動作を実行するためのプロセッサと、命令およびデータを記憶するための１つ以上のメモリデバイスである。一般に、コンピュータはまた、データを記憶するための１つ以上の大容量記憶デバイス、例えば、磁気ディスク、光磁気ディスク、または光ディスクを含むか、またはそれらからデータを受信するか、それらにデータを転送するか、またはそれらの両方を行うように動作可能に結合される。しかし、コンピュータは、そのようなデバイスを有する必要はない。さらに、コンピュータは、ほんの数例を挙げると、別のデバイス、例えば、携帯電話、携帯情報端末（PDA）、モバイルオーディオまたはビデオプレーヤ、ゲームコンソール、全地球測位システム（GPS）受信機、またはポータブル記憶デバイス（例えば、ユニバーサルシリアルバス（USB）フラッシュドライブ）に埋め込まれ得る。コンピュータプログラム命令およびデータを格納するのに適したデバイスは、例として、半導体メモリデバイス、EPROM、EEPROM（登録商標）、およびフラッシュメモリデバイス、磁気ディスク、例えば、内部ハードディスクまたはリムーバブルディスク、光磁気ディスク、ならびにCD−ROMおよびDVD−ROMディスクを含む、あらゆる形態の不揮発性メモリ、媒体、およびメモリデバイスを含む。プロセッサおよびメモリは、専用論理回路によって補足され得るか、または専用論理回路に組み込まれ得る。

ユーザとの対話を提供するように、本明細書で説明される主題の実装形態は、ユーザに情報を表示するためのディスプレイデバイス、例えば、CRT（陰極線管）またはLCD（液晶ディスプレイ）モニタと、ユーザがコンピュータに入力を提供することができるキーボードおよびポインティングデバイス、例えば、マウスまたはトラックボールとを有するコンピュータ上で実装することができる。他の種類のデバイスも、ユーザとの対話を提供するように使用することができ、例えば、ユーザに提供されるフィードバックは、任意の形態の感覚フィードバック、例えば、視覚フィードバック、聴覚フィードバック、または触覚フィードバックとすることができ、ユーザからの入力は、音響効果、音声、または触覚入力を含む任意の形態で受信することができる。さらに、コンピュータは、ユーザによって使用されるデバイスにリソースを発信し、デバイスからリソースを受信することによって、例えば、ウェブブラウザから受信されたリクエストに応答して、ユーザのクライアントデバイス上のウェブブラウザにウェブページを発信することによって、ユーザと対話することができる。

本明細書で説明される対象の実施態様は、バックエンドコンポーネント、例えば、データサーバとして、またはミドルウェアコンポーネント、例えば、アプリケーションサーバを含む、またはフロントエンドコンポーネント、例えば、ユーザが本明細書で説明される対象の実施態様と対話することができる画面操作インタフェースまたはウェブブラウザを有するクライアントコンピュータ、または１つもしくは複数のバックエンド、ミドルウェア、もしくはフロントエンドコンポーネントの任意の組合せなどを含むコンピューティングシステムで実施態様することができる。システムのコンポーネントは、任意の形態または媒体のデジタルデータ通信、例えば、通信ネットワークによって相互接続することができる。通信ネットワークの例は、ローカルエリアネットワーク（「LAN」）およびワイドエリアネットワーク（「WAN」）、インターネットワーク（例えば、インターネット）、およびピアツーピアネットワーク（例えば、アドホックピアツーピアネットワーク）を含む。

コンピューティングシステムは、クライアントおよびサーバを含むことができる。クライアントとサーバは、一般に、互いに離れており、典型的には、通信ネットワークを介して対話する。クライアントとサーバとの関係は、それぞれのコンピュータ上で実行され、互いにクライアント−サーバ関係を有するコンピュータプログラムによって生じる。いくつかの実装形態では、サーバは、（例えば、クライアントデバイスと対話するユーザにデータを表示し、ユーザからユーザ入力を受信するように）クライアントデバイスにデータ（例えば、HTMLページ）を送信する。クライアントデバイスで生成されたデータ（例えば、前記ユーザ対話の結果）は、サーバでクライアントデバイスから受信することができる。

１つ以上のコンピュータのシステムは、ソフトウェア、ファームウェア、ハードウェア、またはそれらの組み合わせを、動作中にシステムに動作を実行させるか、または実行させるシステムにインストールさせることによって、特定操作または動作を実行するように構成することができる。１つ以上のコンピュータプログラムは、データ処理装置によって実行されると、前記装置に動作を実行させる命令を含むことによって、特定操作または動作を実行するように構成することができる。

本明細書は、多くの特定の実施態様の詳細を含むが、これらは、任意の発明または特許請求され得るものの範囲に対する限定として解釈されるべきではなく、むしろ、特定の発明の特定の実施態様に特有の特徴の説明として解釈されるべきである。本明細書では、別個の実施態様の文脈で説明される特定の特徴を、単一の実施態様で組み合わせて実施することもできる。逆に、単一の実装の文脈で説明される様々な特徴は、複数のインプリメンテーションで別々に、または任意の適切なサブコンビネーションでインプリメントされることもできる。さらに、特徴は、特定の組合せで動作するものとして上述され、そのようなものとして最初に請求されてもよいが、請求された組合せからの１つ以上の特徴が、場合によっては組合せから切り出されることができ、請求される組合せは、サブコンビネーションまたはサブコンビネーションの変形を対象とすることができる。同様に、動作は、特定の順序で図面に描かれているが、これは、望ましい結果を達成するように、そのような動作が、示されている特定の順序で、または連続した順序で実行されること、または図示されているすべての動作が実行されることを必要とするものとして理解されるべきではない。特定の状況では、マルチタスキングおよび並列処理が有利であり得る。さらに、上述の実施態様における様々なシステムコンポーネントの分離は、すべての実施態様においてそのような分離を必要とするものと理解されるべきではなく、説明されるプログラムコンポーネントおよびシステムは、一般に、単一のソフトウェア製品に統合されるか、または複数のソフトウェア製品にパッケージ化され得ることが理解されるべきである。

図１は、生産環境アシスタントの様々な要素を図示するブロック図である。 図２は、データ収集ユニットの様々な要素を図示するブロック図である。 図３は、データ収集および変換ユニットの様々な要素を図示するブロック図である。 図４は、メトリックユニットの様々な要素を図示するブロック図である。 図５は、評価ユニットの様々な要素を図示するブロック図である。 図６は、インシデントユニットの様々な要素を図示するブロック図である。 図７は、通知ユニットの様々な要素を図示するブロック図である。 図８は、能動インスペクタシステムの様々な要素を図示するブロック図である。 図９は、改善ユニットの様々な要素を図示するブロック図である。 図１０は、ユーザインタフェースシステムの様々な要素を図示するブロック図である。 図１１は、クライアントシステムからデータを収集する方法のステップを図示するフローチャートである。 図１２は、受信したクライアントデータを様々なデータリポジトリに格納する方法のステップを図示するフローチャートである。 図１３は、収集されたクライアントデータから様々なメトリックを計算する方法のステップを図示するフローチャートである。 図１４は、インシデントが発生したか否かを判定するためにデータを分析する方法のステップを図示するフローチャートである。 図１５は、発生したインシデントを報告する方法のステップを図示するフローチャートである。 図１６は、データを取得し、所定のインシデントが発生したか否かを判定するためにクライアントのシステムを能動的に監視する方法のステップを図示するフローチャートである。 図１７は、クライアントのシステムに関する課題または問題を修正するように改善措置をとる方法のステップを図示するフローチャートである。

Claims (20)

1. 生産環境を監視し、報告するための方法であって、
   生産環境に関連するデータを取得するステップと、
   前記取得されたデータに基づいて少なくとも１つのメトリック（metric）を計算するステップと、
   所定のインシデントが発生したか否かを判定するために、前記取得されたデータおよび前記計算された少なくとも１つのメトリックのうちの少なくとも１つを分析するステップと、
   所定のインシデントが発生した場合、前記所定のインシデントに関連するルールが存在するか否かに基づいて前記所定のインシデントを報告するか否かを判定するステップと、を含む方法。
2. データを取得する前記ステップは、前記生産環境内に常駐する（resident）コンピューティングシステムにインストールされた少なくとも１つのアプリケーションプログラミングインタフェース（ＡＰＩ）からデータを取得するステップを含む請求項１に記載の方法。
3. データを取得する前記ステップは、前記生産環境内に常駐するコンピューティングシステムにインストールされた少なくとも１つのアプリケーションプログラミングインタフェース（ＡＰＩ）からデータを取得するステップと、
   前記取得されたデータを少なくとも１つのキューにロードするステップと、を含む請求項１に記載の方法。
4. 少なくとも１つのメトリックを計算する前記ステップは、
   前記取得されたデータが有効なデータであるか否かを、前記生産環境に割り当てられた暗号化コードまたは鍵のうちの少なくとも１つを使用して判定するステップと、
   前記取得されたデータが有効であると判定された場合にのみ、前記取得されたデータに基づいて少なくとも１つのメトリックを計算するステップと、を含む、請求項１に記載の方法。
5. 前記イベントを報告するか否かを判定する前記ステップは、
   前記所定のインシデントに関連するルールが存在するか否かを判定するステップと、
   前記所定のインシデントに関連するルールが存在しない場合に、前記所定のインシデントを報告するステップと、
   前記所定のインシデントに関連するルールが存在する場合、前記ルールに従う二次分析を実行するステップと、
   前記ルールおよび前記二次分析の結果が前記所定のインシデントを報告すべきであることを示す場合に限り、前記所定のインシデントを報告するステップと、を含む、請求項１に記載の方法。
6. 生産環境に関連するデータを取得する前記ステップは、前記生産環境に常駐する１つ以上のコンピューティングシステムに、前記１つ以上のコンピューティングシステムにインストールされた１つ以上のアプリケーションプログラミングインタフェースを介して、能動的に問い合わせることによって、データを能動的に取得するステップを含む、請求項１に記載の方法。
7. 分析する前記ステップは、所定のインシデントが発生したか否かを判定するために、前記取得されたデータのうちの少なくとも１つと、データへの前記計算された少なくとも１つのメトリックおよび／または他の同様の生産環境からの計算されたメトリックと、を比較するステップを含む、請求項１に記載の方法。
8. 分析する前記ステップは、所定のインシデントが発生したか否かを判定するために、人工知能技術およびデータ、ならびに他の同様の生産環境からの計算されたメトリックを利用する、請求項１に記載の方法。
9. 所定のインシデントが発生したと判定された場合、前記所定のインシデントを引き起こした前記生産環境内の課題または性能問題を潜在的に緩和することができる改善措置を同定するステップをさらに含む、請求項１に記載の方法。
10. 生産環境を監視し、報告するシステムであって、
    生産環境に関連するデータを取得するステップのための手段と、
    前記取得されたデータに基づいて少なくとも１つのメトリックを計算するステップのための手段と、
    所定のインシデントが発生したか否かを判定するために、前記取得されたデータおよび前記計算された少なくとも１つのメトリックのうちの少なくとも１つを分析するステップのための手段と、
    所定のインシデントが発生した場合、前記所定のインシデントに関連するルールが存在するか否かに基づいて前記所定のインシデントを報告するか否かを判定するステップのための手段と、を含むシステム。
11. 生産環境を監視し、報告するためのシステムであって、生産環境に関連するデータを取得する少なくとも１つのプロセッサを備えるデータ収集ユニットと、
    前記取得されたデータに基づいて少なくとも１つのメトリックを計算する少なくとも１つのプロセッサを備えるメトリックユニットと、
    所定のインシデントが発生したか否かを判定するために、前記取得されたデータおよび／または前記計算された少なくとも１つのメトリックのうちの少なくとも１つを使用する少なくとも１つのプロセッサを備えるインシデントユニットと、
    所定のインシデントが発生した場合、前記所定のインシデントに関連するルールが存在するか否かに基づいて前記所定のインシデントを報告するか否かを判定する少なくとも１つのプロセッサを備える評価ユニットと、を含むシステム。
12. 前記メトリックユニットは、前記生産環境内に常駐するコンピューティングシステムにインストールされた少なくとも１つのアプリケーションプログラミングインタフェース（ＡＰＩ）からデータを取得する、請求項１１に記載のシステム。
13. 前記メトリックユニットは、
    前記生産環境内に常駐するコンピューティングシステムにインストールされた少なくとも１つのアプリケーションプログラミングインタフェース（ＡＰＩ）からデータを取得し、
    前記取得されたデータを少なくとも１つのキューにロードする、請求項１１に記載のシステム。
14. 前記メトリックユニットは、
    前記取得されたデータが有効なデータであるか否かを、前記生産環境に割り当てられた暗号化コードまたは鍵のうちの少なくとも１つを使用して判定し、
    前記取得されたデータが有効であると判定された場合にのみ、前記取得されたデータに基づいて少なくとも１つのメトリックを計算する、請求項１１に記載のシステム。
15. 前記評価ユニットは、
    前記所定のインシデントに関連するルールが存在するか否かを判定し、
    前記所定のインシデントに関連するルールが存在しない場合、前記所定のインシデントを報告し、
    前記所定のインシデントに関連するルールが存在する場合、前記ルールに従う二次分析を実行し、
    前記ルールおよび二次分析の結果が、前記所定のインシデントが報告されるべきであることを示す場合に限り、前記所定のインシデントを報告する、請求項１１に記載のシステム。
16. 前記１つ以上のコンピューティングシステムにインストールされた１つ以上のアプリケーションプログラミングインタフェースを介して、前記生産環境に常駐する１つ以上のコンピューティングシステムに能動的に問い合わせることによって、データを能動的に取得する能動インスペクタユニットをさらに備える、請求項１１に記載のシステム。
17. 所定のインシデントが発生したか否かを判定するために、前記取得されたデータのうちの少なくとも１つ、および／またはデータへの前記計算された少なくとも１つのメトリック、および／または他の同様の生産環境からの計算されたメトリック、を比較するインシデントユニットを含む、請求項１１に記載のシステム。
18. 前記インシデントユニットは、所定のインシデントが発生したか否かを判定するために、人工知能技術およびデータ、ならびに他の同様の生産環境からの計算されたメトリックを利用する、請求項１１に記載のシステム。
19. 所定のインシデントが発生したと判定された場合、前記所定のインシデントを引き起こした前記生産環境内の課題または性能問題を潜在的に緩和することができる改善措置を同定する改善ユニットをさらに含む、請求項１１に記載のシステム。
20. １つ以上のプロセッサによって実行されるときに生産環境を監視し、報告するシステムのための命令を含む非一時的なコンピュータ読み取り可能記録媒体であって、
    生産環境に関連するデータを取得するステップと、
    前記取得されたデータに基づいて少なくとも１つのメトリックを計算するステップと、
    所定のインシデントが発生したか否かを判定するために、前記取得されたデータおよび前記計算された少なくとも１つのメトリックのうちの少なくとも１つを分析するステップと、
    所定のインシデントが発生した場合、前記所定のインシデントに関連するルールが存在するか否かに基づいて前記所定のインシデントを報告するか否かを判定するステップと、を含む方法の実行を引き起こす、非一時的なコンピュータ読み取り可能記録媒体。
    
    

Images