JP2019168928A - 緊急性判定装置、緊急性判定方法および緊急性判定プログラム - Google Patents

Abstract

【課題】過剰な保守サービスを抑止すること。【解決手段】緊急性判定装置１００は、記憶部１４０と、受信部１５１と、判定部１５２とを有する。記憶部１４０は、複数の装置によって冗長化された製品の構成情報を記憶する。受信部１５１は、製品に含まれる複数の装置のうち何れかの装置に障害が発生した場合に、障害の発生した装置を特定する情報の通知を受け付ける。判定部１５２は、障害の発生した装置を特定する情報と構成情報とを基にして、製品に対する保守作業の緊急性を判定する。【選択図】図２

Description

本発明は、緊急性判定装置等に関する。

従来、製品の保守サービスを提供する企業では、保守契約を結んだクライアントの製品に障害が発生した場合に、迅速に対応することが求められてきた。このため、従来型の保守サービスでは、保守対象の製品に含まれる一部の装置に障害が発生したことを示す障害通報を受け付けると、直ちに、保守作業員が現地におもむき、装置交換等の保守作業を行っている。

なお、近年では、ＨＤＤ（Hard Disk Drive）やＰＳＵ（Power Supply Unit）等のコストが低下しており、冗長構成の製品を購入することが昔ほど難しいものではなくなっている。たとえば、一般の企業では、重要なデータを格納するストレージ製品を導入する場合には、保守契約を結びつつも、ＲＡＩＤ（Redundant Arrays of Inexpensive Disks）構成のものを用いることで、データがロストすることを予防している。

特開平９−１８４６４４号公報 特開２００８−１７１２３１号公報

しかしながら、上述した従来技術では、過剰な保守サービスを抑止することができないという問題がある。

上記のように、保守対象となる製品は冗長化されていることが多く、製品に含まれる一部の製品に障害が発生したとしても、直ちにデータロストすることは希である。このような状況下において、従来のように、保守対象の製品に関する障害通知を受け付けた場合において、直ちに保守作業員を現地に派遣すると、保守作業員の負担が増加するだけでなく、保守コストが増加し、保守サービスを受ける側にとっても適切であるとは言い難い。

１つの側面では、本発明は、過剰な保守サービスを抑止することができる緊急性判定装置、緊急性判定方法および緊急性判定プログラムを提供することを目的とする。

第１の案では、緊急性判定装置は、記憶部と、受信部と、判定部とを有する。記憶部は、複数の装置によって冗長化された製品の構成情報を記憶する。受信部は、製品に含まれる複数の装置のうち何れかの装置に障害が発生した場合に、障害の発生した装置を特定する情報の通知を受け付ける。判定部は、障害の発生した装置を特定する情報と構成情報とを基にして、製品に対する保守作業の緊急性を判定する。

過剰な保守サービスを抑止することができる。

図１は、本実施例に係るシステムの構成を示す図である。 図２は、本実施例に係る緊急性判定装置の構成を示す機能ブロック図である。 図３は、障害通知情報のデータ構造の一例を示す図である。 図４は、構成情報テーブルのデータ構造の一例を示す図である。 図５は、構成情報のデータ構造の一例を示す図である。 図６は、作業員テーブルのデータ構造の一例を示す図である。 図７は、本実施例に係る緊急性判定装置の処理手順を示すフローチャートである。 図８は、緊急性判定装置と同様の機能を実現するコンピュータのハードウェア構成の一例を示す図である。

以下に、本願の開示する緊急性判定装置、緊急性判定方法および緊急性判定プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。

図１は、本実施例に係るシステムの構成を示す図である。図１に示すように、このシステムは、製品１０と、緊急性判定装置１００とを有する。製品１０と緊急性判定装置１００とは、ネットワーク５０を介して相互に接続される。

製品１０は、保守対象となる製品（ストレージ製品）であり、冗長化されている。たとえば、製品１０は、複数のＨＤＤ１１ａ，１１ｂ，１１ｃ，１１ｄを有し、ＲＡＩＤ６によって冗長化されているものとする。ＲＡＩＤ６によって冗長化された製品１０は、同時に２台のＨＤＤが故障した場合でも、データ回復が可能である。以下の説明では、ＨＤＤ１１ａ〜１１ｄをまとめて、適宜、「ＨＤＤ１１」と表記する。

