JP2014146212A - Ｂｃｐ実施支援システムおよびｂｃｐ実施支援プログラム - Google Patents

Abstract

【課題】ＢＣＰの発動の要否を判断する際に、判断主体からの指示を得ることができない状況であっても、実施主体が自立的に発動の要否を判断可能とする。
【解決手段】障害事象の発生を検知する障害監視部３１と、障害事象を検知した場合に所定の連絡先に連絡を行い、その応答に係る情報を取得する連絡処理部３２と、障害事象、連絡先からの応答の内容、および事業継続計画の発動の判断に係る状態を含む情報に基づいて、ルールに従って連絡先に連絡を行い、もしくは事業継続計画の発動の要否を判断するルール処理部３３と、状態の遷移を管理する状態管理部３４とを有し、連絡先には少なくとも顧客４０および情報処理基盤を運用する運用者を含み、ルール処理部３３は、顧客４０に対する連絡により事業継続計画の発動に係る指示を受けた場合にはその指示に従い、連絡が不能な場合であっても運用者からの応答内容に基づいて事業継続計画の発動の要否を判定する。
【選択図】図１

Description

本発明は、ＢＣＰ（Business Continuity Plan：事業継続計画）の実施を支援する技術に関し、特に、災害や事故などの予期せぬ危機事象が発生した場合にＢＣＰの発動要否に係る意思決定を支援するＢＣＰ実施支援システムおよびＢＣＰ実施支援プログラムに適用して有効な技術に関するものである。

企業では、災害や事故などの予期せぬ危機事象の発生に対して、被害を最小限に抑え、事業を継続的に実施できるようにするとともに、被害の早期の復旧を図ることを可能とするリスクマネジメントの一環としてＢＣＰを策定しておくことが推奨されている。ＢＣＰの中には、例えば、情報処理システムやインフラによるサービス提供を維持するために、稼動系のデータセンターや情報処理システムなどのＩＴインフラに対していわゆる災対センターや災対システムを予め準備しておき、災害等による障害の発生時に運用を切り替える仕組みを構築してマニュアル化しておくことが含まれる場合も多い。

災害等による障害発生時に、データセンターや情報処理システム（以下ではこれらを総称して“データセンター”と記載する場合がある）の運用を災対センターに切り替える際の技術としては様々なものが提案されており、システムの規模や内容等に応じて種々の技術が利用可能となっている。

例えば、特開２０１０−２６２５００号公報（特許文献１）には、端末からの電文を受け付ける中間サーバと、中間サーバにより振り分けられた電文を何れか一方で処理する現用センターシステム及び待機センターシステムとを有し、電文の振り分け先を現用センターシステムから待機センターシステムに切り替えるとき、ＤＢの内容を事前同期させる手段と、事前同期後、端末からの電文の受け付けを継続しつつ、電文の振り分けを保留する手段と、ＤＢの内容を最終同期させる手段と、最終同期後、電文の振り分け先を待機センターシステムに切り替え、電文の振り分けを再開させる手段とを有するシステムが記載されている。

一方、災対センターに運用を切り替えることは、多大な作業負荷やリスク、制約等を有するため、実施要否の判断には慎重を要すると考えられる。一般的には、稼動系のデータセンターにおける稼働状況を確認した上で、当該センターの運営やシステム設計・開発・管理を行なうＩＴベンダーや、当該センターを利用して業務サービスを提供する顧客企業の担当者等が協議することにより切替の要否を判断・決定するという意思決定プロセスがとられる場合が多い。

危機管理時における意思決定の支援に係る技術としては、例えば、特開２００４−１１０４６９号公報（特許文献２）には、関与対象の事象が予め定めた複数の評価軸上でいかなる評価値に対応するかを評価する手段と、複数の評価軸上で評価した関与対象事象の各評価値のいずれかが許容範囲を外れているか否かを判定する手段と、複数の評価軸上での各評価値のいずれかが許容範囲を外れていた場合、重要評価軸を選択し、重要評価軸に対応して定めた方策を抽出する手段と、抽出した方策のうち任意数の方策を選択し、その選択された方策を実施した場合に関与対象事象の重要評価軸上での評価値の変化を推論モデルにより方策別に推論する手段と、推論結果に基づき関与対象事象を許容範囲の状態に矯正する最適な方策を選択する手段とを備えることで、組織または個人の関与対象となる事象が発生した場合に、いかなる方策をとるべきかの意思決定を支援する意思決定支援シミュレーションシステムに係る技術が記載されている。

特開２０１０−２６２５００号公報 特開２００４−１１０４６９号公報

災害等の発生時に、データセンターの運用を稼動系から待機系である災対センターに切り替えるか否かを判断するにあたっては、例えば、上記の特許文献２に記載されたような技術を利用することで、各種の事象を入力としたシミュレーションの結果に基づいて切替の要否を判断することも可能である。また、判断の結果として切替を行うことになった場合には、例えば、特許文献１に記載されたような技術を利用することで影響を最小限にしつつ切り替えることが可能である。

しかしながら、データセンターで稼働する情報処理システムによって業務サービス等を提供する企業は、情報処理システムやインフラの運用管理をデータセンター（もしくはデータセンターを運営するＩＴベンダー）に委託して行うのが一般的である。この場合、データセンターの運用者の観点からは、上述したように、災対センターへの切替にあたっては、例えば、ＩＴベンダーの担当者が顧客の担当者と協議して切替要否の判断を行ったうえでデータセンターに指示するなど、可能な限り、一次的な判断主体（ＢＣＰの策定主体）である顧客や、ＩＴベンダーの担当者等の判断・指示に従う運用とするのが望ましい。

