特許 5995265 情報処理システム、保守方法及びプログラム

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】5995265

(24)【登録日】2016年9月2日

(45)【発行日】2016年9月21日

(54)【発明の名称】情報処理システム、保守方法及びプログラム

(51)【国際特許分類】

   G06Q 10/00 20120101AFI20160908BHJP

   G06F 11/30 20060101ALI20160908BHJP

   G06Q 50/10 20120101ALI20160908BHJP

【ＦＩ】

   G06Q10/00 300

   G06F11/30

   G06Q50/10

【請求項の数】9

【全頁数】16

(21)【出願番号】特願2012-74131(P2012-74131)

(22)【出願日】2012年3月28日

(65)【公開番号】特開2013-206105(P2013-206105A)

(43)【公開日】2013年10月7日

【審査請求日】2015年2月5日

(73)【特許権者】

【識別番号】000227205

【氏名又は名称】ＮＥＣプラットフォームズ株式会社

(74)【代理人】

【識別番号】100080816

【弁理士】

【氏名又は名称】加藤 朝道

(72)【発明者】

【氏名】進藤 久

【審査官】 小原 正信

(56)【参考文献】

【文献】 特開２００２−２６９２６４（ＪＰ，Ａ）

【文献】 特開２０１１−１７５５１３（ＪＰ，Ａ）

【文献】 特開平０１−２７８８６６（ＪＰ，Ａ）

【文献】 特開平０７−２９６０６５（ＪＰ，Ａ）

【文献】 特開２００４−１６１１９５（ＪＰ，Ａ）

【文献】 特開平０７−０８７１９１（ＪＰ，Ａ）

【文献】 特開２００４−１０２７２７（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｑ １０／００−９９／００

Ｇ０６Ｆ １１／３０

(57)【特許請求の範囲】

【請求項1】

少なくともプロセッサ、メモリを含む置換可能な部位を備えた情報処理システムであって、
前記置換可能な部位からエラーコードが出力された場合、前記置換可能な部位のうちの障害要因部位を特定するための情報と、該障害要因部位の障害の履歴情報とを格納した情報源にアクセスして、前記エラーコードに対応する被疑割合付きの障害要因部位情報と、該障害要因部位の障害の履歴情報とを取得する障害要因解析部と、
前記被疑割合付きの障害要因部位と前記障害の履歴情報とに基づいて、保守作業の難易度を示す保守レベルを算出する保守レベル算出部と、を備え、
前記保守レベルを含んだ保守作業の指示情報を出力する情報処理システム。

【請求項2】

前記情報源には、各障害要因部位に関する保守支援情報を格納した保守情報データベースが含まれ、
前記保守支援情報を含んだ保守作業の指示情報を出力する請求項１の情報処理システム。

【請求項3】

前記保守情報データベースには、さらに、各障害要因部位において発生した保守時のミスによる故障情報が含まれ、
保守レベル算出部は、前記障害要因部位と前記障害の履歴情報とに加えて、前記保守時のミスによる故障情報を用いて保守レベルを算出する請求項２の情報処理システム。

【請求項4】

前記保守レベルが所定のレベル以下である場合、オンラインでの保守作業を指示し、
前記保守レベルが前記所定のレベルを超えた場合、オフラインでの保守作業を指示する請求項１から３いずれか一の情報処理システム。

【請求項5】

前記保守レベルを含んだ保守作業の指示情報の出力後、所定の条件が成立するまで、オンラインでの保守操作を禁止する保守操作ロック機能を有する請求項１から４いずれか一の情報処理システム。

【請求項6】

さらに、管理対象のシステムの構成情報に基づいて、保守作業により影響を受ける他の運用システムまたは運用中の別の論理パーティションの有無を判別し、サービスプロセッサに通報する構成情報解析部を備え、
前記サービスプロセッサは、前記保守作業により影響を受ける他の運用システムまたは運用中の別の論理パーティションを、前記保守作業による障害検出を抑止させるよう制御する請求項１から５いずれか一の情報処理システム。

【請求項7】

前記情報源には、各保守作業の映像を記録した動画データが含まれ、
保守員からの要求に応じて、前記動画データを再生する請求項１から６いずれか一の情報処理システム。

【請求項8】

