特許 6132740 復旧計画データ作成プログラム及び復旧計画データ作成方法

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

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

(11)【特許番号】6132740

(24)【登録日】2017年4月28日

(45)【発行日】2017年5月24日

(54)【発明の名称】復旧計画データ作成プログラム及び復旧計画データ作成方法

(51)【国際特許分類】

   G06Q 10/00 20120101AFI20170515BHJP

【ＦＩ】

   G06Q10/00 300

【請求項の数】3

【全頁数】16

(21)【出願番号】特願2013-218760(P2013-218760)

(22)【出願日】2013年10月21日

(65)【公開番号】特開2015-82153(P2015-82153A)

(43)【公開日】2015年4月27日

【審査請求日】2016年4月20日

【早期審査対象出願】

(73)【特許権者】

【識別番号】513265253

【氏名又は名称】株式会社ヒルベット・ソリューション

(74)【代理人】

【識別番号】100121658

【弁理士】

【氏名又は名称】高橋 昌義

(72)【発明者】

【氏名】小山 隆

【審査官】 宮地 匡人

(56)【参考文献】

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

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

【文献】 米国特許出願公開第２０１１／００８８０３４（ＵＳ，Ａ１）

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

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

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

【請求項1】

コンピュータにより、
複数のリソースデータ、並びに、前記複数のリソースデータにそれぞれ付随して記録される依存関係データ及び復旧時間データを用いて、リソースデータそれぞれに稼働停止時間データを計算処理して求める復旧計画データ作成方法であって、
それぞれの前記依存関係データは、付随する前記リソースデータの依存先又は依存元の前記リソースデータのリソース名データと、それが強依存であるか又は弱依存であるかの情報を含む強弱データと、を含み、
前記稼働停止時間データは、
計算処理対象となる前記リソースデータが依存先に対し強依存である場合、又は、弱依存であって計算処理対象となる前記リソースデータの前記復旧時間が０でない場合、計算処理対象となる前記リソースデータの前記復旧時間と依存先の前記リソースデータの前記復旧時間データ又はすでに計算処理された前記依存先の前記リソースデータの稼働停止時間データに基づく所定の計算処理により求められ、
計算処理対象となる前記リソースデータが依存先に対し弱依存であって計算処理対象となる前記リソースデータの前記復旧時間が０である場合は、計算処理対象となる前記リソースデータの前記復旧時間には依存先の前記リソースデータの前記復旧時間データ又はすでに計算処理された前記依存先の前記リソースデータの稼働停止時間データを加えない計算処理により求められる、
復旧計画データ作成方法。

【請求項2】

それぞれの前記依存関係データは、依存先に直列的に依存するか並列的に依存するかの情報を含む直並列関係データを含み、
前記稼働停止時間データは、
計算対象となる前記リソースデータが依存先に対し直列関係かつ強依存である場合、又は、直列関係かつ弱依存であって計算処理対象となる前記リソースデータの前記復旧時間が０でない場合、計算処理対象となる前記リソースデータの前記復旧時間と依存先の前記リソースデータの前記復旧時間データ又はすでに計算処理された前記依存先の前記リソースデータの稼働停止時間データを足し合わせる計算処理により求められ、
計算対象となる前記リソースデータが依存先に対し並列関係かつ強依存である場合、又は、弱依存であって計算処理対象となる前記リソースデータの前記復旧時間が０でない場合、計算処理対象となる前記リソースデータの前記復旧時間と依存先の前記リソースデータの前記復旧時間データ又はすでに計算処理された前記依存先の前記リソースデータの稼働停止時間データのうちの最大値として求められる、
請求項１記載の復旧計画データ作成方法。

【請求項3】

それぞれの前記依存関係データは、グループデータを含み、
前記稼働停止時間データは、
計算処理対象となる前記リソースデータの依存先の前記リソースデータにおいて、同じグループデータを有する前記依存関係データが付随された前記リソースデータがある場合、前記同じグループデータを有する前記依存関係データが付随された前記リソースデータのうちの最小の前記復旧時間データ又はすでに計算処理された前記依存先の前記リソースデータの稼働時間データをグループ復旧時間データとして採用する処理を行った後、
計算処理対象となる前記リソースデータが依存先の前記グループデータに対し強依存である場合、又は、弱依存であって計算処理対象となる前記リソースデータの前記復旧時間が０でない場合、計算処理対象となる前記リソースデータの前記復旧時間と前記グループ復旧時間データに基づく所定の計算処理により求められ、
計算処理対象となる前記リソースデータが依存先の前記グループデータに対し弱依存である場合、計算処理対象となる前記リソースデータの前記復旧時間に前記グループ復旧時間データを加えない計算処理により求められる、
請求項１記載の復旧計画データ作成方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、復旧計画データ作成プログラム及び復旧計画データ作成方法に関し、より具体的には、何らかの要因により事業における業務が停止した場合における業務の復旧をシミュレートする技術に好適なものである。

【背景技術】

【0002】

事業を行う際において、その事業における業務の一部又は全部が停止した場合にその業務の停止が事業に与える影響を予め分析しておくことは事業を継続していくためには非常に重要な作業であり、近年、事業継続計画（Ｂｕｚｉｎｅｓｓ Ｃｏｎｔｉｎｕｉｔｙ Ｐｌａｎ、以下「ＢＣＰ」という。）として広く知られてきている。

【0003】

ところで、ＢＣＰは非常に複雑な要素を含み、それらの相互関係を手作業で計画することは非常に煩雑であるため、コンピュータ等の情報処理装置を用いてＢＣＰを立案する技術が提案されつつある。

【0004】