ここで、例えば大規模な災害等が発生したような場合には、通信インフラが利用不能となったり、人的被害が発生したりなど、そもそも、顧客とＩＴベンダーや、データセンターとの間で連絡をとること自体ができなくなる場合がある。このような場合には、例えば、顧客とＩＴベンダーとの協議の上で切替要否の判断を行い、データセンターに切替の指示を行うというようなプロセスでは実施が困難となり、円滑な切替が行えず、最悪の場合は事業やサービスの継続が途絶するという事態にもなりかねない。

そこで本発明の目的は、稼動系のデータセンターの災対センターへの切替など、ＢＣＰに策定された内容の発動の要否を判断する際に、顧客やＩＴベンダー等の本来の判断主体からの指示や判断を得ることができない状況であっても、災対センターなどの実施主体が自立的に円滑に発動の要否を判断することを可能とするＢＣＰ実施支援システムおよびＢＣＰ実施支援プログラムを提供することにある。

本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。

本発明の代表的な実施の形態によるＢＣＰ実施支援システムは、危機事象が発生した際の、顧客の情報処理基盤に係る事業継続計画の発動の要否についての判断を支援するシステムであって、前記情報処理基盤における障害事象の発生を検知する障害監視部と、前記障害監視部により障害事象を検知した場合に、所定の連絡先に連絡を行い、その応答に係る情報を取得する連絡処理部と、前記障害監視部により検知した障害事象、前記連絡処理部により取得した連絡先からの応答の内容、および前記事業継続計画の発動の判断に係る状態を含む情報に基づいて、ルール保持部に予め定義されたルールのうち対応するものに従って、当該ルールにより指定された連絡先に前記連絡処理部を介して連絡を行い、もしくは前記事業継続計画の発動の要否を判断するルール処理部と、前記ルール処理部によって抽出された前記ルールに従って、前記状態の遷移を状態保持部に記録して管理する状態管理部と、を有する。

また、前記ルール保持部に定義されたルールにおいては、前記障害事象を検知した場合に前記連絡処理部により連絡を行う所定の連絡先には、少なくとも前記顧客および前記情報処理基盤を運用する運用者を含み、前記ルール処理部は、前記障害事象を検知した場合に、前記連絡処理部による前記顧客に対する連絡により、前記顧客から前記事業継続計画の発動に係る指示の情報を受けた場合にはその指示に従い、前記顧客との連絡が不能な場合であっても、前記運用者からの応答内容に基づいて把握される前記情報処理基盤の状況が所定の条件を満たすか否かによって、前記事業継続計画の発動の要否を判定するものである。

また、本発明は、コンピュータを上記のようなＢＣＰ実施支援システムとして動作させるプログラムにも適用することができる。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。

すなわち、本発明の代表的な実施の形態によれば、稼動系のデータセンターの災対センターへの切替など、ＢＣＰに策定された内容の発動の要否を判断する際に、顧客やＩＴベンダー等の本来の判断主体からの指示や判断を得ることができない状況であっても、災対センターなどの実施主体が自立的に円滑に発動の要否を判断することが可能となる。

本発明の一実施の形態であるＢＣＰ実施支援システムの構成例について概要を示した図である。 本発明の一実施の形態におけるＢＣＰの発動判断に係る状態遷移図の例について概要を示した図である。 本発明の一実施の形態におけるＢＣＰ実施支援システムのルールＴＢに定義されるルールの具体的な例について概要を示した図である。 本発明の一実施の形態における稼動系ＤＣでのルールの具体的な例について概要を示した図である。 本発明の一実施の形態におけるＩＴベンダーでのルールの具体的な例について概要を示した図である。 本発明の一実施の形態における顧客でのルールの具体的な例について概要を示した図である。 本発明の一実施の形態における顧客の遠隔拠点でのルールの具体的な例について概要を示した図である。 従来技術における待機系データセンターへの切替手順の処理の流れの例について概要を示したフローチャートである。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。また、以下においては、本発明の特徴を分かり易くするために、従来の技術と比較して説明する。

上述したように、企業におけるＢＣＰの実施内容の一つとして、データセンターが災害等により障害となった場合に稼動系から災対センター（待機系）に運用を切り替えるか否かの判断を行う際、従来は、切替作業の実施主体である待機系データセンターにおいて、本来の判断主体である顧客や、ＩＴベンダーの担当者からの指示や判断を得て、その指示内容に従って切替作業を行うという手順をとるのが一般的であった。

図８は、従来の待機系データセンターへの切替手順の処理の流れの例について概要を示したフローチャートである。例えば、関東地域に稼動系データセンターがあり、関西地域に災対用の待機系データセンターが準備されているとした場合に、待機系データセンターでは、常時、稼動系データセンターの障害の有無を監視している（Ｓ０１）。例えば、稼動系データセンター側のルータの生死状況を定期的に監視し、所定の期間以上応答がない場合に障害として検知する（Ｓ０２）。

待機系データセンターは、障害を検知した場合に、顧客やＩＴベンダーの予め定められた担当者に対して、稼動系データセンターで障害が発生した旨を電話や電子メールなどの予め定められた手段により連絡し（Ｓ０３）、連絡状況を判定する（Ｓ０４）。連絡ができた場合、連絡を受けた顧客やＩＴベンダーの担当者は、稼動系データセンターに対して連絡する等の所定の手順により、稼動系データセンターの状況を確認し（Ｓ０５）、切替要否の判断を行う（Ｓ０６）。切替必要と判断した場合は、待機系データセンターに対して稼動系からの切替の実施を指示し（Ｓ０７）、切替不要と判断した場合は、待機系データセンターに対して切替しない旨を指示する（Ｓ０８）（すなわち、稼動系データセンターで障害復旧作業を行ってサービスを継続する）。

ステップＳ０４で、待機系データセンターから顧客やＩＴベンダーの担当者のいずれにも連絡がとれなかった場合、従来では、待機系データセンターにおいて切替実施の判断ができないことから、上述のように切替しないものとしていた（Ｓ０８）。大規模な災害等が発生したような場合には、通信インフラが利用不能となったり、人的被害が発生したりなどにより、顧客やＩＴベンダーの担当者と連絡をとること自体ができなかったり、切替要否の判断主体となるべき担当者が判断不能となったり、稼動系データセンターの状況が確認できなかったりという状況が生じ得る。このような場合に従来のように切替しない（できない）ものとすると、稼動系データセンターの状況によっては、最悪の場合は事業やサービスの継続が途絶するという事態にもなり得る。