少なくともプロセッサ、メモリを含む置換可能な部位を備えた情報処理システムによる保守方法であって、
前記置換可能な部位からエラーコードが出力された場合、前記置換可能な部位のうちの障害要因部位を特定するための情報と、該障害要因部位の障害の履歴情報とを格納した情報源にアクセスして、前記エラーコードに対応する被疑割合付きの障害要因部位情報と、該障害要因部位の障害の履歴情報とを取得するステップと、
前記被疑割合付きの障害要因部位と前記障害の履歴情報とに基づいて、保守作業の難易度を示す保守レベルを算出するステップと、
前記保守レベルを含んだ保守作業の指示情報を出力するステップとを含む、保守方法。

【請求項9】

少なくともプロセッサ、メモリを含む置換可能な部位を備えた情報処理システムに含まれるコンピュータに、
前記置換可能な部位からエラーコードが出力された場合、前記被疑割合付きの障害要因部位情報と、該障害要因部位の障害の履歴情報とを取得する処理と、
前記被疑割合付きの障害要因部位と前記障害の履歴情報とに基づいて、保守作業の難易度を示す保守レベルを算出する処理と、
前記保守レベルを含んだ保守作業の指示情報を出力する処理とを実行させるプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、情報処理システム、保守方法及びプログラムに関し、特に、保守作業に関する指示を出力する情報処理システム、保守方法及びプログラムに関する。

【背景技術】

【0002】

特許文献１に、設定当初のＦＲＵテーブルを用いて正確な被疑割合を含む情報を提供する障害管理システムが開示されている。同文献によると、この障害管理システムは、サービスプロセッサにより障害事象が検知された場合に、当該障害事象を特定する情報をキーとして障害履歴情報を検索し、当該障害事象が過去に発生した障害事象と一致する場合に、前記障害履歴情報から当該障害事象を引き起こした誘因履歴のある障害要因部位を抽出する機能を備える。そして、前記誘因履歴のある障害要因部位が抽出された場合に、当該障害要因部位の前記誘因頻度に応じて、ＦＲＵテーブルの当該障害要因部位に対応する設定当初の被疑割合を補正して得られる補正被疑割合を算出する。当該障害事象と当該障害要因部位との関係が、前記ＦＲＵテーブルと前記障害履歴情報とで一致する場合に、当該障害履歴情報の相当する前記誘因頻度をインクリメントする、と記載されている。

【0003】

また、特許文献２には、発生した異常状態の復旧難易度を算出し、復旧難易度に応じた宛て先に通知メールを送信するようにして、適切な宛て先にエラーを通知することができるようにした電子装置が開示されている。同文献によると、この電子装置は、異常状態を検出する状態検出部と、状態検出部によって検出された異常状態に応じた内容の通知メールを生成するメール生成部と、状態検出部によって検出された異常状態に応じた宛て先を抽出する宛て先抽出部と、宛て先抽出部によって抽出された宛て先との間の電子メールの通信及び再送を制御する通信制御部とを備えると記載されている。そして、状態検出部は、検出した異常状態の復旧難易度を算出し、宛て先抽出部は、算出された復旧難易度に基づいて通知メールを送信する宛て先を抽出し、メール生成部は、宛て先抽出部よって抽出された宛て先に対する通知メールを生成し、通信制御部は、メール生成部によって生成された通知メールを宛て先抽出部よって抽出された宛て先に送信する、と記載されている。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２０１１−１７５５１３号公報

【特許文献2】特開２００７−３０４４４号公報

【発明の概要】

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

【0005】

以下の分析は、本発明によって与えられたものである。近年、電子機器製品のダウンサイジング化にともない、多くのコモディティプロセッサを高速ネットワークで接続する高密度実装サーバ（ブレード、クラスタ）技術など分散・並列処理技術が進んでいる。これらの技術の進歩により保守コスト削減のための構造設計も重要な要素の一つであるが、相反してシステム構成あるいは形態によってはより高度な高密度実装がとられ、定期保守あるいは障害発生時の保守自体も高度な訓練や相応の経験が必要となるケースがある。

【0006】

また、上記システム構成や形態に依存しない場合でも、設計不良、製造工程での初期不良あるいはロット不良（品質バラツキ）、顧客先での運用環境による劣化、部品の経年劣化等が挙げられ、これらの要因に応じて保守の対応も追随しないと適切な保守が出来ず、運用停止時間の長期化や健全に運用されているシステムへの副次的な影響を及ぼし兼ねずユーザに甚大な被害を与えることがある。

