(57)【要約】【課題】障害に対する対応の遅れを抑制することができる通知システム、通知装置および通知方法を提供することを目的とする。【解決手段】通知システムにおいて、監視対象機器のインシデント情報を管理するインシデント管理手段と、監視対象機器の構成情報を管理する構成管理手段と、監視対象機器に対して施される作業情報を管理する作業管理手段と、インシデント情報、構成情報および作業情報に基づき、監視対象機器が所属するシステムの将来の一定期間における障害発生可能性を算出する可能性算出手段と、障害発生可能性を通知する通知手段と、を備える構成とした。【選択図】図１
2020140525.tif 000002
【特許請求の範囲】
【請求項１】
監視対象機器のインシデント情報を管理するインシデント管理手段と、
前記監視対象機器の構成情報を管理する構成管理手段と、
前記監視対象機器に対して施される作業情報を管理する作業管理手段と、
前記インシデント情報、前記構成情報および前記作業情報に基づき、前記監視対象機器が所属するシステムの将来の一定期間における障害発生可能性を算出する可能性算出手段と、
前記障害発生可能性を通知する通知手段と、
を備える通知システム。
【請求項２】
前記可能性算出手段は、
前記将来の一定期間内に、前記監視対象機器に対して施される作業がある場合に、前記監視対象機器が所属するシステムの前記障害発生可能性に所定の値を加算する
請求項１に記載の通知システム。
【請求項３】
前記可能性算出手段は、
前記将来の一定期間内に、前記監視対象機器に対して施される作業がある場合であって、かつ前記作業と同じ作業による障害が前記監視対象機器において過去に発生している場合に、前記監視対象機器が所属するシステムの前記障害発生可能性に所定の値を加算する
請求項１または２に記載の通知システム。
【請求項４】
前記可能性算出手段は、
前記将来の一定期間内に、前記監視対象機器に対して施される作業がある場合であって、かつ前記作業と同じ作業による障害が前記監視対象機器において過去に発生している場合に、前記障害に対する対応手順を取得して記憶する
請求項１〜３の何れか一項に記載の通知システム。
【請求項５】
前記可能性算出手段は、
過去のインシデントの発生件数が閾値を超えたときの処理条件と、前記将来の一定期間における処理条件とが一致する場合に、前記監視対象機器が所属するシステムの前記障害発生可能性に所定の値を加算する
請求項１〜４の何れか一項に記載の通知システム。
【請求項６】
前記通知手段は、
前記障害発生可能性を含むメールを生成し、関係者に送信する
請求項１〜５の何れか一項に記載の通知システム。
【請求項７】
監視対象機器のインシデント情報、前記監視対象機器の構成情報および前記監視対象機器に対して施される作業情報に基づき、前記監視対象機器が所属するシステムの将来の一定期間における障害発生可能性を算出する可能性算出手段と、
前記障害発生可能性を通知する通知手段と、
を備える通知装置。
【請求項８】
監視対象機器のインシデント情報、前記監視対象機器の構成情報および前記監視対象機器に対して施される作業情報に基づき、前記監視対象機器が所属するシステムの将来の一定期間における障害発生可能性を算出するステップと、
前記障害発生可能性を通知するステップと、
を含む通知方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インシデントとなりうる障害に関する通知を行う通知システム、通知装置および通知方法に関するものである。
【背景技術】
【０００２】
従来、クラウド環境または障害許容性を考慮した構成の監視対象システムにおいて、インシデントとなりうる障害を事前検知する技術が知られている。例えば、特許文献１には、監視イベントを用いた広範囲なＩＴ障害の予兆検知と、ＩＴ障害の特定とを行う予兆検知装置が提案されている。また、特許文献２には、監視対象システムからのメッセージを元に障害の予兆判定条件を自動的に生成し、自動学習することで障害の事前検知の精度を向上させるシステム障害の予兆監視システムおよびシステム障害予兆監視方法が開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１２−２０３６８４号公報
【特許文献２】特開２０１６−２０１０６０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
特許文献１および特許文献２に記載されるような従来の事前検知技術により、障害の発生率を低減することができる。ここで、障害の発生を事前検知した際に、当該障害に対して定型的な対応ができない場合、運用担当者から担当システムエンジニアに対して対応方法のエスカレーションが発生する。このとき、担当システムエンジニアに連絡がつかない場合は、障害への対応の遅れが生じてしまう。障害への対応が遅れると、システム全体に影響を及ぼすような重大なインシデントが発生してしまうことがある。
【０００５】
本発明は、上記のような課題を背景としたものであり、障害に対する対応の遅れを抑制することができる通知システム、通知装置および通知方法を提供することを目的とする。
【課題を解決するための手段】
【０００６】
本発明に係る通知システムは、監視対象機器のインシデント情報を管理するインシデント管理手段と、監視対象機器の構成情報を管理する構成管理手段と、監視対象機器に対して施される作業情報を管理する作業管理手段と、インシデント情報、構成情報および作業情報に基づき、監視対象機器が所属するシステムの将来の一定期間における障害発生可能性を算出する可能性算出手段と、障害発生可能性を通知する通知手段と、を備える。
【０００７】
本発明に係る通知装置は、監視対象機器のインシデント情報、監視対象機器の構成情報および監視対象機器に対して施される作業情報に基づき、監視対象機器が所属するシステムの将来の一定期間における障害発生可能性を算出する可能性算出手段と、障害発生可能性を通知する通知手段と、を備える。
【０００８】
本発明に係る通知方法は、監視対象機器のインシデント情報、監視対象機器の構成情報および監視対象機器に対して施される作業情報に基づき、監視対象機器が所属するシステムの将来の一定期間における障害発生可能性を算出するステップと、障害発生可能性を通知するステップと、を含む。
【発明の効果】
【０００９】
本発明に係る通知システム、通知装置および通知方法によれば、インシデント情報、構成情報および作業情報に基づき将来の障害発生可能性を算出して通知することで、対応の遅れの発生を抑制することができる。
【図面の簡単な説明】
【００１０】
【図１】実施の形態における通知システムの概略構成図である。
【図２】実施の形態の通知システムにおける障害発生可能性通知処理のフローチャートである。
【発明を実施するための形態】
【００１１】
（構成の説明）
以下、図面を参照して本発明の通知システム、通知装置および通知方法の実施の形態を詳細に説明する。図１は、実施の形態における通知システム１の概略構成図である。本実施の形態の通知システム１は、一または複数の監視対象機器８１を含む一または複数の監視対象システム８０における障害発生の可能性を算出し、通知するシステムである。監視対象機器８１は、例えばサーバ、データベース、端末装置（パーソナルコンピュータ）などである。監視対象システム８０は、一または複数の監視対象機器８１がネットワークを介して接続された構成を有している。監視対象システム８０は、例えばインターネットなどを介して通知システム１と接続される。
【００１２】
図１に示すように、本実施の形態の通知システム１は、通知装置１０と、構成管理装置２０と、作業管理装置３０と、インシデント管理装置４０とからなる。通知装置１０は、構成管理装置２０、作業管理装置３０およびインシデント管理装置４０と通信可能に接続される。また、通知システム１は、障害情報ＤＢ５００と、構成情報ＤＢ６００と、インシデント情報ＤＢ７００と、を備える。なお、「ＤＢ」は、「データベース」の略記である。
【００１３】
通知装置１０は、ＣＰＵ（Central Processing Unit）およびメモリを備える一または複数のコンピュータにより構成され、監視対象システム８０における障害発生の可能性を算出し、監視対象システム８０の関係者に通知する。通知装置１０は、可能性算出部１０１と、画面入出力部１０２と、メール送信部１０３とを有する。可能性算出部１０１と、画面入出力部１０２と、メール送信部１０３は、通知装置１０が備えるＣＰＵによりメモリに記憶されるプログラムを実行することで実現される機能部である。
【００１４】
可能性算出部１０１は、インシデント情報、監視対象機器８１の構成情報および作業情報に基づき、監視対象システム８０毎の障害発生可能性を算出する。可能性算出部１０１により算出された障害発生可能性は、障害情報ＤＢ５００の障害発生可能性テーブル５０３に記憶される。また、可能性算出部１０１は、障害発生可能性の算出に用いる作業情報およびインシデント情報を障害情報ＤＢ５００の作業情報テーブル５０１およびインシデント情報テーブル５０２にそれぞれ記憶する。
【００１５】
画面入出力部１０２は、通知装置１０が備える表示部（不図示）に障害発生の可能性を含む通知メールを表示する。また、画面入出力部１０２は、通知装置１０が備える操作部（不図示）を介して入力される通知情報を受け付け、通知情報テーブル５０４に通知情報を記憶する。通知情報は、監視対象システム８０の運用担当者、担当システムエンジニアおよび所属部門の関係者のメールアドレスなどを含む。
【００１６】
メール送信部１０３は、障害情報ＤＢ５００の障害発生可能性テーブル５０３に記憶される障害発生可能性を含むメールを生成する。また、メール送信部１０３は、生成したメールを、通知情報テーブル５０４に記憶される通知情報に基づき、運用担当者、担当システムエンジニアおよびその所属部門の関係者に対して送信する。
【００１７】
構成管理装置２０は、ＣＰＵおよびメモリを備える一または複数のコンピュータにより構成され、監視対象機器８１の構成を構成情報として管理する装置である。具体的には、構成管理装置２０は、監視対象機器８１のリソース情報および監視対象機器８１が所属する監視対象システム８０に関する情報などを含む構成情報を、監視対象機器８１から収集する。そして、構成管理装置２０は、収集した構成情報を構成情報ＤＢ６００の構成情報テーブル６０１へ記憶する、または更新する。なお、監視対象機器８１の構成情報は、担当システムエンジニア等により設定されて構成情報テーブル６０１に記憶されてもよい。また、構成管理装置２０は、通知装置１０からの制御指令に基づき、構成情報テーブル６０１に記憶される構成情報の参照を行う。
【００１８】
作業管理装置３０は、ＣＰＵおよびメモリを備える一または複数のコンピュータにより構成され、監視対象機器８１に対して施される作業を管理する装置である。具体的には、作業管理装置３０は、監視対象機器８１に施される作業予定を含む作業情報を収集する。作業情報は、監視対象機器８１名と、作業予定日時と、作業内容とを含む。また、作業管理装置３０は、収集した作業情報に基づいて、監視対象機器８１における作業工程表の生成または作業進捗の管理を行ってもよい。監視対象機器８１に対して施される作業は、例えば、監視対象機器８１におけるソフトウェアのアップデートなどである。
【００１９】
インシデント管理装置４０は、ＣＰＵおよびメモリを備える一または複数のコンピュータにより構成され、監視対象機器８１において発生した過去のインシデント情報を管理する装置である。具体的には、インシデント管理装置４０は、監視対象機器８１毎に過去のインシデント情報をインシデント情報ＤＢ７００のインシデント情報テーブル７０１に記憶する、または更新する。インシデント情報は、インシデントの発生からインシデントに対する対応までの情報、インシデントの要因となった障害および障害の対応手順に関する情報を含む。また、インシデント管理装置４０は、通知装置１０からの制御指令に基づき、インシデント情報テーブル７０１に記憶されるインシデント情報の参照を行う。
【００２０】
（動作の説明）
図２は、実施の形態の通知システム１における障害発生可能性通知処理のフローチャートである。本処理は、通知装置１０により、定期的に実行される。定期的とは、一日一回、週一回、または月一回などであり、その期間は担当システムエンジニアなどにより設定される。本処理が開始されると、まず、障害情報ＤＢ５００の障害発生可能性テーブル５０３に記憶される障害発生可能性が初期化される（Ｓ１）。例えば、障害発生可能性テーブル５０３に記憶される全ての監視対象システム８０の障害発生可能性が「０％」とされる。
【００２１】
続いて、監視対象機器８１への作業影響による障害発生の可能性が算出される。具体的には、まず所定の予測期間内に何れかの監視対象機器８１に作業が予定されているか否かが判断される（Ｓ２）。所定の予測期間は、障害発生可能性通知処理が開始された日時から将来の一定期間である。例えば、障害発生可能性通知処理が一日一回実施される場合は、障害発生可能性通知処理が開始された日時から一日の間に監視対象機器８１に対する作業が予定されているかが判断される。ここでは、通知装置１０からの制御指令に基づき、作業管理装置３０が監視対象機器８１から収集した予測期間内の作業情報を通知装置１０に送信する。通知装置１０は、作業管理装置３０から受信した作業情報に基づき、予測期間内に作業が予定されているか否かを判断する。
【００２２】
そして、全ての監視対象機器８１において作業が予定されていない場合は（Ｓ２：Ｎｏ）、ステップＳ８に移行する。一方、何れかの監視対象機器８１に予測期間内に作業が予定されている場合は（Ｓ２：Ｙｅｓ）、作業が予定されている監視対象機器８１が所属する監視対象システム８０が特定される（Ｓ３）。具体的には、まず、作業情報から作業が予定されている監視対象機器名が識別される。そして、構成管理装置２０を介して、識別された監視対象機器名に基づく構成情報が構成情報テーブル６０１から取得される。続いて、取得された構成情報から、識別された監視対象機器８１が構成要素となっている監視対象システム８０が特定される。
【００２３】
そして、障害情報ＤＢ５００の障害発生可能性テーブル５０３に記憶されている、特定された監視対象システム８０の障害発生可能性に所定の値が加算される（Ｓ４）。ここでは、予定されている作業の影響により、障害発生の可能性が高まると推定して、障害発生可能性テーブル５０３に所定の値が加算される。加算される所定の値は、予定されている作業の内容に応じて異なる値が加算されてもよいし、作業の内容に依らず一律の値が加算されてもよい。
【００２４】
次に、予定されている作業と同じ作業による障害が、該当する監視対象機器８１について過去に発生しているかどうかが判断される（Ｓ５）。ここでは、通知装置１０からの制御により、インシデント管理装置４０によってインシデント情報ＤＢ７００のインシデント情報テーブル７０１が参照される。そして、インシデント情報テーブル７０１において、今回予定されている作業と同じ作業による障害が該当する監視対象機器８１において過去に発生しているかどうかが照合される。
【００２５】
そして、予定されている作業と同じ作業による障害が該当する監視対象機器８１において過去に発生していない場合は（Ｓ５：Ｎｏ）、ステップＳ８へ移行する。一方、予定されている作業と同じ作業による障害が該当する監視対象機器８１において過去に発生している場合は（Ｓ５：Ｙｅｓ）、障害発生可能性テーブル５０３に記憶される、該当する監視対象システム８０の障害発生可能性に所定の値が加算される（Ｓ６）。加算される所定の値は、過去に発生した障害の内容に応じて異なる値が加算されてもよいし、障害の内容に依らず一律の値が加算されてもよい。また、加算される所定の値は、過去に障害が発生した件数が多いほど大きな値であってもよい。
【００２６】
続いて、インシデント管理装置４０を介して、インシデント情報ＤＢ７００のインシデント情報テーブル７０１から障害が発生した際の対応手順情報が取得され、障害情報ＤＢ５００のインシデント情報テーブル５０２に記憶される（Ｓ７）。
【００２７】
続いて、過去のインシデントの発生傾向から、予測期間内における障害発生可能性が算出される。具体的には、まずインシデント管理装置４０を介して、インシデント情報ＤＢ７００のインシデント情報テーブル７０１から、時間、週、月または年の単位で、監視対象機器８１が提供するサービスごとに過去のインシデントの発生件数が取得される（Ｓ８）。
【００２８】
そして、過去のインシデントの発生件数が閾値を超えたときの処理条件と今回の予測期間内における処理条件とが一致するか否かが判断される（Ｓ９）。処理条件は、例えば監視対象機器８１のＣＰＵおよびメモリの使用状況などである。そして、過去のインシデントの発生件数が閾値を超える処理条件と今回の予測期間内における処理条件とが一致しない場合には（Ｓ９：Ｎｏ）、ステップＳ１１へ移行する。一方、過去のインシデントの発生件数が閾値を超える処理条件と今回の処理条件とが一致する場合には（Ｓ９：Ｙｅｓ）、障害発生可能性テーブル５０３に記憶される、該当する監視対象システム８０の障害発生可能性に、所定の値が加算される（Ｓ１０）。加算される所定の値は、過去のインシデント発生件数が多いほど高い値であってもよいし、インシデント発生件数に依らず一律の値が加算されてもよい。
【００２９】
その後、障害発生可能性テーブル５０３に記憶される障害発生可能性が通知される（Ｓ１１）。具体的には、通知装置１０のメール送信部１０３によって、監視対象システム８０毎に、障害情報ＤＢ５００の障害発生可能性テーブル５０３に記憶される障害発生可能性を含む通知メールが生成される。ここでは、障害発生可能性が「０％」以外の監視対象システム８０に対してのみ、通知メールを生成してもよいし、全ての監視対象システム８０に対して通知メールを生成してもよい。ステップＳ７にてインシデント情報テーブル５０２に障害の対応手順が記憶された場合は、通知メールに対応手順情報を含んでもよい。また、通知メールを通知装置１０の表示部に表示させ、運用担当者または担当システムエンジニアによって編集してもよい。生成された通知メールは、通知情報テーブル５０４に記憶される通知情報に含まれる監視対象システム８０の運用担当者、担当システムエンジニアおよび所属部門の関係者のメールアドレス宛てに送信される。
【００３０】
以上のように、本実施の形態によれば、担当システムエンジニアおよびその所属部門の関係者が、通知メールにより将来の一定期間における障害の発生可能性を把握することができる。これにより、エスカレーションを受ける可能性を意識して障害に対する対応の準備をできるようになり、対応の遅れを抑制することができる。また、事前に準備することで、インシデント対応時間を短縮することもできる。
【００３１】
なお、実施の形態の可能性算出部１０１が「可能性算出手段」に相当し、メール送信部１０３が「通知手段」に相当する。また、実施の形態の「インシデント管理装置」、「構成管理装置」および「作業管理装置」が、それぞれ「インシデント管理手段」、「構成管理手段」および「作業管理手段」に相当する。
【００３２】
以上が本発明の実施の形態の説明であるが、本発明は、上記の実施の形態の構成に限定されるものではなく、その技術的思想の範囲内で様々な変形または組み合わせが可能である。例えば、上記実施の形態では、作業情報および過去のインシデントの発生傾向情報を用いて、障害発生可能性に対し三段階の加算（図２のステップＳ４、Ｓ６、Ｓ１０）を行ったが、これに限定されるものではなく、少なくとも何れか一つの加算を実施すればよい。また、作業情報と過去のインシデントの発生傾向情報に加えて、従来技術の予兆検知方法などを用いて定量的な値を算出し、障害発生可能性に加算してもよい。
【００３３】
また、上記実施の形態では、通知をメールで行うこととしたが、これに限定されるものではなく、ポップアップメッセージを表示すること、運用システム内の掲示板に掲載すること、またはその他のコミュニケーションツールを用いて通知を行ってもよい。
【００３４】
また、本実施の形態では、通知装置１０と、構成管理装置２０と、作業管理装置３０と、インシデント管理装置４０とを別個の装置とした形態について説明したが、これら全ての装置または一部の装置、もしくは一部の機能を１つの装置に集約させてもよい。さらに、上記実施の形態では、通知装置１０のＣＰＵがソフトウェア（プログラム）を実行することにより障害発生可能性通知処理を実行する構成としたが、ＣＰＵ以外の各種のプロセッサにより実行してもよい。この場合のプロセッサとしては、ＦＰＧＡ（Field-Programmable Gate Array）等の製造後に回路構成を変更可能なＰＬＤ（Programmable Logic Device）、およびＡＳＩＣ（Application Specific Integrated Circuit）等の特定の処理を実行させるために専用に設計された回路構成を有するプロセッサである専用電気回路等が例示される。
【符号の説明】
【００３５】
１  通知システム、１０  通知装置、２０  構成管理装置、３０  作業管理装置、４０  インシデント管理装置、８０  監視対象システム、８１  監視対象機器、１０１  可能性算出部、１０２  画面入出力部、１０３  メール送信部、５００  障害情報ＤＢ、５０１  作業情報テーブル、５０２  インシデント情報テーブル、５０３  障害発生可能性テーブル、５０４  通知情報テーブル、６００  構成情報ＤＢ、６０１  構成情報テーブル、７００  インシデント情報ＤＢ、７０１  インシデント情報テーブル。
【図１】
2020140525.tif 000003
【図２】
2020140525.tif 000004