そこで、本発明の一実施の形態であるＢＣＰ実施支援システムは、待機系データセンターにおいて稼動系データセンターでの障害を検知し、ＢＣＰの実施としての切替の要否を判断する必要が生じた際に、顧客やＩＴベンダー（すなわちＢＣＰの実施対象システムの設計者）の担当者等の本来の判断主体との連絡がとれず、指示や判断を得ることができない状況であっても、予め、顧客企業とＩＴベンダー、およびデータセンターの間で合意された所定のルールに基づいて、切替の実施主体である待機系データセンターが自立的に切替要否の判断を行うことを可能とするものである。これにより、災害等の発生時にＢＣＰに策定された内容を円滑かつ迅速に実施し、顧客の業務サービスへの影響を最小化することが可能となる。

＜システム構成＞
図１は、本発明の一実施の形態であるＢＣＰ実施支援システムの構成例について概要を示した図である。インターネット等のネットワーク６０を介して利用者に顧客４０に係る業務サービスを提供する稼動系データセンター（ＤＣ）１０と待機系データセンター（ＤＣ）２０からなる災対システム構成に対して、待機系ＤＣ２０側にＢＣＰ実施支援システム３０が接続される構成を有する。稼動系ＤＣ１０と待機系ＤＣ２０との間は専用線やＶＰＮ（Virtual Private Network）などにより相互に接続されており、公知の技術を利用して稼動系ＤＣ１０から待機系ＤＣ２０に対してデータ等のバックアップや同期がとられるとともに、切替が可能なように構成されている。

顧客４０の担当者や、データセンターの運営を行うＩＴベンダー５０の担当者（システムエンジニアなど）は、ＰＣ（Personal Computer）等の情報処理端末を利用して、ネットワーク６０等を介してＢＣＰ実施支援システム３０から発信された電子メールを受信することが可能である。また、顧客４０やＩＴベンダー５０の担当者は、各自が電話（外線／内線電話、携帯電話など）を有しており、待機系ＤＣ２０の運用者から発信された電話や、ＢＣＰ実施支援システム３０から自動発信された電話を受けることができる。

ＢＣＰ実施支援システム３０は、例えば、サーバ機器やクラウドコンピューティング環境の仮想サーバなどのコンピュータシステムからなり、図示しないＯＳ（Operating System）やＤＢＭＳ（DataBase Management System）、Ｗｅｂサーバプログラムなどのミドルウェア上で稼働するソフトウェアプログラムとして実装される、障害監視部３１、連絡処理部３２、ルール処理部３３、状態管理部３４、および状況出力部３５などの各部を有する。また、データベースやファイルテーブルなどにより実装される連絡先テーブル（ＴＢ）３６、ルールテーブル（ＴＢ）３７、状態テーブル（ＴＢ）３８などの各テーブルを有する。

障害監視部３１は、公知の技術により稼動系ＤＣ１０の障害の有無を監視する機能を有する。例えば、稼動系ＤＣ１０側のルータの生死状況を定期的（例えば１０分毎）に監視し、所定の期間（例えば３０分間）以上死状態である場合に障害として検知する。ここでは、災害による障害の可能性がある事象に限って監視するのが望ましい。例えば、ルータ等のネットワーク機器やサーバ機器などは正常に応答するが、その上で稼働する業務アプリケーションが正常に動作していない、というような場合には、災対センターである待機系ＤＣ２０への切替実施の対象外となるよう、障害検知の対象から除外してもよい。なお、このような障害監視機能をＢＣＰ実施支援システム３０が有するのではなく待機系ＤＣ２０が有しており、障害が検知された場合にＢＣＰ実施支援システム３０に対して通知する構成であってもよい。

連絡処理部３２は、障害監視部３１により障害を検知した場合に、後述するルール処理部３３による判定に基づいて、所定の連絡先に障害が発生した旨等を所定の手段で連絡し（もしくは連絡する旨を待機系ＤＣ２０の運用者に指示する）、応答（もしくは応答内容に係る情報）を受領する機能を有する。連絡手段は、電子メールや電話とすることができる。連絡先の情報（電子メールアドレスや電話番号）は、連絡先ＴＢ３６に予め登録しておき、これを参照するものとする。各宛先への連絡の実施と応答の受領状況は、例えば、後述する状態管理部３４により状態ＴＢ３８に記録するものとする。

電子メールによる連絡の場合は、連絡処理部３２がメールサーバの機能を有していてもよいし、メールクライアントの機能を有して、他のメールサーバを介してメールを送信するものであってもよい。顧客４０やＩＴベンダー５０の複数の担当者等の宛先に対して所定の内容を連絡する電子メールを一斉に自動送信し、返信を受信する。返信の内容は、後述するように、ルールに従った所定の内容（例えば、“切替実施”、“切替不要”、“判断不可”などの指示内容や状況報告のキーワード）が含まれるものとし、その内容をテキスト処理等により自動的に判別する。また、例えば、顧客４０とＩＴベンダー５０の各担当者からそれぞれ矛盾する内容の指示を受領した場合等を考慮して、各連絡先からの応答の優先順位を予め設定しておく。例えば、顧客４０＞ＩＴベンダー５０＞稼動系ＤＣ１０の担当者の順で優先順位を設定しておく。返信が一定期間（例えば１時間）以上ない場合は連絡不能と判断する。