【0007】

上記のように、適切な保守を行うためには、保守作業の難易度に応じた訓練や経験が必要とされるところ、特許文献１の障害管理システムは、障害発生時に、障害要因部位について正確な被疑割合を提供することを主眼としており、保守作業の難易度を提供できるものとなっていない。

【0008】

特許文献２の電子機器は、異常状態が検出されると、異常状態の復旧難易度を算出すると記載されているが、当該復旧難易度は、異常状態を通知する通知メールの宛先を決定するために用いられているに過ぎない。また、復旧難易度の算出方法自体も、同公報図４のような異常ステータスと復旧難易度とを対応付けたテーブル（異常ステータスエリア）から読み出すものであり、上述のように、システム構成や形態のみならず、様々な要素が絡み合って適切な保守を行う必要があるシステムには到底対応することは不可能である。

【0009】

本発明は、上記した事情に鑑みてなされたものであって、その目的とするところは、上記した多種多様かつ難易度の異なる保守作業への対応を支援する情報処理システム、保守方法及びプログラムを提供することにある。

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

【0010】

本発明の第１の視点によれば、少なくともプロセッサ、メモリを含む置換可能な部位を備えた情報処理システムであって、前記置換可能な部位からエラーコードが出力された場合、前記置換可能な部位のうちの障害要因部位を特定するための情報と、該障害要因部位の障害の履歴情報とを格納した情報源にアクセスして、前記エラーコードに対応する被疑割合付きの障害要因部位情報と、該障害要因部位の障害の履歴情報とを取得する障害要因解析部と、前記被疑割合付きの障害要因部位と前記障害の履歴情報とに基づいて、保守作業の難易度を示す保守レベルを算出する保守レベル算出部と、を備え、前記保守レベルを含んだ保守作業の指示情報を出力する情報処理システムが提供される。

【0011】

本発明の第２の視点によれば、少なくともプロセッサ、メモリを含む置換可能な部位を備えた情報処理システムによる保守方法であって、前記置換可能な部位からエラーコードが出力された場合、前記置換可能な部位のうちの障害要因部位を特定するための情報と、該障害要因部位の障害の履歴情報とを格納した情報源にアクセスして、前記エラーコードに対応する被疑割合付きの障害要因部位情報と、該障害要因部位の障害の履歴情報とを取得するステップと、前記被疑割合付きの障害要因部位と前記障害の履歴情報とに基づいて、保守作業の難易度を示す保守レベルを算出するステップと、前記保守レベルを含んだ保守作業の指示情報を出力するステップとを含む、保守方法が提供される。本方法は、保守員に対し、保守レベルを含んだ保守作業の指示情報を出力する情報処理システムという、特定の機械に結びつけられている。

【0012】

本発明の第３の視点によれば、少なくともプロセッサ、メモリを含む置換可能な部位を備えた情報処理システムに含まれるコンピュータに、前記置換可能な部位からエラーコードが出力された場合、前記被疑割合付きの障害要因部位情報と、該障害要因部位の障害の履歴情報とを取得する処理と、前記被疑割合付きの障害要因部位と前記障害の履歴情報とに基づいて、保守作業の難易度を示す保守レベルを算出する処理と、前記保守レベルを含んだ保守作業の指示情報を出力する処理とを実行させるプログラムが提供される。なお、このプログラムは、コンピュータが読み取り可能な記憶媒体に記録することができる。即ち、本発明は、コンピュータプログラム製品として具現することも可能である。

【発明の効果】

【0013】

本発明によれば、多種多様かつ難易度の異なる保守作業への対応を好適に支援することが可能となる。

【図面の簡単な説明】

【0014】

【図1】本発明の一実施形態の構成を示す図である。

【図2】本発明の第１の実施形態の情報処理システムの構成を示す図である。

【図3】本発明の第１の実施形態の情報処理システムのＦＲＵテーブルに保持されている情報を示す図である。

【図4】本発明の第１の実施形態の情報処理システムの動作を表した流れ図である。

【図5】保守作業の流れを表した図である。

【図6】論理パーティションによる複数のシステムが運用されているサーバの例である。

【図7】論理パーティションの構成例を示す図である。

【図8】図７の構成における障害発生時の影響範囲を示す図である。

