特開 2024-141095 イベント管理プログラム、イベント管理方法、および情報処理装置

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

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

(11)【公開番号】P2024141095

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

(54)【発明の名称】イベント管理プログラム、イベント管理方法、および情報処理装置

(51)【国際特許分類】

   G06F 11/07 20060101AFI20241003BHJP

【ＦＩ】

G06F11/07 193

G06F11/07 140A

【審査請求】未請求

【請求項の数】10

【出願形態】ＯＬ

(21)【出願番号】P 2023052558

(22)【出願日】2023-03-29

(71)【出願人】

【識別番号】000005223

【氏名又は名称】富士通株式会社

(74)【代理人】

【識別番号】110002918

【氏名又は名称】弁理士法人扶桑国際特許事務所

(72)【発明者】

【氏名】福田 雅広

(72)【発明者】

【氏名】中村 冴子

(72)【発明者】

【氏名】梅澤 侑生

(72)【発明者】

【氏名】廣田 直弥

(72)【発明者】

【氏名】下田 雄太

(72)【発明者】

【氏名】近藤 沙綾子

(72)【発明者】

【氏名】下川 健一郎

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

5B042

【Ｆターム（参考）】

5B042KK13

5B042KK17

5B042KK20

5B042MA08

5B042MA14

5B042MC35

5B042MC40

(57)【要約】

【課題】イベントに対する運用担当者の対処し易さを容易に把握できるようにする。
【解決手段】情報処理装置１０は、コンピュータシステム１ａ，１ｂ，１ｃで発生した新規イベントの発生日時および属性を示す新規イベント情報５を取得する。情報処理装置１０は、運用担当者２～４が対処した過去イベントの発生日時および属性を示す過去イベント情報１１ａに基づいて、過去イベントのうち、新規イベントと属性に共通性のある第１の過去イベントを特定する。情報処理装置１０は、第１の過去イベントの発生日時と新規イベントの発生日時との差分を計算する。そして情報処理装置１０は、差分に基づいて、新規イベントへの運用担当者の対処容易度を計算する。
【選択図】図１

【特許請求の範囲】

【請求項1】

コンピュータシステムで発生した新規イベントの発生日時および属性を示す新規イベント情報を取得し、
運用担当者が対処した過去イベントの発生日時および属性を示す過去イベント情報に基づいて、前記過去イベントのうち、前記新規イベントと属性に共通性のある第１の過去イベントを特定し、
前記第１の過去イベントの発生日時と前記新規イベントの発生日時との差分を計算し、
前記差分に基づいて、前記新規イベントへの前記運用担当者の対処容易度を計算する、
処理をコンピュータに実行させるイベント管理プログラム。

【請求項2】

前記対処容易度を計算する処理では、前記差分が大きいほど前記対処容易度を低い値とする、
請求項１記載のイベント管理プログラム。

【請求項3】

前記対処容易度を計算する処理では、前記運用担当者のイベントへの対処能力を示す第１の係数に基づいて、前記対処容易度を計算する、
請求項１記載のイベント管理プログラム。

【請求項4】

前記対処容易度を計算する処理では、前記新規イベントと前記過去イベントとの発生元に関する属性の同一性が高いほど高い値となる第２の係数と、前記第１の係数とに基づいて、前記対処容易度を計算する、
請求項３記載のイベント管理プログラム。

【請求項5】

前記運用担当者が複数存在する場合、前記第１の過去イベントを特定する処理、前記差分を計算する処理、および前記運用担当者ごとの前記第１の係数に基づいて前記対処容易度を計算する処理を、前記運用担当者ごとに実行し、
前記対処容易度に基づいて対処するのが適切と判断される第１の運用担当者が前記新規イベントに対処したのか、前記第１の運用担当者以外の第２の運用担当者が前記新規イベントに対処したのかに基づいて、前記運用担当者ごとの前記第１の係数の値を更新する、
請求項３記載のイベント管理プログラム。

【請求項6】