電話による連絡の場合は、上述したように、連絡処理部３２がＣＴＩ（Computer Telephony Integration）やＩＶＲ（Interactive Voice Response）などの機能を有して、電話の自動発信や音声自動応答を行なってもよいし、待機系ＤＣ２０の運用者に対して画面を介して電話連絡する旨の指示を行い、電話連絡の結果の入力を受け付けるユーザインタフェースの機能を有していてもよい。電話を発信したがコールに対して一定期間（例えば１分間）以上応答がない場合や、留守番電話に切り替わる場合、「混雑しており、つながりにくい」等のアナウンスが流れた場合は連絡不能と判断する。

ルール処理部３３は、所定の条件が成立したことを検出して、後述する状態管理部３４によって管理されたＢＣＰの発動判断に係る現在の状態／ステータスに応じて、予めルールＴＢ３７に定義しておいたルールに基づいて、連絡処理部３２を介して所定の連絡・通知を行う、もしくはその旨の指示を出力する機能を有する。所定の条件と、これに対応する連絡内容との対応関係を定義したルールＴＢ３７の内容については後述する。なお、連絡先となる稼動系ＤＣ１０や顧客４０、ＩＴベンダー５０には、それぞれ、ＢＣＰ実施支援システム３０から連絡等を受けた場合の担当者等の対応内容を予め定義しておいたルール（ルール１１、４１、５１）を有している。これらのルールは、例えば、マニュアル等の形式で文書や文書データとして保持していてもよい。

状態管理部３４は、ＢＣＰ実施支援システム３０によるＢＣＰの発動判断に係る現在の状態／ステータスの情報を状態ＴＢ３８によって管理する機能を有する。ここでは、ルール処理部３３によって検出された条件の成立の内容に応じて状態を遷移させる。状態遷移の内容については後述する。また、連絡処理部３２によって各宛先に対して行われた連絡・通知に対する応答状況についても状態ＴＢ３８に記録して管理する。

状況出力部３５は、例えば、待機系ＤＣ２０の運用者等に対して、障害に対する対応状況や、連絡状況に係る情報を状態ＴＢ３８等から取得して提示するユーザインタフェースの機能を有する。例えば、図示しないＷｅｂサーバプログラムにより、運用者等が有する情報処理端末上のＷｅｂブラウザに各種状況を画面表示させることができる。

なお、図１の例では、ＢＣＰ実施支援システム３０が待機系ＤＣ２０側に接続された構成としているが、待機系ＤＣ２０からは独立して構築されていてもよい。また、顧客４０やＩＴベンダー５０の担当者の所在は、特に限定されないが、顧客４０の担当者のうち少なくとも一部は、稼動系ＤＣ１０が災害等に遭って大規模障害となるような場合でも、その影響を受けずに顧客４０に係る業務サービス等にアクセスすることが可能な地域に所在するものとする。例えば、上述したように、稼動系ＤＣ１０が関東地域に所在する場合に、顧客４０の担当者の少なくとも一部は、関東地域での災害に影響を受けない関西地域などの遠隔の拠点に所在するものとする。より確実を期すため海外拠点に所在していてもよい。

＜状態管理＞
図２は、ＢＣＰの発動判断に係る状態遷移図の例について概要を示した図である。ここに示す状態遷移は、状態管理部３４により状態ＴＢ３８に記録されて管理される。通常時・正常時は、ＢＣＰの発動判断に係る状態は、障害監視Ｓ１の状態にある。この状態では、上述したように、待機系ＤＣ２０側（ＢＣＰ実施支援システム３０の障害監視部３１もしくは待機系ＤＣ２０）から稼動系ＤＣ１０における災害による障害発生の有無を監視している。

障害監視Ｓ１の状態で障害が検知された場合には、障害連絡Ｓ２の状態に遷移する。この状態では、ルールＴＢ３７に登録されたルールに基づいて、所定の連絡先に障害の発生を電話や電子メールにより連絡して応答を受領し、また、稼動系ＤＣ１０の状況を確認する。

ここで、顧客４０やＩＴベンダー５０の担当者には連絡がつかず、指示を得ることができなかったものの、稼動系ＤＣ１０の状況は確認することができた場合（連絡不能）に、稼動系ＤＣ１０の状況が予め定めた所定の基準や条件に照らして切替不要と判断される場合には、切替なしＳ３の状態に遷移する。ここでは、所定の連絡先に切替を行わない旨の連絡を行うとともに、稼動系ＤＣ１０において障害対応を行う。なお、障害が復旧した場合は障害監視Ｓ１の状態に遷移する。

一方、稼動系ＤＣ１０の状況が切替要と判断される場合には、切替実施Ｓ４の状態に遷移する。ここでは、稼動系ＤＣ１０から待機系ＤＣ２０への切替を実施し、実施後にその旨を所定の連絡先に連絡する。なお、切替処理の実施は、待機系ＤＣ２０の運用者等に対する指示を出力することによって手動で行ってもよいし、待機系ＤＣ２０の所定の切替処理用プログラムを起動するなどにより自動で行なってもよい。なお、後に稼動系ＤＣ１０の障害が復旧し、通常の運用状態に戻った場合には障害監視Ｓ１の状態に遷移する。

障害連絡Ｓ２の状態で、顧客４０やＩＴベンダー５０の担当者には連絡がつかずに指示を得ることができず、かつ稼動系ＤＣ１０の状況も確認できなかった場合（連絡全不能）、もしくは顧客４０やＩＴベンダー５０の担当者と連絡がとれて待機指示を受けた場合には、切替待機・状況確認Ｓ５の状態に遷移する。ここでは、障害発生の連絡に対して連絡先からの応答や指示を待つ。顧客４０やＩＴベンダー５０の担当者からの指示を受領した場合、その内容が切替を行わない指示であった場合は、上述した切替なしＳ３の状態に遷移する。一方、切替を実施する指示であった場合は、上述した切替実施Ｓ４の状態に遷移する。