【図9】本発明の第１の実施形態の情報処理システムの状態表示ランプ（エラー／メンテナンス状態）の点灯制御を行う回路構成を示す図である。搭載可能なメンテナンス報告手段および障害報告手段の一例を示す図である。

【図10】図７の構成におけるエラー閾値変更処理を説明するための図である。

【図11】エラー検出時の判定フローを表した流れ図である。

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

【0015】

はじめに本発明の一実施形態の概要について図面を参照して説明する。なお、この概要に付記した図面参照符号は、理解を助けるための一例として各要素に便宜上付記したものであり、本発明を図示の態様に限定することを意図するものではない。

【0016】

本発明は、図１に示すように、その一実施形態において、障害要因解析部１１０と、保守レベル算出部１２０と、前記保守レベルを含んだ保守作業の指示情報を出力する表示部１３０とを備える構成にて実現できる。

【0017】

より具体的には、障害要因解析部１１０は、管理対象のシステムに含まれる置換可能な部位のうちの障害要因部位を特定するための情報と、該障害要因部位の障害の履歴情報とを格納した情報源１００にアクセスして、管理対象のシステムに含まれる置換可能な部位から発せられるエラーコードから、被疑割合付きの障害要因部位情報と、該障害要因部位の障害の履歴情報とを生成する。

【0018】

そして、前記保守レベル算出部１２０は、障害要因部位と前記障害の履歴情報とに基づいて、保守作業の難易度を示す保守レベルを算出する。例えば、保守レベル算出部１２０は、ある障害要因部位に故障が多発している場合、保守レベルを引き上げる。これにより、相応の高度な訓練や経験を持った保守員による保守や、オンラインではなく、オフラインによる保守作業が行われる。
［第１の実施形態］

【0019】

続いて、本発明の第１の実施形態について図面を参照して詳細に説明する。図２は、本発明の第１の実施形態の構成を表したブロック図である。

【0020】

図２を参照すると、障害情報管理サーバ１２と接続された情報処理システム１１が示されている。情報処理システム１１は、主記憶装置（以下、「ＭＥＭ」）２１と、複数のプロセッサ（以下、「ＰＲＯＣ」）２２と、複数のノードコントローラ（以下、「ＮＣ」）２３と、複数のクロスバスイッチ（以下、「Ｘｂａｒ」）２４と、複数の入出力装置（以下、「ＩＯ」）２５と、サービスプロセッサ（以下、「ＳＶＰ」）２６と、データ収集部４０と、障害要因解析部４１と、保守レベル算出部４２と、コンソール４３と、構成情報解析部４４とを備えている。

【0021】

また、この情報処理システム１１は、情報源として、ＦＲＵ（Ｆｉｅｌｄ Ｒｅｐｌａｃａｂｌｅ Ｕｎｉｔ）テーブル３０と、障害履歴格納部Ａ３１と、障害履歴格納部Ｂ３２と、を備えている。

【0022】

ＭＥＭ２１、ＰＲＯＣ２２、ＮＣ２３、Ｘｂａｒ２４、ＩＯ２５のいずれか１つあるいは複数の箇所で障害が検出された場合、信号線ｅ００１を介してエラーがＳＶＰ２６に報告される。

【0023】

ＳＶＰ２６は、前記エラー報告を受信すると、そのサービスログから、上記ＭＥＭ２１、ＰＲＯＣ２２、ＮＣ２３、Ｘｂａｒ２４、ＩＯ２５の障害情報を採取する。さらに、ＳＶＰ２６は、前記障害情報に含まれるエラーインディケータフラグ（ＥＩＦ）をキーとして、ＦＲＵテーブル３０から障害要因部位（ＮＡＭＥ）やその被疑割合（ＲＡＴＥ）等を抽出し、障害履歴格納部Ａ３１に登録する。

【0024】

ＦＲＵテーブル３０は、エラーコードを示すエラーインディケータフラグ（ＥＩＦ）に対応する障害要因部位（ＮＡＭＥ）やその被疑割合（ＲＡＴＥ）、製造ロット番号やリビジョン番号（ＲＥＶ）、ベンダーＩＤ（ＶＩＤ）等を登録したテーブルである。

【0025】