上記ＢＣＰ立案に関する技術として、例えば、下記特許文献１に記載の技術がある。下記特許文献１では、障害発生から復旧までの状態遷移の過程を業務の遂行に用いられるリソースごとに示すとともに依存先リソースが定義されている依存先定義リソースの状態遷移の遷移条件を依存先リソースの状態に関連付けて定義する状態遷移データを用い、状態情報シミュレーション演算部が、依存先定義リソースについては依存先リソースの状態に基づいて状態遷移の有無を判断しながらリソースごとに障害発生から復旧までの時間経過に伴う状態遷移を演算し、実際に障害が発生した際の復旧過程に近い形で時間経過に伴う各リソース及び業務の復旧状況をシミュレートする技術が開示されている。

【先行技術文献】

【特許文献】

【0005】

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

【発明の概要】

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

【0006】

しかしながら、上記特許文献１に記載の技術では、復旧計画をする際、一度依存関係を設定してしまうとその稼働状況に関わらず常時依存先の復旧時間データを算入せざるを得ないといった課題があり、実際に業務が停止した場合により近づけるためにはまだ課題が残る。

【0007】

そこで、本発明は、上記課題に鑑み、より実際に業務が停止した場合の復旧状況に近くなる復旧計画を作成することのできる復旧計画データ作成プログラム及び復旧計画データ作成方法を提供することを目的とする。

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

【0008】

本発明者は、上記課題につき検討を行っていたところ、依存関係が存在している場合であっても、その依存元の稼働状況に基づき処理を異ならせる関係を考慮することで上記課題を解決することができることを発見し、本発明を完成させるに至った。

【0009】

すなわち、上記課題を解決する本発明の一の観点にかかる復旧計画データ作成プログラムは、コンピュータに、リソースデータを複数記録する手段、複数のリソースデータ間の依存関係データを作成する手段、復旧時間データを記録する手段、復旧時間データ、依存関係データ、リソースデータに基づき稼動停止時間データを作成する手段、として機能させるものであって、依存関係データは、依存元の前記リソースデータの稼働状況に基づき処理を異ならせるための強弱データを含むことを特徴とする。

【0010】

また、本発明の他の一観点にかかる復旧計画データ作成方法は、リソースデータを複数記録し、複数のリソースデータ間の依存関係データを作成し、復旧時間データを記録し、復旧時間データ、依存元のリソースデータの稼働状況に基づき処理を異ならせるための強弱データを含む依存関係データ、リソースデータに基づき稼動停止時間データを作成することを特徴とする。

【発明の効果】

【0011】

以上、本発明によって、より実際に業務が停止した場合の復旧状況に近くなる復旧計画を作成することのできる復旧計画データ作成プログラム及び復旧計画データ作成方法を提供することができる。

【図面の簡単な説明】

【0012】

【図1】実施形態に係る復旧計画データ作成方法の処理の流れを示す図である。

【図2】実施形態に係るネットワークサーバーシステムの構成の概略を示す図である。

【図3】実施形態に係るネットワークサーバーシステムにおけるリソース間の依存関係を示す図である。

【図4】実施形態に係るネットワークサーバーシステムにおける強弱データのうち、弱データが付される関係にあるリソースを示す図である。

【図5】実施形態に係るネットワークサーバーシステムにおいて弱関係にある場合の復旧時間及び稼動停止時間の計算のイメージを示す図である。

【図6】実施形態に係るネットワークサーバーシステムにおいて直列関係にあるリソースの例の関係図である。

【図7】実施形態に係るネットワークサーバーシステムの復旧時間及び稼動停止時間の計算のイメージ図である。

【図8】実施形態に係るネットワークサーバーシステムの復旧時間及び稼動停止時間の計算のイメージ図である。

【図9】実施形態に係るネットワークサーバーシステムのリソース毎の復旧時間のイメージ図である。

【図10】図９におけるリソース毎の復旧時間のイメージ図に基づく稼動停止時間のイメージ図である。

【図11】実施形態に係る製品製造ラインシステムの概略を示す図である。

【図12】実施形態に係るネットワークサーバーシステムにおける依存の関係を示す図である。

【図13】実施形態における復旧時間のイメージを示す図である。なお、本図は実際に災害等の要因によってシステムが停止した状況をイメージしている。

【図14】図１３における、結果計算される稼動停止時間のイメージを示す図である。

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

【0013】

以下、本発明に係る復旧計画データ作成プログラム及び復旧計画データ作成方法について、図面を用いて詳細に説明する。ただし、本発明は多くの異なる形態による実施が可能であり、以下に示す実施形態において示す具体的な例示的記述にのみ限定されるわけではない。

【0014】

（ネットワークサーバーシステム）
図１は、本実施形態に係る復旧計画データ作成方法（以下「本方法」という。）の処理の流れを示す図である。本図で示すとおり、本方法は、（１）リソースデータを複数記録し（Ｓ１）、（２）複数のリソースデータ間の依存関係データを作成し（Ｓ２）、（３）復旧時間データを記録し（Ｓ３）、（４）復旧時間データ、依存元の前記リソースデータの稼働状況に基づき処理を異ならせるための強弱データを含む依存関係データ、リソースデータに基づき稼動停止時間データを作成する（Ｓ４）。

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

以上、本実施形態によっても、より実際に業務が停止した場合の復旧状況に近くなる復旧計画を作成することのできる復旧計画データ作成プログラム及び復旧計画データ作成方法を提供することができる。

【産業上の利用可能性】

【0075】

本発明は、復旧計画データ作成プログラム及び復旧計画データ作成方法として産業上の利用可能性がある。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】