＜データ構成＞
図３は、ＢＣＰ実施支援システム３０のルールＴＢ３７に定義されるルールの具体的な例について概要を示した図である。ここでは、図２に示した状態毎に、連絡等の対応を実施するトリガーとなる条件と、当該条件が成立した場合の対応内容として、連絡手段、連絡先、および連絡内容の各項目を保持する。

障害監視Ｓ１の状態では特に連絡対応はない（図中の１．１項）。ここで障害を検知した場合は障害連絡Ｓ２の状態に遷移し、顧客４０、ＩＴベンダー５０に対してセンターの切替の要否を問い合わせるメールを送信する（２．１、２．２項）。また、稼動系ＤＣ１０の運用者等に対して障害状況を問い合わせるメールを送信する（２．３項）。また、顧客４０の遠隔拠点（例えば海外拠点）の担当者等に対して、顧客４０が稼動系ＤＣ１０を利用して提供する業務サービスが利用可能か否かを問い合わせるメールを送信する（２．４項）。

また、メールでの連絡と並行して、顧客４０の担当者等に対して、センターの切替の要否を問い合わせる電話を発信する（２．５項）。災害被害や回線混雑等により電話がつながらない場合は、次にＩＴベンダー５０の担当者等に同様の電話を発信する（２．６項）。この電話もつながらない場合は、稼動系ＤＣ１０の運用者等に対して障害状況を問い合わせる電話を発信する（２．７項）。この電話もつながらない場合は、遠隔拠点の担当者等に対して業務サービスが利用可能かをメールにて回答するよう依頼する電話を発信する（２．８項）。

このように、いずれかの担当者や運用者に連絡がとれるまで順次電話を発信する。なお、可能な場合には、ある担当者について、まず外線電話に連絡し、つながらない場合は内線電話、これもつながらない場合は携帯電話、というように順次連絡先の電話を切り替える。ＢＣＰ実施支援システム３０からのメールや電話による連絡を受けた顧客４０やＩＴベンダー、稼動系ＤＣ１０などでは、後述するように問合せに対する応答をするが、判断できない場合や、状況が分からない場合などでは、応答をパスすることも可能である。

切替待機・状況確認Ｓ５の状態で、２．１項、２．２項、２．５項、２．６項の連絡により顧客４０およびＩＴベンダー５０の各担当者等と連絡がとれ、切替不要の指示を受けた場合は、切替なしＳ３の状態に遷移し、指示により切替を行わない旨を通知するメールを顧客４０、ＩＴベンダー５０、および顧客４０の遠隔拠点の各担当者等にそれぞれ送信する（３．１項）。なお、連絡した顧客４０およびＩＴベンダー５０の全ての担当者等の全員一致の指示がある場合にのみ指示があったとしてもよいし、連絡がとれた担当者等のうち、最も優先度の高い者からの指示に従うものとしてもよい。

また、障害連絡Ｓ２の状態で、顧客４０、およびＩＴベンダー５０の各担当者とのメール／電話での連絡がとれず、かつ、２．３項、２．７項の連絡により稼動系ＤＣ１０の運用者とは連絡がとれ、得られた障害状況が切替を不要とする所定の条件を満たした場合は、切替なしＳ３の状態に遷移し、稼動系ＤＣ１０の状況確認の結果により切替を行わない旨を通知するメールを顧客４０、ＩＴベンダー５０、および顧客４０の遠隔拠点の各担当者等にそれぞれ送信する（３．２項）。

また、障害連絡Ｓ２の状態で、顧客４０、ＩＴベンダー５０、および稼動系ＤＣ１０の各担当者や運用者とのメール／電話での連絡がとれず、かつ、２．４項、２．８項の連絡により顧客４０の遠隔拠点の担当者等から業務サービスが利用可能との回答を受けた場合は、切替なしＳ３の状態に遷移し、業務サービスが利用可能により切替を行わない旨を通知するメールを顧客４０、ＩＴベンダー５０、および顧客４０の遠隔拠点の各担当者等にそれぞれ送信する（３．３項）。

切替待機・状況確認Ｓ５の状態で、顧客４０やＩＴベンダー５０の各担当者等と連絡がとれ、切替実施の指示を受け、かつ、顧客４０の遠隔拠点の担当者等から業務サービスが利用不能との回答を受けた場合は、切替実施Ｓ４の状態に遷移し、指示により切替を実施する旨を通知するメールを顧客４０、ＩＴベンダー５０、および顧客４０の遠隔拠点の各担当者等にそれぞれ送信する（４．１項）。なお、連絡した顧客４０およびＩＴベンダー５０の全ての担当者等の全員一致の指示がある場合にのみ指示があったとしてもよいし、連絡がとれた担当者等のうち、最も優先度の高い者からの指示に従うものとしてもよい。

また、障害連絡Ｓ２の状態で、顧客４０、およびＩＴベンダー５０の各担当者とのメール／電話での連絡がとれない、もしくは連絡はとれたが切替要否について判断不可との回答を受け、かつ、稼動系ＤＣ１０の運用者とは連絡がとれ、得られた障害状況が切替を必要とする所定の条件を満たした場合、かつ、顧客４０の遠隔拠点の担当者等から業務サービスが利用不能との回答を受けた場合は、切替実施Ｓ４の状態に遷移し、稼動系ＤＣ１０の状況確認の結果により切替を実施する旨を通知するメールを顧客４０、ＩＴベンダー５０、および顧客４０の遠隔拠点の各担当者等にそれぞれ送信する（４．２項）。

また、障害連絡Ｓ２の状態で、顧客４０、ＩＴベンダー５０、および稼動系ＤＣ１０の各担当者や運用者とのメール／電話での連絡がとれず、かつ、顧客４０の遠隔拠点の担当者等から業務サービスが利用不能との回答を受けた場合は、切替実施Ｓ４の状態に遷移し、連絡がとれずかつ業務サービスが利用不能により切替を実施する旨を通知するメールを顧客４０、ＩＴベンダー５０、および顧客４０の遠隔拠点の各担当者等にそれぞれ送信する（４．３項）。