図３は、ＦＲＵテーブル３０の一例を示す図である。例えば、ＥＩＦが「Ｎ０＿ＥＩＦ＿０」には、ＦＲＵ［０］として、ＮＡＭＥ＝Ｎ０＿ＮＣＣ、ＲＡＴＥ＝１００、ＲＥＶ＝Ａ０００１、ＶＩＤ＝０００という情報が対応付けられている。これは、「Ｎ０＿ＥＩＦ＿０」とのエラーインディケータフラグ（ＥＩＦ）から、障害要因部位として、１００％の割合でＮ０ノードコントローラのカード「Ｎ０＿ＮＣＣ」が特定されることを示している。同様に、「Ｎ０＿ＥＩＦ＿２」とのエラーインディケータフラグ（ＥＩＦ）から、障害要因部位として、Ｎ０ノードコントローラのポート０「Ｎ０＿Ｐ０」、Ｎ１ノードコントローラのポート０「Ｎ１＿Ｐ０」、ケーブルＡ（ＣＡＢＬＥ＿Ａ）が特定される。また、それぞれ被疑割合は、４９％、５０％、１％という情報が得られる。

【0026】

また、図３のＦＲＵテーブルは、ＥＩＦ毎に、エラー回数（Ｅｒｒｏｒ Ｃｏｕｎｔ）と、メンテナンス状態フラグ（ＭＮ１）とを保持可能となっている。これらの情報は、ＳＶＰ２６から適宜更新される。

【0027】

障害履歴格納部Ａ３１は、情報処理システム１１で検出された障害の履歴情報を格納する。また、これらの障害の履歴情報に、製造ロットやベンダＩＤ等を含ませることで、障害発生頻度から、設計マージンに余裕のない機能や製造ロットにより障害発生頻度の多い部品の分析が可能となる。障害履歴格納部Ａ３１には、ＥＩＦ毎に、エラー回数フィールドを管理するテーブルが備えられており、各ＥＩＦのエラー発生回数を把握できるようになっている。

【0028】

障害履歴格納部Ｂ３２は、信号線ｎ００１を介して障害情報サーバ１２から提供された他の情報処理システムで検出された障害の履歴情報を格納する。また、障害履歴格納部Ｂ３２も、ＥＩＦ毎に、エラー回数フィールドを管理するテーブルが備えられており、各ＥＩＦのエラー発生回数を把握できるようになっている。

【0029】

データ収集部４０は、ＳＶＰ２６によるＦＲＵテーブル３０、障害履歴格納部Ａ３１の更新が完了すると、ＦＲＵテーブル３０、障害履歴格納部Ａ３１及び障害履歴格納部Ｂ３２のデータを収集し、障害要因解析部４１及び構成情報解析部４４に出力する。

【0030】

障害要因解析部４１は、データ収集部４０から出力されたデータに基づいて、報告されたエラーが過去の障害履歴、他の情報処理システムの障害履歴、製造ロット等を分析し、被疑割合付きの障害要因部位情報と、該障害要因部位の障害の履歴情報とを生成する。また、障害要因解析部４１が、必要に応じて外部サーバ等に対し、障害要因部位として特定された部位の情報等を問い合わせるようにしてもよい。

【0031】

保守レベル算出部４２は、障害要因解析部４１から出力された被疑割合付きの障害要因部位情報と、該障害要因部位の障害の履歴情報と、信号線ｎ００２を介して得られる保守情報とに基づいて、保守の難易度を算出し、被疑割合付きの障害要因部位情報とともに保守の難易度情報（保守レベル）を含んだ保守作業の指示情報を出力する。例えば、保守支援情報に、保守時のミス（手順ミス）による障害や保守による故障（過剰な押し込み、引き込みなどにより発生したもの）の回数が含まれている場合、保守レベル算出部４２は、この保守時のミスによる故障回数情報が多い部位の保守レベルを保守レベル高（難易度大）と算出する。前記保守レベルの算出は、例えば、予め定めた数式により、障害要因部位や、故障の回数、そのうちの保守時のミスによる回数等を評点に換算し、予め定めたレベル毎の閾値と、この評点と比較することにより求めることができる。なお、閾値は部品のＦＩＴ（Ｆａｉｌｕｒｅ Ｉｎ Ｔｉｍｅ）値等から障害要因部位毎に決めておくことが好ましい。

【0032】

コンソール４３は、保守レベル算出部４２から出力された、被疑割合付きの障害要因部位情報および保守の難易度情報（保守レベル）を含んだ保守作業の指示情報を出力する。

【0033】

