特開 2024-127092 障害対応方法および障害対応システム

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

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

(11)【公開番号】P2024127092

(43)【公開日】2024-09-20

(54)【発明の名称】障害対応方法および障害対応システム

(51)【国際特許分類】

   G06F 11/07 20060101AFI20240912BHJP

【ＦＩ】

G06F11/07 172

G06F11/07 193

【審査請求】未請求

【請求項の数】6

【出願形態】ＯＬ

(21)【出願番号】P 2023035975

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

【公序良俗違反の表示】

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

１．ＷＩＮＤＯＷＳ

(71)【出願人】

【識別番号】598057291

【氏名又は名称】エフサステクノロジーズ株式会社

(74)【代理人】

【識別番号】110002147

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

(72)【発明者】

【氏名】山口 龍二

(72)【発明者】

【氏名】塩川 順

(72)【発明者】

【氏名】泉 博文

(72)【発明者】

【氏名】山口 敦

(72)【発明者】

【氏名】村井 幸治

(72)【発明者】

【氏名】大場 重志

(72)【発明者】

【氏名】岡 賢作

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

5B042

【Ｆターム（参考）】

5B042KK13

5B042KK17

5B042KK20

5B042MA08

5B042MC16

5B042MC17

5B042MC35

(57)【要約】

【課題】顧客システムの障害対応を行うための承認を適切に得ること。
【解決手段】障害対応システムは、システムと、システムを管理する管理サーバとを有する。管理サーバは、監視サーバによって、システムに障害が発生したことが検知され、障害の対応情報が記憶部に登録された場合に、システムの重要度と、対応情報の種別とを基にして、障害の緊急度を算出する。管理サーバは、緊急度を基にして、対応情報に応じた処理の承認要求を承認者端末に行うための手段を選定する。管理サーバは、選定した手段によって、承認者端末に承認要求を行う。
【選択図】図１

【特許請求の範囲】

【請求項1】

システムと、前記システムを管理する管理サーバとを有する障害対応システムの障害対応方法であって、
前記管理サーバは、監視サーバによって、前記システムに障害が発生したことが検知され、前記障害の対応情報が記憶部に登録された場合に、前記システムの重要度と、前記対応情報の種別とを基にして、前記障害の緊急度を算出し、
前記管理サーバは、前記緊急度を基にして、前記対応情報に応じた処理の承認要求を承認者端末に行うための手段を選定し、
前記管理サーバは、選定した前記手段によって、前記承認者端末に前記承認要求を行う
ことを特徴とする障害対応方法。

【請求項2】

前記システムのツールは、前記記憶部に登録された前記対応情報と、前記承認要求の結果とを基にして、前記対応情報に応じた処理を前記システムに対して実行する処理を更に実行することを特徴とする請求項１に記載の障害対応方法。

【請求項3】

前記管理サーバは、前記緊急度が閾値以上の場合には、前記承認者端末に電話を発信し、自動音声を再生することで、前記対応情報に応じた処理の承認要求を行うことを特徴とする請求項１に記載の障害対応方法。

【請求項4】

前記管理サーバは、前記緊急度が閾値未満の場合には、前記承認者端末に、前記対応情報に応じた処理の承認要求に関するテキスト情報を設定したメールを送信することを特徴とする請求項１に記載の障害対応方法。

【請求項5】

前記管理サーバは、前記障害の対応情報が前記記憶部に登録された日時を基にして、前記緊急度を補正する処理を更に実行することを特徴とする請求項１に記載の障害対応方法。

【請求項6】

システムと、前記システムを管理する管理サーバとを有する障害対応システムであって、
前記管理サーバは、監視サーバによって、前記システムに障害が発生したことが検知され、前記障害の対応情報が記憶部に登録された場合に、前記システムの重要度と、前記対応情報の種別とを基にして、前記障害の緊急度を算出し、
前記管理サーバは、前記緊急度を基にして、前記対応情報に応じた処理の承認要求を承認者端末に行うための手段を選定し、
前記管理サーバは、選定した前記手段によって、前記承認者端末に前記承認要求を行う
ことを特徴とする障害対応システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、障害対応方法および障害対応システムに関する。

【背景技術】

【0002】

従来、顧客システムを監視し、顧客システムに何らかの障害が発生した場合に、係る障害に対応する障害対応システムがある。

【0003】