障害連絡Ｓ２の状態で、顧客４０、ＩＴベンダー５０、および稼動系ＤＣ１０の各担当者や運用者とのメール／電話での連絡がとれず、かつ、顧客４０の遠隔拠点の担当者からの回答もない場合は、切替待機・状況確認Ｓ５の状態に遷移する（５．１項）。また、障害連絡Ｓ２の状態で、顧客４０、およびＩＴベンダー５０の担当者等の少なくとも一方と連絡がとれ、状況確認ができるまで待機する旨の指示を受けた場合は、切替待機・状況確認Ｓ５の状態に遷移する（５．２項）。これらの場合の連絡対応は特にない。

上記の３．２項、３．３項、および４．２項、４．３項に示したルールのように、顧客４０やＩＴベンダー５０の担当者等の本来の判断主体との連絡がとれず、指示や判断を得ることができない状況であっても、他の条件に基づいてＢＣＰ実施支援システム３０（待機系ＤＣ２０）が自立的に切替要否の判断を行うことで、ＢＣＰに策定された内容を円滑かつ迅速に実施し、顧客４０が提供する業務サービスへの影響を最小化する。

図４は、稼動系ＤＣ１０でのルール１１の具体的な例について概要を示した図である。テーブルの構成は図３に示したルールＴＢ３７と同様である。ＢＣＰの発動判断に係る状態が障害監視Ｓ１の状態では特に連絡対応はない（図中の１．１項）。障害連絡Ｓ２の状態で、待機系ＤＣ２０（ＢＣＰ実施支援システム３０）からメールもしくは電話により連絡を受けた場合は、連絡に対する返信もしくは応答として、稼動系ＤＣ１０の稼働状況や障害状況（例えば、ラックが転倒している、等）を通知する（２．１項、２．２項）。切替なしＳ３や切替実施Ｓ４の状態では特に連絡対応はない（３．１項、４．１項）。また、切替待機・状況確認Ｓ５の状態で、ＩＴベンダー５０の担当者等からメールもしくは電話により連絡を受けた場合は、連絡に対する返信もしくは応答として、稼動系ＤＣ１０の稼働状況や障害状況を通知する（５．１項、５．２項）。

図５は、ＩＴベンダー５０でのルール５１の具体的な例について概要を示した図である。ＢＣＰの発動判断に係る状態が障害監視Ｓ１の状態では特に連絡対応はない（図中の１．１項）。障害連絡Ｓ２の状態で、待機系ＤＣ２０（ＢＣＰ実施支援システム３０）からメールもしくは電話により連絡を受けた場合は、連絡に対する返信もしくは応答として、状況確認ができるまで待機する旨の指示を連絡する（２．１項、２．２項）。また、切替待機・状況確認Ｓ５の状態で、稼動系ＤＣ１０の状況を確認し、顧客４０の担当者等との間の協議で切替不要と判断した場合は、稼動系ＤＣ１０の状況確認の結果により切替を行わない旨の指示を、メールおよび電話により待機系ＤＣ２０（ＢＣＰ実施支援システム３０）に対して連絡する（３．１項、３．２項）。これにより、状態は切替なしＳ３に遷移する。

また、切替待機・状況確認Ｓ５の状態で、稼動系ＤＣ１０の状況を確認し、顧客４０の担当者等との間の協議で切替必要と判断した場合は、切替を実施する旨の指示を、メールおよび電話により待機系ＤＣ２０（ＢＣＰ実施支援システム３０）に対して連絡する（４．１項、４．２項）。これにより、状態は切替実施Ｓ４に遷移する。また、切替待機・状況確認Ｓ５の状態で、顧客４０の担当者等もしくは待機系ＤＣ２０（ＢＣＰ実施支援システム３０）からメールもしくは電話により連絡を受けた場合は、稼動系ＤＣ１０に対して稼働状況、障害状況の確認を行う（５．１項、５．２項）。障害状況を確認したが、顧客４０の担当者等と連絡がとれず切替要否について協議できない場合に、判断不可の旨を待機系ＤＣ２０（ＢＣＰ実施支援システム３０）に指示することも可能である。

図６は、顧客４０でのルール４１の具体的な例について概要を示した図である。ＢＣＰの発動判断に係る状態が障害監視Ｓ１の状態では特に連絡対応はない（図中の１．１項）。障害連絡Ｓ２の状態で、待機系ＤＣ２０（ＢＣＰ実施支援システム３０）からメールもしくは電話により連絡を受けた場合は、連絡に対する返信もしくは応答として、状況確認ができるまで待機する旨の指示を通知する（２．１項、２．２項）。

また、切替待機・状況確認Ｓ５の状態で、稼動系ＤＣ１０の状況を確認し、ＩＴベンダー５０の担当者等との間の協議で切替不要と判断した場合は、稼動系ＤＣ１０の状況確認の結果により切替を行わない旨を、メールおよび電話により顧客４０の遠隔拠点に対して連絡する（３．１項、３．２項）。なお、待機系ＤＣ２０（ＢＣＰ実施支援システム３０）への指示は、図５に示したルール５１の３．１項、３．２項により行われ、これにより状態は切替なしＳ３に遷移する。

また、切替待機・状況確認Ｓ５の状態で、稼動系ＤＣ１０の状況を確認し、ＩＴベンダー５０の担当者等との間で連絡がとれず切替要否について協議できない状況で、独自に切替不要と判断した場合は、稼動系ＤＣ１０の状況確認の結果により切替を行わない旨の指示を、メールおよび電話により待機系ＤＣ２０（ＢＣＰ実施支援システム３０）に対して連絡する（３．３項、３．４項）。これにより状態は切替なしＳ３に遷移する。