図１に示す例では、ＲＡＩＤ６による冗長構成の製品１０を示すが、製品１０は、他の種類のＲＡＩＤによって冗長化されていてもよい。他の種類のＲＡＩＤは、ＲＡＩＤ０、ＲＡＩＤ１、ＲＡＩＤ２、ＲＡＩＤ０＋１、ＲＡＩＤ１＋０、ＲＡＩＤ３、ＲＡＩＤ４、ＲＡＩＤ５等を含む。更に、製品１０は、ＲＡＩＤによる冗長化に加えて、スペアとなるＨＤＤを備えていてもよい。また、図１のシステムは、製品１０以外のストレージ製品に接続されていてもよい。

製品１０は、ＨＤＤ１１の何れかに障害が発生したことを検出すると、障害が発生したことを示す「障害通知情報」を、緊急性判定装置１００に送信する。障害通知情報は、障害の発生したＨＤＤを特定する情報を含む。

緊急性判定装置１００は、製品１０から障害通知情報を受信した場合に、製品１０の構成情報と、障害通知情報とを基にして、保守作業の緊急性を判定する装置である。緊急性判定装置１００は、製品１０でデータロストが発生する危険が高い場合には、保守作業員を直ちに製品１０に向かわせる旨の通知を行う。一方、緊急性判定装置１００は、製品１０でデータロストが発生する危険が高くない場合には、保守作業員を直ちに製品１０に向かわせる旨の通知を抑止する。

たとえば、製品１０は、ＲＡＩＤ６によって冗長化されており、同時に２台のＨＤＤ１１が故障した場合でも、データ回復が可能である。このため、緊急性判定装置１００は、ＨＤＤ１１のうち、何れか１台のＨＤＤ１１に障害が発生した旨の障害通知情報を受信した場合には、製品１０でデータロストが発生する危険が低い（緊急性が低い）と判定する。一方、ＨＤＤ１１のうち、何れか２台のＨＤＤ１１に障害が発生した旨の障害通知情報を受信した場合には、他のＨＤＤ１１が故障した時点で、製品１０でデータロストが発生するため、データロストが発生する危険が高い（緊急性が高い）と判定する。

上記のように、緊急性判定装置１００は、ＲＡＩＤ構成により冗長化された製品から障害発生の通知を受け付けた場合に、障害の発生した装置と製品の構成情報とを基にして、製品の保守作業の緊急性を判定する。これによって、過剰な保守サービスを抑止することができる。

また、過剰な保守サービスを抑止することで、緊急性を要しない保守作業の回数を削減でき、保守サービスを行う保守作業員の負担を軽減させることが可能になるだけでなく、保守サービスのコストを低下させることもできる。このため、保守サービスの提供側、受け側の双方にとって、よりよい保守サービスを行うことができる。

次に、本実施例に係る緊急性判定装置１００の構成について説明する。図２は、本実施例に係る緊急性判定装置の構成を示す機能ブロック図である。図２に示すように、緊急性判定装置１００は、通信部１１０と、入力部１２０と、表示部１３０と、記憶部１４０と、制御部１５０とを有する。

通信部１１０は、製品１０との間でデータ通信を実行する処理部である。通信部１１０は、通信装置の一例である。たとえば、通信部１１０は、製品１０から障害通知情報を受信し、受信した障害通知情報を、制御部１５０に出力する。

図３は、障害通知情報のデータ構造の一例を示す図である。図３に示すように、この障害通知情報は、製品ＩＤと、故障装置ＩＤと、Ｉ／Ｏ数情報と、メディアエラー情報とを有する。製品ＩＤは、製品を一意に識別する情報である。故障装置ＩＤは、故障した装置（ＨＤＤ１１）を一意に識別する情報である。