図１４は、従来の障害対応システムの一例を示す図である。図１４に示すように、この障害対応システムは、顧客システム５、自動化処理部６、監視サーバ７、ＩＴＳＭ（IT Service Management）サーバ８を有する。監視サーバ７およびＩＴＳＭサーバ８と、自動化処理部６との間には、不正アクセス等を防止するためのFirewall９が配置される。

【0004】

顧客システム５は、顧客が利用するシステムであり、複数の電子機器から構成される。自動化処理部６は、インバウンド通信によって、外部の監視サーバ７から、ワークアラウンドの実行命令を受信した場合に、該当するワークアラウンドに応じたジョブを、顧客システムに対して実行する。図示を省略するが、障害対応システムは、顧客システム５に加えて、他の顧客システムを更に含んでいてもよい。

【0005】

監視サーバ７は、ＳａａＳ（Software as a Service）型の監視サーバであり、顧客システム５や、他の顧客システム（図示略）の監視を行う。ここでは、顧客システム５を用いて、監視サーバ７の説明を行う。

【0006】

監視サーバ７は、顧客システム５から、障害発生の通知を受け付けた場合等に、顧客システム５の障害発生を検知し、表示画面等に障害発生の情報を表示させる。監視サーバ７のオペレータは、障害発生の情報を表示画面等で確認すると、障害内容に対応するワークアラウンドを実行するための承認プロセスを行い、承認を得られたワークアラウンドの実行命令を、自動化処理部６に対して送信する。

【0007】

たとえば、監視サーバ７のオペレータは、承認プロセスにおいて、事前に指定された顧客の携帯電話等に電話をかけることで、承認をもらう場合もある。

【0008】

ＩＴＳＭサーバ８は、ＳａａＳ型のＩＴＳＭサーバであり、顧客システム５および他の顧客システム（図示略）に発生した障害内容、係る障害内容に対して選択したワークアラウンド等の履歴情報を保存する。監視サーバ７のオペレータは、ＩＴＳＭサーバ８に保存された履歴情報を参照して、顧客システム５で新たに発生した障害内容に対応するワークアラウンドを選択する場合もある。

【先行技術文献】

【特許文献】

【0009】

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

【発明の概要】

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

【0010】

たとえば、監視サーバ７のオペレータは、承認プロセスにおいて、事前に指定された顧客の携帯電話等に電話をかけることで、承認を得ているが、深夜に障害が発生した場合には、顧客が就寝中であるため、実際に電話をかけるか否かはオペレータの判断に依存することになる。緊急の障害であれば、深夜であっても顧客から承認を得るべきであるが、緊急の障害でない場合には、翌日に承認を得てもよいことになる。しかしながら、オペレータ自身が、係る判断を行って承認を得ることは難しい。

【0011】

１つの側面では、本発明は、顧客システムの障害対応を行うための承認を適切に得ることができる障害対応方法および障害対応システムを提供することを目的とする。

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

【0012】

第１の案では、障害対応システムは、システムと、システムを管理する管理サーバとを有する。管理サーバは、監視サーバによって、システムに障害が発生したことが検知され、障害の対応情報が記憶部に登録された場合に、システムの重要度と、対応情報の種別とを基にして、障害の緊急度を算出する。管理サーバは、緊急度を基にして、対応情報に応じた処理の承認要求を承認者端末に行うための手段を選定する。管理サーバは、選定した手段によって、承認者端末に承認要求を行う。

【発明の効果】

【0013】

顧客システムの障害対応を行うための承認を適切に得ることができる。

【図面の簡単な説明】

【0014】

【図1】図１は、本実施例に係る障害対応システムの一例を示す図である。

【図2】図２は、障害ＤＢのデータ構造の一例を示す図である。

【図3】図３は、本実施例に係る自動化処理装置の構成を示す機能ブロック図である。

【図4】図４は、処理テーブルのデータ構造の一例を示す図である。

【図5】図５は、監視サーバの構成を示す機能ブロック図である。

【図6】図６は、ＩＴＳＭサーバの構成を示す機能ブロック図である。

【図7】図７は、ワークアラウンド管理テーブルのデータ構造の一例を示す図である。

【図8】図８は、システムレベル管理テーブルのデータ構造の一例を示す図である。

【図9】図９は、本実施例に係る自動化処理装置の処理手順を示すフローチャートである。

【図10】図１０は、監視サーバおよびＩＴＳＭサーバの処理手順を示すフローチャートである。

