JP2013527957A - 複雑な分散アプリケーションにおける自動化されたリカバリ及びエスカレーション - Google Patents

Abstract

複雑な分散アプリケーション環境における検出されたハードウエア及び／又はソフトウエアの問題に基づくアラートは、自動的に問題を解決するためのリカバリアクションにマッピングされる。マッピングされていないアラートは、指定された個人又はチームからの確認ハンドオフ通知を含む循環エスカレーション方法を介して指定された個人やチームにエスカレーションされる。各アラートだけでなく解消のためにエスカレーションプロセスを介して収集された情報は、自動化された解決の知識ベースを拡大するために記録される。

Description

本発明は、複雑な分散アプリケーションにおける自動化されたリカバリ及びエスカレーションするめのシステムおよび方法に関する。

今日のネットワーク通信環境において、ローカルで実行されるアプリケーションによって提供されていた多くのサービスは、分散サービスを介して提供されている。例えば、電子メールサービス、カレンダー／スケジューリングサービス、及び同様のものは、物理サーバー、仮想サーバー、ストレージ設備、及び地理的な境界を越えて他のコンポーネントの多くを含む複雑なネットワークシステムを介して提供される。企業ネットワーク等の組織のシステムは、物理的に別のサーバーファーム等を介して実施されることができる。

分散サービスはアプリケーションのインストール、アップデート及びメンテナンスを管理することをより簡単にさせる一方で（すなわち、何百回のインストール、アップデート及びメンテナンスの代わりに、何千ものローカルアプリケーションでは無いにしても、集中管理サービスはこれらの作業の面倒を見ることができない）、かかるサービスは依然として複数のサーバー上で実行される多くのアプリケーションを巻き込んでいる。かかる大規模な分散アプリケーションを継続的に管理するとき、様々な問題が予想される。ハードウエアの故障、ソフトウエアの問題、及びその他の予期しない不具合が定期的に発生することがある。かかる問題を手動で管理してリカバリしようとすると、専用かつドメイン知識の豊富な運用エンジニアのコストが法外な数で必要とする場合がある。

この概要は、以下の詳細な説明で更に説明されて簡略化した形で概念の選択を紹介するために提供される。この概要は、排他的に重要な特徴又は請求された主題の本質的な特徴を特定することを意図しておらず、特許請求された主題の範囲を決定する際の助けとして意図されている。

実施形態は、検出されたアラートをリカバリアクションにマッピングして、ネットワーク接続された通信環境における問題を自動的に解決することに向けられている。マッピングされていないアラートは、指定された個人からの確認ハンドオフ通知を含む循環エスカレーション方法を介して特定の個人にエスカレーションされることができる。いくつかの実施形態によれば、エスカレーションプロセスを介して各アラートと同様に解消のために収集した情報は、自動化された解決の知識ベースを拡大するために記録されることができる。

これら及び他の特徴及び利点は、以下の詳細な説明を読むこと及び関連する図面の見ることから明らかになるであろう。上記の一般的な説明及び以下の詳細な説明は説明であり、請求項に記載された態様を制限するものではないことを理解すべきである。

図１はアラートの検出が修復アクション又はアラートのエスカレーションを導くことができる環境の一例を示す概念図である。 図２はアラートのエスカレーション中のアクションを示す作用図である。 図３は、多領域環境におけるアラート管理を示す別の概念図である。 図４は実施形態によるシステムが実施されるネットワーク環境である。 図５は実施形態が実施されるコンピューティングオペレーティング環境の一例のブロック図である。 図６は、実施形態によるネットワーク化された通信環境でのアラートの自動管理のための論理フロー図を図解する。

上記で簡単に説明したように、ネットワーク化されたシステム内のアラートは、自動化されたアクション／エスカレーションプロセスを介して管理される。当該プロセスは、自動化されたアクションの部分のための知識ベースを拡大しながら、手動で解決するためのアラート及び／又はエスカレーションに対してマッピングされたアクションを利用し、問題を対処する指定された個人に収集した情報を提供する。以下の詳細な説明では、参照符号が一部を形成する添付図面に対して行われ、その中に図解として具体的な実施形態又は例が示されている。これらの態様は組み合わされてもよく、他の態様を利用してもよいし、構造上の変更は、本開示の精神又は範囲から逸脱することなく行うことができる。以下の詳細な説明は、限定的な意味に解釈されるべきではなく、本発明の範囲は添付の特許請求の範囲及びその等価物によって定義される。