Ｉ／Ｏ数情報は、製品１０に含まれる各ＨＤＤ１１に対する書き込み／読み込みの回数を示す情報である。メディアエラー情報は、各ＨＤＤ１１で発生したメディアエラーの回数を示す情報である。

なお、製品１０は、ＨＤＤ１１の障害を検出しない場合でも、定期的に、通知情報を、緊急性判定装置１００に送信してもよい。通知情報には、製品ＩＤ、装置ＩＤ、Ｉ／Ｏ数情報、メディアエラー情報が含まれる。通信部は、係る通知情報を受信し、受信した通知情報を、制御部１５０に出力する。

また、通信部１１０は、図示しない保守作業員の端末装置とデータ通信を実行してもよい。保守作業員の端末装置は、ノートＰＣ、タブレット端末、スマートフォン等に対応する。後述する制御部１５０は、通信部１１０を介して、製品１０（他の製品）、保守作業員の端末装置とデータをやり取りする。

入力部１２０は、緊急性判定装置１００に各種の情報を入力するための入力装置である。入力部１２０は、キーボードやマウス、タッチパネル等に対応する。

表示部１３０は、制御部１５０から出力される各種の情報を表示する表示装置である。表示部１３０は、液晶ディスプレイ、タッチパネル等に対応する。

記憶部１４０は、構成情報テーブル１４１、作業員テーブル１４２を有する。記憶部１４０は、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、フラッシュメモリ（Flash Memory）などの半導体メモリ素子や、ＨＤＤ（Hard Disk Drive）などの記憶装置に対応する。

構成情報テーブル１４１は、ネットワーク５０に接続される、製品１０および図示しない他の製品の構成情報を保持するテーブルである。図４は、構成情報テーブルのデータ構造の一例を示す図である。図４に示すように、構成情報テーブル１４１は、製品ＩＤと、保守契約有無と、構成情報とを対応付ける。製品ＩＤは、製品を一意に識別する情報である。本実施例では一例として、製品１０の製品ＩＤを「Ｐ１０１」とする。また、図示しない他の製品の製品ＩＤを「Ｐ１０２、Ｐ１０２、Ｐ１０３、Ｐ１０４、・・・」とする。

保守契約有無は、該当する製品ＩＤにより識別される製品に関して保守契約を結んでいるか否かを示す情報である。保守契約を結んでいる場合には、保守契約有無が「有」となる。保守契約を結んでいない場合には、保守契約有無が「無」となる。

構成情報は、該当する製品ＩＤにより識別される製品のＲＡＩＤ構成を示す情報である。図５は、構成情報のデータ構造の一例を示す図である。たとえば、図５の構成情報は、製品ＩＤ「Ｐ１０１」の構成情報の一例である。構成情報は、ＲＡＩＤ種別と、装置ＩＤと、アクティブフラグと、障害発生フラグと、Ｉ／Ｏ数履歴情報と、メディアエラー数履歴情報とを対応付ける。

ＲＡＩＤ種別は、ＲＡＩＤの種類を示すものである。装置ＩＤは、ＨＤＤを一意に識別する情報である。アクティブフラグは、該当する装置ＩＤのＨＤＤが運用系であるか待機系であるかを区別するフラグである。ＨＤＤが運用系である場合には、アクティブフラグが「オン」となる。ＨＤＤが待機系（スペア）である場合には、アクティブフラグが「オフ」となる。障害発生フラグは、該当する装置ＩＤのＨＤＤに障害が発生したか否かを示す情報である。

Ｉ／Ｏ数履歴情報は、製品１０から通知されたＩ／Ｏ数の履歴を示すものである。メディアエラー履歴情報は、製品１０から通知されたメディアエラー回数の履歴を示すものである。

作業員テーブル１４２は、保守作業員に関する各種の情報を保持するテーブルである。図６は、作業員テーブルのデータ構造の一例を示す図である。図６に示すように、この作業員テーブル１４２は、作業員ＩＤと、氏名と、担当製品ＩＤと、連絡先情報と、スケジュール情報とを対応付ける。作業員ＩＤは、保守作業員を一意に識別する情報である。氏名は、保守作業員の氏名である。担当製品ＩＤは、該当する保守作業員が担当する製品の製品ＩＤである。たとえば、作業員ＩＤ「Ｕ１０１」の保守作業員「富士太郎」が保守作業を担当する製品の製品ＩＤは「Ｐ１０１」である。