前記第１の過去イベントを特定する処理では、前記新規イベントと同じソフトウェアによる同じメッセージの前記過去イベントを、前記第１の過去イベントとして特定する、
請求項１記載のイベント管理プログラム。

【請求項7】

前記第１の過去イベントを特定する処理では、前記新規イベントと発生元のシステムが共通の前記過去イベントを、前記第１の過去イベントとして特定する、
請求項１記載のイベント管理プログラム。

【請求項8】

前記対処容易度を計算する処理では、前記第１の過去イベントが複数特定された場合、前記第１の過去イベントそれぞれについて、前記差分に基づいて、前記第１の過去イベントの評価値を計算し、前記第１の過去イベントごとの前記評価値の合計を前記対処容易度とする、
請求項１記載のイベント管理プログラム。

【請求項9】

コンピュータシステムで発生した新規イベントの発生日時および属性を示す新規イベント情報を取得し、
運用担当者が対処した過去イベントの発生日時および属性を示す過去イベント情報に基づいて、前記過去イベントのうち、前記新規イベントと属性に共通性のある第１の過去イベントを特定し、
前記第１の過去イベントの発生日時と前記新規イベントの発生日時との差分を計算し、
前記差分に基づいて、前記新規イベントへの前記運用担当者の対処容易度を計算する、
処理をコンピュータが実行するイベント管理方法。

【請求項10】

コンピュータシステムで発生した新規イベントの発生日時および属性を示す新規イベント情報を取得し、運用担当者が対処した過去イベントの発生日時および属性を示す過去イベント情報に基づいて、前記過去イベントのうち、前記新規イベントと属性に共通性のある第１の過去イベントを特定し、前記第１の過去イベントの発生日時と前記新規イベントの発生日時との差分を計算し、前記差分に基づいて、前記新規イベントへの前記運用担当者の対処容易度を計算する処理部、
を有する情報処理装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、イベント管理プログラム、イベント管理方法、および情報処理装置に関する。

【背景技術】

【0002】

運用中のコンピュータシステムは、運用担当者によって動作状況が監視される。システムの監視作業では、複数のシステムから発生する大量のイベントを、例えば複数の運用担当者が確認する。

【0003】

システムの監視を支援する技術としては、例えば、状況や目的によって変化する必要なアラートを、容易に設定可能なフィルタ条件で選択して画面に表示するアラート表示装置が提案されている。複数のイベントが複合的に原因となる不具合の発生原因およびその対策を特定することを可能とするネットワーク運用管理システムも提供されている。機器等に発生した事象への対応を、より早く正確に実行できるようにユーザを支援する事象対応支援装置も提案されている。アラートの監視の負荷を軽減することが可能な監視装置も提案されている。情報システムの運用を安定的に行うことが可能な担当者割当装置も提案されている。さらに各トラブル事例情報に記載されているトラブルの様々な要因に立脚したトラブル回避難易度を適切に判定することが可能なトラブル情報分析プログラムも提案されている。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２０１５－８７９８７号公報

【特許文献2】特開２０１２－２３４３８１号公報

【特許文献3】特開２０１４－１３０４９９号公報

【特許文献4】特開２０２０－１４４９５４号公報

【特許文献5】特開２０２０－１１３０２２号公報

【特許文献6】特開２００７－１９９８０９号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

システムで発生するイベントの中には対処が容易なものと対処が難しいものとが混在している。そこで、例えばイベントの対処難易度を個別に事前定義しておくことが考えられる。この場合、運用担当者は、発生したイベントに対して予め定義された対処難易度を参照することで、そのイベントへの対処し易さを把握できる。

【0006】

しかし、イベントへの対処は、ある運用担当者にとっては難しくても他の運用担当者にとっては簡単など、対処のし易さが人によって異なる。また同じ運用担当者でも、長期間対処していないイベントだと対処難易度は高くなる。そのため、イベントごとに事前定義された対処難易度を運用担当者に提示するだけでは、運用担当者は、発生したイベントに対する対処し易さを正しく把握することができない。

【0007】