【図11】図１１は、承認処理を示すフローチャートである。

【図12】図１２は、実施例の監視サーバと同様の機能を実現するコンピュータのハードウェア構成の一例を示す図である。

【図13】図１３は、実施例のＩＴＳＭサーバと同様の機能を実現するコンピュータのハードウェア構成の一例を示す図である。

【図14】図１４は、従来の障害対応システムの一例を示す図である。

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

【0015】

以下に、本願の開示する障害対応方法および障害対応システムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。

【実施例0016】

図１は、本実施例に係る障害対応システムの一例を示す図である。図１に示すように、この障害対応システムは、顧客システム１０ａ，１０ｂ，１０ｃと、自動化処理装置２０ａ，２０ｂ，２０ｃと、承認者端末５５と、監視サーバ１００と、ＩＴＳＭサーバ２００とを有する。本実施例では、監視サーバ１００と、ＩＴＳＭサーバ２００とを別々のサーバとして説明するが、監視サーバ１００と、ＩＴＳＭサーバ２００とを一つのサーバで実現することもできる。

【0017】

顧客システム１０ａ～１０ｃは、自動化処理装置２０ａ～２０ｃにそれぞれ接続される。自動化処理装置２０ａ～２０ｃは、それぞれ、外部からの不正アクセスを防止するためのFirewall３０ａ，３０ｂ，３０ｃを介して、ネットワーク５０に接続される。監視サーバ１００およびＩＴＳＭサーバ２００は、ネットワーク５０に接続される。

【0018】

顧客システム１０ａ～１０ｃは、顧客が利用するシステムであり、複数の電子機器から構成される。以下の説明では、特に区別する場合を除き、顧客システム１０ａ～１０ｃをまとめて「顧客システム１０」と表記する。顧客システム１０は、自顧客システム１０内に障害が発生した場合に、障害情報を、監視サーバ１００に送信する。

【0019】

たとえば、障害情報には、障害の内容を一意に識別する障害コードと、顧客システム１０を一意に識別するシステム識別番号が含まれる。顧客システム１０ａのシステム識別番号を「ｓｙｓ１」、顧客システム１０ｂのシステム識別番号を「ｓｙｓ２」、顧客システム１０ｃのシステム識別番号を「ｓｙｓ３」とする。

【0020】

承認者端末５５は、承認者が利用する端末装置である。承認者端末５５は、スマートフォン等に対応する。承認者端末５５は、ＩＴＳＭサーバ２００から、自動音声による電話またはメールによって、ワークアラウンドに対応する処理の承認要求を受け付ける。承認者は、承認者端末５５を操作して、承認要求の内容を確認し、該当の処理を承認するか否かを設定した承認結果の情報を、ＩＴＳＭサーバ２００に送信する。

【0021】

監視サーバ１００は、顧客システム１０を監視する。監視サーバ１００は、顧客システム１０から障害情報を受信した場合、障害情報を表示画面に表示する。また、監視サーバ１００は、障害情報を設定したインシデント発行要求を、ＩＴＳＭサーバ２００に送信する。

【0022】

ＩＴＳＭサーバ２００は、インシデント発行要求を受付けると、インシデント番号を発行し、障害情報に関する情報を、障害ＤＢ２４１に登録する。

【0023】

図２は、障害ＤＢのデータ構造の一例を示す図である。図２に示すように、この障害ＤＢ２４１は、障害テーブルｔａ１，ｔａ２，ｔａ３を有する。障害テーブルｔａ１は、顧客システム１０ａの障害情報に関する情報を保持する。障害テーブルｔａ２は、顧客システム１０ｂの障害情報に関する情報を保持する。障害テーブルｔａ３は、顧客システム１０ｃの障害情報に関する情報を保持する。障害ＤＢ２４１は、他の顧客システムの障害テーブルを更に有していてもよい。

【0024】

障害テーブルｔａ１について説明する。障害テーブルｔａ１には、顧客システム１０ａのシステム識別番号「ｓｙｓ１」が設定される。また、障害テーブルｔａ１には、インシデント番号、障害コード、ワークアラウンド、日時、承認済みフラグ、対処フラグが設定される。

【0025】

インシデント番号は、ＩＴＳＭサーバ２００が発行する番号である。障害コードは、障害情報に設定された障害を一意に識別する情報である。ワークアラウンドは、障害コードによって識別される障害の対処内容を示す。たとえば、ワークアラウンドは、Windowsサーバのサービス状態確認、長時間走行ジョブの確認等である。その他のワークアラウンドの説明を省略する。

