(57)【要約】【課題】クラウドコンピューティングサービスでは，障害の発生に伴い，連絡すべき顧客を判断するためには，先に障害の内容を分析する必要がある。しかしながら，この作業のため，顧客への連絡までに必要な時間が増大するという問題がある。【解決手段】障害発生時に，その障害が原因で，将来波及する可能性のある障害を予測し，顧客連絡内容の準備を行う。障害の予測があたった場合，準備した連絡内容を用いて，迅速に連絡を行う。【選択図】図１
2013222313.tif 000002
【特許請求の範囲】
【請求項１】
クラウドコンピューティングシステムの障害をシステムにより検知して通知を行う機能を有するサーバ監視システムと，
前記サーバ監視システムからの通知を入力として障害の原因箇所を推定して出力する機能を有する根本原因分析システムと，
前記根本原因分析システムが推定した障害の原因箇所を入力として，障害の直接の影響を受ける利用者と，その障害に起因する障害により今後障害の影響を受けうる利用者を特定する機能を有する波及先予測システムと，
前記根本原因分析システムが推定した障害の原因箇所と，前記波及先予測システムが導出した利用者の情報を入力として，障害の直接の影響を受ける利用者と，その障害に起因する障害により影響を受けうる利用者双方に対してオペレータが連絡すべき内容を生成するとともに，各利用者に設定された連絡の優先度とシステムの状態にもとづき，連絡すべき順番を判断する機能を有する，顧客連絡/優先度決定システムとを有し，
前記障害連絡効率化システムは，前記波及先予測システムで推定した将来の障害の影響を受ける利用者に対する障害連絡内容を，顧客連絡/優先度決定システムにてあらかじめ作成し，実際に障害が発生した際に，前記根本原因分析システムにより同じ原因により障害が発生したと判断された場合に，先に作成した障害連絡内容をオペレータへ提示することを特徴とする障害連絡効率化システム。
【請求項２】
請求項１において，前記顧客連絡/優先度決定システムは，一定時間内に発生した通知を一時的に保持するデータ保持部を有し，一定時間経過後にデータ保持部に格納された通知を，各利用者に設定された連絡の優先度とシステムの状態にもとづいて，連絡すべき順番を判断し，その順番にもとづいてオペレータに通知する順番を入れ替えたのちにオペレータに通知することを特徴とする，障害連絡効率化システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は，コンピューティングシステムの運用管理における，障害対応時の顧客連絡の障害連絡効率化システムに関する。
【背景技術】
【０００２】
クラウドコンピューティングサービスでは，物理サーバの仮想化による，高集約化に伴い，障害発生時には，複数の利用者に影響が及ぶ。そのため，クラウドコンピューティングサービスの提供者は，その利用者には効率的に障害連絡を行う必要がある。
利用者への効率的な連絡方法として，特許文献１では，不具合発生時に，あらかじめ登録しておいた不具合事象から連絡先を特定し，不具合発生連絡を行う。 
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開2007-141007号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
特許文献１は，顧客ごとにシステムが独立している場合を対象としており，障害が発生した場合，どの顧客に連絡するかは一意であった。また，顧客ごとに専任の運用の従事者が割り当てられ，連絡内容が定まれば，すぐに顧客に連絡することが可能だった。
しかしクラウドコンピューティングサービスは，大規模かつ仮想化されたクラウドコンピューティングシステム上で，専任の従事者を設けずに多数の顧客のシステムを運用する。したがって，ある障害の発生に伴い，連絡すべき顧客を判断するためには，先に障害の内容を分析する必要があるが，この作業のため，顧客への連絡までに必要な時間が増大するという問題がある。
また，ある障害の結果として，複数の顧客に連絡する必要がある場合，連絡先の顧客数よりも少ない運用の従事者で対応することになるため，結果として顧客への連絡までに必要な時間が増大するという問題がある。
【課題を解決するための手段】
【０００５】
本発明では，障害発生時に，その障害が原因で将来波及する可能性のある障害を予測し，利用者へ連絡する内容の準備を行う。予測があたった場合は，あらかじめ準備していた連絡内容を用いて，迅速に連絡を行う。
また，同時多発的な障害の発生に対し，利用者・システム特性のパラメータにもとづいて，優先度のシステムによる決定を行う。
【発明の効果】
【０００６】
利用者への連絡内容は同じ障害を背景にしているため，効率的に準備することが可能で，利用者への連絡完了までの時間を短縮できる。
また，優先度の高い利用者の順に連絡を行うことで，クラウド環境全体でのサービスレベルをより広く満足させることができる。
【図面の簡単な説明】
【０００７】
【図１】実施例１による障害連絡効率化システムの構成図である。
【図２】実施例１による障害発生時の時間経過にもとづく，障害発生時の処理の流れを表したものである。
【図３】実施例１によるストレージ１２０と，ストレージ１２１で保管されるデータの詳細図である。
【図４】実施例１によるストレージ１２２と，ストレージ１２３と，ストレージ１２４で保管されるデータの詳細図である。
【図５】実施例１のシステム間同士でやり取りされるデータの詳細図である。
【図６】実施例１による障害発生時にもとづく，サーバ監視システム１１０と，根本原因分析システム１１１と，波及先予測システム１１２と，顧客連絡／優先度決定システム１１３の処理手順の詳細を表すフローチャートである。
【図７】実施例１による障害発生時にもとづく，波及先予測システム１１２の処理手順の詳細を表すフローチャートである。
【図８】実施例１による障害発生時にもとづく，顧客連絡／優先度決定システム１１３の顧客連絡文面決定の処理手順の詳細を表すフローチャートである。
【図９】実施例１による障害発生時にもとづく，顧客連絡／優先度決定システム１１３の顧客連絡優先度決定の処理手順の詳細を表すフローチャートである。
【図１０】実施例１による障害発生時にもとづく，顧客連絡／優先度決定システム１１３の顧客連絡文面決定時の電話連絡かメール連絡かを判断する処理手順の詳細を表すフローチャートである。
【図１１】実施例１による障害発生時にもとづく，顧客連絡／優先度決定システム１１３の顧客連絡優先度の決定方法の具体例を示した図である。
【発明を実施するための形態】
【０００８】
図１は本発明を適用した，マルチテナント環境を考慮した，利用者への障害連絡効率化システムを表す第一の実施例である。データセンタ１００内に，複数の物理サーバと管理用ルータとルータ，ストレージを具備する。複数の物理サーバ上では，仮想マシンを稼働させている。
【０００９】
本実施例では，サーバ監視システム１１０，障害根本原因分析システム１１１，波及先予測システム１１２，顧客連絡／優先度決定システム１１３の各システムは仮想サーバで実装した例を用いて説明する。各仮想サーバと管理用ルータ１０３は，Ethernet（登録商標）により接続され，各仮想サーバに接続された仮想NIC経由で，Ethernetパケットを各サーバ間で通信を行う。各仮想サーバにはIPアドレスが割り振られており，各仮想サーバはIPアドレスにより送受信先を特定できる。各仮想サーバ上のシステム間で送受信されるデータは，全てこのEthernetパケットに変換され，目的のシステムと送受信される。ここで目的のシステムのIPアドレスは，.hostsファイルによりあらかじめ定義してもよいし，各システムの名称からIPアドレスを変換するDNSシステムに問い合わせることで確かめてもよい。こうしたEthernetを利用したデータの送受信の仕組みは，下記のシステム間のデータ送受信において共通のものであり，特に断りがない限り上記の説明は省略する。
【００１０】
サーバ監視システム１１０は，データセンタ１００内の装置（物理サーバ１３０・１３５，ハイパバイザ１３１・１３６，仮想サーバ等１３２・１３３・１３４・１３７・１３８・１３９）からログ等を収集し，装置の状態を監視するシステムである。
【００１１】
サーバ監視システム１１０は，データセンタ１００内に装置を設置し監視を行うが，データセンタ外からリモートでデータセンタ１００内の装置を監視してもよい。サーバ監視システムはネットワークを利用し，データセンタ１００内の管理用ルータ１０３を介して，物理サーバ１３０・１３５と，ハイパバイザ１３１・１３６と，仮想マシン１３２・１３３・１３４・１３７・１３８・１３９に接続されている。また，サーバ監視システムは，ネットワークを利用し，サーバ稼働情報１２０と接続されており，また障害根本原因分析システム１１１，波及先予測システム１１２，顧客連絡/優先度決定システム１１３，Webポータル１１４と接続されている。
【００１２】
サーバ管理システム１１０が，これらの装置からログを収集する手段としては，SNMPトラップのようにこれらの装置から送信されるデータを受信する仕組みであってもよいし，これらの装置が持つAPIを利用して能動的に読み出す仕組みであってもよい。
【００１３】
また，これらの装置から収集されるデータとしては，障害などの装置の状態を判断する情報が該当する。物理サーバ１３０・１３５からは，IPアドレスや，CPU・メモリ・ネットワークの使用率，ストレージへの一秒間あたりのIO数や，装置の障害などの情報が収集されてもよい。ハイパバイザ１３１・１３６からは，仮想マシンに割り当てた仮想ネットワークや仮想CPUの情報や，それら仮想デバイス上で発生した障害の情報が収集されてもよい。仮想マシン１３２・１３３・１３４・１３７・１３８・１３９からは，仮想CPU・仮想メモリ・仮想ネットワークの使用率や，仮想ストレージへの一秒間あたりのIO数や，仮想装置の障害などの情報が収集されてもよい。
【００１４】
ここで，データセンタ１００内の物理サーバ数や，物理サーバ上で稼働するハイパバイザ数や種別や有無，ハイパバイザ上で稼働する仮想サーバ数は任意の数であってもよく，サーバ監視システム１１０は，複数のサブシステムを利用して，これらの機器から分散してログを収集してもよい。
【００１５】
サーバ監視システム１１０は，クラウドコンピューティングシステム１０１内の物理サーバ１３０および１３５，ハイパバイザ１３１および１３６，仮想マシン１３２，および１３３，および１３４，および１３７，および１３９，ストレージ１０５に対して，異常がないかを常に確認している。サーバ監視システム１１０の実装は，ソフトウェアに加え，ハードウェアや，ハードウェアとソフトウェアを含むものであってもよい。
【００１６】
障害根本原因分析システム１１１は，サーバ監視システムが検知したエラーメッセージをもとに，サーバ稼働情報１２０と，構成管理情報１２１を参照し，発生した障害の根本原因となった部位はどこであったかを分析するシステムである。根本原因分析システム１１１が特定できる部位は，物理サーバ１３０・１３５と，ハイパバイザ１３１・１３６と，仮想マシン１３２・１３３・１３４・１３７・１３８・１３９，ルータ１０４，管理用ルータ１０３，ストレージ１０５等の装置と，その装置内のCPUやメモリ，ストレージ，IOモジュール等である。
【００１７】
根本原因分析システム１１１は，データセンタ１００内に設置されているが，データセンタ外からリモートでデータセンタ１００内の装置と接続してもよい。根本原因分析システム１１１は，ネットワークを利用し，データセンタ１００内の管理用ルータ１０３を介して，物理サーバ１３０・１３５と，ハイパバイザ１３１・１３６と，仮想マシン１３２・１３３・１３４・１３７・１３８・１３９に接続されている。また，根本原因分析システム１１１は，ネットワークを利用し，サーバ稼働情報１２０，構成管理情報１２１と接続されており，また，サーバ監視システム１１０，波及先予測システム１１２，顧客連絡/優先度決定システム１１３，Webポータル１１４と接続されている。
【００１８】
根本原因分析システム１１１が，サーバ監視システム１１０からのアラートを受信する手段としては，サーバ監視システム１１０から，根本原因分析システム１１１のAPIを利用してデータを送信する仕組みであってもよいし，根本原因分析システム１１１が，サーバ監視システム１１０のAPIを用いて定期的にアラートの有無を確認し，読み出す処理としてもよい。障害根本原因分析システム１１１は，サーバ監視システム１１０が障害を検知した際に，検知した障害の根本原因が何であるのかを判定する処理を行う。根本原因分析システム１１１の実装は，ソフトウェアに加え，ハードウェアや，ハードウェアとソフトウェアを含むものであってもよい。
【００１９】
波及先予測システム１１２は，障害根本原因分析システム１１１が特定した障害発生部位をもとに，構成管理情報１２１と，契約情報１２２を参照し，波及すると考えられる顧客システムの特定を行うシステムである。
【００２０】
波及先予測システム１１２は，データセンタ１００内に設置されているが，データセンタ外からリモートでデータセンタ１００内の装置と接続してもよい。
【００２１】
波及予測システム１１２は，ネットワークを利用し，データセンタ１００内の管理用ルータ１０３を介して，物理サーバ１３０・１３５と，ハイパバイザ１３１・１３６と，仮想マシン１３２・１３３・１３４・１３７・１３８・１３９に接続されている。また，波及予測システム１１２は，ネットワークを利用し，構成管理情報１２１，契約情報１２２と接続されており，また，サーバ監視システム１１０，根本原因分析システム１１１，顧客連絡/優先度決定システム１１３，Webポータル１１４と接続されている。
【００２２】
波及先予測システム１１２が，障害根本原因分析システム１１１からの結果を受信する手段としては，障害根本原因分析システム１１１から，波及先予測システム１１２のAPIを利用してデータを送信する仕組みであってもよいし，波及先予測システム１１２が，障害根本原因分析システム１１１のAPIを用いて定期的に分析結果の有無を確認し，読み出す処理としてもよい。
【００２３】
波及先予測システム１１２は，障害原因根本分析システム１１１が障害原因である部位を推定した際に，構成管理情報１２１と契約情報１２２などを用いて，障害の影響を受ける利用者や，今後障害を受ける可能性の高い利用者を特定する処理を行う。波及先予測システム１１２が障害IDと障害部位の情報１２６を受信（４３１）し，未処理の障害IDが存在するかを確認する（４３２）。
【００２４】
未処理の障害IDが存在する場合，受信した障害部位が物理サーバであるかを確認する（４３５）。物理サーバの障害であった場合，構成管理情報１２１から障害部位の物理サーバを共有する顧客IDとシステム名を検索する（４４０）。物理サーバ障害でない場合は，受信した障害部位がソフトウェアであるかを確認する（４３６）。
【００２５】
ソフトウェア障害であった場合，構成管理情報１２１から同じソフトウェアを利用している顧客IDとシステム名を検索する（４４１）。ソフトウェア障害でない場合は，受信した障害部位がネットワークであるかを確認する（４３７）。ネットワーク障害であった場合，構成管理情報１２１から同じネットワーク装置，ネットワーク回線を利用している顧客IDとシステム名を検索する（４４２）。ネットワーク障害でない場合は，受信した障害部位がストレージであるかを確認する（４３８）。
【００２６】
ストレージ障害であった場合，構成管理情報１２１から同じストレージ装置，ディスクを共有する顧客ID，システム名を検索する（４４３）。ストレージ障害でない場合は，受信した障害部位が仮想サーバであるかを確認する（４３９）。仮想サーバ障害であった場合，構成管理情報１２１から仮想サーバを使用している顧客ID，システム名を検索する。
【００２７】
仮想サーバ障害でない場合は，その他の章が波及先推定困難な障害としてメッセージを記載する（４４７）。波及先予測システム１１２の実装は，ソフトウェアに加え，ハードウェアや，ハードウェアとソフトウェアを含むものであってもよい。
【００２８】
顧客連絡／優先度決定システム１１３は，波及先予測システムが特定した顧客に対し，構成管理情報１２１と，契約情報１２２と，連絡文面テンプレート１２３を参照し，顧客連絡の優先度と，顧客への連絡文面の作成を行うシステムである。
【００２９】
顧客連絡／優先度決定システム１１３は，データセンタ１００内に設置されているが，データセンタ外からリモートでデータセンタ１００内の装置と接続してもよい。
【００３０】
顧客連絡／優先度決定システム１１３は，ネットワークを利用し，データセンタ１００内の管理用ルータ１０３を介して，物理サーバ１３０・１３５と，ハイパバイザ１３１・１３６と，仮想マシン１３２・１３３・１３４・１３７・１３８・１３９に接続されている。また，顧客連絡／優先度決定システム１１３は，ネットワークを利用し，構成管理情報１２１，契約情報１２２と，連絡文面テンプレート１２３と接続されており，また，サーバ監視システム１１０，根本原因分析システム１１１，波及先予測システム１１２，Webポータル１１４と接続されている。
【００３１】
顧客連絡／優先度決定システム１１３が，波及先予測システム１１２からの結果を受信する手段としては，波及先予測システム１１２から，顧客連絡／優先度決定システム１１３のAPIを利用してデータを送信する仕組みであってもよいし，顧客連絡／優先度決定システム１１３が，波及先予測システム１１２のAPIを用いて，定期的に予測結果の有無を確認し，読み出す処理としてもよい。
【００３２】
顧客連絡／優先度決定システム１１３は，波及先予測システム１１２により障害が波及すると予測された利用者と，構成管理情報１２１と契約情報１２２の情報を利用し，連絡すべき順番を決定する処理を行う。
顧客連絡／優先度決定システム１１３の顧客連絡文面作成部では，波及予測先システムの出力である，障害IDと原因IDと顧客IDとシステム名の情報１２７を受信し，受信した顧客IDと契約情報１２２の顧客管理情報１３６の顧客ID２８０と一致するものを検索し，一致するレコードの報告パターン２９５を確認し，電話連絡かメール連絡であるかを確認する（４５２）。メール連絡の場合，連絡文面テンプレート１２３から原因IDに対応するメールテンプレートが存在するかどうかを確認する（４５３）。メールテンプレートが存在する場合は，テンプレートを利用し，メールの連絡文面を準備する（４５５）。
【００３３】
メールテンプレートが存在しない場合は，オペレータが新たにメールテンプレートを作成する（４５６）。メールテンプレートに契約情報１２２の顧客情報管理１３６のメールアドレス２９４を挿入し，ログファイル１２４などを添付する（４５９）。 
電話連絡の場合，連絡文面テンプレート１２３から原因IDに対応する電話用テンプレートが存在するかどうかを確認する（４５４）。電話用テンプレートが存在する場合は，テンプレートを利用し，電話連絡文面を準備する（４５７）。電話用テンプレートが存在しない場合は，オペレータが新たに電話用テンプレートを作成する（４５８）。電話用テンプレートに契約情報１２２の顧客情報管理の電話番号２９３を挿入する（４６０）。
【００３４】
４６０，４６１に対して，障害IDと一致するログ１２４の障害発生時刻３３２と復旧時間を挿入する（４６１，４６２）。復旧時間の計算は，障害内容により，オペレータが計算してもよいし，障害内容により予め復旧時間を登録しておいてもよい。
【００３５】
顧客連絡／優先度決定システム１１３の顧客連絡優先度決定部では，顧客連絡文面作成部の出力である１２８，１２９を受信（４７１）し，キューに受信したデータを格納する（４７２）。キュー内にあるすべての顧客に対して優先度の評価が完了しているかどうかを確認する（４７３）。優先度の評価が完了してない場合，仮想サーバ稼働情報のCPU使用率，アクセス数にもとづく優先度，契約情報１２２のシステム種別２８６，SLA２８４，クレーム数２８５，運用開始日２８２と運用終了日２８３から算出した利用期間にもとづく優先度を加点する（４７４，４７５，４７６）。
【００３６】
優先度の評価が完了している場合，加点した点数にもとづき，優先度順にキューを並べ替え（４７７），すぐに連絡すべきデータがあるか確認する（４７８）。すぐに連絡すべきデータがある場合，すぐに連絡すべき情報のうち，優先順位の高い顧客への連絡文面からオペレータの画面に表示する（４８１）。すべてのデータの表示が終わったら，新規に障害が発生するのを待ち（４８２），新規に障害が発生したかどうかを確認する（４７９）。新規に障害が発生した場合は，一定時間が経過した後，優先順位の高い順に，顧客への連絡文面から画面への表示を行う（４８０）。
【００３７】
Webポータル１１４は，顧客連絡／優先度決定システムの出力である，連絡すべき顧客の優先度と，連絡文面を表示し，オペレータ１４０が確認し，IT管理者１４１または１４２に連絡を行うためのシステムである。ただし，必要に応じてサーバ監視システム１１０が検知した障害内容，障害根本原因分析システム１１１が特定した障害発生部位，波及先予測システム１１２が特定した，障害が波及すると予測される顧客システム，サーバ稼働情報１２０，構成管理情報１２１，契約情報１２２，連絡文面テンプレート等の情報を参照してもよい。
【００３８】
Webポータル１１４は，データセンタ１００内に設置されているが，データセンタ外からリモートでデータセンタ１００内の装置と接続してもよい。
Webポータル１１４は，ネットワークを利用し，データセンタ１００内の管理用ルータ１０３を介して，物理サーバ１３０・１３５と，ハイパバイザ１３１・１３６と，仮想マシン１３２・１３３・１３４・１３７・１３８・１３９に接続されている。また，顧客連絡／優先度決定システム１１３は，ネットワークを利用し，構成管理情報１２１，契約情報１２２と，連絡文面テンプレート１２３と接続されており，また，サーバ監視システム１１０，根本原因分析システム１１１，波及先予測システム１１２，顧客連絡／優先度決定システム１１３と接続されている。 
Webポータル１１４は，オペレータ１４０がサーバ監視システム１１０，根本原因分析システム１１１，波及予測システム１１２，顧客連絡／優先度決定システム１１３からのアウトプットを確認するために使用する。Webポータルの実装は，ソフトウェアに加え，ハードウェアや，ハードウェアとソフトウェアを含むものであってもよい。
【００３９】
データセンタ１００は，仮想サーバと顧客システム（A社）１１５と，顧客システム（B社）１１６を接続するネットワーク１０２からの通信を適切な仮想サーバに受け渡すルータ１０４を持つ。ここで，ルータ１０４の機能として，外部との不正な接続を遮断するファイアウォール，外部からの不正な通信を監視，およびフィルタリングするIntrusion Detection SystemやIntrusion Prevention System，データセンタ１００外部との通信に用いるIPアドレスとデータセンタ１００内部での通信に用いるIPアドレスを変換するNetwork Address Translation，ルータ１０４を複数台のルータとして論理的に動作させるVirtual Routing Forwarding，ネットワークを論理的に分割するVLANの機能を有していてもよく，またこうした機能を持つ装置と接続されていてもよい。
【００４０】
ルータ１０４は，アクセス元のIPアドレスに応じて接続先のネットワークを選択し，またアクセス先のIPアドレスにもとづき，データを送信する装置を選択する。ルータ１０４は，仮想サーバ１３２・１３３・１３４・１３７・１３８・１３９，物理サーバ１３０・１３５，ハイパバイザ１３１・１３６に接続されており，基本的な処理として顧客システム（A社）１１５や顧客システム（B社）１１６からのリクエストをこれらの仮想サーバに転送する役割を持つ。
【００４１】
仮想サーバ１３２および１３３および１３４は，物理サーバ１３０上の論理的に分割したサーバであり，ハイパバイザ１３１上で動作するものである。仮想サーバ１３７および１３８および１３９は物理サーバ１３５上の論理的に分割したサーバであり，ハイパバイザ１３６上で動作するものである。
【００４２】
ハイパバイザ１３１および１３６は，物理サーバのCPU，メモリ，および物理サーバ１３１および１３６に接続されたネットワークの回線容量，物理サーバ１３１および１３５に接続されたストレージ１０５のデータ領域などを論理的に分割し，複数のOSを物理サーバにインストールして利用可能とする機能を持つ。
【００４３】
管理用ルータ１０３はサーバ監視システム１１０，障害根本原因分析システム１１１，波及先予測システム１１２，顧客連絡／優先度決定システムに接続されている。
【００４４】
図２は本実施例の特徴である，障害発生時の処理の流れを表したものである。はじめに，クラウドコンピューティングシステムにおける通常の障害発生から顧客への連絡までの流れを説明する。クラウドコンピューティングシステムでは，障害発生（９１０）時にオペレータ１４０は，サーバ監視システム１１０から挙がってきた情報をもとに障害原因を特定するため，根本原因分析システム１１１による障害原因分析（９１１）を行う。その後，オペレータ１４０は，特定された障害原因をもとに，対象となる顧客を特定するため，波及先予測システム１１２を用いて顧客を特定する（９１２）。
【００４５】
その後，オペレータ１４０は，は，顧客ごとの連絡内容文面を作成するために，顧客連絡／優先度決定システム１１３を用いて顧客連絡文面の作成（９１３）を行う。文面作成後，オペレータ１４０はIT管理者（A社）１４１へ電話またはメールでの連絡（９１４）を行う，通常，（９１０）から（９１４）までの手順を障害発生ごとに行い，その間に発生した障害は，手順終了まで待って同様に処理される（９２１，９２２，９２３，９２４）。このため，顧客は未処理の障害連絡完了まで，この処理にかかる時間だけ障害の連絡を待たされることになる。
【００４６】
本実施例の特徴は，クラウドコンピューティングシステムの特徴を利用し，２件目以降の障害連絡までの処理を効率化することにある。障害発生（９４０）後，オペレータ１４０はサーバ監視システム１１０から挙がってきた情報をもとに障害原因を特定するために，障害根本原因分析システム１１１を用いて障害原因分析を行う（９４１）。その後，オペレータ１４０は，特定された障害原因をもとに，対象となる顧客を特定するため，波及先予測システム１１２を用いて顧客を特定する（９４２）。その後，波及先予測システム１１２は，直接の障害の対象となる顧客とは別に，今後障害が発生しうる顧客に対しての障害連絡文面を並行して作成する（９５１）。
【００４７】
このことは，クラウドコンピューティングシステムの顧客間でハードウェアを共有するという特徴にもとづく。たとえば，ある仮想サーバに障害が発生した場合，その根本原因は，ハードウェアやハードウェアの設定に起因する場合が多い。この場合，同様の障害は，同じハードウェアを共有するほかの顧客が利用するシステムでも発生する可能性が大きい。
【００４８】
このため，ある仮想サーバを直接利用する顧客だけでなく，その仮想サーバとハードウェアを共用する顧客に対して，同時に障害連絡文面を作成しておくことは，今後発生する顧客への連絡作業工数を削減する上で効果がある。この予測があたり，障害が発生した場合（９５０），オペレータ１４０は，前の障害連絡完了後，サーバ監視システム１１０から挙がってきた情報をもとに障害原因を特定するために，障害根本原因分析システム１１１による分析を行う（９５２）。
【００４９】
このとき，障害原因が先の障害と同じ場合，その原因に対しては顧客へ連絡する内容は同じになることから，オペレータ１４０は，あらかじめ作成していた連絡文面を用い，IT管理者（B社）１４２へ電話またはメールでの連絡を行う（９５３）。これにより，２社目以降の連絡完了までの時間を短縮できる。
【００５０】
図３は，サーバ稼働情報１２０，構成管理情報１２１の詳細を表している。
【００５１】
サーバ稼働情報１２０は，仮想サーバごとに１つずつ定義されるデータであり，仮想サーバ名２１０や，CPU使用率ログ２１１，ディスクI/Oログ２１２，ネットワークログ２１３，アクセスログ２１４，メモリ使用量ログ２１５，ディスク使用量ログ２１６などの情報を含むデータである。
【００５２】
構成管理情報１２１は，仮想サーバ管理情報１３０，物理サーバ管理情報１３１，ネットワーク管理情報１３２，ストレージネットワーク管理情報１３３，ストレージ管理情報１３４，ソフトウェア管理情報１３５などを含むデータである。
【００５３】
仮想サーバ管理情報１３０は，仮想サーバごとにユニークな，仮想サーバを管理するための情報であり，仮想サーバ名２２０，IPアドレス２２１，接続情報２２２，コア数２２３，周波数２２４，メモリ容量２２５，ディスク容量２２６，物理サーバ名２２７，ストレージ接続情報２２８，ソフトウェア情報２２９などの情報を含む。
【００５４】
物理サーバ構成情報１３１は，物理サーバごとにユニークな，物理サーバを管理するための情報であり，物理サーバ名２３０，IPアドレス２３１，コア数２３２，周波数２３３，メモリ容量２３４，ストレージ名２３５，ファームウェアバージョン２３６，ハイパバイザ種別２３７，接続情報２３８，設定情報２３９などの情報を含む。
【００５５】
ネットワーク管理情報１３２は，ネットワーク装置ごとにユニークな，ネットワーク装置を管理するための情報であり，装置名２４０，IPアドレス２５１，装置種別２４２，ファームウェアバージョン２５２，設定情報２４４，接続情報２４５などの情報を含む。
【００５６】
ファイバチャネルスイッチ管理情報１３３は，ファイバチャネルスイッチ装置ごとにユニークな，ファイバチャネルスイッチを管理するための情報であり，装置名２６０，IPアドレス２６１，設定情報２６２，ファームウェアバージョン２６３，接続情報２６４などの情報を含む。
【００５７】
ストレージ管理情報１３４は，ストレージ装置ごとにユニークな，ストレージを管理するための情報であり，装置名２６０，IPアドレス２６１，設定情報２６２，ファームウェアバージョン２６３，接続情報２６４などの情報を含む。
【００５８】
ソフトウェア管理情報１３５は，仮想サーバ，物理サーバ等にインストールされており，ソフトウェアを管理するための情報であり，ソフトウェア名２７０，設定情報２７１，バージョン情報２７２，ライセンス情報２７３などの情報を含む。
【００５９】
図４は，契約情報１２２，連絡文面テンプレート１２３，ログ１２４の詳細を表している。
【００６０】
契約情報１２２は，顧客管理情報１３６，顧客システム管理情報１３７などを含むデータである。
【００６１】
顧客管理情報１３６は，顧客ID２８０，契約サービス２８１，運用開始日２８２，運用終了日２８３，SLA２８４，クレーム数２８５，システム種別２８６，エンドユーザ数２８７，システム名２８８，企業名２８９，住所２９０，担当者名２９１，役職２９２，電話番号２９３，メールアドレス２９４，報告パターン２９５などの情報を含む。
【００６２】
顧客システム管理情報１３７は，システム名３１０，ルーティング情報３１１，利用仮想サーバ情報３１２，利用ソフトウェア情報３１３などの情報を含む。
【００６３】
連絡文面テンプレート１２３は，顧客への連絡文面を作る際のひな型になる情報であり，過去に発生した障害や原因，対策の種別等に応じて用意される情報である。原因ID３２０，対策方法３２１，過去文面３２２，お願い事項３２３などの情報を含む。
【００６４】
ログ１２３は，サーバ監視システム１１０，および障害根本原因分析システム１１１，および波及先予測システム１１２，および，顧客連絡／優先度決定システム１１３での処理に必要となるデータや，処理結果等を表している。障害ID３３０，障害部位３３１，障害発生時刻３３２，関連ID３３３，原因ID３３４，ログID３３５，原因正解率３３６などの情報を含む。
【００６５】
図５は，アラート１２５，障害根本原因１２６，障害波及先顧客情報１２７，連絡文面（メール）１２８，連絡文面（電話）１２９の詳細を表している。
【００６６】
アラート１２５は，障害ID３４０，障害発生時刻３４１などの情報を含む。
【００６７】
根本原因１２６は，障害ID３５０，システム名３５１，障害部位名３５２，障害原因３５３，メッセージ３５４などの情報を含む。
【００６８】
障害波及先顧客情報１２７は，障害ID３６０，顧客ID３６１，システム名３６２などの情報を含む。
【００６９】
連絡文面（メール）１２８は，メールアドレス３７０，件名３７１，障害発生時刻３７２，障害種別３７３，推定障害原因３７４，復旧予定時間３７５，お願い事項３７６，連絡先３７７，添付情報３７８などの情報を含む。
【００７０】
連絡文面（電話）１２９は，電話番号３８０，障害発生時刻３８１，障害種別３８２，推定障害原因３８３，復旧予定時間３８４，お願い事項３８５などの情報を含む。
【００７１】
図６は，データセンタ１００で，仮想マシン１３２・１３３・１３４・１３７・１３８・１３９等で発生した障害をサーバ監視システム１１０で障害検知（４００）した際の障害根本原因分析システム１１１，波及先予測システム１１２，顧客優先度／優先度決定システム１１３の処理の詳細である。
【００７２】
障害が発生すると（４００），サーバ監視システム１１０が障害を検知し，アラートを発生させ（４０１），障害根本原因分析システム１１１にアラート１２５の障害ID３４０を渡す。根本原因分析システム１１１がアラート１２５の障害ID３４０を受信すると（４０３），障害根本原因分析（４０４）を行い，障害の根本原因を突き止め，原因IDを特定し，この原因IDをログ１２４に一定期間保持する。一定期間ログ１２４に保持しておいた原因IDと，新たに発生した障害に対し，障害根本原因分析システム１１１により特定した原因IDが一致するかどうかを確認する（４０５）。
【００７３】
一致するものがない場合，障害根本原因１２６のデータ群を波及先予測システム１１２に通知を行う（４０６）。
【００７４】
ここで障害根本原因分析とは，計算機を用いて，監視結果から障害の原因となりうる事象を推定する処理である。この処理手法としてFTA（Fault Tree Analysis）を用いてもよい。クラウドコンピューティングシステムの管理者は，あらかじめクラウドコンピューティングシステムで発生する既知の障害に対して，事故に対してその原因となる事象と，監視データの結果にもとづきその事象が原因となる確率とを論理式で記述したFault Treeを作成しておく。
【００７５】
障害発生時には，障害IDにより示されるサーバ監視システムからの監視結果にもとづき，その監視結果から導かれうる事故の大きさと，その監視結果を導く根本原因となりうる障害部位を導出する。この障害部位は複数であってもよく，複数の障害部位の多重障害により発生したとみなしてもよい。ここで，監視結果にもとづく事故の大きさは，監視結果と，あらかじめ定めた閾値との比較により導出する。たとえば，ネットワークの監視において，一分間Pingの応答が返らない場合に障害とみなすとしている場合，Pingの応答が一分以上返らなければ値として1を設定し，一分未満に応答が返っているなら値として０を設定するといった状態の二値化の処理が該当する。Fault Treeは論理式で記述されるため，結果として，ある監視結果に対して発生うる事故の種類とその確率が導出される。また監視結果から導出される根本原因は，Fault Treeの構造により導出される。
【００７６】
たとえば，仮想サーバのネットワークIOエラーが見つかった場合，この原因として，ハイパバイザの障害，物理サーバのNIC（Network Interface Card）の障害，スイッチと接続しているケーブルの断線などの原因となる事象を発生確率付きで定義しておき，発生確率の高い順にログデータから異常がないか検出する。このように順に異常を判断することで，最初のネットワークIOエラーの発生につながった確率の高い障害部位を特定していくことができる。根本原因分析システム１１１は，導出した障害部位と特定した根本原因ごとにあらかじめ定義しておいた原因IDを付与し，障害IDによって示されるログデータに格納する。
【００７７】
一方で，ログ１２４に保持しておいた原因ID３３４と，新たに発生した障害に対し，障害根本原因分析システム１１１により特定した原因IDが一致するものがある場合（４０５）は，障害根本原因１２６を顧客連絡／優先度決定システム１１３に送信する（４０７）。波及先予測システム１１２が障害根本原因１２６を受信すると（４１０），障害波及先顧客の特定を行い（４１１），障害波及先顧客情報１２７を出力する。波及先予測システムの詳細は図７の説明で詳細に述べる。顧客の特定後，障害波及先顧客名１２７の障害ID３６０，顧客ID３６１，システム名３６２を含むデータ群を顧客連絡／優先度決定システム１１３に送信する（４１２）。波及先予測システム１１１の詳細は後述する。顧客連絡／優先度決定システム１１３が障害波及先顧客名１２７の障害ID３６０，顧客ID３６１，システム名３６２を含むデータ群を受信すると（４１４），顧客への連絡優先度の決定処理と，顧客への連絡文面の作成処理を行う（４１５）。顧客連絡／優先度決定システム１１３の詳細は図７，図８で詳細に述べる。決定した連絡優先度と連絡文面をDBに格納し，それに対応する障害IDをキューに格納する（４１６）。新たに発生した障害の障害IDがすでにキューに格納済みでないことを確認し（４１７），障害IDがすでに格納されている場合は，障害が発生した優先順位の高い顧客への連絡文面をオペレータ１４０が閲覧する画面へ表示を行う（４１８）。キューに格納された障害IDと，障害IDを比較し，一致しなかった場合は，４１４の処理に戻る。オペレータ１４０は表示画面を確認し（４１９），連絡文面を確認（４２０）した後，該当する顧客へ連絡を行う（４２１）。顧客への連絡手順の詳細は後述する。
【００７８】
図７は，波及先予測システム１１２の処理の詳細である。
【００７９】
波及先予測システム１１２は，障害根本原因分析システム１１１からの受信データを保持するバッファを持ち，複数の受信データを保持できるものとする。データは，キューのように受信順にデータが並べられており，どのデータが最も古いデータかわかるようになっているものとする。また各受信データと対応して，そのデータが処理済みかどうかを示すフラグをメモリ上に有するものとする。波及先予測システム１１２は，障害根本原因分析システム１１１より，障害根本原因１２６を受信（４３１）する。
【００８０】
波及先予測システム１１２は，受信バッファの中の受信が古く，また，処理済みフラグが設定されていない，未処理の障害IDがあるかどうかの確認を行う（４３２）未処理の障害IDがない場合は，送信キューにデータがあるかを確認する（４３４）。送信キューにデータがない場合，処理を終了（４３４）し，送信キューにデータがある場合は，波及先予測システム１１２で作成した障害波及先顧客情報１２７を，顧客連絡／優先度決定システム１１３に送信するとともに，障害波及先顧客情報１２７の障害ID，原因IDをログ１２４に格納し，処理を終了する（４３８）。未処理の障害IDがある場合，物理サーバ障害であるかを確認する（４３５）。
【００８１】
物理サーバ障害であった場合は，構成管理情報１２１の物理サーバ管理情報１３１の物理サーバ名２３０を検索キーにして，構成管理情報１２１の仮想サーバ管理情報１３０の物理サーバ名２２７と一致するものを検索し，まずは仮想サーバの特定を行う。さらに，仮想サーバ名２２０を検索キーとして，契約情報１３７の顧客システム管理情報１３７の利用仮想サーバ情報を取得し，システム名３１０を検索キーとして，顧客管理情報１３６のシステム名２８８を検索し，顧客IDを突き止める（４４０）。
【００８２】
物理サーバ障害ではない場合は，ソフトウェア障害であるかを確認する（４３６）。ソフトウェア障害であった場合は，構成管理情報１２１のソフトウェア管理情報１３５のソフトウェア名を検索キーにして，構成管理情報１２１の仮想サーバ管理情報１３０のソフトウェア情報２２９と一致するものを検索し，まずは仮想サーバの特定を行う。さらに，仮想サーバ名２２０を検索キーとして，契約情報１３７の顧客システム管理情報１３７の利用仮想サーバ情報を取得し，システム名３１０を検索キーとして，顧客管理情報１３６のシステム名２８８を検索し，顧客IDを突き止める（４４１）。
【００８３】
ソフトウェア障害ではない場合は，ネットワーク障害であるかを確認する（４３７）。ネットワーク障害であった場合は，構成管理情報１２１のネットワーク管理情報１３２の接続情報２４５を検索キーにして，構成管理情報１２１の仮想サーバ管理情報１３０の接続情報２２２と一致するものを検索し，まずは仮想サーバの特定を行う。さらに，仮想サーバ名２２０を検索キーとして，契約情報１３７の顧客システム管理情報１３７の利用仮想サーバ情報を取得し，システム名３１０を検索キーとして，顧客管理情報１３６のシステム名２８８を検索し，顧客IDを突き止める（４４２）。
【００８４】
ネットワーク障害でない場合は，ストレージ障害であるかを確認する（４３８）。ストレージ障害であった場合，構成管理情報１２１のストレージ管理情報１３４の接続情報２５３を検索キーにして，構成管理情報１２１の仮想サーバ管理情報１３０のストレージ接続情報２２８と一致するものを検索し，まずは仮想サーバの特定を行う。さらに，仮想サーバ名２２０を検索キーとして，契約情報１３７の顧客システム管理情報１３７の利用仮想サーバ情報を取得し，システム名３１０を検索キーとして，顧客管理情報１３６のシステム名２８８を検索し，顧客IDを突き止める（４４３）。
【００８５】
ストレージ障害ではない場合は，仮想サーバ障害であるかを確認する（４３９）。
【００８６】
仮想サーバ障害であった場合は，仮想サーバ名２２０を検索キーとして，契約情報１３７の顧客システム管理情報１３７の利用仮想サーバ情報を取得し，システム名３１０を検索キーとして，顧客管理情報１３６のシステム名２８８を検索し，顧客IDを突き止める（４４４）。
【００８７】
仮想サーバ障害でない場合は，その他の障害波及先推定困難な障害としてメッセージを記載し，処理４３２に戻る（４４７）。
【００８８】
次に波及先予測システム１１２は，処理４４０，および４４１，および４４２，および４４３，および４４４の処理の結果として突き止めた顧客IDとシステム名と，障害根本原因分析システム１１１から受信した障害IDと，波及先予測システム１１２の処理の結果として付与する原因ＩＤと障害波及先顧客情報１２７を送信キューに格納する。 
図８は，顧客連絡／優先度決定システム１１３の連絡文面作成処理の詳細である。顧客連絡／優先度決定システム１１３は，波及先予測システムから送信した障害波及先顧客情報１２７を受信すると（４５１），障害波及先顧客情報１２７の顧客ID３６１とシステム名３６２の情報を検索キーにして，契約情報１２２の顧客管理情報１３６から，一致するレコードの報告パターン２９５を確認する。報告パターン２９５をもとに，電話連絡かメール連絡であるか，両方であるのかを判断する（４５２）。連絡方法の判断方法は後程詳細に述べる。メール連絡であると判断した場合，原因IDに対応する連絡文面（メール）１２８の有無を確認する（４５３）。
【００８９】
原因IDの対応する連絡文面（メール）１２８が存在する場合は，原因IDに対応する連絡文面（メール）１２８をコピーし，原因IDを件名３７１に挿入し，連絡文面（メール）１２８の準備を行う（４５５）。件名は原因IDではなく，別の情報でもよい。原因IDに対応する連絡文面（メール）１２８が存在しない場合は，オペレータ１４０が連絡文面（メール）１２８を作成する（４５６）。連絡文面（メール）１２８に，顧客IDにもとづき，契約情報１２２の顧客管理情報１３６のメールアドレス３７０を検索し，メールに挿入し，ログなどの添付するファイルがあれば，添付する（４５９）。その後，アラート１２５の障害IDから障害発生時刻３７２を検索後，メールに挿入する（４６１）。
【００９０】
顧客連絡／優先度決定システム１１３は，処理４５２で電話連絡であると判断した場合は，原因IDに対応する連絡文面（電話）１２９があるかを確認する（４５４）。原因IDに対応する連絡文面（電話）１２９が存在する場合は，原因IDに対応する連絡文面（電話）１２９をコピーし，連絡の準備を行う（４５７）。原因IDに対応する連絡文面（電話）１２９が存在しない場合は，オペレータ１４０が連絡文面（電話）１２９を作成する（４５８）。連絡文面（電話）１２９に，顧客IDにもとづき，契約情報１２２の顧客管理情報１３６の電話番号２９３を検索し，連絡文面（電話）に挿入する。
【００９１】
連絡文面（電話）１２９の準備を行う（４５７）。原因IDに対応する連絡文面（電話）１２９が存在しない場合は，オペレータ１４０が連絡文面（電話）１２９を作成する（４５８）。連絡文面（電話）１２９に顧客電話番号を挿入する（４６０）。電話連絡，メール連絡同様に，復旧時間を計算し，文面への挿入し（４６２），優先度決定部に障害ID，顧客ID，原因ID，システム名，連絡文面を渡す（４６３）。電話連絡，メール連絡同様に，障害発生時刻と，障害内容から復旧時間を計算し，連絡文面（メール）１２８，または連絡文面（電話）１２９へ挿入し（４６２），優先度決定部に障害ID，顧客ID，原因ID，システム名，連絡文面（メール）１２８，または連絡文面（電話）１２９を渡す（４６３）。
【００９２】
図９は，顧客連絡／優先度決定システム１１３の顧客連絡の優先度決定処理の詳細である。顧客連絡／優先度決定システム１１３は，連絡文面作成処理部から送信された連絡文面（メール）１２８，または，連絡文面（電話）１２９を受信（４７１）すると，キューに格納する（４７２）。このキューの構造として，受信した連絡文面（メール）１２８，または，連絡文面（電話）１２９に加え，優先度の格納も行うことができるものとする。顧客連絡／優先度決定システム１１３は，一定時間ごとにキューに格納された情報に対して処理を行うものとする。まず，顧客連絡／優先度決定システム１１３は，キュー内に格納したすべてのデータに対して，連絡優先度が付与されているかを確認する（４７３）。  連絡優先度がまだ付与されていないデータがある場合，顧客連絡／優先度決定システム１１３は，仮想サーバ稼働情報をもとに，CPU使用率，アクセス数ごとにあらかじめ定めた閾値にもとづき，優先度を計算する（４７４）。この処理の一例としては，ＣＰＵ使用率が50%を以上の場合は1点，50%未満ならば0点として判断し，この結果の点数を項目ごとに加算していく処理となる。次に，構成管理情報をもとに，システム種類にもとづく優先度を計算し，処理４７４の計算結果に加える（４７５）。
【００９３】
最後に，契約情報をもとに，SLA（Service Level Agreement），クレーム数，利用実績にもとづく優先度を計算し，処理４７５の計算結果に加え，これを対象となった連絡文面（メール）１２８，または，連絡文面（電話）１２９に結び付けて，優先度としてキューに格納する（４７６）。ただし，このパラメータの計算方法は一例であり，その他のパラメータを追加してもよい。処理４７６後，顧客連絡／優先度決定システム１１３は，再度処理４７３を実行する。こうしてキュー内のすべてのデータに対して優先度を付与が完了すると，顧客連絡／優先度決定システム１１３は，連絡優先度順にキューの並べ替えを行う（４７７）。
【００９４】
ここで，顧客連絡／優先度決定システム１１３は，障害の直接の対象や，関連する障害であってもＳＬＡで報告することが求められている障害が含まれているかどうかを調べる（４７８）。連絡すべきものがある場合，優先度の高い顧客への連絡文面から画面に表示させ，新規アラート待ちの状態に移行する（４８１）。処理４７８ですぐに連絡すべきデータがない場合，新規障害発生待ちの状態に移行する（４８２）。この状態で新規障害が発生した場合，すなわち，図6において，処理４０７の結果として障害根本原因１２６が顧客連絡／優先度決定システム１１３に送信されてきた場合，顧客連絡／優先度決定システム１１３は，一定時間，同時に発生した障害がないかを待ち，その間に受信した障害に対して，原因ＩＤをキーに連絡優先度順にキューに一致するものがあるか確認し，一致したものを優先度の高い順に画面に表示させる。
【００９５】
図１０は，顧客連絡／優先度決定システム１１３の連絡方法決定処理の詳細である。顧客への連絡方法は，障害が発生した時間帯や障害内容，顧客との契約に応じて，電話での連絡なのか，メールでの連絡なのかを例外的な場合にも対応する必要がある。波及先予測システム１１２から送信した障害波及先顧客名１２７を顧客連絡／優先度決定システム１１３で受信した後（４９１），顧客連絡／優先度決定システム１１３は，顧客IDを検索キーとして，契約情報１２２の顧客管理情報１３６の顧客ID２８０と一致する報告パターン２９５を検索し，標準連絡方法を参照し，連絡方法を確認する（４９２）。もし，報告パターン２９５に例外がなければ，標準連絡方法にしたがい顧客への連絡を行う（４９７・４９８・４９９）。
【００９６】
例外がある場合は，障害に応じた連絡方法があるかを確認し（４９５），障害に応じた連絡方法がある場合は，障害連絡に応じた連絡方法にしたがい連絡を行う（４９７・４９８・４９９）。障害に応じた連絡方法がない場合は，時刻により連絡方法が異なるかを確認し（４９６），時刻による連絡方法にしたがい連絡を行う（４９７・４９８・４９９）。
【００９７】
図１１は，顧客へ連絡する際の優先順位決定部の実施例である。５０８は連絡優先順位を決定するためのパラメータの例を表している。たとえば，顧客企業名５００，CPU使用率５０１，アクセス数５０２，システム種類５０３，SLA（サポート時間）５０４，SLA（契約稼働率残り時間）５０５，クレーム数５０６，利用実績５０７を利用する。５０８以外のパラメータを利用してもよい。５１９は連絡優先順位の決定方法を表している。閾値例５１３のように，５１９のパラメータに閾値や点数例５１３（重みづけ）を決定し，５０８のパラメータをあてはめ，合計点数を求める。この点数が高いものが，連絡優先順位の上位にくる。パラメータの閾値５１３，点数例５１４は一例であり，変更してもよい。
【符号の説明】
【００９８】
１００…データセンタ
１０１…クラウドコンピューティングシステム
１０２…ネットワーク
１０３…管理用ルータ
１０４…ルータ
１０５…ストレージ
１１０…サーバ監視システム
１１１…障害根本原因分析システム
１１２…波及先予測システム
１１３…顧客連絡／優先度決定システム
１１４…Webポータル
１１５…顧客システム（A社）
１１６…顧客システム（B社）
１３０・１３５…物理サーバ
１３１・１３６…ハイパバイザ
１３２・１３３・１３４・１３７・１３８・１３９…仮想マシン
１４０…オペレータ
１４１…IT管理者（A社）
１４２…IT管理者（B社）
【図１】
2013222313.tif 000003
【図２】
2013222313.tif 000004
【図３】
2013222313.tif 000005
【図４】
2013222313.tif 000006
【図５】
2013222313.tif 000007
【図６】
2013222313.tif 000008
【図７】
2013222313.tif 000009
【図８】
2013222313.tif 000010
【図９】
2013222313.tif 000011
【図１０】
2013222313.tif 000012
【図１１】
2013222313.tif 000013