１つの側面では、本件は、イベントに対する運用担当者の対処し易さを容易に把握できるようにすることを目的とする。

【課題を解決するための手段】

【0008】

１つの案では、以下の処理をコンピュータに実行させるイベント管理プログラムが提供される。
コンピュータは、コンピュータシステムで発生した新規イベントの発生日時および属性を示す新規イベント情報を取得する。コンピュータは、運用担当者が対処した過去イベントの発生日時および属性を示す過去イベント情報に基づいて、過去イベントのうち、新規イベントと属性に共通性のある第１の過去イベントを特定する。コンピュータは、第１の過去イベントの発生日時と新規イベントの発生日時との差分を計算する。そしてコンピュータは、差分に基づいて、新規イベントへの運用担当者の対処容易度を計算する。

【発明の効果】

【0009】

１態様によれば、イベントに対する運用担当者の対処し易さを容易に把握することが可能となる。

【図面の簡単な説明】

【0010】

【図1】第１の実施の形態に係るイベント管理方法の一例を示す図である。

【図2】監視システムの一例を示す図である。

【図3】運用管理サーバのハードウェアの一例を示す図である。

【図4】イベントに対処する運用担当者を適切に決定するのが困難となる場合の一例を示す図である。

【図5】クラウドシステムにおけるイベントの発生元の一例を示す図である。

【図6】監視システムにおけるイベント監視用の機能の一例を示す図である。

【図7】日時係数テーブルの一例を示す図である。

【図8】発生元係数テーブルの一例を示す図である。

【図9】イベントテーブルの一例を示す図である。

【図10】監視処理の手順の一例を示すフローチャートである。

【図11】対処容易度算出処理の手順の一例を示すフローチャートである。

【図12】対処実績評価値算出処理の手順の一例を示すフローチャートである。

【図13】発生元評価値算出処理の手順の一例を示すフローチャートである。

【図14】イベント詳細画面の一例を示す図である。

【図15】日時係数フィードバック処理の手順の一例を示すフローチャートである。

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

【0011】

以下、本実施の形態について図面を参照して説明する。なお各実施の形態は、矛盾のない範囲で複数の実施の形態を組み合わせて実施することができる。
〔第１の実施の形態〕
第１の実施の形態は、イベントに対する運用担当者の対処し易さを容易に把握することが可能なイベント管理方法である。

【0012】

図１は、第１の実施の形態に係るイベント管理方法の一例を示す図である。図１には、イベント管理方法を実現する情報処理装置１０が示されている。情報処理装置１０は、例えばイベント管理プログラムを実行することにより、イベント管理方法を実施することができる。

【0013】

情報処理装置１０は、記憶部１１と処理部１２とを有する。記憶部１１は、例えば情報処理装置１０が有するメモリまたはストレージ装置である。処理部１２は、例えば情報処理装置１０が有するプロセッサまたは演算回路である。

【0014】

記憶部１１は、過去イベント情報１１ａ、第１の係数１１ｂ、および第２の係数を記憶する。
過去イベント情報１１ａは、コンピュータシステム１ａ，１ｂ，１ｃ（以下、単にシステムと呼ぶこともある）で過去に発生して運用担当者２～４が対処した過去イベントを示す情報である。例えば過去イベント情報１１ａには、過去イベントの発生日時、イベントの属性（発生元のシステム、発生元のソフトウェアの種別、メッセージ）、対処した担当者名などが含まれる。発生元のシステム、発生元のソフトウェアの種別は、発生元に関する属性である。メッセージは、イベントの発生原因、発生した理由、起きた事象に関する属性である。メッセージに代えて、例えばエラーコードが用いられてもよい。

【0015】

第１の係数１１ｂは、運用担当者２～４それぞれのイベントへの対処能力を示す情報である。第２の係数１１ｃは、新規イベントと過去イベントとの発生元に関する属性の同一性の度合いに応じた値を示す情報である。例えば第２の係数１１ｃとして、発生元のシステムとソフトウェアの種別とが同一の場合、システムのみが同一の場合のそれぞれに対応する値が設定されている。