【0026】

日時は、インシデント発行要求を受付けた日時が設定される。承認済みフラグは、ワークアラウンドに対応する処理を実行することが承認されたか否かを示すフラグである。ワークアラウンドに対応する処理が承認されている場合には、承認済みフラグが「ＯＮ」となる。ワークアラウンドに対応する処理が承認されていない場合には、承認済みフラグが「ＯＦＦ」となる。承認済みフラグの初期値を「ＯＦＦ」とする。

【0027】

対処フラグは、顧客システムの障害に対応したか否かを示すフラグである。障害に対処した場合には、対処フラグに「ＯＮ」が設定される。障害に対応していない場合には、対処フラグに「ＯＦＦ」が設定される。対処フラグの初期値を「ＯＦＦ」とする。

【0028】

障害テーブルｔａ２について説明する。障害テーブルｔａ２には、顧客システム１０ｂのシステム識別番号「ｓｙｓ２」が設定される。また、障害テーブルｔａ２には、インシデント番号、障害コード、ワークアラウンド、日時、承認済みフラグ、対処フラグが設定される。

【0029】

障害テーブルｔａ３について説明する。障害テーブルｔａ３には、顧客システム１０ｃのシステム識別番号「ｓｙｓ３」が設定される。また、障害テーブルｔａ３には、インシデント番号、障害コード、ワークアラウンド、日時、承認済みフラグ、対処フラグが設定される。

【0030】

以下の説明では、障害テーブルｔａ１，ｔａ２，ｔａ３のインシデント番号によって識別されるレコードを「インシデント」と表記する。たとえば、インシデント番号「inc_1」によって識別されるインシデントは、障害コード「error1100」、ワークアラウンド「Windowsサーバのサービス状態確認」、日時「２０２３年２月２０日 １１時００分」、承認済みフラグ「ＯＮ」、対処フラグ「ＯＦＦ」のレコードに対応する。以下の説明では、適宜、対処フラグが「ＯＦＦ」となるインシデントを、未対処のインシデントと表記する。また、承認済みフラグが「ＯＦＦ」となるインシデントを、未承認のインシデントと表記する。

【0031】

ここで、ＩＴＳＭサーバ２００は、障害の発生した顧客システム１０の重要度と、ワークアラウンドの種別に応じた値と乗算することで、緊急度を算出する。ＩＴＳＭサーバ２００は、緊急度を基にして、ワークアラウンドの処理の承認要求を、承認者端末５５に行うための手段を選定する。たとえば、ＩＴＳＭサーバ２００は、緊急度が閾値以上となる場合には、緊急の障害が発生していると判定し、自動音声による電話を承認者端末５５にかける（電話を発信する）。自動音声には、該当するインシデント番号、障害コード、ワークアラウンド等を伝える音声と、承認を要求する旨の音声が含まれる。

【0032】

一方、ＩＴＳＭサーバ２００は、緊急度のスコアが閾値未満となる場合には、翌日でも対応可能な障害が発生していると判定し、承認要求のメールを承認者端末５５に送信する。承認要求のメールには、該当するインシデント番号、障害コード、ワークアラウンドの情報と、承認を要求する旨のテキストが含まれる。

【0033】

ＩＴＳＭサーバ２００は、承認要求を行った後に、承認者端末５５からの承認結果を受信する。承認結果には、ワークアラウンドに対応する処理を承認するか否かの情報が設定される。ＩＴＳＭサーバ２００は、承認結果に「承認する」旨が設定されている場合には、承認済みフラグを「ＯＮ」に更新する。ＩＴＳＭサーバ２００は、承認結果に「承認しない」旨が設定されている場合には、承認済みフラグを「ＯＦＦ」のままとする。

【0034】

図１の説明に戻る。自動化処理装置２０ａ～２０ｃは、アウトバウンド通信によって、所定時間毎に、ＩＴＳＭサーバ２００の障害ＤＢ２４１にアクセスし、自身の顧客システム１０に対応する障害テーブルを参照する。たとえば、自動化処理装置２０ａは、顧客システム１０ａに対応する障害テーブルｔａ１を参照する。自動化処理装置２０ｂは、顧客システム１０ｂに対応する障害テーブルｔａ２を参照する。自動化処理装置２０ｃは、顧客システム１０ｃに対応する障害テーブルｔａ３を参照する。