構成情報解析部４４は、データ収集部４０から出力されたデータに基づいて、運用形態から構成情報を分析してＳＶＰ２６に伝達する。この分析結果には、例えば、障害要因部位の保守操作（カバーの脱着、ケーブルの移動／脱着、モジュール交換）に伴う副次的な影響による運用可否情報が含まれる。前記分析の結果、運用可能と判断された場合、ＳＶＰ２６は、ＭＥＭ２１、ＰＲＯＣ２２、ＮＣ２３、Ｘｂａｒ２４、ＩＯ２５をメンテナンスモードに移行させるとともに、メンテナンスモード中のエラーカウント等の変更を実施する。

【0034】

障害情報管理サーバ１２は、信号線ｎ００３、ｎ００４を介して、情報処理システム１１を含む他の情報処理システムと接続され、障害情報を収集するサーバである。より具体的には、障害情報管理サーバ１２は、前記収集した障害情報を蓄積する障害情報データベース（障害情報ＤＢ）３５と、保守支援情報として情報処理システム１１を含む他の情報処理システムにて行われた保守作業の情報を格納する保守情報データベース（保守情報ＤＢ）３６とを備えている。障害情報ＤＢ３５に格納された情報は、所定のタイミングで、信号線ｎ００１を介して、情報処理システム１１の障害履歴格納部Ｂ３２に転送される。

【0035】

なお、図２に示した情報処理システム１１のデータ収集部４０、障害要因解析部４１と、保守レベル算出部４２とおよび構成情報解析部４４はそれぞれ、情報処理システム１１に搭載されたコンピュータに、そのハードウェアを用いて、上記した各処理を実行させるコンピュータプログラムにより実現することもできる。

【0036】

続いて、本実施形態の動作について図面を参照して詳細に説明する。情報処理システム１１においては、以下の障害が発生しうる。
・ＭＥＭ２１−ＰＲＯＣ２２間
・ＰＲＯＣ２２−ＮＣ２３間
・ＮＣ２３−Ｘｂａｒ２４間
・Ｘｂａｒ２４−ＩＯ２５間
・ＳＶＰ２６−ＭＥＭ２１、ＰＲＯＣ２２、ＮＣ２３、Ｘｂａｒ２４、ＩＯ２５間
・ＭＥＭ２１、ＰＲＯＣ２２、ＮＣ２３、Ｘｂａｒ２４、ＩＯ２５、ＳＶＰ２６の単体障害
以下の説明では、情報処理システム１１の複数のノード間を接続しているＸｂａｒ２４とＩＯ２５間で障害を発生した場合の動作を説明する。

【0037】

図４は、本発明の第１の実施形態の情報処理システムにおいて、Ｘｂａｒ２４またはＩＯ２５のいずれかにおいてエラーが検出された際の動作を表した流れ図である。図４を参照すると、まず、Ｘｂａｒ２４−ＩＯ２５間の障害により、Ｘｂａｒ２４またはＩＯ２５のいずれかにおいてエラーが検出されると（ステップＳ００１）、ＳＶＰ２６へのエラー報告が行われる（ステップＳ００２）。

【0038】

前記エラー報告を受けたＳＶＰ２６は、そのサービスログ（ＳＶＰログ）から、上記Ｘｂａｒ２４、ＩＯ２５の障害情報を採取する（ステップＳ００３）。

【0039】

次に、ＳＶＰ２６は、前記採取した障害情報に含まれるエラーインディケータ（ＥＩＦ）をキーとしてＦＲＵテーブル３０から該当するデータを検索する（ステップＳ００４）。次に、ＳＶＰ２６は、前記ＦＲＵテーブル３０から検索したデータを障害履歴格納部Ａ３１に格納するとともに、データ収集部４０を起動する。ここで、ＳＶＰ２６は、前記ＦＲＵテーブル３０の該当するエントリのエラー回数フィールドの値を１加算する。

【0040】

データ収集部４０は、まず、ステップＳ００４での登録より前に、ステップＳ００３で特定されたエラーインディケータ（ＥＩＦ）に対応するデータが障害履歴格納部Ａ３１に登録されていたか否かを確認する（ステップＳ００５）。

【0041】