連絡先情報は、該当する保守作業員の連絡先を示す情報である。たとえば、連絡先情報は、保守作業員の使用する端末装置のＩＰ（Internet Protocol）アドレスである。スケジュール情報は、該当する保守作業員のスケジュール情報である。たとえば、スケジュール情報は、定期メンテナンス等のために出張する各出張先と日時とを対応付ける。

図２の説明に戻る。制御部１５０は、受信部１５１、判定部１５２、通知部１５３を有する。たとえば、制御部１５０は、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）などによって実現できる。また、制御部１５０は、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）などのハードワイヤードロジックによっても実現できる。

受信部１５１は、製品１０または他の製品から、障害通知情報または通知情報を受信する処理部である。受信部１５１は、障害通知情報を受信した場合には、障害通知情報に含まれる製品ＩＤに対応する、構成情報テーブル１４１の構成情報を特定し、特定した構成情報を更新する。受信部１５１は、障害通知情報の故障装置ＩＤに対応する装置ＩＤの障害発生フラグをオンに設定する。また、受信部１５１は、障害通知情報に含まれるＩ／Ｏ数情報、メディアエラー情報によって、構成情報テーブル１４１のＩ／Ｏ数履歴情報、メディアエラー履歴情報を更新する。受信部１５１は、障害通知情報を受信して、構成情報テーブル１４１を更新した場合に、障害通知情報を、判定部１５２に出力する。

受信部１５１は、通知情報を受信した場合には、通知情報に含まれる製品ＩＤに対応する、構成情報テーブル１４１の構成情報を特定し、特定した構成情報（Ｉ／Ｏ数履歴情報、メディアエラー履歴情報）を更新する。

判定部１５２は、製品１０に含まれる装置に障害が発生した場合に、障害の発生した装置ＩＤと、構成情報テーブル１４１とを基にして、製品１０に対する保守作業の緊急性を判定する処理部である。判定部１５２は、判定結果を通知部１５３に出力する。以下において、判定部１５２の処理の一例について説明する。

判定部１５２は、受信部１５１から障害通知情報を取得すると、障害通知情報の製品ＩＤと、構成情報テーブル１４１とを比較し、保守契約有無を参照する。判定部１５２は、障害通知情報の製品ＩＤに対応する保守契約有無が「無」の場合には、障害通知情報に対応する処理をスキップする。一方、判定部１５２は、障害通知情報の製品ＩＤに対応する保守契約有無が「有」の場合には、下記に示す処理を実行する。

判定部１５２は、障害通知情報の製品ＩＤと、構成情報テーブル１４１とを比較して、障害通知情報の製品ＩＤに対応する構成情報を取得する。判定部１５２は、取得した構成情報において、障害発生フラグが「オン」となる装置（装置ＩＤ）の数をカウントすることで、故障したＨＤＤ１１の台数を特定する。

判定部１５２は、ＲＡＩＤ種別と、障害許容台数とを対応付けた判定ポリシー情報を保持しているものとする。ＲＡＩＤ種別は、ＲＡＩＤの種類を示す情報である。障害許容台数は、該当するＲＡＩＤ種別の冗長構成よって、障害が発生してもデータロストが発生しない限界台数である。すなわち、障害の発生したＨＤＤの数が、障害許容台数を超えると、データロストが発生する。たとえば、ＲＡＩＤ種別「ＲＡＩＤ６」の障害許容台数は「２」である。

たとえば、判定部１５２は、下記の条件（１）を満たす場合に、緊急性が「高」であると判定する。条件（１）において、スペアのＨＤＤの数は、アクティブフラグが「オフ」かつ、障害発生フラグが「オン」となるＨＤＤの数である。

障害許容台数≦障害の発生したＨＤＤの数−スペアのＨＤＤの数・・・条件（１）