【0035】

自動化処理装置２０ａは、障害テーブルｔａ１のインシデントのうち、承認済みフラグが「ＯＮ」、かつ、対処フラグが「ＯＦＦ」となる未対処のインシデントを特定し、特定したインシデントに設定されたワークアラウンドに対応するジョブを、顧客システム１０ａに対して実行する。図２に示す例では、自動化処理装置２０ａは、ワークアラウンド「Windowsサーバのサービス状態確認」のジョブ、「長時間走行ジョブの確認」のジョブを顧客システム１０ａに対して実行する。自動化処理装置２０ａは、「Windowsサーバのサービス状態確認」、「長時間走行ジョブの確認」の処理結果を、ＩＴＳＭサーバ２００に通知する。

【0036】

ＩＴＳＭサーバ２００は、ワークアラウンド「Windowsサーバのサービス状態確認」、「長時間走行ジョブの確認」に対処した旨の情報を、処理結果として受信した場合には、障害テーブルｔａ１のワークアラウンド「Windowsサーバのサービス状態確認」、「長時間走行ジョブの確認」に対応する対処フラグを「ＯＦＦ」から「ＯＮ」に更新する。

【0037】

一方、ＩＴＳＭサーバ２００は、ワークアラウンド「Windowsサーバのサービス状態確認」、「長時間走行ジョブの確認」に対処に失敗した旨の情報を、処理結果として受信した場合には、エラー情報を、監視サーバ１００に送信する。エラー情報には、システム識別番号、対処に失敗したワークアラウンドに対応するインシデント番号等が設定される。

【0038】

自動化処理装置２０ｂは、障害テーブルｔａ２のインシデントのうち、承認済み、かつ、未対処のインシデントを特定し、特定したインシデントに設定されたワークアラウンドに対応するジョブを、顧客システム１０ｂに対して実行する。自動化処理装置２０ｂは、ジョブの処理結果を、ＩＴＳＭサーバ２００に通知する。その他の説明は、自動化処理装置２０ａに関する説明と同様である。

【0039】

自動化処理装置２０ｃは、障害テーブルｔａ３のインシデントのうち、承認済み、かつ、未対処のレコードを特定し、特定したインシデントに設定されたワークアラウンドに対応するジョブを、顧客システム１０ｃに対して実行する。自動化処理装置２０ｃは、ジョブの処理結果を、ＩＴＳＭサーバ２００に通知する。その他の説明は、自動化処理装置２０ａに関する説明と同様である。

【0040】

以下の説明では、自動化処理装置２０ａ～２０ｃを特に区別しない場合、自動化処理装置２０ａ～２０ｃをまとめて「自動化処理装置２０」と表記する。自動化処理装置２０は、顧客システム１０のツールの一例である。自動化処理装置２０は、顧客システム１０内に設定されていてもよいし、顧客システム１０が、自動化処理装置２０の機能を有していてもよい。

【0041】

上記のように、本実施例に係る障害対応システムは、監視サーバ１００が、顧客システム１０の障害情報を受信した場合に、インシデント発行要求を、ＩＴＳＭサーバ２００に行い、ＩＴＳＭサーバ２００は、障害情報に関する情報を、障害ＤＢ２４１に登録する。

【0042】

ここで、ＩＴＳＭサーバ２００は、障害の発生した顧客システム１０の重要度と、ワークアラウンドの種別とを基にして、緊急度を算出する。ＩＴＳＭサーバ２００は、緊急度が閾値以上となる場合には、緊急の障害が発生していると判定し、自動音声による電話を承認者端末５５にかける。一方、ＩＴＳＭサーバ２００は、緊急度が閾値未満となる場合には、翌日でも対応可能な障害が発生していると判定し、承認要求のメールを承認者端末５５に送信する。

【0043】

このように、ＩＴＳＭサーバ２００は、緊急度を基にして、自動音声による電話またはメールによって、承認者端末５５に承認要求を行う。これによって、緊急の障害が発生している場合には、電話によって、迅速に承認要求を行うことができ、翌日でも対応可能な障害が発生している場合には、承認者に即時対応を求めないメールによって、承認要求を行うことができる。すなわち、本実施例の障害対応システムによれば、顧客システムの障害対応を行うための承認を適切に得ることができる。