【0016】

処理部１２は、コンピュータシステム１ａ，１ｂ，１ｃで発生した新規イベントを示す新規イベント情報５を取得する。新規イベント情報５には、イベントが発生した日時、発生元のシステム、発生元のソフトウェアの種別、イベントの内容を示すメッセージなどが含まれる。処理部１２は、運用担当者２～４それぞれについて、過去イベント情報１１ａに基づいて、その運用担当者が対処した過去イベントのうち、新規イベントと属性に共通性のある第１の過去イベントを特定する。属性に共通性のある第１の過去イベントとは、例えば新規イベントと同じソフトウェアによる同じメッセージの過去イベントである。また処理部１２は、新規イベントと発生元のシステムが共通の過去イベントを、第１の過去イベントとして特定することもできる。

【0017】

処理部１２は、第１の過去イベントの発生日時と新規イベントの発生日時との差分を計算する。そして処理部１２は、計算した差分に基づいて、新規イベントへの運用担当者の対処容易度を計算する。例えば処理部１２は、差分が大きいほど対処容易度を低い値とする。

【0018】

処理部１２は、計算した対処容易度を示す対処容易度情報６を、運用担当者２～４それぞれが使用する端末のモニタに表示させる。対処容易度情報６には、新規イベントに対する運用担当者２～４の対処の優先順位が示されている。対処容易度が高い運用担当者ほど対処の優先順位が高い。運用担当者２～４は、対処容易度情報６を参照することで、新規イベントに対する自身の対処し易さ、および対処するのに適しているのが誰なのかを容易に把握することができる。

【0019】

しかも対処容易度は、新規イベントと属性に共通性のある過去のイベントを対処してから経過した期間が長いほど低い値となる。そのため、同様のイベントへの対処経験の時間による忘却を反映させた対処容易度が得られる。

【0020】

なお処理部１２は、運用担当者２～４のイベントへの対処能力を示す第１の係数１１ｂに基づいて、対処容易度を計算することができる。例えば処理部１２は、運用担当者２～４それぞれの第１の係数の値（０以上１未満の実数）を底とし、発生日時の差分を冪指数とした冪乗の値を、対処容易度とする。また、対処容易度は、第１の係数の値が大きいほど高い値となる。これにより、運用担当者２～４それぞれについて、イベント全般への対処能力の高さを反映させた対処容易度が得られる。

【0021】

処理部１２は、新規イベントと過去イベントとの発生元に関する属性の同一性が高いほど高い値となる第２の係数１１ｃと、第１の係数１１ｂとに基づいて、対処容易度を計算することもできる。例えば処理部１２は、運用担当者２～４それぞれの第１の係数の値を底とし、発生日時の差分を冪指数とした冪乗の値を計算する。処理部１２は、運用担当者２～４それぞれについて計算した冪乗の値に、その運用担当者が対処した過去イベントと新規イベントとの発生元の属性の同一性に応じた第２の係数の値を乗算し、乗算結果を対処容易度とする。このように処理部１２は、イベント間の発生元の属性の同一性を用いて対処容易度を計算することで、発生元の属性の同一性が高い過去イベントに対処した経験のある運用担当者ほど、対処容易度を高くすることができる。

【0022】

図１の例では、「担当者Ａ」は、新規イベント情報５に示される新規イベントと同一のイベントに対処したことがある。そのため「担当者Ａ」が対処した過去イベント（過去イベント情報１１ａの先頭のイベント）に基づいて、「担当者Ａ」の対処容易度が計算されている。すなわち「担当者Ａ」の第１の係数の値「ａ１」を底とし、発生日時の差分「ｎ１＝Ｔ４－Ｔ１」を冪指数とした冪乗の値「ａ１ⁿ¹」が、「担当者Ａ」の対処容易度となる。

【0023】