実施形態は、パーソナルコンピュータ内のオペレーティングシステム上で動作するアプリケーションプログラムと連携して実行されるプログラムモジュールの一般的な文脈で説明されるが、当業者は態様が他のプログラムモジュールと組み合わせても実施できることを認識するであろう。

一般的に、プログラムモジュールは、ルーチン、プログラム、コンポーネント、データ構造、及び、特定の作業を実行するか又は特定の抽象データ型を実施するその他の種類の構造を含む。更に、当業者は、実施形態がハンドヘルド装置、マルチプロセッサシステム、マイクロプロセッサベース又はプログラマブルコンシューマエレクトロニクス、ミニコンピュータ、メインフレームコンピュータと同等のコンピューティング装置を含むその他のコンピュータシステム構成で実施されること、を理解するであろう。また、実施形態は、作業が通信ネットワークを介してリンクされたリモート処理装置によって実行される分散コンピューティング環境で実施される。分散コンピューティング環境において、プログラムモジュールはローカルとリモートの両方のメモリ記憶装置に配置される。

実施形態は、コンピュータ実装プロセス（方法）としてコンピューティングシステムに実装されてもよいし、又は、コンピュータプログラム製品若しくはコンピュータ可読媒体等の製造品であってもよい。コンピュータプログラム製品は、コンピュータシステムによって読み取り可能でありかつ、コンピュータ又はコンピューティングシステムに実施例のプロセスを実行させるための命令を含むコンピュータプログラムを符号化するコンピュータ記憶媒体であってもよい。コンピュータ可読記憶媒体は、例えば不揮発性のコンピュータメモリ、不揮発性メモリ、ハードドライブ、フラッシュドライブ、フロッピーディスク、コンパクトディスク、及び同様の媒体の１つ以上を介して実施されることができる。コンピュータプログラム製品は、キャリア上の伝播信号（例えば周波数又は位相変調信号）、又はコンピューティングシステムによって読み取り可能でかつコンピュータプロセスを実行するための命令のコンピュータプログラムをエンコードする記録媒体であってもよい。

本明細書を通して、参照符号はサービスになされている。本明細書で使用されるサービスは、通常の操作の一部及び情報の処理／保存／転送としてアラートを受信することができる任意のネットワーク接続／オンラインアプリケーション（複数可）を記述する。かかるアプリケーション（複数可）は、単一のコンピューティング装置上や、分散した態様の複数のコンピューティング装置等の上で実行される。また、実施形態は複数のサーバー又は同等のシステムにわたって実行されるホストされたサービスで実施される。「サーバー」という用語は、一般的にネットワーク化された環境において典型的には、１つ以上のソフトウエアプログラムを実行するコンピューティング装置を言う。しかし、サーバーは、ネットワーク上のサーバーとして見える１つ以上のコンピューティング装置上で実行される仮想サーバー（ソフトウエアプログラム）として実施されてもよい。これらの技術と実施例の操作に関する詳細は、以下に提供されている。

図１を参照すると、概念図中の１００は、アラートの検出が修復アクション又はアラートのエスカレーションを導く可能性がある環境の一例を示している。上記に簡単に紹介したように、実施形態は、修復アクションとアラートのエスカレーションの自動化によって技術支援サービスの複雑性に対処する。例えば、分散技術サポートサービスシステムにおいて、監視エンジン１０３は、分散システムにおけるハードウエア、ソフトウエア、又はハードウエア／ソフトウエアの組み合わせの問題を検出したとき、アラート１１３を自動化エンジン１０２に送信する。自動化エンジン１０２はアラート１１３を修復アクション１１２にマッピングすることを試行することができる。自動化エンジン１０２が正常に修復アクション１１２にアラート１１３をマッピングした場合、自動化エンジン１０２は、検出された問題に対処するための一連の命令を含むことができる修復アクション１１２を実行することができる。

問題は、地理的に分散したサービスロケーション１０５に１つ以上の装置１０４と関連している場合がある。装置は、デスクトップコンピュータサーバー、スマートフォン、ラップトップコンピュータ、及び同等のもの等の任意のコンピューティング装置を含んでもよい。装置１０４は、更に、モニター、オーディオ機器、テレビ、ビデオキャプチャ装置、及びその他の類似の装置等の追加のリモートアクセスが可能な装置を含むことができる。

アラート１１３は、装置のメモリの内容、センサーの読み取り値、最後に実行された命令、及びその他等の検出された問題に関連付けられている装置の状態情報又はプログラムを含むことができる。更に、アラート１１３は、どの命令の実行に失敗したか、どの実行が事前定義された制限を超えた結果を示しているか、等の問題の説明を含めることができる。