判定部１５２は、条件（１）を満たさない場合には、障害通知情報の製品ＩＤに対応する構成情報のＩ／Ｏ数履歴情報を基にして、繁忙期であるか否かを推定する。たとえば、判定部１５２は、最新のＩ／Ｏ数が予め設定された閾値以上である場合には、繁忙期であると判定する。判定部１５２は、最新日時を起点とした所定期間において、Ｉ／Ｏ数が予め設定された閾値未満である場合には、繁忙期ではないと判定する。

判定部１５２が「繁忙期である」と判定した場合の処理について説明する。判定部１５２は、障害通知情報の製品ＩＤに対応する構成情報のメディアエラー履歴情報を基にして、緊急性を判定する。たとえば、判定部１５２は、最新日時を起点とした所定期間において、メディアエラー回数が「０以上１０未満」の範囲に含まれる場合には、緊急性が「低」であると判定する。判定部１５２は、メディアエラー回数が「１０以上３０未満」の範囲に含まれる場合には、緊急性が「中」であると判定する。判定部１５２は、メディアエラー回数が「３０以上」の範囲に含まれる場合には、緊急性が「高」であると判定する。

なお、上記のメディアエラー回数は、製品ＩＤに対応する構成情報の各装置ＩＤ（障害発生フラグがオフの装置ＩＤ）のメディアエラー回数（所定期間のメディアエラー回数）のうち、最大のメディアエラー回数とする。

続いて、判定部１５２が「繁忙期でない」と判定した場合の処理について説明する。判定部１５２は、障害通知情報の製品ＩＤに対応する構成情報のＩ／Ｏ数履歴情報を参照し、最新日時より所定期間前から最新日時までの期間において、Ｉ／Ｏ数が増加傾向にあるか否かを判定する。判定部１５２は、所定期間前から最新日時までの期間において、Ｉ／Ｏ数が増加傾向にない場合には、緊急性が「低」であると判定する。

一方、判定部１５２は、Ｉ／Ｏ数が増加傾向にある場合には、次の処理を実行する。判定部１５２は、障害通知情報の製品ＩＤに対応する構成情報のメディアエラー履歴情報を基にして、緊急性を判定する。たとえば、判定部１５２は、最新日時を起点とした所定期間において、メディアエラー回数が「０以上２０未満」の範囲に含まれる場合には、緊急性が「低」であると判定する。判定部１５２は、メディアエラー回数が「２０以上５０未満」の範囲に含まれる場合には、緊急性が「中」であると判定する。判定部１５２は、メディアエラー回数が「５０以上」の範囲に含まれる場合には、緊急性が「高」であると判定する。

判定部１５２は、上記処理を行うことで、緊急性を判定し、判定結果を通知部１５３に出力する。判定結果には、障害通知情報に含まれる製品ＩＤと、緊急性の情報が含まれる。

通知部１５３は、判定部１５２の判定結果に応じて、保守作業員の端末装置に保守作業に関する情報を通知する処理部である。通知部１５３は、判定部１５２の判定結果に含まれる製品ＩＤと、作業員テーブル１４２とを比較して、通知先となる保守作業員の端末装置を特定する。通知部１５３は、緊急性に応じて、保守作業員の端末装置に通知する情報を変更する。

緊急性が「低」である場合の通知部１５３の処理について説明する。通知部１５３は、保守作業員担当の製品に障害が発生したこと、次回点検時に障害の発生したＨＤＤを交換することを促す情報を、端末装置に通知する。

緊急性が「中」である場合の通知部１５３の処理について説明する。通知部１５３は、保守作業員担当の製品に障害が発生したこと、翌日以降に保守作業を行うことを示す情報を、端末装置に通知する。通知部１５３は、作業員テーブル１４２の保守作業員のスケジュール情報を参照して、翌日以降で、障害の発生した製品を有する会社へ保守作業員が出勤する最速の日時を特定し、端末装置に通知してもよい。