【0044】

また、本実施例に係る障害対応システムは、アウトバウンド通信によって、自動化処理装置２０側から、ワークアラウンドを取得するため、インバウンド通信の場合と比較して、顧客システム１０の障害対応をセキュアに実行することができる。

【0045】

次に、図１で説明した自動化処理装置２０の構成例について説明する。図３は、本実施例に係る自動化処理装置の構成を示す機能ブロック図である。図３に示すように、この自動化処理装置２０ａ（２０）は、通信部２１と、記憶部２４と、制御部２５とを有する。

【0046】

通信部２１は、ネットワーク５０を介して、監視サーバ１００、ＩＴＳＭサーバ２００との間で情報の送受信を行う。また、通信部２１は、顧客システム１０との間で情報の送受信を行う。通信部２１は、ＮＩＣ（Network Interface Card）等によって実現される。

【0047】

記憶部２４は、処理テーブル２４ａを有する。たとえば、記憶部２４は、メモリ等の記憶装置である。

【0048】

処理テーブル２４ａは、ワークアラウンドに対応するジョブを設定するテーブルである。図４は、処理テーブルのデータ構造の一例を示す図である。図４に示すように、この処理テーブル２４ａは、ワークアラウンドと、ジョブとを対応付ける。ワークアラウンドに関する説明は、上記のワークアラウンドに関する説明と同様である。ジョブは、複数のプログラムをまとめて連続して実行するひとつのかたまりである。また、ジョブは、複数のコード部品の実行順を定義したパーツに対応する。

【0049】

図３の説明に戻る。制御部２５は、取得部２５ａと、実行部２５ｂとを有する。制御部２５は、たとえば、ＣＰＵ（Central Processing Unit）やＭＰＵ(Micro Processing Unit)等である。

【0050】

取得部２５ａは、所定時間毎に、ＩＴＳＭサーバ２００の障害ＤＢ２４１の障害テーブルｔａ１にアクセスする。取得部２５ａは、ＩＴＳＭサーバ２００にアクセスする場合、ジョブの実行対象となる顧客システムのシステム識別番号を通知する。取得部２５ａは、障害テーブルｔａ１のインシデントのうち、承認済み、かつ、未対処のインシデントのワークアラウンドを取得する。取得部２５ａは、インシデント番号もあわせて取得してもよい。取得部２５ａは、取得したワークアラウンドを、実行部２５ｂに出力する。

【0051】

実行部２５ｂは、取得部２５ａから取得したワークアラウンドと、処理テーブル２４ａとを比較し、ワークアラウンドに対応するジョブを特定する。実行部２５ｂは、特定したジョブを、顧客システム１０ａに対して実行する。実行部２５ｂは、処理結果を、ＩＴＳＭサーバ２００に送信する。処理結果には、インシデント番号と、ワークアラウンドに対応するジョブの実行に成功したか否かの情報が含まれる。

【0052】

ここで、実行部２５ｂは、ジョブの実行に失敗した場合に、所定回数、ジョブの実行を再試行してもよい。実行部２５ｂは、所定回数、ジョブを再試行しても、ジョブの実行に成功しない場合に、処理結果に、ワークアラウンドに対応するジョブの実行に失敗した旨の情報を設定し、ＩＴＳＭサーバ２００に送信する。

【0053】

自動化処理装置２０ｂ，２０ｃの機能ブロック図は、図３に示した自動化処理装置２０ａの機能ブロック図に対応するため、説明を省略する。

【0054】

次に、図１で説明した監視サーバ１００の構成例について説明する。図５は、監視サーバの構成を示す機能ブロック図である。図５に示すように、この監視サーバ１００は、通信部１１０と、入力部１２０と、表示部１３０と、記憶部１４０と、制御部１５０とを有する。

【0055】

通信部１１０は、ネットワーク５０を介して、ＩＴＳＭサーバ２００、自動化処理装置２０、顧客システム１０と情報の送受信を行う。通信部１１０は、ＮＩＣ等によって実現される。

【0056】

入力部１２０は、各種の情報を、監視サーバ１００に入力する入力装置である。入力部１２０は、キーボードやマウス、タッチパネル等に対応する。

【0057】

表示部１３０は、制御部１５０から出力される情報を表示する表示装置である。表示部１３０は、液晶ディスプレイ、有機ＥＬ（Electro Luminescence）ディスプレイ、タッチパネル等に対応する。たとえば、表示部１３０は、顧客を表示する。