自動化エンジン１０２は、トラブルシュートデータベース１１４を検索することにより、修復アクション１１２にアラート１１３をマッピングすることを試行することができる。トラブルシュートデータベース１１４は、装置又はソフトウエアプログラムによって更に分類された修復アクションに一致したアラートのプロファイルを格納することができる。１つの実施例は、通信装置のネットワークインタフェースを再起動する修復アクションに一致した通信機器の「接続なし」のアラートであってもよい。１つ以上の修復アクションは、各アラートにマッピングされることができる。更に、１つ以上のアラートは、単一の修復アクションにマッピングされることができる。

自動化エンジン１０２がアラートに対して複数の修復アクションを判断した場合には、実行優先度は修復アクションの事前定義された優先度に依存していてもよい。例えば、上記のシナリオにおける第１の修復アクションは、通信装置を再起動する第２の修復アクションで続くネットワークインターフェイスの再起動でもよい。修復アクションの事前定義された優先度は、トラブルシュートデータベース１１４へ手動で入力されてもよく、又は、問題の成功補正時での修復アクション成功評価スキームに基づいて自動的に決定されてもよい。

いくつかの実施形態によれば、修復アクション１１２は、問題に関連する装置及び／又はソフトウエアプログラムから追加の診断情報を収集することを含んでいてもよい。追加の診断情報は、他の実施形態による自動サイクルを再起動アラートとして監視エンジンに送信することができる。アラートに応答して、追加の診断情報もまた収集され、システムに格納されることができる。格納された情報は、アラートが指定先の人やチーム（例えば１０１）にエスカレーションが行われたとき、問題の状態を取得し、状況を提供するために使用することができる。

マッピングされた修復アクションが自動化エンジン１０２によってトラブルシュートデータベース１１４内で検出されない場合、アラート１１３は、指定先の人又はチーム１０１にエスカレーションされることができる。マッピングされたアクションが見つからず、情報提供の目的で実行された場合でも、指定された個人又はチーム１０１は通知されてもよい。アラート１１３を指定先の人やチーム１０１に送信することはアラート１１３の命名規則から決定することができる。アラートの命名規則は、ハードウエアサポートチーム、ソフトウエアサポートチーム及び同様のもの等の何れのサポート担当者にアラートがエスカレーションされるべきであるか、を示すことができる。命名規則スキーマもまたアラートをリカバリアクションにマッピングするために使用されてもよい。例えば、アラートは階層式（すなわちシステム／コンポーネント／アラート名）で指定することができ、リカバリアクションは、システムの全てのアラート（システム／＊）から特定のアラートのための特定なリカバリアクションのどこにでもマッピングされることができる。いくつかの実施形態によれば、各特定のアラートは、それに関連付けられ指定されたチームを有していてもよい。ただし、そのチームが全体のコンポーネントに固有の値にデフォルト設定されていてもよい。チームメンバーにアラートを送信する決定は、サポートチームスケジュールの認識のための自動化エンジン内に存在する所定のマッピングアルゴリズムに依存してもよい。所定のマッピングアルゴリズムは、内蔵又は外付けのスケジューリングシステムによって、手動又は自動で更新されてもよい。

自動化エンジン１０２は、電子メール、インスタントメッセージ、テキストメッセージ、ページ、ボイスメール、又は同様の手段を介して、アラート１１３を第１の指定先の人やチームにエスカレーションさせることができる。アラートは、チーム名にマッピングされ、チーム名は事前に定義された間隔（例えば１日、１週間等）のコールを受けている個人のグループにマッピングされることができる。マッピングの一部では、人々が間隔のためのコールを受けているかを識別するために使用されてもよい。この方法では、アラートのマッピングは、流動的である個々のチームメンバーから抽出することができる。そこで自動化エンジン１０２は、指定された個人又はチームからハンドオフ通知を待機することができる。ハンドオフ通知は、アラートがどのような方法で送信されたかにより自動化エンジン１０２によって受信されることができ、又は、他の手段を介して受信されることができる。自動化エンジン１０２は、所定の時間内にハンドオフ通知を受信しない場合、事前定義されたマッピングアルゴリズムによって決定された輪番で次の指定を受けた者又はチームにアラート１１３をエスカレーションさせてもよい。自動化アルゴリズムは、ハンドオフ通知を受信するまで、輪番で次の指定を受けた者又はチームにアラートをエスカレーションさせ続けてもよい。