緊急性が「高」である場合の通知部１５３の処理について説明する。通知部１５３は、保守作業員担当の製品に障害が発生したこと、直ちに障害の発生したＨＤＤを交換することを示す情報を、端末装置に通知する。通知部１５３は、緊急性が「高」であることを保守作業員により確実に通知するために、端末装置にアラーム音等を出力させてもよい。

次に、本実施例に係る緊急性判定装置１００の処理手順の一例について説明する。図７は、本実施例に係る緊急性判定装置の処理手順を示すフローチャートである。図７に示すように、緊急性判定装置１００の受信部１５１は、障害通知情報を受信する（ステップＳ１０１）。

緊急性判定装置１００の判定部１５２は、保守契約が有であるか否かを判定する（ステップＳ１０２）。判定部１５２は、保守契約が有でない場合には（ステップＳ１０２，Ｎｏ）、処理を終了する。一方、判定部１５２は、保守契約が有である場合には（ステップＳ１０２，Ｙｅｓ）、ステップＳ１０３に移行する。

判定部１５２は、障害通知情報と、構成情報テーブル１４１の構成情報とを基にして、緊急性を判定する（ステップＳ１０３）。緊急性判定装置１００の通知部１５３は、緊急性が「高」の場合には（ステップＳ１０４，Ｙｅｓ）、保守作業員の端末装置に即、出動指示を行い（ステップＳ１０５）、処理を終了する。

一方、判定部１５２は、緊急性が「高」でない場合には（ステップＳ１０４，Ｎｏ）、Ｉ／Ｏ数を基にして、繁忙期か否かを判定する（ステップＳ１０６）。判定部１５２は、繁忙期である場合には（ステップＳ１０７，Ｙｅｓ）、ステップＳ１０８に移行する。判定部１５２および通知部１５３は、繁忙期における、メディアエラー回数に応じた通知処理を行う（ステップＳ１０８）。

一方、判定部１５２は、繁忙期でない場合には（ステップＳ１０７，Ｎｏ）、ステップＳ１０９に移行する。判定部１５２および通知部１５３は、Ｉ／Ｏ数の推移に応じた通知処理を行う（ステップＳ１０９）。また、判定部１５２および通知部１５３は、非繁忙期における、メディアエラー回数に応じた通知処理を行う（ステップＳ１１０）。

次に、本実施例に係る緊急性判定装置１００の効果について説明する。緊急性判定装置１００は、製品１０から障害通知情報を受信した場合に、製品１０の構成情報と、障害通知情報とを基にして、保守作業の緊急性を判定する。保守作業員が、緊急性判定装置１００の判定結果により保守作業を行うことで、過剰な保守サービスを抑止することができる。

緊急性判定装置１００は、障害の発生したＨＤＤ１１と構成情報とを基にして、障害の発生していないＨＤＤ１１の何れかに障害が発生した場合においてデータロストが発生するか否かにより、緊急性を判定する。これによって、データロストが発生するか否かの基準により、緊急性を判定することができる。

緊急性判定装置１００は、複数のハードディスクに対するデータの書き込みおよび読み込みの回数（Ｉ／Ｏ回数）の情報を用いて、緊急性を判定する。たとえば、繁忙期においては、非繁忙期と比較して、緊急性のレベルが高くなりやすいようにすることで、繁忙期にデータロストがより発生しないような保守作業を行うことができる。

緊急性判定装置１００は、メディアエラー回数を基にして、緊急性を判定するため、今後、発生しえる障害を見越した保守作業を行うことができる。

次に、上記実施例に示した緊急性判定装置１００と同様の機能を実現するコンピュータのハードウェア構成の一例について説明する。図８は、緊急性判定装置と同様の機能を実現するコンピュータのハードウェア構成の一例を示す図である。

図８に示すように、コンピュータ２００は、各種演算処理を実行するＣＰＵ２０１と、ユーザからのデータの入力を受け付ける入力装置２０２と、ディスプレイ２０３とを有する。また、コンピュータ２００は、記憶媒体からプログラム等を読み取る読み取り装置２０４と、有線または無線ネットワークを介して他装置との間でデータの授受を行うインターフェース装置２０５とを有する。また、コンピュータ２００は、各種情報を一時記憶するＲＡＭ２０６と、ハードディスク装置２０７とを有する。そして、各装置２０１〜２０７は、バス２０８に接続される。