ここで、ステップＳ００３で特定されたエラーインディケータ（ＥＩＦ）に対応するデータが障害履歴格納部Ａ３１に登録されていた場合（ステップＳ００５のＹｅｓ）、データ収集部４０は、ステップＳ００３で特定されたエラーインディケータ（ＥＩＦ）に対応するデータが障害履歴格納部Ｂ３２に登録されていたか否かを確認する（ステップＳ００６−１）。

【0042】

また、ステップＳ００３で特定されたエラーインディケータ（ＥＩＦ）に対応するデータが障害履歴格納部Ａ３１に登録されていない場合も（ステップＳ００５のＮｏ）、同様に、データ収集部４０は、ステップＳ００３で特定されたエラーインディケータ（ＥＩＦ）に対応するデータが障害履歴格納部Ｂ３２に登録されていたか否かを確認する（ステップＳ００６−２）。

【0043】

上記ステップＳ００５、Ｓ００６−１、Ｓ００６−２の結果に応じて、ステップＳ００７〜Ｓ０１０のいずれかの処理が行われる。また、障害履歴格納部Ａ３１、障害履歴格納部Ｂ３２のいずれかまたは双方に、同一の障害履歴が存在していた場合、データ収集部４０は、それぞれのエラー回数フィールドを管理するテーブルのエラー発生回数フィールドの値を１加算する。

【0044】

まず、障害履歴格納部Ａ３１、障害履歴格納部Ｂ３２の双方に、同一の障害履歴が存在していた場合（ステップＳ００５、Ｓ００６−１が共にＹｅｓ）、データ収集部４０は、これら双方の障害履歴を障害要因解析部４１に出力する。障害要因解析部４１は、前記双方の障害履歴情報について、製造ロット、ベンダーＩＤ等の条件を比較分析し、障害要因部位および障害要因部位の被疑割合の補正の必要性を判定する（ステップＳ００７）。

【0045】

一方、障害履歴格納部Ａ３１に、同一の障害履歴が存在しているが、障害履歴格納部Ｂ３２に、同一の障害履歴が存在していない場合（ステップＳ００５がＹｅｓ、Ｓ００６−１がＮｏ）、データ収集部４０は、障害履歴格納部Ａ３１の障害履歴を障害要因解析部４１に出力する。障害要因解析部４１は、障害履歴格納部Ａ３１の障害履歴情報について、製造ロット、ベンダーＩＤ等の条件を比較分析し、障害要因部位および障害要因部位の被疑割合の補正の必要性を判定する（ステップＳ００８）。

【0046】

一方、障害履歴格納部Ａ３１に、同一の障害履歴が存在していないが、障害履歴格納部Ｂ３２に、同一の障害履歴が存在している場合（ステップＳ００５がＮｏ、Ｓ００６−２がＹｅｓ）、データ収集部４０は、障害履歴格納部Ｂ３２の障害履歴を障害要因解析部４１に出力する。障害要因解析部４１は、障害履歴格納部Ｂ３２の障害履歴情報について、製造ロット、ベンダーＩＤ等の条件を比較分析し、障害要因部位および障害要因部位の被疑割合の補正の必要性を判定する（ステップＳ００９）。

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

１１ 情報処理システム
１１Ａ、１１Ｂ 装置
１２ 障害情報管理サーバ
２１ 主記憶装置（ＭＥＭ）
２２ プロセッサ（ＰＲＯＣ）
２３ ノードコントローラ（ＮＣ）
２４ クロスバスイッチ（Ｘｂａｒ）
２５ 入出力装置（ＩＯ）
２６ サービスプロセッサ（ＳＶＰ）
３０ ＦＲＵ（Ｆｉｅｌｄ Ｒｅｐｌａｃａｂｌｅ Ｕｎｉｔ）テーブル
３１ 障害履歴格納部Ａ
３２ 障害履歴格納部Ｂ
３５ 障害情報データベース（障害情報ＤＢ）
３６ 保守情報データベース（保守情報ＤＢ）
４０ データ収集部
４１ 障害要因解析部
４２ 保守レベル算出部
４３ コンソール
４４ 構成情報解析部
４６ ＥＦ制御部
４７ メンテナンス状態表示ランプ（ＭＦ表示）
４８ エラー状態表示ランプ（ＥＦ表示）
１００ 情報源
１１０ 障害要因解析部
１２０ 保守レベル算出部
１３０ 表示部
ｅ００１、ｎ００１、ｎ００２、ｎ００３、ｎ００４ 信号線

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】