監視エンジン１０３は、修復アクション１１２の実行が自動化エンジン１０２上への応答を通過した後、装置又はソフトウエアプログラムからのフィードバック応答（例えば、アクションの形式で）を受信することができる。その後、自動化エンジン１０２はトラブルシュートデータベース１１４を更新することができる。修復アクションの成功率等の統計情報は、修復アクションの実行優先度を変更することで使用することができる。更にまた、機械学習アルゴリズム又は同様のメカニズムが採用されて、アクションのリストを展開したり、新しいアラートを既存のアクションへマッピングしたり、既存のアラートを新しいアクションへマッピングする等々のように、指定先の人やチームによって実行されたアクションに関連付けられたフィードバック応答もまた、データベース１１４に記録されてもよい。自動化エンジンのアクションと指定先でのアクションは、いくつかの実施形態によれば、システムによって検査されてもよい。システムでは、いつ、どの装置又はサーバーに対して、特定のアクションを実行した人のログを維持することができる。そこで記録は、トラブルシューティング、システム内の変更の追跡、及び／又は自動化された新しいアラート応答の開発のために使用することができる。

更なる実施形態によれば、自動化エンジン１０２はトラブルシュートデータベース１１４のワイルドカード検索を実行し、そして受信したアラートの応答に応じて複数の修復アクションを決定することができる。修復アクションの単一又はグループの実行は、修復アクションの所定の優先度に依存してもよい。修復アクションのグループはまた、アラートのグループにマッピングされることができる。１つのアラートがいくつかのワイルドカードマッピングに一致する一方で、ほとんどの具体的なマッピングは実際に適用されることができる。例えば、アラートの交換／トランスポート／キューイングは、マッピングの交換／＊、交換／トランスポート／＊、及び交換／トランスポート／キューに一致する。しかし、最後の１つは、それが最も具体的なものであるから、実際に真のマッピングである。

図２は、図中の２００におけるアラートのエスカレーション時のアクションを示している。監視エンジン２０２は、アラート（２１１）として検出された問題を自動化エンジン２０４に提供することができる。自動化エンジン２０４は、アクションストア２０６（図１のトラブルシュートデータベース１１４）からの利用可能なアクション（２１２）を検査し、利用可能なもの（２１３）がある場合、アクションを実行することができる。いずれもアクションが使用可能でない場合、自動化エンジン２０４は、アラート（２１４）をプロセス所有者２０８にエスカレーションさせることができる。アラートは、更に他の指定先２０９にエスカレーション（２１５）されることができる。上記したように、エスカレーションはまた、決定したアクションの実行と並行して実行されることができる。

プロセス所有者２０８又は他の指定先２０９から実行されるべき新しいアクション（２１６、２１７）を受信するとき、自動化エンジン２０４は新しいアクション（２１８）を実行し、将来の使用のための新しいアクション（２１９）で記録を更新してもよい。図中の２００の例の相互作用は限定されたシナリオを示している。また、指名された者とのハンドオフ、問題を報告する装置／ソフトウエアからのフィードバック、及び同様のもの等の他の相互作用は、実施形態による自動化されたリカバリ及びエスカレーションシステムの操作に含めることができる。

図３は、図中の３００の多領域環境におけるアラート管理を示す概念図である。分散システムでは、アラートのエスカレーションは、地理的領域の所定の優先度に依存してもよい。例えば、所定の優先度は、エスカレーションが両方の領域のための単一のサポートチームによって管理されている場合、アラートが昼間である領域からのアラートをエスカレーションし、そしてアラートが夜間である領域からのアラートを保持することができる。同様に、検出された問題を対処するために、異なる領域からの修復アクションが同一のハードウエア、ソフトウエア、通信リソースのために競合する場合、異なる領域からの修復アクションは、所定の優先度に基づいて優先度を付けられることができる。