ハードディスク装置２０７は、受信プログラム２０７ａ、判定プログラム２０７ｂ、通知プログラム２０７ｃを有する。ＣＰＵ２０１は、各プログラム２０７ａ〜２０７ｃを読み出してＲＡＭ２０６に展開する。

受信プログラム２０７ａは、受信プロセス２０６ａとして機能する。判定プログラム２０７ｂは、判定プロセス２０６ｂとして機能する。通知プログラム２０７ｃは、通知プロセス２０６ｃとして機能する。

受信プロセス２０６ａの処理は、受信部１５１の処理に対応する。判定プロセス２０６ｂの処理は、判定部１５２の処理に対応する。通知プロセス２０６ｃの処理は、通知部１５３の処理に対応する。

なお、各プログラム２０７ａ〜２０７ｃについては、必ずしも最初からハードディスク装置２０７に記憶させておかなくても良い。例えば、コンピュータ２００に挿入されるフレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＤＶＤ、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」に各プログラムを記憶させておく。そして、コンピュータ２００が各プログラム２０７ａ〜２０７ｃを読み出して実行するようにしても良い。

１００ 緊急性判定装置
１１０ 通信部
１２０ 入力部
１３０ 表示部
１４０ 記憶部
１４１ 構成情報テーブル
１４２ 作業員テーブル
１５０ 制御部
１５１ 受信部
１５２ 判定部
１５３ 通知部

Claims (7)

1. 複数の装置によって冗長化された製品の構成情報を記憶する記憶部と、
   前記製品に含まれる複数の装置のうち何れかの装置に障害が発生した場合に、障害の発生した装置を特定する情報の通知を受け付ける受信部と、
   前記障害の発生した装置を特定する情報と前記構成情報とを基にして、前記製品に対する保守作業の緊急性を判定する判定部と
   を有することを特徴とする緊急性判定装置。
2. 前記製品は複数のハードディスクによるＲＡＩＤ（Redundant Arrays of Inexpensive Disks）構成によって冗長化されており、前記判定部は、前記障害の発生したハードディスクと前記構成情報とを基にして、障害の発生していないハードディスクの何れかに障害が発生した場合においてデータロストが発生するか否かにより、前記緊急性を判定することを特徴とする請求項１に記載の緊急性判定装置。
3. 前記判定部は、複数のハードディスクに対するデータの書き込みおよび読み込みの回数の情報を更に用いて、前記緊急性を判定することを特徴とする請求項２に記載の緊急性判定装置。
4. 前記判定部は、前記障害の発生していないハードディスクで発生するエラーの情報を更に用いて、前記緊急性を判定することを特徴とする請求項２または３に記載の緊急性判定装置。
5. 前記記憶部は、前記製品の保守作業を行う作業員のスケジュール情報を更に記憶し、
   前記判定部の判定結果と、前記スケジュール情報とを基にして、通知を行う通知部を更に有することを特徴とする請求項１〜４のいずれか一つに記載の緊急性判定装置。
6. コンピュータが実行する緊急性判定方法であって、
   複数の装置によって冗長化された製品について、前記複数の装置のうち何れかの装置に障害が発生した場合に、障害の発生した装置を特定する情報の通知を受け付け、
   前記製品の構成情報を記憶する記憶装置を参照し、
   前記障害の発生した装置を特定する情報と前記構成情報とを基にして、前記製品に対する保守作業の緊急性を判定する
   処理を実行することを特徴とする緊急性判定方法。
7. コンピュータに、
   複数の装置によって冗長化された製品について、前記複数の装置のうち何れかの装置に障害が発生した場合に、障害の発生した装置を特定する情報の通知を受け付け、
   前記製品の構成情報を記憶する記憶装置を参照し、
   前記障害の発生した装置を特定する情報と前記構成情報とを基にして、前記製品に対する保守作業の緊急性を判定する
   処理を実行させることを特徴とする緊急性判定プログラム。

Images