【0058】

記憶部１４０は、制御部１５０が処理を実行するための各種の情報を保持する。記憶部１４０は、メモリ等の記憶装置である。

【0059】

制御部１５０は、異常検知部１５１、依頼部１５２、表示制御部１５３を有する。制御部１５０は、たとえば、ＣＰＵやＭＰＵ等である。

【0060】

異常検知部１５１は、顧客システム１０ａ～１０ｃを監視し、障害が発生したか否かを検知する。たとえば、異常検知部１５１は、顧客システム１０から障害情報を受信した場合、障害情報に設定されたシステム識別番号に対応する顧客システム１０に障害が発生したことを検知する。異常検知部１５１は、受信した障害情報を、依頼部１５２、表示制御部１５３に出力する。

【0061】

異常検知部１５１は、データを顧客システム１０に送信し、送信先の顧客システム１０から応答がない場合に、顧客システム１０の異常を検知してもよい。この場合、異常検知部１５１は、応答なしを示す障害コードと、異常を検知した顧客システム１０のシステム識別番号を設定した障害情報を生成し、生成した障害情報を、依頼部１５２、表示制御部１５３に出力する。

【0062】

依頼部１５２は、異常検知部１５１から障害情報を取得した場合に、障害情報を設定したインシデント発行要求を、ＩＴＳＭサーバ２００に送信する。

【0063】

表示制御部１５３は、各種の情報を表示部１３０に表示させる。たとえば、表示制御部１５３は、障害情報を、表示部１３０に表示させる。表示制御部１５３は、ＩＴＳＭサーバ２００から、エラー情報を受信した場合には、エラー情報を、表示部１３０に表示させる。

【0064】

次に、図１で説明したＩＴＳＭサーバ２００の構成例について説明する。図６は、ＩＴＳＭサーバの構成を示す機能ブロック図である。図６に示すように、このＩＴＳＭサーバ２００は、通信部２１０と、入力部２２０と、表示部２３０と、記憶部２４０と、制御部２５０とを有する。

【0065】

通信部２１０は、ネットワーク５０を介して、監視サーバ１００、自動化処理装置２０、顧客システム１０と情報の送受信を行う。通信部１１０は、ＮＩＣ等によって実現される。

【0066】

入力部２２０は、各種の情報を、ＩＴＳＭサーバ２００に入力する入力装置である。入力部２２０は、キーボードやマウス、タッチパネル等に対応する。

【0067】

表示部２３０は、制御部１５０から出力される情報を表示する表示装置である。表示部２３０は、液晶ディスプレイ、有機ＥＬディスプレイ、タッチパネル等に対応する。たとえば、表示部１３０は、顧客を表示する。

【0068】

記憶部２４０は、障害ＤＢ２４１、ワークアラウンド管理テーブル２４２、システムレベル管理テーブル２４３を保持する。記憶部２４０は、メモリ等の記憶装置である。

【0069】

障害ＤＢ２４１は、障害情報に関する情報を保持する。障害ＤＢ２４１のデータ構造は、図２で説明したデータ構造に対応する。

【0070】

ワークアラウンド管理テーブル２４２は、障害コードによって識別される障害に対処するためのワークアラウンドを定義する。図７は、ワークアラウンド管理テーブルのデータ構造の一例を示す図である。図７に示すように、このワークアラウンド管理テーブル２４２は、障害コードと、種別と、ワークアラウンドとを対応付ける。障害コードは、障害を一意に識別する情報である。種別には、参照系、または、更新系が設定される。参照系のワークアラウンドは、顧客システム１０の情報を参照するワークアラウンドである。更新系のワークアラウンドは、顧客システム１０の情報を更新するワークアラウンドである。ワークアラウンドは、障害に対処するためのワークアラウンド名である。たとえば、障害コード「error1000」に対応するワークアラウンド（ワークアラウンド名）は「システム再起動」である。

【0071】

システムレベル管理テーブル２４３は、顧客システム１０のシステムレベルの情報を保持する。図８は、システムレベル管理テーブルのデータ構造の一例を示す図である。図８に示すように、システムレベル管理テーブル２４３は、システム識別番号と、システムレベルとを対応付ける。システム識別番号は、顧客システム１０を一意に識別する番号である。

【0072】