図中の３００は、どのように異なる領域からのアラートが実施形態によるシステムによって対処されるかを図解している。一例のシナリオによると、監視エンジン３０３、３１３、及び３２３は、それぞれの領域１、２、及び３（３０４、３１４、３２４）からのハードウエア及び／又はソフトウエアの問題を監視する責任がある。問題を検出すると、監視エンジンの各々がそれぞれの領域を担当するそれぞれの自動化エンジン３０２、３１２、３２２にアラートを送信することができる。自動化エンジンのロジックは監視ロジックと同じ方法で、各領域に分配することができる。いくつかの実施形態によれば、自動化は、完全なサイト障害及びリカバリのようなクロス領域を起こすことがある。他の実施形態によれば、自動化エンジンは、多くの領域を担当することがある。同様に、エスカレーションのターゲットは、集中させ又は分散させることができる。例えば、システムは、時刻に基づいて別々のチームにエスカレーションする可能性がある。監視エンジン３０３、３１３、及び３２３は、監視プロセスを管理するために、自分の別の領域のデータベースを持ってもよい。自動化エンジン３０２、３１２、及び３２２は、トラブルシュートデータベース（中央又は分散）に問い合わせて、アラートを修復アクションにマッピングすることができる。

対応する修復アクション（複数可）が検出された場合、自動化エンジン３０２、３１２、及び３２２は装置の上及び／又は領域３０４、３１４、及び３２４内のプログラムの上で修復アクション（複数可）を実行する。グローバル監視データベース３１０は、全ての領域で実施されてもよい。自動化エンジン３０２、３１２、３２２は、それらがマッチング修復アクションを見つけることができない場合、組織構造等の定義済みの領域の優先度に基づいて、指定されたサポートチーム３０１にアラートをエスカレーションさせる可能性がある。例えば、領域３２４は、ドキュメントのサポートネットワークである一方、領域３０４は、ビジネス組織のための会社の企業ネットワークであってもよい。領域３０４で検出された問題は、このシナリオでは、領域３２４で検出された問題よりも優先されることがある。同様に、領域の優先度を決定するとき、異なる領域及び同等の因子の間の日中の時間や作業日／休日の区別を考慮する必要がある。

いくつかの実施形態によれば、複数の自動化エンジンは、異なる領域並びにエスカレーション及び／又は上記したような自動化エンジン間のコンセンサスアルゴリズムを経て決定された修復アクションの優先度の実行に割り当てられてもよい。あるいは、領域の自動化エンジンを監督するプロセスは、優先度の決定をすることができる。更に、自動化エンジン３０２、３１２、及び３２２は、カスタマイズされた修復アクション−異なる領域のアラートのマッピングを含む領域のトラブルシュートデータベースと対話することができる。

分散システムにおけるリカバリ及びエスカレーションのプロセスの自動化が実施例シナリオや図１、２、３と関連した特定の修復アクションの実行とアラートのエスカレーションを使用した上で議論されてきたが、実施形態はそれらに限定されない。修復アクションへのアラートのマッピング、修復アクションの優先度付け、アラートのエスカレーション、及び他のプロセスは、本明細書で説明した原理を用いて、他の操作、優先度、評価等を用いて実施することができる。

図４は、実施形態を実施することができるネットワーク化された環境の一例である。修復アクションへのアラートのマッピングは、ホストされたサービス等の１つ以上のサーバー４２２に亘って実行されるソフトウエアを介して実現することができる。サーバー４２２は、ネットワーク（複数可）４１０を介して、携帯電話４１１は、モバイルコンピューティング装置４１２は、スマートフォン４１３、ラップトップコンピュータ４１４、及びデスクトップコンピュータ４１５（クライアント装置）等の個々のコンピューティング装置上のクライアントアプリケーションと通信することができる。クライアント装置４１１から４１５上のクライアントアプリケーションは、サービスに関連するソフトウエア及び／又はハードウエアの問題の自動管理を可能にするサーバー（複数可）４２２上で実行されるサービスとユーザーとの対話を促進することができる。自動化エンジンと監視エンジン（複数可）は、サーバー４２２のいずれか上で実行することができる。

アラートを修復アクションへマッピングする等の操作に関連付けられたデータは、１つ以上のデータストア（例えば、データストア４２５又は４２６）に格納されてもよく、これはサーバー（複数可）４２２のいずれかによって、又はデータベースサーバー４２４により管理されてもよい。上記の例で説明したように、アラートが監視エンジンによって検出された場合の実施形態によれば、検出された問題のリカバリ及びエスカレーションを自動化がトリガされる。

ネットワーク（複数可）４１０は、サーバー、クライアント、インターネットサービスプロバイダ、及び通信媒体の任意のトポロジを含むことができる。実施形態によるシステムは、静的又は動的なトポロジを有してもよい。ネットワーク（複数可）４１０は、企業ネットワーク等の安全なネットワークや、無線オープンネットワーク又はインターネット等の非安全な保護されていないネットワーク含むことができる。ネットワーク（複数可）４１０は、本明細書に記載のノード間の通信を提供する。例えば、限定はしないが、ネットワーク（複数可）４１０は、音響、ＲＦ、赤外線及び他の無線媒体等の無線媒体を含むことができる。