また、切替待機・状況確認Ｓ５の状態で、稼動系ＤＣ１０の状況を確認し、ＩＴベンダー５０の担当者等との間の協議で切替必要と判断した場合は、切替を実施する旨を、メールおよび電話により顧客４０の遠隔拠点に対して連絡する（４．１項、４．２項）。なお、このときの待機系ＤＣ２０（ＢＣＰ実施支援システム３０）への指示は、図５に示したルール５１の４．１項、４．２項により行われ、これにより状態は切替実施Ｓ４に遷移する。

また、切替待機・状況確認Ｓ５の状態で、稼動系ＤＣ１０の状況を確認し、ＩＴベンダー５０の担当者等との間で連絡がとれず切替要否について協議できない状況で、独自に切替必要と判断した場合は、切替を実施する旨の指示を、メールおよび電話により待機系ＤＣ２０（ＢＣＰ実施支援システム３０）に対して連絡する（４．３項、４．４項）。これにより状態は切替実施Ｓ４に遷移する。

また、切替待機・状況確認Ｓ５（もしくは障害連絡Ｓ２）の状態で、待機系ＤＣ（ＢＣＰ実施支援システム３０）等から障害発生の連絡を受けた場合は、ＩＴベンダー５０の担当者等に対して、稼動系ＤＣ１０の状況を確認する旨の指示をメールもしくは電話により行う（５．１項、５．２項）。これに対する返信がない場合や連絡がとれない場合は、稼動系ＤＣ１０に対してメールおよび電話連絡により稼働状況、障害状況の確認を行う（５．３項、５．４項）。障害状況を確認したが、ＩＴベンダー５０の担当者等と連絡がとれず切替要否について協議できない場合に、判断不可の旨を待機系ＤＣ２０（ＢＣＰ実施支援システム３０）に指示することも可能である。

図７は、顧客４０の遠隔拠点でのルール４１’の具体的な例について概要を示した図である。ＢＣＰの発動判断に係る状態が障害監視Ｓ１の状態では特に連絡対応はない（図中の１．１項）。障害連絡Ｓ２の状態で、待機系ＤＣ２０（ＢＣＰ実施支援システム３０）からメールもしくは電話により連絡を受けた場合は、連絡に対する返信もしくは応答として、顧客４０が稼動系ＤＣ１０において提供している業務サービスの当該遠隔拠点からの利用可否の情報を通知する（２．１項、２．２項）。電話での連絡の場合は、状況を確認した後にメールで回答する旨を応答してもよい。切替なしＳ３や切替実施Ｓ４の状態では特に連絡対応はない（３．１項、４．１項）。

また、切替待機・状況確認Ｓ５の状態で、２．２項の電話連絡において状況確認後にメールにて回答する旨を応答していた場合は、業務サービスの当該遠隔拠点からの利用可否の情報を、待機系ＤＣ２０（ＢＣＰ実施支援システム３０）、顧客４０、およびＩＴベンダー５０の担当者等に対してメールにて通知する（５．１項）。

上記の図４〜図７の各テーブルは、それぞれ、稼動系ＤＣ１０やＩＴベンダー５０、顧客４０が有して判断のために用いるものであり、担当者等のマニュアルに類するものであるが、例えば、待機系ＤＣ２０（ＢＣＰ実施支援システム３０）からの連絡内容を入力として、これに対して何を実施し、何を応答すべきかの情報を、各テーブルを参照して判断し、出力するようなアプリケーションプログラムを、それぞれの拠点等に有して、判断をシステム化するようにしてもよい。このとき、可能な場合には、必要に応じてＢＣＰ実施支援システム３０の状態ＴＢ３８を参照して現在の状態を把握するようにしてもよい。

また、上記の図３〜図７の各テーブルの構成やデータの具体例は、あくまで一例であり、同様のデータを保持・管理することが可能な構成であれば、他のテーブル構成やデータ構成であってもよい。また、これらの構成や具体例は、論理的なものであり、実装の際の形式は、これらの情報を取得して判断を行うアプリケーションプログラム（例えば、ＢＣＰ実施支援システム３０のルール処理部３３）が理解可能な形式やフォーマット、コード値などとすることができる。

以上に説明したように、本発明の一実施の形態であるＢＣＰ実施支援システム３０によれば、待機系ＤＣ２０（ＢＣＰ実施支援システム３０）において稼動系ＤＣ１０での障害を検知し、切替の要否を判断する必要が生じた際に、顧客４０やＩＴベンダー５０の担当者等の本来の判断主体との連絡がとれず、指示や判断を得ることができない状況であっても、予め、顧客企業とＩＴベンダー、およびデータセンターの間で合意された所定のルール（例えば、図３の３．２項、３．３項、および４．２項、４．３項などのルール）に基づいて、切替の実施主体である待機系ＤＣ２０（ＢＣＰ実施支援システム３０）が自立的に切替要否の判断を行うことが可能となる。これにより、災害等の発生時にＢＣＰに策定された内容を円滑かつ迅速に実施し、顧客の業務サービスへの影響を最小化することが可能となる。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、上記の実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。また、上記の各図において、制御線や情報線は説明上必要と考えられるものを示しており、必ずしも実装上の全ての制御線や情報線を示しているとは限らない。実際にはほとんど全ての構成が相互に接続されていると考えてもよい。

本発明は、災害や事故などの予期せぬ危機事象が発生した場合にＢＣＰの発動要否に係る意思決定を支援するＢＣＰ実施支援システムおよびＢＣＰ実施支援プログラムに利用可能である。

１０…稼動系データセンター（ＤＣ）、１１…ルール、
２０…待機系データセンター（ＤＣ）、
３０…ＢＣＰ実施支援システム、３１…障害監視部、３２…連絡処理部、３３…ルール処理部、３４…状態管理部、３５…状況出力部、３６…連絡先テーブル（ＴＢ）、３７…ルールテーブル（ＴＢ）、３８…状態テーブル（ＴＢ）、
４０…顧客、４１…ルール、
５０…ＩＴベンダー、５１…ルール。

Claims (8)