システムレベルは、顧客システムの障害が社会に与える重要性を示すレベルである。システムレベルが大きいほど、顧客システムの障害が社会に与える重要度が大きい。たとえば、顧客システム１０のシステムレベルは、（１）、（２）、（３）の何れかとなる。システムレベル（１）の顧客システムは、「社会的影響が殆どないシステム」である。システムレベル（２）の顧客システムは、「社会的影響が限定されるシステム」である。システムレベル（３）の顧客システムは、「社会的影響が極めて大きいシステム」である。

【0073】

たとえば、システム識別番号「ｓｙｓ１」によって識別される顧客システム１０ａのシステムレベルは「システムレベル（１）」である。このため、顧客システム１０ａは、障害が発生した場合でも、「社会的影響が殆どないシステム」である。

【0074】

図６の説明に戻る。制御部２５０は、受信部２５１、登録部２５２、承認処理部２５３、アクセス受付部２５４を有する。制御部２５０は、たとえば、ＣＰＵやＭＰＵ等である。

【0075】

受信部２５１は、監視サーバ１００からインシデント発行要求を受信した場合に、インシデント発行要求に設定された障害情報を、登録部２５２に出力する。

【0076】

登録部２５２は、障害情報を基にして、インシデントに関する情報を障害ＤＢ２４１に登録する。たとえば、登録部２５２は、障害情報を取得した場合に、ユニークなインシデント番号を生成する。登録部２５２は、障害情報に設定された障害コードと、ワークアラウンド管理テーブル２４２とを比較して、障害コードに対応するワークアラウンドを特定する。

【0077】

登録部２５２は、障害情報に設定されたシステム識別番号を基にして、インシデントを登録する障害テーブルを選択する。登録部２５２は、システム識別番号が「ｓｙｓ１」である場合には、障害テーブルｔａ１を選択する。登録部２５２は、システム識別番号が「ｓｙｓ２」である場合には、障害テーブルｔａ２を選択する。登録部２５２は、システム識別番号が「ｓｙｓ３」である場合には、障害テーブルｔａ３を選択する。

【0078】

登録部２５２は、選択した障害テーブルに、インシデント（インシデント番号、障害情報の障害コード、ワークアラウンド、日時、承認済みフラグ＜ＯＦＦ＞、対処フラグ＜ＯＦＦ＞）を登録する。たとえば、登録部２５２は、インシデントの日時として、インシデント発行要求を受信した日時を設定する。

【0079】

承認処理部２５３は、障害ＤＢ２４１に、インシデントが登録された場合に、障害の発生した顧客システム１０の重要度と、ワークアラウンドの種別に応じた値とを乗算することで、緊急度を算出する。

【0080】

承認処理部２５３は、インシデントに対応するシステム識別情報と、システムレベル管理テーブル２４３とを基にして、顧客システム１０のシステムレベルを特定する。たとえば、承認処理部２５３は、顧客システムのシステムレベルがシステムレベル（１）の場合には、顧客システム１０の重要度を「１」とする。承認処理部２５３は、顧客システムのシステムレベルがシステムレベル（２）の場合には、顧客システム１０の重要度を「２」とする。承認処理部２５３は、顧客システムのシステムレベルがシステムレベル（３）の場合には、顧客システム１０の重要度を「３」とする。

【0081】

また、承認処理部２５３は、インシデントに対応する障害コードと、ワークアラウンド管理テーブル２４２とを基にして、ワークアラウンドの種別を特定する。たとえば、承認処理部２５３は、ワークアラウンドの種別が「参照系」の場合には、種別に対応する値を「α」とする。承認処理部２５３は、ワークアラウンドの種別が「更新系」の場合には、種別に対応する値を「β」とする。ただし、αとβとの大小関係をα＜βとする。

【0082】

たとえば、障害ＤＢ２４１の障害テーブルｔａ１（システム識別番号：ｓｙｓ１）に、インシデント番号「inc_1」のレコードが登録された場合、顧客システムの重要度は「１」となり、障害コード「error1100」の種別（更新系）の値は「β」となる。この場合、承認処理部２５３は、緊急度「１×β」を計算する。

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

１０ａ，１０ｂ，１０ｃ 顧客システム
２０ａ，２０ｂ，２０ｃ 自動化処理装置
３０ａ，３０ｂ，３０ｃ Firewall
５０ ネットワーク
１００ 監視サーバ
２００ ＩＴＳＭサーバ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】