コンピューティング装置、アプリケーション、データソース、及びデータ配信システムの多くの他の構成は、実施形態による分散システムの問題の管理を自動化するためシステムを実施するために採用されてもよい。更に、図４で説明しているネットワーク環境は、例示のみを目的としている。実施形態は、実施例アプリケーション、モジュール、又はプロセスに限定されるものではない。

図５と関連した説明は、実施形態を実施することができる適切なコンピューティング環境の簡潔で一般的な説明を提供することを意図している。図５を参照すると、実施形態によるサービスアプリケーションのためのコンピューティングオペレーティング環境の一例のブロック図は、コンピューティング装置５００として示されている。基本的な構成では、コンピューティング装置５００は、ホストされたサービスシステム内のサーバーとなることができ、そして少なくとも１つの処理ユニット５０２及びシステムメモリ５０４を含むことができる。コンピューティング装置５００はまた、実行中のプログラムに協力する複数の処理ユニットを含んでもよい。厳密な構成及びコンピューティング装置のタイプに応じて、システムメモリ５０４は、揮発性のもの（ＲＡＭ等）、不揮発性のもの（例えば、ＲＯＭ、フラッシュメモリ等）又は該２つのいくつかの組み合わせでもよい。システムメモリ５０４は、典型的には、ワシントン州レドモンドのマイクロソフト社のウインドウズ（登録商標）オペレーティングシステム等のプラットフォームの動作を制御するのに適したオペレーティングシステム５０５、含む。システムメモリ５０４はまた、１つ以上のプログラムモジュール５０６、自動化エンジン５２２、及び監視エンジン５２４を含むことができる。

自動化エンジン及び監視エンジン５２２及び５２４は、上記に議論するようにシステムアラートを処理する個別のアプリケーションであってもよく、又はホストされたサービスの一体モジュールであってもよい。この基本的な構成は、破線５０８内のそれらのコンポーネントで図５に示されている。

コンピューティング装置５００は、追加的な特徴又は機能を有することもできる。例えば、コンピューティング装置５００は、例えば、磁気ディスク、光ディスク、又はテープ、等の追加のデータ記憶装置（リムーバブル及び／又は非リムーバブル）、を含むことができる。このような追加のストレージは、リムーバブル記憶装置５０９及び取り外しができない非リムーバブル記憶装置５１０によって図５に示されている。コンピュータ可読記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、又はその他のデータ等の情報を格納するための任意の方法又は技術で実施された揮発性及び不揮発性、リムーバブル及び非リムーバブル媒体を含むことができる。システムメモリ５０４、リムーバブルストレージ５０９及び非リムーバブルストレージ５１０は、コンピュータ可読記憶媒体の例である。コンピュータ可読記憶媒体は、これらに限定されないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ又は他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）又は他の光ストレージ、磁気カセット、磁気テープ、磁気ディスク記憶装置や、他の磁気記憶装置を含み、これらは、所望の情報を格納するために使用でき、そしてコンピューティング装置５００によってアクセスすることができる任意の他の媒体を含む。このような任意のコンピュータ可読記憶媒体は、コンピューティング装置５００の一部であってもよい。コンピューティング装置５００は、キーボード、マウス、ペン、音声入力装置、タッチ入力装置、及び同等の入力装置等の入力装置（複数可）５１２を持っていてもよい。ディスプレイ等の出力装置（複数可）５１４は、スピーカ、プリンタと出力装置の他のタイプも含まれる場合がある。これらの装置は、当技術分野で周知であり、ここで詳細に論じる必要はない。

コンピューティング装置５００は通信接続装置５１６が含まれていてもよく、通信接続装置５１６は、分散コンピューティング環境、衛星リンク、携帯電話リンク、及び同等のメカニズムにおける無線ネットワークを越えて他の装置５１８と通信することを可能にするものである。その他の装置５１８は、分散アプリケーションを実行するコンピュータ装置（複数可）を含めると、同様の操作を実行することができる。通信接続（複数可）５１６は、通信媒体の一例である。通信媒体は、搬送波又は他のトランスポートメカニズムとして、その中に、コンピュータ可読命令、データ構造、プログラムモジュール、又は変調されたデータ信号内の他のデータを、含まれており、任意の情報配信媒体を含むことができる。「変調されたデータ信号」は信号に情報を符号化するように設定するか、又は変更された特性の１以上を有する信号を意味する。例えば、限定はしないが、通信媒体は、有線ネットワーク又は直接有線接続等の有線媒体、及び音響、ＲＦ、赤外線、その他の無線媒体等の無線媒体が含まれている。