1. 危機事象が発生した際の、顧客の情報処理基盤に係る事業継続計画の発動の要否についての判断を支援するＢＣＰ実施支援システムであって、
   前記情報処理基盤における障害事象の発生を検知する障害監視部と、
   前記障害監視部により障害事象を検知した場合に、所定の連絡先に連絡を行い、その応答に係る情報を取得する連絡処理部と、
   前記障害監視部により検知した障害事象、前記連絡処理部により取得した連絡先からの応答の内容、および前記事業継続計画の発動の判断に係る状態を含む情報に基づいて、ルール保持部に予め定義されたルールのうち対応するものに従って、当該ルールにより指定された連絡先に前記連絡処理部を介して連絡を行い、もしくは前記事業継続計画の発動の要否を判断するルール処理部と、
   前記ルール処理部によって抽出された前記ルールに従って、前記状態の遷移を状態保持部に記録して管理する状態管理部と、を有し、
   前記ルール保持部に定義されたルールにおいては、前記障害事象を検知した場合に前記連絡処理部により連絡を行う所定の連絡先には、少なくとも前記顧客および前記情報処理基盤を運用する運用者を含み、
   前記ルール処理部は、前記障害事象を検知した場合に、前記連絡処理部による前記顧客に対する連絡により、前記顧客から前記事業継続計画の発動に係る指示の情報を受けた場合にはその指示に従い、前記顧客との連絡が不能な場合であっても、前記運用者からの応答内容に基づいて把握される前記情報処理基盤の状況が所定の条件を満たすか否かによって、前記事業継続計画の発動の要否を判定する、ＢＣＰ実施支援システム。
2. 請求項１に記載のＢＣＰ実施支援システムにおいて
   前記ルール保持部に定義されたルールにおいて、前記障害事象を検知した場合に前記連絡処理部により連絡を行う所定の連絡先には、さらに前記情報処理基盤の設計者を含み、
   前記ルール処理部は、前記障害事象を検知した場合に、前記連絡処理部による前記顧客および前記設計者に対する連絡により、前記顧客および／または前記設計者から前記事業継続計画の発動に係る指示の情報を受けた場合にはその指示に従い、前記顧客および前記設計者との連絡が不能な場合であっても、前記運用者からの応答内容に基づいて把握される前記情報処理基盤の状況が所定の条件を満たすか否かによって、前記事業継続計画の発動の要否を判定する、ＢＣＰ実施支援システム。
3. 請求項１または２に記載のＢＣＰ実施支援システムにおいて、
   前記ルール保持部に定義されたルールにおいて、前記障害事象を検知した場合に前記連絡処理部により連絡を行う所定の連絡先には、さらに前記顧客の遠隔拠点を含み、
   前記ルール処理部は、前記障害事象を検知した場合に、少なくとも、前記連絡処理部による前記遠隔拠点に対する連絡により、前記情報処理基盤が利用不能である旨の応答を受けた場合に限り、前記事業継続計画を発動させる、ＢＣＰ実施支援システム。
4. 請求項１〜３のいずれか１項に記載のＢＣＰ実施支援システムにおいて、
   前記連絡処理部は、連絡先に対して電子メールおよび／または電話により連絡を行う、ＢＣＰ実施支援システム。
5. 請求項１〜４のいずれか１項に記載のＢＣＰ実施支援システムにおいて、
   前記ルール処理部は、前記連絡処理部により複数の連絡先から前記事業継続計画の発動に係る指示の情報を受けた場合に、全ての指示内容が一致した場合にのみ当該指示を有効とする、ＢＣＰ実施支援システム。
6. 請求項１〜４のいずれか１項に記載のＢＣＰ実施支援システムにおいて、
   前記ルール処理部は、前記連絡処理部により複数の連絡先から前記事業継続計画の発動に係る指示の情報を受けた場合に、予め各連絡先について定められた優先順位が最も高い連絡先からの指示を有効とする、ＢＣＰ実施支援システム。
7. 請求項１〜６のいずれか１項に記載のＢＣＰ実施支援システムにおいて、
   前記情報処理基盤は、稼動系のデータセンターと、災害対策用の待機系のデータセンターとを有して切替可能な構成を有する、ＢＣＰ実施支援システム。
8. 危機事象が発生した際の、顧客の情報処理基盤に係る事業継続計画の発動の要否についての判断を支援する情報処理システムとしてコンピュータを動作させるＢＣＰ実施支援プログラムであって、
   前記情報処理基盤における障害事象の発生を検知する障害監視処理と、
   前記障害監視処理により障害事象を検知した場合に、所定の連絡先に連絡を行い、その応答に係る情報を取得する連絡処理と、
   前記障害監視処理により検知した障害事象、前記連絡処理により取得した連絡先からの応答の内容、および前記事業継続計画の発動の判断に係る状態を含む情報に基づいて、ルール保持部に予め定義されたルールのうち対応するものに従って、当該ルールにより指定された連絡先に前記連絡処理を介して連絡を行い、もしくは前記事業継続計画の発動の要否を判断するルール処理と、
   前記ルール処理によって抽出された前記ルールに従って、前記状態の遷移を状態保持部に記録して管理する状態管理処理と、を前記コンピュータに実行させ、
   前記ルール保持部に定義されたルールにおいては、前記障害事象を検知した場合に前記連絡処理により連絡を行う所定の連絡先には、少なくとも前記顧客および前記情報処理基盤を運用する運用者を含み、
   前記ルール処理では、前記障害事象を検知した場合に、前記連絡処理による前記顧客に対する連絡により、前記顧客から前記事業継続計画の発動に係る指示の情報を受けた場合にはその指示に従い、前記顧客との連絡が不能な場合であっても、前記運用者からの応答内容に基づいて把握される前記情報処理基盤の状況が所定の条件を満たすか否かによって、前記事業継続計画の発動の要否を判定する、ＢＣＰ実施支援プログラム。

Images