「担当者Ｂ」は、新規イベント情報５に示される新規イベントと同じシステムを発生元とするイベントに対処したことがある。そのため「担当者Ｂ」が対処した過去イベント（過去イベント情報１１ａの２つ目のイベント）に基づいて、「担当者Ｂ」の対処容易度が計算されている。なお発生元のシステムが同じ場合の第２の係数の値は「０．１」である。そこで「担当者Ｂ」の第１の係数の値「ａ２」を底とし、発生日時の差分「ｎ２＝Ｔ４－Ｔ２」を冪指数とした冪乗の値「ａ２ⁿ²」に第２の係数の値「０．１」を乗算した結果「ａ２ⁿ²×０．１」が、「担当者Ｂ」の対処容易度となる。

【0024】

「担当者Ｃ」は、新規イベントと同一のイベントも、発生元の属性の同一性を有するイベントも対処した経験がない。そのため、「担当者Ｃ」の対処容易度は「０」となる。
なお、処理部１２は、ある運用担当者について第１の過去イベントが複数特定された場合、特定された第１の過去イベントそれぞれについて、差分に基づいて、第１の過去イベントの評価値を計算する。そして処理部１２は、第１の過去イベントごとの評価値の合計を対処容易度とする。これにより、新規イベントと同じイベントまたは発生元の属性の同一性があるイベントを多く対処した運用担当者ほど、対処容易度が高くなる。

【0025】

また、処理部１２は、図１に示すように運用担当者２～４が複数存在する場合、第１の過去イベントを特定する処理、差分を計算する処理、および運用担当者ごとの第１の係数に基づいて対処容易度を計算する処理を、運用担当者ごとに実行する。このとき、処理部１２は、新規イベントに対して誰が対処したのかにもとづいて、運用担当者ごとの第１の係数１１ｂの値を更新してもよい。例えば処理部１２は、対処容易度に基づいて対処するのが適切と判断される第１の運用担当者が新規イベントに対処したのか、第１の運用担当者以外の第２の運用担当者が新規イベントに対処したのかに基づいて、第１の係数１１ｂの値を更新する。これにより第１の係数１１ｂの値が動的に更新され、対処容易度の精度が向上する。

【0026】

〔第２の実施の形態〕
第２の実施の形態は、クラウドコンピューティングシステム（以下、クラウドシステムと呼ぶ）を利用してサービスを提供する企業の運用担当者によるサービスの運用状況の監視を支援する監視システムである。

【0027】

図２は、監視システムの一例を示す図である。クラウドシステム２００は、複数のサーバ２１０，２２０，２３０で構成される。各サーバ２１０，２２０，２３０は、ネットワーク２０に接続されている。ネットワーク２０には、さらに運用管理サーバ１００と端末３１～３３が接続されている。運用管理サーバ１００は、クラウドシステム２００上で運用されているサービスを監視するためのコンピュータである。端末３１～３３は、運用管理サーバ１００を利用して、発生したイベントを確認し、そのイベントに対する対処する運用担当者４１～４３が利用するコンピュータである。

【0028】

図３は、運用管理サーバのハードウェアの一例を示す図である。運用管理サーバ１００は、プロセッサ１０１によって装置全体が制御されている。プロセッサ１０１には、バス１０９を介してメモリ１０２と複数の周辺機器が接続されている。プロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、例えばＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、またはＤＳＰ（Digital Signal Processor）である。プロセッサ１０１がプログラムを実行することで実現する機能の少なくとも一部を、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）などの電子回路で実現してもよい。

【0029】

メモリ１０２は、運用管理サーバ１００の主記憶装置として使用される。メモリ１０２には、プロセッサ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、メモリ１０２には、プロセッサ１０１による処理に利用する各種データが格納される。メモリ１０２としては、例えばＲＡＭ（Random Access Memory）などの揮発性の半導体記憶装置が使用される。

【0030】

バス１０９に接続されている周辺機器としては、ストレージ装置１０３、ＧＰＵ（Graphics Processing Unit）１０４、入力インタフェース１０５、光学ドライブ装置１０６、機器接続インタフェース１０７およびネットワークインタフェース１０８がある。