実施形態の例も方法が含まれている。これらの方法は、この文書で説明する構造を含む任意の数の方法で実施できる。その１つの方法は、この文書に記載されたタイプの装置で、機械操作によるものである。

他の任意の方法は、いくつかを実行している一人以上の人間オペレータと連動して実行される方法の個々の操作のうちの1つ以上のためにある。これらの人間オペレータは、互い同士が一まとめにされる必要はないが、各人がプログラムの一部を実行する機械だけ持つことができる。

図６の実施形態による分散システム内の問題の回復及びエスカレーションの管理を自動化するための論理流れ図の６００を示している。プロセス６００は、ホストされたサービスの一部としてのサーバーで又は上記されたようなサービスと相互に作用するためのクライアントアプリケーションで実施されることができる。

プロセス６００は操作６０２から始まり、自動化エンジンは、監視エンジンによって送信されたアラートを、システム内の装置及び／又はソフトウエアアプリケーションの問題に応じて、検出する。操作６０４において監視エンジンからアラートを受信した自動化エンジンは、アラートに関連付けられている情報の収集を開始することができる。これは、動作６０６で、アラートを１つ以上の修復アクションにマッピングしようとする試みによって続けられることがある。

アラートにマッピングされた明示的なアクションが決定操作６０８で検出された場合、アクション（複数可）は後続の操作６１０で実行されてもよい。明示的なアクションがマッピングプロセス中に決定されていない場合、アラートが操作６１４で指定先の人やチームにエスカレーションされることができる。操作６１４は任意の操作６１６及び６１８に続いてもよく、ここで、新しいアクションは指定先の人やチームから受信され、実行される。動作６１２で、記録は、マッピングデータベースが拡大されるように実行されたアクション（マッピングされた又は新しい）で更新されることができて、又は成功率に関連する統計情報は、将来の監視と自動応答の作業のために使用されてもよい。

プロセス６００に含まれる操作は、例示の目的のためのものである。複雑な分散アプリケーションにおける問題のリカバリ及びエスカレーションを自動化することは、少ないステップ又は追加のステップを持つだけでなく、本明細書に記載される原理を使用して、操作の順序とは異なる順序で同様のプロセスにより実施される。

上記の仕様、例及びデータは、実施形態の組成物の製造及び使用の完全な説明を提供する。主題は構造的特徴及び／又は方法論的行為に特有の言葉で説明されてきたが、添付の特許請求の範囲で定義される主題は必ずしも上記の特定の特徴又は行為に限定されるものではないことを理解すべきである。むしろ、上記の特定の特徴及び行為は、特許請求の範囲及び実施形態を実施する形態の例として開示されている。

Claims (15)

1. 分散システムにおけるアラートの自動化されたリカバリ及びエスカレーションのためのコンピューティング装置において少なくとも部分的に実行される方法であって、
   監視エンジンから検出された問題に関連付けられているアラートを受信するステップと、
   前記アラートをリカバリアクションにマッピングすることを試行するステップと、
   前記アラートがリカバリアクションにマッピングされるとき、リカバリアクションを実行し、それ以外は、前記アラートを指定先にエスカレーションするステップと、
   前記アラートと前記リカバリアクションとのマッピングに関連付けられた記録を更新するステップと
   を具えたことを特徴とする方法。
2. 前記検出された問題に関連する診断情報を収集するステップと、
   前記アラートがエスカレーションされるとき、前記収集された診断情報を前記指定先に提供するステップと、
   前記記録を更新する際に前記収集された診断情報を採用するステップと
   をさらに具えたことを特徴とする請求項１記載の方法。
3. 前記収集された診断情報は、装置のメモリの内容、センサーの読み取り値、最後に実行された命令、失敗した命令、及び前記検出された問題に関連付けられている失敗の結果の組からの少なくとも１つを含むことを特徴とする請求項２記載の方法。
4. 前記アラートをエスカレーションした後に前記指定先からハンドオフ応答を待つステップと、
   ハンドオフ応答が事前に定義された期間内に受信されない場合、前記アラートを別の指定先にエスカレーションするステップと
   をさらに具えたことを特徴とする請求項１記載の方法。
5. 前記指定先は指定される人達及び前記アラートの命名規則の定義済みのリストの１つから決定され、前記指定先には人とチームの１つが含まれていることを特徴とする請求項１記載の方法。
6. 前記アラートをエスカレーションするステップは、電子メール、インスタントメッセージ、テキストメッセージ、ページ、及びボイスメールの組からの少なくとも１つによって前記アラートを前記指定先へ送信するステップを含むことを特徴とする請求項１記載の方法。
7. 装置及びリカバリアクションの実行時に前記検出された問題に関連付けられているプログラムの１つからフィードバックアクションを受信するステップと、
   前記リカバリアクションに関連付けられている成功率記録を更新するステップと
   をさらに具えたことを特徴とする請求項１記載の方法。
8. 分散システムにおけるアラートの自動化されたリカバリ及びエスカレーションするためのシステムであって、
   監視エンジンと自動化エンジンを実行するサーバーとを含み、
   前記監視エンジンは、
   分散システム内の装置及びソフトウエアアプリケーションの少なくとも１つに関連付けられている問題を検出し、
   前記検出された問題に基づいてアラートを送信するように構成され、
   前記自動化エンジンは、
   前記アラートを受信し、
   前記検出された問題に関連する診断情報を収集し、
   リカバリアクションデータベースを用いて、前記アラートをリカバリアクションにマッピングすることを試行し、
   前記アラートがリカバリアクションにマッピングされるとき、リカバリアクションを実行し、それ以外は、
   前記収集された診断情報とともに前記アラートを指定先にエスカレーションし、
   前記リカバリアクションデータベース内の記録を更新するように構成されたことを特徴とするシステム。
9. 複数の監視エンジンを更に含み、前記監視エンジンの各々は分散システム内の各領域のためのシステム規模に基づく別個領域を監視し、それぞれの領域で前記検出された問題に基づいてアラートを送信するように構成され、
   前記自動化エンジンは、
   １つが、マッピングされたリカバリアクションを実行し、領域の優先度に基づいて、異なる領域からアラートを前記指定先にエスカレーションするように構成されたことを特徴とする請求項８記載のシステム。
10. 前記領域の優先度は、指定されたサポートチーム、ハードウエアリソース、ソフトウエアリソース、及び通信リソースの組からの少なくとも１つの利用可能性に基づいてさらに決定されることを特徴とする請求項８記載のシステム。
11. 前記アラートが複数のリカバリアクションにマッピングされ、前記リカバリアクションは事前定義された実行優先度に従って実行されることを特徴とする請求項８記載のシステム。
12. 前記装置は、デスクトップコンピュータ、ラップトップコンピュータ、ハンドヘルドコンピュータ、サーバー、スマートフォン、モニター、オーディオ機器、テレビ、ビデオキャプチャ装置の１つを含むことを特徴とする請求項８記載のシステム。
13. 分散システムにおけるアラートの自動化されたリカバリ及びエスカレーションのために格納された命令を有するコンピュータ可読記憶媒体であって、
    前記命令は、
    監視エンジンにおける分散システム内の装置及びソフトウエアアプリケーションの少なくとも１つに関連する問題を検出するステップと、
    監視エンジンから前記検出された問題に基づいてアラートを送信するステップと、
    自動化エンジンにおいて前記アラートを受信するステップと、
    前記検出された問題に関連する診断情報を収集するステップと、
    リカバリアクションデータベースからの前記検出された問題を対処する命令のセットを含むリカバリアクションに、前記アラートをマッピングすることを試行するステップと、
    前記アラートが単一のリカバリアクションにマッピングされるとき、リカバリアクションを実行するステップと、
    前記アラートが複数のリカバリアクションにマッピングされるとき、事前定義された実行優先度に従ってリカバリアクションを実行するステップと、
    前記アラートがリカバリアクションにマッピングされていないとき、前記アラートを指定先にエスカレーションするステップと、
    前記指定先からハンドオフ応答を受信するステップと、
    前記収集された診断情報及び実行されたリカバリアクションと関連付けられたリカバリアクションデータベースを用いて、リカバリアクションデータベース内の記録を更新するステップと
    を具えたことを特徴とするコンピュータ可読記憶媒体。
14. 前記リカバリアクションは、単一のアラートとアラートのグループのうちの１つにマッピングされていることを特徴とする請求項１３記載のコンピュータ可読記憶媒体。
15. 前記指定先は、アラートの命名規則及びサポート担当者の利用可能性に基づく回転アルゴリズムのうちの１つから決定されることを特徴とする請求項１３記載のコンピュータ可読記憶媒体。

Images