【0031】

ストレージ装置１０３は、内蔵した記録媒体に対して、電気的または磁気的にデータの書き込みおよび読み出しを行う。ストレージ装置１０３は、運用管理サーバ１００の補助記憶装置として使用される。ストレージ装置１０３には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。なお、ストレージ装置１０３としては、例えばＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）を使用することができる。

【0032】

ＧＰＵ１０４は画像処理を行う演算装置である。ＧＰＵ１０４は、グラフィックコントローラの一例である。ＧＰＵ１０４には、モニタ２１が接続されている。ＧＰＵ１０４は、プロセッサ１０１からの命令に従って、画像をモニタ２１の画面に表示させる。モニタ２１としては、有機ＥＬ（Electro Luminescence）を用いた表示装置や液晶表示装置などがある。

【0033】

入力インタフェース１０５には、キーボード２２とマウス２３とが接続されている。入力インタフェース１０５は、キーボード２２やマウス２３から送られてくる信号をプロセッサ１０１に送信する。なお、マウス２３は、ポインティングデバイスの一例であり、他のポインティングデバイスを使用することもできる。他のポインティングデバイスとしては、タッチパネル、タブレット、タッチパッド、トラックボールなどがある。

【0034】

光学ドライブ装置１０６は、レーザ光などを利用して、光ディスク２４に記録されたデータの読み取り、または光ディスク２４へのデータの書き込みを行う。光ディスク２４は、光の反射によって読み取り可能なようにデータが記録された可搬型の記録媒体である。光ディスク２４には、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ－ＲＡＭ、ＣＤ－ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ－Ｒ（Recordable）／ＲＷ（ReWritable）などがある。

【0035】

機器接続インタフェース１０７は、運用管理サーバ１００に周辺機器を接続するための通信インタフェースである。例えば機器接続インタフェース１０７には、メモリ装置２５やメモリリーダライタ２６を接続することができる。メモリ装置２５は、機器接続インタフェース１０７との通信機能を搭載した記録媒体である。メモリリーダライタ２６は、メモリカード２７へのデータの書き込み、またはメモリカード２７からのデータの読み出しを行う装置である。メモリカード２７は、カード型の記録媒体である。

【0036】

ネットワークインタフェース１０８は、ネットワーク２０に接続されている。ネットワークインタフェース１０８は、ネットワーク２０を介して、他のコンピュータまたは通信機器との間でデータの送受信を行う。ネットワークインタフェース１０８は、例えばスイッチやルータなどの有線通信装置にケーブルで接続される有線通信インタフェースである。またネットワークインタフェース１０８は、基地局やアクセスポイントなどの無線通信装置に電波によって通信接続される無線通信インタフェースであってもよい。

【0037】

運用管理サーバ１００は、以上のようなハードウェアによって、第２の実施の形態の処理機能を実現することができる。なお、第１の実施の形態に示した情報処理装置１０も、図３に示した運用管理サーバ１００と同様のハードウェアにより実現することができる。

【0038】

運用管理サーバ１００は、例えばコンピュータ読み取り可能な記録媒体に記録されたプログラムを実行することにより、第２の実施の形態の処理機能を実現する。運用管理サーバ１００に実行させる処理内容を記述したプログラムは、様々な記録媒体に記録しておくことができる。例えば、運用管理サーバ１００に実行させるプログラムをストレージ装置１０３に格納しておくことができる。プロセッサ１０１は、ストレージ装置１０３内のプログラムの少なくとも一部をメモリ１０２にロードし、プログラムを実行する。また運用管理サーバ１００に実行させるプログラムを、光ディスク２４、メモリ装置２５、メモリカード２７などの可搬型記録媒体に記録しておくこともできる。可搬型記録媒体に格納されたプログラムは、例えばプロセッサ１０１からの制御により、ストレージ装置１０３にインストールされた後、実行可能となる。またプロセッサ１０１が、可搬型記録媒体から直接プログラムを読み出して実行することもできる。

【0039】

以上のような監視システムにより、運用担当者４１～４３は、クラウドシステム２００上のサービスの運用状況を監視することができる。システム監視では、複数のサーバ２１０，２２０，２３０から発生する大量のイベントを複数の運用担当者４１～４３が手分けして確認する。

【0040】

以下、図４を参照し、複数の運用担当者４１～４３によるシステム監視において、イベントの対処する運用担当者を適切に決定することの困難性について説明する。
図４は、イベントに対処する運用担当者を適切に決定するのが困難となる場合の一例を示す図である。図４の例では、サーバ２１０でイベントが発生した場合が想定されている。イベントが発生すると、サーバ２１０は、イベントの発生を示すアラート５１を出力する。アラート５１には、例えばイベント発生元のアプリケーション（以下、アプリと呼ぶ）の種別、新規イベントを示すメッセージなどが含まれる。

【0041】

発生するイベントの中には対処が容易なものや対処が難しいものが混在する。そこで、イベントの対処の難易度を個別に事前定義しておくことができる。例えばサーバ２１０で動作している複数のアプリそれぞれで発生するイベントの種別ごとに、そのイベントメッセージのひな型またはイベントメッセージ内の特定ワードに応じた難易度が事前定義されているものとする。この場合、運用担当者４１～４３は、アラート５１に示されるイベントの情報に基づいて、新規イベントの難易度を判定することが可能である。

【0042】

図４の例では、難易度「中」と判定されている。しかしイベントの対処の難易度は、ある担当者にとっては難しくても他の人にとっては簡単など、運用担当者によって異なる。
例えば運用担当者４１は業務経験の長いベテランの担当者であり、運用担当者４２は、ある程度の経験を積んだ中堅の担当者であり、運用担当者４３は経験が浅い新人の担当者であるものとする。このとき運用担当者４１は、新規イベントを簡単に対処することができる。他方、運用担当者４２は、新規イベントと同様のイベントへの対処経験はあるものの、その経験から時間が経っているものとする。その場合、運用担当者４２は、過去に行った対処方法を部分的に忘れてしまっており、対処に時間を要する可能性がある。運用担当者４３については、経験と知識が不足しており、新規イベントへの対処ができない。

【0043】

このようにイベントに設定された対処難易度が「中」であっても、実際の難易度は運用担当者ごとに異なる。しかも同じ運用担当者でも、長期間対処していないイベントだと対処難易度は高くなる。そのため、従来の事前定義に基づく固定的な方法では、イベントの難易度を適切に設定することができない。

【0044】

発生するイベントの数が少なければ、新規イベントごとにベテランの運用担当者が、そのイベントを対処する運用担当者を決めることも可能である。しかし多くのユーザにサービスを提供するシステムでは、大量のイベントが発生する。大量のイベントの振りわけを人手で行うのは困難である。

【0045】

なお、監視システムでは、大量のイベントを監視する場合、事前に定義したフィルタリング定義を適用することにより対処不要なイベントを表示させないことも可能である。ただし、フィルタリングにより対処するイベント数を絞り込むことができたとしても、システムの規模が大きくなれば、発生するイベントの種類が多くなる。そして、新規イベントに対する各運用担当者の対処の難易度の正しい判断は、イベントの種類が多くなるほど困難となる。

【0046】

図５は、クラウドシステムにおけるイベントの発生元の一例を示す図である。例えばオンプレミスで運用されているサーバ２４０でＶＭ（Virtual Machine）２４０ａが構築される。そしてＶＭ２４０ａ上で動作するアプリ２４１～２４３によりサービスが提供される。この場合であれば、１人の運用担当者４０が全体を監視することも可能である。

【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】

１ａ，１ｂ，１ｃ コンピュータシステム
２～４ 運用担当者
５ 新規イベント情報
６ 対処容易度情報
１０ 情報処理装置
１１ 記憶部
１１ａ 過去イベント情報
１１ｂ 第１の係数
１１ｃ 第２の係数
１２ 処理部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】