特許 6373217 情報処理装置、プログラム、情報提供方法

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

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

(11)【特許番号】6373217

(24)【登録日】2018年7月27日

(45)【発行日】2018年8月15日

(54)【発明の名称】情報処理装置、プログラム、情報提供方法

(51)【国際特許分類】

   G06F 11/07 20060101AFI20180806BHJP

【ＦＩ】

   G06F11/07 190

   G06F11/07 140V

【請求項の数】11

【全頁数】37

(21)【出願番号】特願2015-70684(P2015-70684)

(22)【出願日】2015年3月31日

(65)【公開番号】特開2016-192016(P2016-192016A)

(43)【公開日】2016年11月10日

【審査請求日】2017年9月20日

(73)【特許権者】

【識別番号】591106864

【氏名又は名称】富士通エフ・アイ・ピー株式会社

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(72)【発明者】

【氏名】齋藤 一将

【審査官】 多賀 実

(56)【参考文献】

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

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

【文献】 国際公開第２０１４／１０３０２９（ＷＯ，Ａ１）

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

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

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

Ｇ０６Ｆ１１／０７

Ｇ０６Ｆ１１／３０−１１／３４

Ｇ０６Ｑ５０／００

Ｇ０６Ｑ５０／１０

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

【請求項1】

機器の稼動状況を監視し所定状況が検出された場合に前記機器の担当者に通知する装置と、通信可能な情報処理装置であって、
前記担当者と他の担当者を対応づける担当者情報から、前記担当者に対応づけられている前記他の担当者を読み出す読出手段と、
前記他の担当者が前記機器を用いた作業を行う前に行う作業前行為の履歴が時刻と共に記録された履歴情報を取得する情報取得手段と、
前記所定状況の発生よりも前の前記作業前行為を含む前記履歴情報を前記担当者が使用する端末に提供する情報提供手段と、を有する情報処理装置。

【請求項2】

前記作業前行為は、前記機器が配置された施設への入館、前記機器へのログイン、又は、前記機器が格納されているラックの開放であり、
前記履歴情報として、
前記他の担当者が前記所定状況の発生時に前記施設へ入館している旨の入館情報、
前記他の担当者が前記所定状況の発生時に前記機器へログインしている旨のログイン情報、又は、
前記所定状況の発生時の前記ラックの開閉情報、の少なくとも一つを前記情報提供手段が前記端末に提供する請求項１に記載の情報処理装置。

【請求項3】

前記情報取得手段は、前記所定状況の発生時又は前記所定状況の発生よりも前に撮影された前記機器の撮影データを取得し、
前記情報提供手段は、前記撮影データを前記端末に提供する請求項１又は２に記載の情報処理装置。

【請求項4】

前記情報取得手段は、前記他の担当者の識別情報と共に前記他の担当者の連絡先情報を取得し、
前記情報提供手段は、前記作業前行為を行った前記他の担当者の前記識別情報及び前記連絡先情報を前記端末に提供する請求項１〜３のいずれか１項に記載の情報処理装置。

【請求項5】

前記他の担当者が前記所定状況の発生時に前記機器が配置された施設へ入館している旨の入館情報、
前記他の担当者が前記所定状況の発生時に前記機器へログインしている旨のログイン情報、及び、前記機器が格納されているラックの前記所定状況の発生時の開閉情報、を総合して、前記他の担当者が前記機器を用いた作業を行っているか否かを推定する推定手段を有し、
前記推定手段による推定結果を前記端末に提供する請求項１〜４のいずれか１項に記載の情報処理装置。

【請求項6】

前記情報提供手段は、前記端末が表示する画面の画面情報を作成するものであり、
１つの画面に前記入館情報、前記ログイン情報、前記ラックの開閉情報、前記情報取得手段が取得した前記機器の撮影データ、前記他の担当者の連絡先情報及び前記推定結果が表示される前記画面情報、又は、１つの画面に前記入館情報、前記ログイン情報、前記機器が撮影された撮影データ、前記ラックの開閉情報、前記他の担当者の連絡先情報及び前記推定結果をそれぞれ表示させる個別の操作受付部が表示される前記画面情報を作成し、
前記情報提供手段は前記画面情報を前記端末に送信する請求項５に記載の情報処理装置。

【請求項7】

前記情報提供手段は、前記端末が表示する画面の画面情報を作成するものであり、
前記情報取得手段は、前記装置が前記機器の前記所定状況を検知するため監視する時系列の監視情報、前記機器に生じた前記所定状況を含むイベントと該イベントの時刻を取得し、
前記情報提供手段は、前記監視情報が時間軸に対するグラフとして描画され、該グラフ上に前記イベントの発生を表すイベントマークが描画される前記画面情報を作成し、
前記情報提供手段は前記画面情報を前記端末に送信する請求項１〜６いずれか１項に記載の情報処理装置。

【請求項8】

前記情報提供手段は前記イベントマークに、前記他の担当者の連絡先情報、及び、前記機器が設置された施設への入館申請、遠隔メンテナンス又は前記所定状況の検知を抑止する設定を前記担当者が行うための画面がリンクされた前記画面情報を作成する請求項７に記載の情報処理装置。

【請求項9】

前記情報提供手段は、前記時間軸に対し前記グラフとして描画される前記監視情報の変更を受け付けるボタンが描画される前記画面情報、又は、
前記グラフ上に描画される前記イベントマークとして表示される前記イベントの変更を受け付けるボタンが描画される前記画面情報、の少なくともいずれかを作成する請求項７又は８に記載の情報処理装置。

【請求項10】

機器の稼動状況を監視し所定状況が検出された場合に前記機器の担当者に通知する装置と、通信可能な情報処理装置を、
前記担当者と他の担当者を対応づける担当者情報から、前記担当者に対応づけられている前記他の担当者を読み出す読出手段、
前記他の担当者が前記機器を用いた作業を行う前に行う作業前行為の履歴が時刻と共に記録された履歴情報を取得する情報取得手段、
前記所定状況の発生よりも前の前記作業前行為を含む前記履歴情報を前記担当者が使用する端末に提供する情報提供手段、として機能させるためのプログラム。

【請求項11】

機器の稼動状況を監視し所定状況が検出された場合に前記機器の担当者に通知する装置と、通信可能な情報処理装置によって行われる情報提供方法であって、
前記担当者と他の担当者を対応づける担当者情報から、前記担当者に対応づけられている前記他の担当者を読み出す読出ステップと、
前記他の担当者が前記機器を用いた作業を行う前に行う作業前行為の履歴が時刻と共に記録された履歴情報を取得する情報取得ステップと、
前記所定状況の発生よりも前の前記作業前行為を含む前記履歴情報を前記担当者が使用する端末に提供する情報提供ステップと、を有する情報提供方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、情報処理装置、プログラム及び情報提供方法に関する。

【背景技術】

【0002】

自社が提供するサービスや社内システムのサーバなどがデータセンターなどに設置される場合がある。データセンターは単にサーバやその設置場所などを提供する以外に、サーバなどの稼動状況を監視したり、障害が検出されるとその内容をアラームとして顧客の担当者に通知したりする運用・監視システムを有している。

【0003】

アラームを通知された顧客の担当者（例えば、ＳＥ：System Engineer）は、顧客が提供するサービスの停止時間をできる限り短くするため障害発生時に素早く初動対応することが重要とされている。このため、アラームが通知された顧客の担当者は、遠隔地からコマンドを送信してサーバの稼動状況を確認したり、必要であればデータセンターに移動し自社の区画（ラック）のサーバなどをリセットしたりケーブルをつなぎ替えたりするなどの復旧作業を行う。

【0004】

しかしながら、データセンターは担当者によりメンテナンス（機能のアップグレードやハードウェアの交換など）される頻度が少なくない。そして、このメンテナンスによる影響が検知されアラームが通知される可能性がある。このため、アラームがメンテナンスによるものであるため対応不要なのか、メンテナンスとは関係がなく担当者の対応が必要なのかを担当者が切り分ける必要が生じてしまう。

【0005】

図１を用いて従来の運用・監視システムによる不都合について説明する。図１は従来の運用・監視システムにおける不都合を説明する図の一例である。データセンター１１ではＸ社システム１９ｘ、Ｙ社システム１９ｙ、及び、Ｚ社システム１９ｚが運用されている。図１ではＸ社システム１９ｘを例にして説明するが、Ｙ社システム１９ｙ又はＺ社システム１９ｚについても同様である。
（１）Ｘ社システム１９ｘはＸ社の担当者（Ａさん１４、Ｂさん１６、Ｃさん１７、Ｄさん１８）により運用されているが、このうちＢさん１６が緊急を要する予定外の作業のためにデータセンター１１に入館し、Ｘ社システム１９ｘのメンテナンスを開始した。
（２）これにより、Ｘ社システム１９ｘを監視する運用・監視システム３０はＸ社システム１９ｘの障害を検出する。
（３）運用・監視システム３０又は運用・監視システム３０のオペレータは、アラームの通知先として登録されている担当者のＡさん１４にアラームの内容を連絡する。
（４）Ａさん１４はユーザ端末７０を用いて運用・監視システム３０にアクセスし、アラームの内容（例えばサーバ名、アラームの詳細など）を把握する。
（５）Ａさん１４はアラームの内容からメンテナンスによる可能性を考慮するが、誰がメンテナンス作業を行っているかは見当が付かない。このため、可能性があるＸ社の担当者（Ｃさん１７、Ｄさん１８）に連絡する。
（６）最終的に、Ａさん１４がＢさん１６に連絡を取るとＢさん１６がメンテナンス中であることを確認できる。

【0006】

このように、メンテナンスが行われた場合、担当者はアラームがメンテナンスによるものかどうかの切り分けに時間がかかる場合が生じる。また、切り分けをできるまではアラームを抑止（障害が生じてもアラームが発報されることを禁止すること）できないので、Ａさん１４は定期的にアラームを受信しなければならない。

【0007】

そこで、従来、メンテナンスによるアラームかそうでないかを切り分ける技術が考案されている（例えば、特許文献１、２参照。）。特許文献１には、メンテナンス等の時間帯を予め設定しておき、その時間帯にはシステムに関する異常情報が出力されないようにする異常情報出力装置が開示されている。また、特許文献２には、作業時間を含む作業申請情報を用いて、作業時間内にアラームが発生したアラーム情報を作業アラームとして抽出して抑止パターンを生成するアラームパターン解析装置が開示されている。これらの技術によれば、担当者に通知されるアラームは対応すべき障害によるものであることが明らかなので、担当者が対応すべきか否かを切り分ける必要性を低減できる。

【先行技術文献】

【特許文献】

【0008】

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

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

【発明の概要】

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

【0009】

しかしながら、特許文献１に開示された技術では、予め定められた時間帯以外に担当者がメンテナンスした場合には障害が検知されてしまうという問題がある。すなわち、実際のメンテナンスの実施状況に基づいてアラームを抑止する技術ではないため、予定外のメンテナンスが行われた場合、障害の検知によりアラームが発報されてしまう。また、特許文献２に開示された技術ではメンテナンスに伴うアラームを必ずしも抑止できるとは限らないという問題がある。

【0010】

本発明は、上記課題に鑑み、対応が必要なアラームかそうでないかを切り分けるための情報を提供可能な情報処理装置を提供することを目的とする。

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

【0011】

上記課題に鑑み、本発明は、機器の稼動状況を監視し所定状況が検出された場合に前記機器の担当者に通知する装置と、通信可能な情報処理装置であって、前記担当者と他の担当者を対応づける担当者情報から、前記担当者に対応づけられている前記他の担当者を読み出す読出手段と、前記他の担当者が前記機器を使用する作業を行う前に行う作業前行為の履歴が時刻と共に記録された履歴情報を取得する情報取得手段と、前記所定状況の発生よりも前の前記作業前行為を含む前記履歴情報を前記担当者が使用する端末に提供する情報提供手段と、を有する。

【発明の効果】

【0012】

対応が必要なアラームかそうでないかを切り分けるための情報を提供可能な情報処理装置を提供することができる。

【図面の簡単な説明】

【0013】

【図1】従来の運用・監視システムにおける不都合を説明する図の一例である。

【図2】本実施形態の運用・監視システムの概略を説明する図の一例である。

【図3】管理システムのシステム構成図の一例である。

【図4】管理支援システムのハードウェア構成図の一例である。

【図5】管理システムの機能ブロック図の一例である。

【図6】ラック配置画像の一例を示す図である。

【図7】担当者対応画面情報によりユーザ端末に表示される担当者対応画面を模式的に示す図の一例である。

【図8】カメラの配置を説明する図の一例である。

【図9】管理システムがアラームを発報しユーザ端末がそれを確認するまでの処理手順を示すシーケンス図の一例である。

【図10】アラーム一覧画面、アラーム詳細画面の一例を示す図である。

【図11】入館情報画面、ログイン情報画面、カメラ情報画面の一例を示す図である。

【図12】センサー検知情報画面、推奨作業情報画面の一例を示す図である。

【図13】メンテナンス推定部がメンテナンスによる可能性が高いか否かを判定する手順を示すフローチャート図の一例である。

【図14】メンテナンス推定部がメンテナンスによる可能性が高いか否かを判定する手順を示すフローチャート図の一例である（変形例）。

【図15】事象詳細確認画面の一例を示す図である。

【図16】電話連絡先一覧画面、アラーム抑止申請画面の一例を示す図である。

【図17】画面作成部がアラーム詳細画面の画面情報を作成する手順を示すフローチャート図の一例である。

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

【0014】

以下、本発明を実施するための形態について図面を参照しながら説明する。

【0015】

＜本実施形態の運用・監視システムによるアラーム判断＞
図２を用いて本実施形態の運用・監視システムの概略を説明する。図２は本実施形態の運用・監視システムの概略を説明する図の一例である。
（１）本実施例の運用・監視システム３０は、定期的に、Ｘ社システム１９ｘへのログイン情報、データセンター１１への入館情報、及び、センサー検知情報（ラックのドアセンサーなど）の少なくとも１つを取得して、データベース９に記録する。担当者は、メンテナンスの前にＸ社システム１９ｘへログインし、データセンター１１へ入館し、必要であればラックを開放する（これらは作業前行為の一例である）。したがって、担当者（例えば、Ｂさん１６）がＸ社システム１９ｘのメンテナンスを行えば、ログインした履歴、入館した履歴、又は、センサーがラックの開放を検知した履歴の少なくともいずれかがデータベース９に記録されると考えられる。
（２）Ｘ社システム１９ｘの担当者であるＢさん１６が緊急を要する予定外の作業のためにデータセンター１１に入館し、Ｘ社システム１９ｘのメンテナンスを開始した。
（３）これにより、Ｘ社システム１９ｘを監視する運用・監視システム３０はＸ社システム１９ｘの障害を検知する。
（４）運用・監視システム３０又は運用・監視システム３０のオペレータはアラームの通知先として登録されている担当者のＡさん１４にアラームの内容を連絡する。
（５）Ａさん１４は、運用・監視システム３０と連携している管理支援システム５０にアクセスし、アラームの内容を確認する。本実施形態では、サーバ名、アラームの詳細以外に、アラーム発生時点の入館情報、ログイン情報又はセンサー検知情報の少なくとも１つをＡさん１４が閲覧できる。
（６）Ａさん１４は、Ｂさん１６がログイン中及び入館中であることを確認できるため、Ｃさん１７、Ｄさん１８に連絡することなくＢさん１６と連絡する。これにより、Ｂさん１６がメンテナンス中であることを確認できる。また、速やかにアラームを抑止することができる。

【0016】

このように、本実施形態では、担当者が管理支援システム５０に問い合わせるだけで、アラームがメンテナンスによるものかどうかを判別できる。また、実際にメンテナンスを行っている担当者が誰なのかすぐ分かるため、状況確認に要する時間も短縮できる。

【0017】

＜用語について＞
障害…アラームの発報基準を満たす事象という狭義の意味と、必ずしもアラームの発報を伴わない事象という広義の意味がある。
アラーム…予め定められた発報基準を満たす障害が検出されたことを通知すること、又は、通知そのものをいう。
メンテナンス…被監視システム１９を構築し、維持し、保守し及び復帰等させることをいう。メンテナンスにはアラームをもたらすものとそうでないものがあるが、本実施形態では主にアラームをもたらしたメンテナンスについて説明される。
作業…メンテナンスを行うことをいう。メンテナンス作業と称される場合がある。本実施形態ではメンテナンスと作業を厳密に区別しなくてよい。
担当者…被監視システム１９を構築し、維持し、保守し及び復帰等させる者である。このため、データセンター１１に入館するか又はログインする資格を有する。本実施形態ではアラームが通知される者も担当者であるが、アラームの通知を受ける者は担当者でなくてもよい。

【0018】

＜構成例＞
図３は、管理システム３００のシステム構成図の一例を示す。管理システム３００は、運用・監視システム３０、管理支援システム５０、入館管理システム２０、及び、ユーザ端末７０がネットワークＮを介して通信可能に接続される。なお、運用・監視システム３０、被監視システム１９、及び、入館管理システム２０がデータセンター１１内に設置されている。

【0019】

データセンター１１は、サーバやルータなどのＩＴ機器を効率的に稼動させるための設備が整えられた施設をいう。例えば、ＩＴ機器に供給される十分な電力が確保されており、冗長化された通信回線が配備されている。また、年間を通して温度や湿度もほぼ一定になるように制御され、ＩＴ機器の温度の上昇が抑制されている。 さらに災害時など、電力の供給が完全に止まってしまっても、自家発電装置やＵＰＳ（無停電電源装置）により、一定時間は継続的に稼動できるようになっている。

【0020】

データセンター１１には、サーバやネットワークを利用者に開放するホスティングサービスと利用者が所有するサーバなどの機器をデータセンター１１に預けるハウジングサービスがある。本実施形態の管理システム３００はどちらのサービス形態にも対応できる。すなわち、サーバなどの機器の所有権の所在は問われない。また、サーバは仮想サーバでもよく、クラウドサービスが提供される場合もある。

【0021】

このデータセンター１１には運用・監視システム３０が配置されており、運用・監視システム３０はデータセンター１１における被監視システム１９の各種の監視サービスやセキュリティーサービスを提供する。なお、データセンター１１内に運用・監視システム３０が配置されているが図示する形態は模式的なものであり、運用・監視システム３０がデータセンター１１内の被監視システム１９を外部から監視しても差し支えない。

【0022】

データセンター１１には、また、被監視システム１９と入館管理システム２０が配置されている。被監視システム１９は上述したＸ社システム１９ｘ、Ｙ社システム１９ｙ又はＺ社システム１９ｚなど、運用・監視システム３０により監視されるシステムである。具体的には、被監視システム１９は１つ以上のサーバ、及び、周辺装置である。したがって、データセンター１１には少なくとも１つ以上の被監視システム１９が配置されている。各被監視システム１９はそれぞれラック内に隔離して配置される。このため、被監視システム１９の担当者は、原則的に自社の被監視システム１９のみしかメンテナンスできない（データセンター１１の技術者（ＳＥ）は複数社のシステムをメンテナンスする場合がある）。

【0023】

また、データセンター１１にはカメラ２１とセンサー２２が配置されている。詳細は後述されるが、カメラ２１は被監視システム１９を撮影可能な位置に配置されている。カメラ２１が被監視システム１９を撮影することで、サーバのＬＥＤランプの点灯状態やメンテナンス中の担当者を撮影することができる。センサー２２は例えばラックの開閉を検知する検出装置であり、被監視システム１９が格納されているラックが開状態か閉状態かを検出する。

【0024】

入館管理システム２０は、担当者のデータセンター１１への入館を管理するシステムである。入館管理の仕組みは様々だが、入館管理システム２０は例えばＩＣカードリーダを有し、担当者が携帯するＩＣカードから担当者ＩＤを読み取ることで担当者の入館及び退館を検知する。被監視システム１９の担当者は予めデータセンター１１に登録されており、担当者がデータセンター１１に入館した時刻、及び、退館した時刻が担当者の識別情報と共に記録されている。なお、入館管理システム２０がデータセンター１１の外部に配置されても差し支えない。

【0025】

運用・監視システム３０は上述した監視サービスやセキュリティーサービスを行う。監視サービスには、例えば、機器のＰＩＮＧ疎通、サーバのサービス稼動状況、機器のリソース等の監視などがある。また、セキュリティーサービスには、ウィルスの検出や侵入検知などのサービスがある。

【0026】

いずれの場合も、何らかの障害が検出された場合、運用・監視システム３０は障害発生を意味するアラームをユーザ端末７０に送信する。なお、アラームの通知には、無人監視と有人監視がある。無人監視では障害発生時の状況をデータマイニングなどでフィルタリングして、通知の必要性が高いアラームのみが担当者のユーザ端末７０に通知される。有人監視では、運用・監視システム３０の監視オペレータが障害発生を把握すると被監視システム１９の稼動状況を確認し、必要であると判断した場合にアラームをユーザ端末７０に通知する。本実施形態ではどちらの態様で監視されてもよい。

【0027】

また、運用・監視システム３０からユーザ端末７０へのアラームの通知方法にはいくつかの手段がある。例えば、無人監視の場合は電子メールによる通知が挙げられ、有人監視の場合は監視オペレータによる電話連絡でもよいし、電子メールによる通知でもよい。無人監視の場合に自動音声を用いた電話連絡も可能である。

【0028】

ユーザ端末７０は、例えば、ＰＣ（Personal Computer）、スマートフォン、ＰＤＡ（Personal Digital Assistant）、タブレット型端末、携帯電話又はウェアラブルＰＣ（腕時計タイプ、サングラスタイプなど）などである。ユーザ端末７０はブラウザソフトウェア又はこれと同等の機能のアプリケーションソフトが動作する情報処理装置であればよい。また、担当者は複数のユーザ端末７０を使用してもよい。例えば、アラームの通知は携帯電話で受け、管理支援システム５０へのアクセスにはＰＣを使うことができる。

【0029】

管理支援システム５０は、ユーザ端末７０からのアクセスに対し、後述するアラーム詳細画面５２０を提供する。担当者はアラーム詳細画面５２０から、入館している担当者、ログインしている担当者、ラックの開閉状態、カメラ２１が撮影した被監視システム１９の撮影データ、推奨される初動作業（メンテナンス中の担当者の連絡先）などを確認できる。

【0030】

≪ハードウェア構成例≫
図４は、管理支援システム５０のハードウェア構成図の一例である。管理支援システム５０は、バス３１０に接続されたＣＰＵ３０１、ＲＯＭ３０２、ＲＡＭ３０３、ＨＤＤ(Hard Disk Drive)３０５、ディスプレイ３０８、ネットワークＩ／Ｆ３０９、キーボード３１１、マウス３１２、メディアドライブ３０７、及び、光学ドライブ３１４を有する。ＣＰＵ３０１は、ＨＤ３０４に記憶されている管理支援用プログラムを実行して、管理支援システム５０全体の動作を制御する。ＲＯＭ３０２はＩＰＬ（Initial Program Loader）等のＣＰＵ３０１の駆動に用いられるプログラムを記憶している。ＲＡＭ３０３はＣＰＵ３０１のワークエリアとして使用される。ＨＤ３０４は不揮発性メモリを搭載した記憶装置であり、管理支援用プログラム、ＯＳ（Operating System）等を記憶している。

【0031】

ＨＤＤ３０５はＣＰＵ３０１の制御にしたがってＨＤ３０４に対する各種データの読み出し又は書き込みを制御する。ディスプレイ３０８はカーソル、メニュー、ウィンドウ、文字、又は画像などの各種情報を表示する。ネットワークＩ／Ｆ３０９はＬＡＮやインターネットなどのネットワークＮとのインタフェースであり、ネットワークＮを介した通信を行う。キーボード３１１及びマウス３１２は入出力装置であり、キーボード３１１は文字、数値、各種指示などの入力のための複数のキーを備えこれらからの入力を受け付ける。マウス３１２はマウスポインターの移動及び各種指示の選択や実行、処理対象の選択などを受け付ける。

【0032】

メディアドライブ３０７はフラッシュメモリ等のメディア３０６に対するデータの読み出し又は書き込み（記憶）を制御する。光学ドライブ３１４は着脱可能な記録媒体の一例としてのＣＤ−ＲＯＭ(Compact Disc Read Only Memory)３１３等に対する各種データの読み出し又は書き込みを制御する。

【0033】

なお、上記管理支援用プログラムは、インストール可能な形式又は実行可能な形式のファイルで、メディア３０６やＣＤ−ＲＯＭ３１３等のコンピュータで読み取り可能な記録媒体に記録して流通させるようにしてもよい。あるいは、管理支援用プログラムは、任意のサーバ型の情報処理装置からダウンロードされる形態で配布されてもよい。

【0034】

なお、管理支援システム５０は、クラウドコンピューティングにより構築されていてもよい。クラウドコンピューティングでは、管理支援システム５０の機能が搭載される情報処理装置が固定されていたり１つの筐体内に配置されている必要はなく、物理的な構造は変動しうる。したがって、図示する管理支援システム５０のハードウェア構成は、管理支援システム５０が備えていることが好ましいハード的な要素を示す。

【0035】

また、運用・監視システム３０、入館管理システム２０、及び、ユーザ端末７０のハードウェア構成は図４と同様であるか、差異があっても本実施形態の説明には支障がないものとする。しかしながら、運用・監視システム３０のＨＤ３０４には運用・管理用プログラムが記憶されており、入館管理システム２０のＨＤ３０４には入館管理用プログラムが記憶されており、ユーザ端末７０にはユーザ端末用プログラムが記憶されている。

【0036】

＜管理システムの機能について＞
続いて、図５を用いて管理システム３００の各機能について説明する。図５は、管理システム３００の機能ブロック図の一例を示す。なお、被監視システム１９は本実施形態では監視対象であるので、その機能は被監視システム１９によって異なる。

【0037】

≪入館管理システム２０≫
入館管理システム２０は、送受信部２５、認証部２６、入退館記録部２７、及び、記憶・読出部２９を有する。これらの各機能は図４に示したＣＰＵ３０１が入館管理用プログラムを実行して入館管理システム２０のハードウェアと協働することで実現される機能又は手段である。これらの機能の一部又は全てがＩＣなどのハードウェア回路により実現されてもよい。

【0038】

また、入館管理システム２０は、図４に示したＨＤ３０４又はＲＡＭ３０３により実現される記憶部２０００を有している。記憶部２０００には、入退館管理ＤＢ２００１及び入館管理用プログラム２１００が記憶されている。入退館管理ＤＢ２００１について表１を用いて説明する。

【0039】

【表1】

【0040】

記憶部２０００には、表１に示されているような入退館情報によって構成されている入退館管理ＤＢ２００１が構築されている。入退館情報には、入館日時及び退館日時に担当者ＩＤが対応づけられている。入館日時は担当者がデータセンター１１に入館した日時、退館日時は担当者がデータセンター１１から退館した日時である。担当者ＩＤはデータセンター１１に入退館する担当者を一意に識別するための識別情報である。入退館情報は履歴情報の一例である。

【0041】

次に、入館管理システム２０が有する機能又は手段について説明する。送受信部２５は、図４に示されているＣＰＵ３０１からの命令、及び図４に示されているネットワークＩ／Ｆ３０９によって実現され、ネットワークＮを介して運用・監視システム３０及び管理支援システム５０等と各種データの送受信を行う。

【0042】

認証部２６は、図４に示されているＣＰＵ３０１からの命令、及びデータセンター１１に配置されたＩＣカードリーダなどによって実現され、担当者を認証する。認証することで担当者を識別できる。担当者が保持するＩＣカードをＩＣカードリーダが読み取ると、認証部２６はＩＣカード番号を取得する。担当者ＩＤとＩＣカード番号が予め対応づけられているため、認証部２６は担当者ＩＤを特定できる。ＩＣカードリーダを用いるほか、担当者がキーボードに入力した担当者ＩＤとパスワード（又は指紋、顔、虹彩などの生体識別情報でもよい）の組が、予め保持している担当者ＩＤとパスワードの組と一致するかに基づき担当者を認証してもよい。認証が成立すると担当者にはＩＣカードが付与される。

【0043】

担当者は、入館時に被監視システム１９のある場所まで移動する（退館時は逆のルートになる）。担当者は移動途中のドアの手前などに設置されたＩＣカードリーダにＩＣカードを読み取らせる。これにより担当者の入退館が記録される。また、移動途中のドアなどで随時、ＩＣカードをＩＣカードリーダに読み取らせるため、データセンター１１内における担当者のおよその場所が検知されている。

【0044】

入退館記録部２７は、図４に示されているＣＰＵ３０１からの命令などによって実現される。入館用のゲートを通過したことがＩＣカードの読み取りにより検出されると、担当者ＩＤを入館日時に対応づけて入退館情報に記録する。また、担当者が退館用のゲートを通過したことがＩＣカードの読み取りにより検出されると、入館日時と担当者ＩＤに対応づけて退館日時を入退館情報に記録する。

【0045】

記憶・読出部２９は、図４に示されているＣＰＵ３０１からの命令、及び図４に示すＨＤＤ３０５によって実現され、記憶部２０００に各種データを記憶したり、記憶部２０００に記憶された各種データを読み出したりする処理を行う。

【0046】

＜＜運用・監視システム３０＞＞
運用・監視システム３０は、送受信部３１、ログイン検出部３２、監視部３３、アラーム判定部３４、情報提供部３５、撮影部３６、センサー検知部３７、及び、記憶・読出部３９を有する。これらの各機能は図４に示したＣＰＵ３０１が運用・管理用プログラムを実行して運用・監視システム３０のハードウェアと協働することで実現される機能又は手段である。これらの機能の一部又は全てがＩＣなどのハードウェア回路により実現されてもよい。

【0047】

また、運用・監視システム３０は、図４に示したＨＤ３０４又はＲＡＭ３０３により実現される記憶部３０００を有している。記憶部３０００には、運用・管理用プログラム３１００、アラーム発報対象ＤＢ３００１、監視対象情報ＤＢ３００２、撮影データＤＢ３００３、アラーム履歴ＤＢ３００４、ログイン情報ＤＢ３００５、監視情報ＤＢ３００６、顧客情報ＤＢ３００７、及び、センサー検知情報ＤＢ３００８が構築されている。以下、これら各データベースについて説明する。

【0048】

【表2】

【0049】

記憶部３０００には、表２に示されているようなログイン情報によって構成されているログイン情報ＤＢ３００５が構築されている。ログイン情報には、担当者が自社の被監視システム１９にログインした情報として、ログインした日時、担当者がログアウトした日時、及び、担当者ＩＤが対応づけて登録されている。ログイン情報は履歴情報の一例である。ログインについては後述する。

【0050】

【表3】

【0051】

記憶部３０００には、表３に示されているような顧客情報によって構成されている顧客情報ＤＢ３００７が構築されている。顧客情報には、顧客ＩＤ、顧客名、サーバＩＤ、プロジェクト名、及び、ラックＩＤが対応づけて登録されている。顧客ＩＤは、データセンター１１の顧客を一意に識別するための識別情報である。顧客名は顧客の通称名である。サーバＩＤは、各顧客がデータセンター１１内に保有するサーバを一意に識別するための識別情報である。プロジェクト名はサーバが関係するプロジェクトの名称である。サーバＩＤだけではどのようなシステムか判別できない場合でもプロジェクト名で判別できる。また、複数のサーバが１つのプロジェクトに関係してもよいし、１つのサーバが複数のプロジェクトに関係してもよい。ラックＩＤは、データセンター１１内においてサーバが設置されているラックを一意に識別するための識別情報である。なお、顧客の住所、代表者氏名、締め日などの情報は、別のデータベースに登録されている。

【0052】

【表4】

【0053】

また、顧客情報ＤＢ３００７には表４に示されているような担当者情報も構築されている。担当者情報は、一例としてプロジェクトごとに構築されており、担当者ＩＤ、連絡優先順位、氏名、ＴＥＬ、及び、Ｅ−Ｍａｉｌアドレスが対応づけて登録されている。連絡優先順位とは、運用・監視システム３０又は運用・監視システム３０のオペレータがアラームの発生を通知する担当者の順位を示す。順位は固定でもよく、ローテーションなどにより変更される場合がある。運用・監視システム３０又は運用・監視システム３０のオペレータはアラームが発生すると、連絡が付くまでこの連絡優先順位にしたがって連絡を取る。なお、担当者情報は顧客ごとに作成してもよいし、サーバごとに作成してもよい。

【0054】

【表5】

【0055】

記憶部３０００には、表５に示されているような監視情報によって構成されている監視情報ＤＢ３００６が構築されている。監視情報は例えばサーバごとに記録され、監視情報には、日時、ＣＰＵ使用率、メモリ使用率、ディスクＩ／Ｏ回数、ＨＤＤ空き容量、及び、ネットワーク使用率が対応づけて登録されている。監視情報は、被監視システム１９の稼動状況を監視するための情報である。これらはアラームを発報させる情報ともなり、被監視システム１９にどの程度の負荷がかかっているかを担当者が把握するための指標となる。監視情報は定期的（表５では５分）に取得されるため、時系列にほぼリアルタイムの監視情報が繰り返し記録される。

【0056】

なお、表５の監視情報は一例に過ぎず、これら以外の情報が記録されてよい。また、監視情報が記録される間隔も５分には限定されず、記録間隔は５分未満又は５分超でもよい。表５では各リソースが１つずつのみの例であるが、各リソースが複数ある場合、個々に監視してもよく、複数のリソースの平均値や最大値を監視してよい。また、ボトルネックとなっている箇所を監視してもよい。

【0057】

【表6】

【0058】

記憶部３０００には、表６に示されているような監視対象情報によって構成されている監視対象情報ＤＢ３００２が構築されている。監視対象情報には、顧客ＩＤ、サーバＩＤ、１つ以上の監視対象／アラーム基準が対応づけて登録されている。監視対象情報とは、各顧客がサーバごとにアラームを発報する監視情報とその基準（アラーム基準）を定義するための情報である。すなわち、各顧客は自分たちのサーバごとにアラームを発報する基準を定義できる。なお、表６のアラーム基準は一例に過ぎず、例えばＣＰＵ使用率の単位時間の上昇率など、監視情報の値の微分値や２回微分値をアラーム基準に用いてもよい。また、複数の監視情報の組み合わせをアラーム基準に用いてもよい。

【0059】

【表7】

【0060】

記憶部３０００には、表７に示されているようなアラーム発報対象情報によって構成されているアラーム発報対象ＤＢ３００１が構築されている。アラーム発報対象情報には、運用・監視システム３０がアラームを発報する事象がアラーム番号に対応づけて登録されている。表６の監視対象情報を顧客が任意に設定できるのに対し、表７のＡＲＭ００１〜ＡＲＭ００３の事象はアラームの基本的な発報対象として予め設定されている。アラーム番号がＡＲＭ００４以降のアラーム発報象情報は、顧客が表６で定義した監視対象が登録される。したがって、アラーム番号によりアラームが発報された事象を担当者等が特定できる。また、顧客が表６の監視対象情報に何も設定しなければ、アラーム発報対象情報は顧客ごとに共通である。このように、アラームが発報される事象は顧客ごとに異なっていても、そうでなくてもよい。したがって、表７で定義した監視対象が障害か否かは定義の問題であり、本実施形態では障害と扱っても障害でないと扱ってもよい。表７に記載されたアラーム発報対象情報はあくまで一例であり、この他にも多くの事象が存在しうる。表７の事象は所定状況の一例である。

【0061】

【表8】

【0062】

記憶部３０００には、表８に示されているような撮影データ情報によって構成されている撮影データＤＢ３００３が構築されている。撮影データ情報はラックごとに作成され、撮影データ情報には、撮影日時と撮影データファイル名が対応づけて登録されている。撮影データファイル名によって特定されるファイル本体はＯＳにより管理された状態で撮影データＤＢ３００３に記憶されている。カメラ２１は定期的（表８では５分間隔）にラックを撮影している。したがって、撮影データＤＢ３００３には各ラックが撮影された撮影データが時系列に記憶されている。また、アラーム発生時に撮影することが好適である。ラックは透明な材質で形成されているため、ラック越しに撮影されたサーバのＬＥＤ、担当者、及び、ラックの開閉状態などが撮影され得る。なお、撮影データは静止画に限られず動画であってもよい。また、音声を取得可能でもよい。

【0063】

【表9】

【0064】

記憶部３０００には、表９に示されているようなセンサー検知情報によって構成されているセンサー検知情報ＤＢ３００８が構築されている。センサー検知情報には、ラックＩＤ、ラック開センサー検知時刻、及び、ラック閉センサー検知時刻が対応づけて登録されている。このセンサー２２はラックの開閉を検出する。このため、１つのセンサー２２はいずれかのラックに対応づけられている。表９ではセンサー２２とラックが１対１の関係であるとしたが、多対１の関係でもよい。担当者はセンサー検知情報により各ラックの開閉状態を把握できる。センサー検知情報は履歴情報の一例である。

【0065】

なお、ラックやサーバに配置されるセンサー２２としてはこの他、温度センサー、震動センサ、火災センサ、浸水センサ等が配置されてもよい。これによりサーバの異常な温度情報を記録できる。

【0066】

【表10】

【0067】

記憶部３０００には、表１０に示されているようなアラーム履歴情報によって構成されているアラーム履歴ＤＢ３００４が構築されている。アラーム履歴情報には、通番、サーバＩＤ、アラーム番号、発生日時、連絡した担当者、状態、及び、メンテナンス推定結果が対応づけて登録されている。通番はアラームの発生した順に付された連番である。サーバＩＤ、アラーム番号、発生日時、及び、（運用・監視システム３０又はオペレータが）連絡した担当者はこれまで説明したとおりである。状態はアラームに対する対応の状態を示し、具体的には担当者がアラームに対応した結果が入力される。なお、アラーム発生時の初期状態は未対応である。メンテナンス推定結果は、アラームがメンテナンスによるものかどうかの推定結果（メンテナンスによると推定されるアラームは注意、そうでないアラームは警告）であり、管理支援システム５０による推定結果が記録される。

【0068】

次に、運用・監視システム３０が有する機能又は手段について説明する。送受信部３１は、図４に示されているＣＰＵ３０１からの命令、及び図４に示されているネットワークＩ／Ｆ３０９によって実現され、ネットワークＮを介して入館管理システム２０及び管理支援システム５０等と各種データの送受信を行う。

【0069】

ログイン検出部３２は、図４に示されているＣＰＵ３０１からの命令によって実現され、被監視システム１９への担当者のログイン状態を定期的に問い合わせる。すなわち、被監視システム１９の担当者はメンテナンスの際、被監視システム１９にログインすることが多い。運用・監視システム３０も被監視システム１９へログインすることができるため（運用・監視のためにログイン権限が与えられている）、被監視システム１９へログインして、担当者のログインに関する情報を読み出し、ログイン情報ＤＢ３００５に記録する。なお、担当者はデータセンター１１に入館しなくても遠隔地から被監視システム１９にログインすることが可能である。

【0070】

監視部３３は、図４に示されているＣＰＵ３０１からの命令によって実現され、被監視システム１９を監視する。具体的には、定期的に被監視システム１９に問い合わせて監視情報を取得し監視情報ＤＢ３００６に記録する。また、監視部３３はアラーム発報対象情報に設定されている事象を検出するため、ＰＩＮＧ応答、プログラム異常情報、及び、温度異常などを監視する。すなわち、定期的に被監視システム１９に対しＰＩＮＧコマンドを送信し応答時間を取得する。また、被監視システム１９のプログラムが異常終了した場合に残すログを被監視システム１９から取得する。また、温度センサーとしてのセンサー２２が検知した温度を取得する。監視部３３はこれらの監視結果を随時、アラーム判定部３４に送出する。

【0071】

アラーム判定部３４は、図４に示されているＣＰＵ３０１からの命令によって実現され、監視部３３による監視結果がアラームの発報条件を満たすか否かを判定し、満たす場合にアラームを発報する。まず、監視対象情報ＤＢ３００２の監視対象情報からアラーム基準を読み出し、監視情報ＤＢ３００６の監視情報のうちアラーム基準を満たすものがあるか否かを判定する。次に、監視部３３から取得した監視結果に基づいて、ＰＩＮＧコマンドへの応答時間が閾値を超えないかなどを判定する。また、被監視システム１９のプログラムが異常終了した場合に残すログにプログラム異常終了の有無が記録されているか否かを判定する。また、ラックの周囲の温度が基準より高くなっていないかを判定する。アラーム判定部３４はアラームを発報すべき事象であると判定するとアラーム履歴情報をアラーム履歴ＤＢ３００４に記録する。また、運用・監視システム３０のオペレータに通知する。これにより運用・監視システム３０のオペレータはアラームの内容やサーバの状態を確認し担当者に連絡すべきかどうかを判断する。あるいは、直接、アラーム判定部３４が連絡優先順位の最も高い担当者から順にアラームを通知してもよい。

【0072】

撮影部３６は、図４に示されているＣＰＵ３０１からの命令及び図３のカメラ２１によって実現され、被監視システム１９のラックを定期的及びアラーム発生時に撮影する。撮影されることで得られた撮影データは撮影データＤＢ３００３に時系列に記録される。

【0073】

センサー検知部３７は、図４に示されているＣＰＵ３０１からの命令及び図３のセンサー２２によって実現され、被監視システム１９のラックの開閉状態及びラック周囲の温度を定期的に取得する。センサー検知部３７が取得したラックの開閉状態や温度はセンサー検知情報ＤＢ３００８に記録される。

【0074】

情報提供部３５は、図４に示されているＣＰＵ３０１からの命令によって実現され、管理支援システム５０から要求があると画面作成情報を提供する。画面作成情報については後述する。

【0075】

記憶・読出部３９は、図４に示されているＣＰＵ３０１からの命令、及び図４に示すＨＤＤ３０５によって実現され、記憶部３０００に各種データを記憶したり、記憶部３０００に記憶された各種データを読み出したりする処理を行う。

【0076】

≪管理支援システム５０≫
管理支援システム５０は、送受信部５１、認証部５２、情報取得部５３、画面作成部５４、メンテナンス推定部５５、及び、記憶・読出部５９を有する。これらの各機能は図４に示したＣＰＵ３０１が管理支援用プログラムを実行して管理支援システム５０のハードウェアと協働することで実現される機能又は手段である。これらの機能の一部又は全てがＩＣなどのハードウェア回路により実現されてもよい。

【0077】

また、管理支援システム５０は、図４に示したＨＤ３０４又はＲＡＭ３０３により実現される記憶部５０００を有している。記憶部５０００には、管理支援用プログラム５１００、ラック配置画像ＤＢ５００２、担当者対応画面情報ＤＢ５００３、及び画面作成情報ＤＢ５００１が構築されている。

【0078】

ラック配置画像ＤＢ５００２にはラックの配置を示す画面を構築するための情報が記憶されている。詳細は図６にて説明する。

【0079】

担当者対応画面情報ＤＢ５００３はアラームに対し担当者が速やかに初動するための担当者対応画面情報が記憶されている。詳細は図７にて説明する。

【0080】

画面作成情報ＤＢ５００１には、担当者に被監視システム１９の状態を提供するための画面作成情報が記憶される。画面作成情報は運用・監視システム３０又は入館管理システム２０の記憶部２０００，３０００に記憶されているもののうち必要な情報の複製である。具体的には、例えば以下の情報が画面作成情報となる。
「ログイン情報、監視情報、顧客情報、担当者情報、センサー検知情報、撮影データ情報、アラーム履歴情報、入退館情報」

【0081】

次に、管理支援システム５０が有する機能又は手段について説明する。送受信部５１は、図４に示されているＣＰＵ３０１からの命令、及び図４に示されているネットワークＩ／Ｆ３０９によって実現され、ネットワークＮを介して運用・監視システム３０及び入館管理システム２０等と各種データの送受信を行う。

【0082】

認証部５２は、図４に示されているＣＰＵ３０１からの命令によって実現され、管理支援システム５０にログインするユーザ端末７０（すなわち担当者）を認証する。認証方法はどのようなものでよいが、一例として、担当者ＩＤとパスワードの組による認証が挙げられる。認証が成立することで管理支援システム５０にログインした担当者ＩＤが特定される。顧客情報ＤＢ３００７には、担当者ＩＤに、プロジェクト名、顧客ＩＤ、サーバＩＤ及びラックＩＤが紐づけられているので、認証が成立した担当者が管理するプロジェクト名等も明らかになる。

【0083】

情報取得部５３は、図４に示されているＣＰＵ３０１からの命令によって実現され、例えば担当者が管理支援システム５０にログインしたことを契機に運用・監視システム３０から画面作成情報を取得する。担当者が管理支援システム５０にログインした理由がアラームの通知であれば、アラーム履歴ＤＢ３００４にアラーム履歴情報が登録されているので、後述するように担当者は画面作成情報に基づき作成された画面により被監視システム１９の状態を把握できる。なお、担当者がアラームの通知に関係なくログインした場合でも、担当者は画面作成情報に基づき作成された画面により被監視システム１９の状態を把握できる。また、情報取得部５３は担当者の管理支援システム５０へのログインに関係なく、定期的又は不定期に画面作成情報を取得してもよい。

【0084】

画面作成部５４は、図４に示されているＣＰＵ３０１からの命令によって実現され、画面作成情報を用いてユーザ端末７０に送信する画面情報を作成する。画面情報は、例えば後述するアラーム一覧画面５１０やアラーム詳細画面５２０などの画面情報である。画面情報は例えばＨＴＭＬ、ＸＭＬ、ＪａｖａＳｃｒｉｐｔ（登録商標）などにより記述されているが、記述形式はどのようなものでもよい。画面情報はＷｅｂアプリとして作成されていてもよい。この場合、画面情報が含むＪａｖａＳｃｒｉｐｔ（登録商標）のコードによりイベントが検知されると、ユーザ端末７０は非同期に管理支援システム５０と通信して、画面遷移することなく画面の内容を更新できる。

【0085】

メンテナンス推定部５５は、図４に示されているＣＰＵ３０１からの命令によって実現され、例えば入館情報、ログイン情報及びセンサー検知情報を総合して、アラームがメンテナンスによるものかどうかを推定する。

【0086】

記憶・読出部５９は、図４に示されているＣＰＵ３０１からの命令、及び図４に示すＨＤＤ３０５によって実現され、記憶部５０００に各種データを記憶したり、記憶部５０００に記憶された各種データを読み出したりする処理を行う。

【0087】

≪ユーザ端末７０≫
ユーザ端末７０は、送受信部７１、操作受付部７２、画面表示部７３、及び、記憶・読出部７９を有する。これらの各機能は図４に示したＣＰＵ３０１がユーザ端末用プログラムを実行してユーザ端末７０のハードウェアと協働することで実現される機能又は手段である。これらの機能の一部又は全てがＩＣなどのハードウェア回路により実現されてもよい。なお、ユーザ端末用プログラムは例えばブラウザソフトウェアであるが、ブラウザと同等の機能を備えたアプリケーションソフトでもよい。また、好ましくはユーザ端末７０の種類に応じてユーザ端末用プログラムが用意されている。

【0088】

また、ユーザ端末７０は、図４に示したＨＤ３０４又はＲＡＭ３０３により実現される記憶部７０００を有している。記憶部７０００には、ユーザ端末用プログラム７１００が記憶されている。

【0089】

送受信部７１は、図４に示されているＣＰＵ３０１からの命令、及び図４に示されているネットワークＩ／Ｆ３０９によって実現され、ネットワークＮを介して管理支援システム５０や被監視システム１９と各種データの送受信を行う。

【0090】

操作受付部７２は、図４に示されているＣＰＵ３０１が管理支援システム５０から送信される画面情報を実行すること、キーボード３１１、マウス３１２，ディスプレイ３０８と一体のタッチパネル、及び、音声入力装置などによって実現される。操作受付部７２は担当者の操作を受け付け、操作内容を画面表示部７３に送出する。

【0091】

画面表示部７３は、図４に示されているＣＰＵ３０１が管理支援システム５０から送信される画面情報を実行することなどによって実現され、ディスプレイ３０８に各種の画面を表示する。また、担当者の操作内容に応じて画面を更新する。

【0092】

記憶・読出部７９は、図４に示されているＣＰＵ３０１からの命令、及び図４に示すＨＤＤ３０５によって実現され、記憶部７０００に各種データを記憶したり、記憶部７０００に記憶された各種データを読み出したりする処理を行う。

【0093】

≪ラック配置画像ＤＢ５００２≫
続いて、図５のラック配置画像ＤＢ５００２について説明する。図６はラック配置画像の一例を示す図である。ラック８１の配置は固定されているため、各ラック８１のラックＩＤは既知である。したがって、予め管理支援システム５０の管理者などが、各ラック８１が配置された画面を描くためのＨＴＭＬファイルなどを作成しておく。すなわち、ラックＩＤを指定してラックを描画できるＨＴＭＬファイルを作成する。ラックの形状は長方形等であるので、例えばｆｉｌｌＲｅｃｔメソッドにより任意のラックが描画されたり塗りつぶされたりする。

【0094】

なお、図６は実在するサーバが収容されるラックの配置画像であるが、仮想サーバやクラウドの場合もラックの配置画像が用意される。例えば、仮想サーバやクラウドコンピュータとそれらが存在する物理サーバ群との対応が算出され、反映される。

【0095】

アラームが発報されラックが特定された場合、画面作成部５４はラック配置画像のＨＴＭＬファイルにおいて他のラックの色とアラームが発報されたラックの色を変える。これにより、ラック配置画像を表示させた担当者はラックの位置をすぐに把握してラックまで移動し初動作業に入ることができる。

【0096】

なお、ラック配置画像には電話アイコン８２とメールアイコン８３が配置されている。画面作成部５４は、アラームの発報時、担当者情報の氏名、ＴＥＬ及びＥ−Ｍａｉｌアドレスを電話アイコン８２とメールアイコン８３にそれぞれ埋め込む（リンクする）。

【0097】

≪担当者対応画面情報ＤＢ５００３≫
図７は担当者対応画面情報によりユーザ端末７０に表示される担当者対応画面５０１を模式的に示す図の一例である。担当者対応画面５０１は関係者連絡ボタン５０２、入館申請ボタン５０３、遠隔メンテナンスボタン５０４、及び、アラーム抑止設定ボタン５０５を有する。これらはＢＵＴＴＯＮタグとして担当者対応画面情報（ＨＴＭＬファイル）に記述されている。

【0098】

また、各ボタンにはそれぞれ遷移先の画面へのリンクが埋め込まれている。関係者連絡ボタン５０２には、担当者対応画面５０１を表示させた担当者と同じプロジェクトを担当する担当者のＴＥＬとＥ−Ｍａｉｌアドレスを表示する画面がリンクされる。したがって、画面作成部５４は顧客情報ＤＢ３００７から担当者対応画面５０１を表示させた担当者と同じプロジェクトを担当する担当者のＴＥＬとＥ−Ｍａｉｌアドレスを読み出して関係者連絡ボタン５０２が押下された際の遷移先の画面情報に設定する。入館申請ボタン５０３には、担当者がデータセンター１１に入館申請するための画面がリンクされる。入館申請するための画面は各顧客に共通であるとする。共通でない場合は、担当者対応画面５０１を表示させた担当者の氏名や担当者ＩＤを画面作成部５４が入館申請するための画面情報に設定してもよい。

【0099】

遠隔メンテナンスボタン５０４には、被監視システム１９にメンテナンス用の各種のコマンドを送信可能な画面がリンクされる。したがって、画面作成部５４は例えば、被監視システム１９のＵＲＩ（例えばＩＰアドレス）が設定され、さらに、被監視システム１９にログインするためのフォーム（担当者ＩＤ、パスワードの入力欄）を有する画面情報を作成する。また、画面作成部５４は、予め用意されている、ＰＩＮＧコマンド、ｕｐｔｉｍｅコマンド、ｄｆコマンド、ｆｒｅｅコマンド、ｐｓコマンド、ａｕｘコマンド、ｔｏｐコマンド、ｉｏｓｔａｔコマンドなどが選択可能な画面情報を、作成した画面情報に関連づける。

【0100】

アラーム抑止設定ボタン５０５には、アラームを抑止するための画面がリンクされる。画面作成部５４は、抑止時間などを入力可能な画面情報に、担当者対応画面５０１を表示させた担当者が紐づけられているプロジェクト名、サーバＩＤ等（アラーム抑止の対象を特定するための情報）を設定する。

【0101】

＜カメラ２１の配置＞
続いて、データセンター１１におけるカメラ２１の配置について説明する。図８（ａ）はラックの前に固定されたカメラ２１の配置例を示す図である。図８（ａ）では２つのラック８１を１つのカメラ２１で監視している。セキュリティ上の不都合等を考慮して、１つのラック８１を１つのカメラ２１で監視してもよい。

【0102】

しかしながら、ラック８１の数が増えた状態でラック８１とカメラ２１の対応が固定されている場合、カメラ２１の数も増大してしまう。したがって、この場合、データセンター１１に図８（ｂ）に示すような自走式のカメラ２１を配置することが有効になる。図８（ｂ）ではラック８１の一列に１台のカメラ２１が配置されている。カメラ２１は天井などからつり下げられたレール８４をラック８１の列に並行に移動する。したがって、ラック８１の数に対するカメラ２１の数を低減できるのでコスト増を抑制できる。

【0103】

なお、カメラ２１の位置は撮影部３６により制御される。撮影部３６は予め基準位置からの移動距離及び方向とラックＩＤを対応づけたテーブルを保持している。撮影部３６はアラーム判定部３４からアラームが発報されたラックＩＤを取得すると、ラックＩＤに対応づけられた移動距離だけカメラ２１を移動させる。あるいは、データセンター１１の管理者などがレール８４の各ラック８１の前にラックＩＤが記憶されたＩＣタグを貼付しておき、カメラ２１がＩＣリーダでＩＣタグのラックＩＤを読み取ってもよい。この場合、カメラ２１は撮影部３６から通知されたラックＩＤを移動しながら探索して、通知されたラックＩＤを検出すると停止する。

【0104】

このように、カメラ２１が各被監視システム１９のラックを撮影することで、エラーを知らせるＬＥＤの点灯状態、担当者の有無、及び、ラック８１の開閉状態を撮影できる。なお、カメラ２１はズーム（変倍）機能を備え、サーバのズーム（拡大）画像やサーバの周辺画像をそれぞれ撮像できることが好ましい。レールを自走する以外にロボットなどが移動して撮影してもよい。

【0105】

＜動作手順＞
続いて、図９を用いて管理システム３００の動作手順について説明する。図９は、管理システム３００がアラームを発報しユーザ端末７０がそれを確認するまでの処理手順を示すシーケンス図の一例である。図９の処理手順は被監視システム１９が稼動中に行われる。

【0106】

Ｓ１：運用・監視システム３０の監視部３３は被監視システム１９を定期的に監視する。監視部３３による監視情報は監視情報ＤＢ３００６に記録され、また、監視結果をアラーム判定部３４に送出する。

【0107】

Ｓ２：アラーム判定部３４は監視情報ＤＢ３００６や監視結果に基づいてアラームを発報する事象か否かを判定する。ここではアラームを発報するものとして説明する。また、このタイミングでデータセンター１１のオペレータがアラームを発報するかどうかを更に確認してもよい。

【0108】

Ｓ３：運用・監視システム３０のアラーム判定部３４は送受信部３１を介してユーザ端末７０にアラームを通知する。すなわち、オペレータによる電話連絡、オートコール（自動電話連絡）、又は、Ｅ−Ｍａｉｌによりアラームが発報されたことを担当者に通知する（連絡優先順位の順番）。

【0109】

Ｓ４：ユーザ端末７０を操作する担当者はアラームの内容を確認するため管理支援システム５０にログインする。これにより、少なくとも担当者ＩＤが判明する。

【0110】

Ｓ５：管理支援システム５０の情報取得部５３は運用・監視システム３０に対し画面作成情報を要求する。この時、担当者ＩＤを送信することで、運用・監視システム３０の記憶・読出部３９は、担当者ＩＤに紐付いている「ログイン情報、監視情報、顧客情報、担当者情報、センサー検知情報、撮影データ情報、アラーム履歴情報、入退館情報」を画面作成情報として記憶部３０００から読み出す。

【0111】

Ｓ６：運用・監視システム３０の情報提供部３５は画面作成情報を管理支援システム５０に送信する。

【0112】

Ｓ７：管理支援システム５０の画面作成部５４は、画面作成情報からアラーム履歴情報を取得し、アラーム一覧をユーザ端末７０に通知する。アラーム一覧は、担当者が管理するプロジェクトのうち状態が解決でないものでよい。あるいは直近の決まった数（例えば１０個）のアラームを送信してもよい。

【0113】

Ｓ８：ユーザ端末７０の画面表示部７３はアラーム一覧画面をディスプレイ３０８に表示する。アラーム一覧画面については図１０（ａ）にて説明する。

【0114】

Ｓ９：次に、担当者はアラーム一覧画面から確認したいアラームを、マウスを用いて又はタッチパネルから選択する。これにより、ユーザ端末７０の送受信部７１は担当者が選択したアラームの通番を管理支援システム５０に送信する。

【0115】

Ｓ１０：これによりアラームが特定されたので、管理支援システム５０の画面作成部５４は担当者により選択されたアラームについてアラーム詳細画面５２０の画面情報を作成する。詳細は後述する。

【0116】

Ｓ１１：管理支援システム５０の送受信部５１はアラーム詳細画面５２０の画面情報をユーザ端末７０に送信する。

【0117】

Ｓ１２：ユーザ端末７０の画面表示部７３はアラーム詳細画面５２０をディスプレイ３０８に表示する。アラーム詳細画面５２０については図１０（ｂ）にて説明する。

【0118】

＜画面例＞
図１０（ａ）はアラーム一覧画面５１０の一例を示し、図１０（ｂ）はアラーム詳細画面５２０の一例を示す。アラーム一覧画面５１０では一例として２つのアラームの概略が表示されている。概略には、アラームの通番５１１、アラームの発生日時５１２、及び、アラームの内容５１３が表示されている。したがって、担当者はアラームの概略を把握して詳細を確認する必要があるかどうかを把握できる。なお、図１０（ａ）に表示される情報は一例にすぎず、図示する以外の情報が表示されてもよいし、図示した情報が表示されなくてもよい。

【0119】

なお、アラーム一覧画面５１０に表示される情報は、画面作成部５４がアラーム履歴ＤＢ３００４及び監視対象情報ＤＢ３００２から取得できる。

【0120】

アラーム詳細画面５２０は、発生日時欄５２１、プロジェクト名欄５１９、サーバ欄５２２、メッセージ種別欄５２３、メッセージ欄５２４、メンテナンス推定欄５２５、及び、横スクロール部５２６を有している。
・発生日時欄５２１…アラームが発生した日時であり、アラーム履歴ＤＢ３００４に記録されている。
・プロジェクト名欄５１９…アラームが発生したサーバが紐づけられているプロジェクト名であり、顧客情報ＤＢ３００７に記録されている。
・サーバ欄５２２…アラームが発生したサーバのサーバＩＤであり、アラーム履歴ＤＢ３００４に記録されている。
・メッセージ種別欄５２３…アラームであることを明記するための欄であり、画面作成部５４が設定する。アラームの重要度・緊急度等を示すメッセージが表示される。
・メッセージ欄５２４…アラームの内容を意味するものであり、アラーム番号に対応するメッセージを画面作成部５４が設定したものである。
・メンテナンス推定欄５２５…担当者が選択したアラームがメンテナンスによる可能性が高いか又は対応が必要な障害の可能性が高いかが表示される。具体的には、メンテナンスによる可能性が高い場合は「メンテナンスの可能性有り」と表示され、対応が必要な障害の可能性が高い場合は「障害の可能性」と表示される。メンテナンスによる可能性が高いか否かの判断については図１３にて説明する。なお、メンテナンスによる可能性が高いか否によってメンテナンス推定欄５２５の色を画面作成部５４が異ならせてもよい。
・横スクロール部５２６…一画面に入りきらない選択ボタンを担当者が横方向にスワイプすることで表示させる領域である。具体的には、選択ボタンとして、入館情報ボタン５２６ａ、ログイン情報ボタン５２６ｂ、カメラ情報ボタン５２６ｃ、センサー検知情報ボタン５２６ｄ、推奨作業ボタン５２６ｅ、及び、事象詳細ボタン５２６ｆが個別に表示される。これらがマウスを用いて又はタッチパネルから選択されると、次の画面に遷移する。

【0121】

≪アラーム詳細画面から表示される画面≫
選択ボタンが選択されることでアラーム詳細画面５２０から表示される画面は、画面遷移を伴ってもよいしアラーム詳細画面５２０に重なるように表示されてもよい。

【0122】

図１１（ａ）は入館情報ボタン５２６ａが押下された場合に表示される入館情報画面５３０の一例を示す図である。入館情報画面５３０には、所属情報５３１、入館詳細情報５３２及び最終更新時刻５３３が表示されている。所属情報５３１は、アラーム詳細画面５２０を表示した担当者が所属する顧客の顧客名やプロジェクト名である。顧客名とプロジェクト名は、担当者ＩＤに基づいて画面作成部５４が顧客情報ＤＢ３００７から読み出す。

【0123】

入館詳細情報５３２は、例えば入館者、入館時刻、及び、入館箇所を有している。画面作成部５４は、例えば以下のようにして入館詳細情報を作成する。まず、アラーム詳細画面５２０を表示した担当者の担当者ＩＤと同じプロジェクト名に対応づけられている担当者ＩＤを顧客情報ＤＢ３００７から取得する。次に、顧客情報ＤＢ３００７から取得した担当者ＩＤのうち入館はしたが、退館していない担当者がいるか否かを、入館情報ＤＢを参照して判定する。該当する担当者がいる場合、担当者ＩＤと入館時刻を読み出す。また、この担当者の氏名を顧客情報ＤＢ３００７から読み出す。

【0124】

なお、入館箇所は、入館した担当者が存在するデータセンター１１内の位置を示す。具体的には、担当者がＩＣカードで入室した場所を運用・監視システム３０に画面作成部５４が問い合わせることで取得できる。

【0125】

また、最終更新時刻５３３は監視部３３が最後に監視情報を記録した時刻であるので、情報取得部５３が運用・監視システム３０から取得する。

【0126】

図１１（ｂ）はログイン情報ボタン５２６ｂが押下された場合に表示されるログイン情報画面５４０の一例を示す図である。ログイン情報画面５４０には、所属情報５４１、ログイン詳細情報５４２、及び、最終更新時刻５４３が表示されている。所属情報５４１と最終更新時刻５４３については図１１（ａ）と同様である。

【0127】

ログイン詳細情報５４２は、例えば担当者ＩＤ、ログイン者及びログイン時刻を有している。画面作成部５４は、例えば以下のようにしてログイン詳細情報５４２を作成する。まず、アラーム詳細画面５２０を表示した担当者の担当者ＩＤと同じプロジェクト名に対応づけられている担当者ＩＤを顧客情報ＤＢ３００７から取得する。次に、顧客情報ＤＢ３００７から取得した担当者ＩＤのうちログインしたが、ログアウトしていない担当者がいるか否かを、ログイン情報ＤＢ３００５を参照して判定する。該当する担当者がいる場合、担当者ＩＤとログイン時刻を読み出す。また、この担当者の氏名を顧客情報ＤＢ３００７から読み出す。

【0128】

なお、図１１（ａ）（ｂ）において担当者名は必ずしも必須ではない。担当者を特定できなくても、メンテナンス中か否かが分かれば対応が必要なアラームかどうかおよその判断は可能だからである。

【0129】

図１１（ｃ）はカメラ情報ボタン５２６ｃが押下された場合に表示されるカメラ情報画面５５０の一例を示す図である。カメラ情報画面５５０には、ズームタグ５５１とサーバ周辺タグ５５２、ズーム画像５５３、及び、所属情報５５４が表示されている。所属情報５５４には、アラームが発報されたサーバやプロジェクトに関する情報が表示される。

【0130】

ズームタグ５５１はズーム画像を表示させるためのタグである。担当者がサーバ周辺タグ５５２をマウスを用いて又はタッチパネルから選択すると図１１（ｄ）に示すようにサーバ周辺画像５５６が表示される。ズーム画像５５３はサーバをズームした画像であり、担当者はＬＥＤの点灯状態を確認できる。サーバ周辺画像５５６はサーバの周辺が撮影された画像であり、担当者はラックの開閉状態や人影を確認できる。

【0131】

画面作成部５４は、例えば以下のようにしてカメラ情報画面を作成する。まず、アラーム詳細画面５２０を表示した担当者の担当者ＩＤに対応づけられているラックＩＤを顧客情報ＤＢ３００７から取得する。次に、このラックＩＤに対応づけられている最新の撮影データファイル名、アラーム発生時の撮影データファイル名及び撮影データを撮影データＤＢ３００３から読み出す。撮影時刻５５５は撮影データファイル名から明らかになっている。なお、読み出す撮影データを１つに制限する必要はなく、直近のいくつかの撮影データを取得してもよい。これにより例えばアラーム発生前より作業をしている担当者等の様子を判断できる。

【0132】

担当者の会社のセキュリティ方針により、撮影データを社外に送信することができない場合がある。この場合は、管理支援システム５０が画像処理を行い、ＬＥＤの点灯状態、担当者の有無、及び、ラックの開閉情報を判断する。撮影データのうちＬＥＤの形状（例えば円形）の輝点をパターン認識により検出することで、ＬＥＤの点灯状態を判断できる。また、例えばオプティカルフローなどで動体を検知すれば、ラックの前に担当者がいることを検出できる。また、予め保持するラックの開状態と閉状態の撮影データと、リアルタイムに撮影された撮影データを比較することで、ラックが開状態か閉状態を判断できる。画面作成部５４は撮影データ（サーバ周辺画像５５６、ズーム画像５５３）の代わりにこれらの画像処理結果をカメラ情報画面５５０に記載する。

【0133】

図１２（ａ）はセンサー検知情報ボタン５２６ｄが押下された場合に表示されるセンサー検知情報画面５６０の一例を示す図である。センサー検知情報画面５６０には、ラック情報５６１とセンサー検知詳細情報５６２が表示されている。ラック情報５６１は、アラーム詳細画面５２０を表示した担当者の担当者ＩＤに対応づけられているラックＩＤである。

【0134】

センサー検知詳細情報５６２は、例えばラック状態を有している。画面作成部５４は、例えば以下のようにしてセンサー検知詳細情報５６２を作成する。まず、アラーム詳細画面５２０を表示した担当者の担当者ＩＤに対応づけられているラックＩＤを顧客情報ＤＢ３００７から取得する。次に、このラックＩＤが開状態か閉状態かをセンサー検知情報ＤＢ３００８から読み出す。

【0135】

図１２（ｂ）は推奨作業ボタン５２６ｅが押下された場合に表示される推奨作業情報画面５７０の一例を示す図である。推奨作業情報画面５７０には、ラック位置５７１、ラック状態情報５７２、電話アイコン５７３、及び、メールアイコン５７４が表示されている。推奨作業情報画面５７０は、管理支援システム５０が担当者に推奨する作業を提案する画面である。

【0136】

ラック位置５７１は、データセンター１１内におけるラックの位置を地図形式で示す。この地図の描画方法は図６にて説明した。また、ラック状態情報５７２にはアラーム源となったサーバＩＤ、ラックの状態、及び、作業状態が表示される。これらの情報の取得方法は図１１，１２で説明した。

【0137】

また、図１２（ｂ）の例では、入館している担当者に連絡を取ることが推奨されている。例えば、鈴木次郎さんがログインしかつ入館しているため、アラーム詳細画面５２０を表示した担当者（例えば、佐藤一郎さん）は鈴木次郎さんに連絡を取ればアラームの原因を知ることができる可能性が高い。推奨作業情報画面５７０には入館又はログインしている担当者への連絡先が表示されている。また、場合によっては、佐藤一郎さんや鈴木次郎さんのプロジェクトの他のプロジェクトメンバに連絡した方がよい場合がある。例えば、プロジェクトの範囲がアプリ、インフラ、基盤などの多岐にわたる場合や、原因が特定できない場合である。このため、ＣＣ（カーボンコピー）などで送信可能なように、その他プロジェクトメンバの連絡先も表示される。

【0138】

画面作成部５４は、入館又はログインしている担当者ＩＤに対応づけられているＴＥＬとＥ−Ｍａｉｌアドレス（連絡先情報の一例）を顧客情報ＤＢ３００７から読み出す。そして、それぞれを電話アイコン、及び、メールアイコンにリンクさせる。したがって、アラーム詳細画面５２０を表示している担当者は電話アイコン５７３、及び、メールアイコン５７４を押下することで、メンテナンスしている可能性が高い担当者と連絡を取ることができる。上記のように、鈴木次郎さん以外のプロジェクトメンバの連絡先（例えばＥ−Ｍａｉｌアドレス）を表示することも可能である。

【0139】

また、推奨作業ボタン５２６ｅが押下されたことで直接、ユーザ端末７０が鈴木次郎さんに電話連絡してもよい。この場合、推奨作業ボタン５２６ｅに鈴木次郎さんの氏名を表示させる。

【0140】

なお、図１０〜図１２の画面の遷移例では、アラーム詳細画面５２０から横スクロール部５２６のボタンを担当者が押下する必要がある。しかし、アラーム詳細画面５２０に、入館情報画面５３０、ログイン情報画面５４０、カメラ情報画面５５０、センサー検知情報画面５６０及び推奨作業情報画面５７０の少なくとも1つ以上を表示してもよい。すなわち、上記の画面遷移は一例である。また、入館情報画面５３０、ログイン情報画面５４０、カメラ情報画面５５０、センサー検知情報画面５６０及び推奨作業情報画面５７０の２つ以上を１つの画面に集約してもよい。

【0141】

≪メンテナンス推定欄≫
続いて、図１３を用いてメンテナンス推定欄５２５に表示される内容の判断方法について説明する。図１３は、メンテナンス推定部５５がメンテナンスによる可能性が高いか否かを判定する手順を示すフローチャート図の一例である。図１３の処理はアラーム詳細画面５２０の画面情報が作成される際に実行される。

【0142】

まず、メンテナンス推定部５５は変数Ｐを初期化する（Ｓ１０）。変数Ｐはメンテナンスの可能性をカウントする変数である。

【0143】

次に、メンテナンス推定部５５は、管理支援システム５０にログインした担当者と同じプロジェクト名に紐づけられている担当者が入館しているか否かを判定する（Ｓ２０）。

【0144】

ステップＳ２０の判定がＹｅｓの場合、メンテナンス推定部５５はＰを１つ大きくする（Ｓ３０）。ステップＳ２０の判定がＮｏの場合、メンテナンス推定部５５は何もしない。

【0145】

次に、メンテナンス推定部５５は、管理支援システム５０にログインした担当者と同じプロジェクト名に紐づけられている担当者が被監視システム１９にログインしているか否かを判定する（Ｓ４０）。

【0146】

ステップＳ４０の判定がＹｅｓの場合、メンテナンス推定部５５はＰを１つ大きくする（Ｓ５０）。ステップＳ４０の判定がＮｏの場合、メンテナンス推定部５５は何もしない。

【0147】

次に、メンテナンス推定部５５は、管理支援システム５０にログインした担当者に紐づけられているラックが開状態か否かを判定する（Ｓ６０）。

【0148】

ステップＳ６０の判定がＹｅｓの場合、メンテナンス推定部５５はＰを１つ大きくする（Ｓ７０）。ステップＳ６０の判定がＮｏの場合、メンテナンス推定部５５は何もしない。

【0149】

最後に、メンテナンス推定部５５はＰが１以上か否かを判定する（Ｓ８０）。そして、Ｐが１以上なら、メンテナンス推定部５５はメンテナンスの可能性が高い（注意）と判断する（Ｓ９０）。一方、Ｐが１未満なら、メンテナンス推定部５５は対応が必要な障害の可能性が高い（警告）と判断する（Ｓ１００）。

【0150】

したがって、入館情報、ログイン情報及びセンサー検知情報を総合して、これらのうち１つ以上でメンテナンス前の行為が行われた場合、メンテナンスの可能性が高いと判断できる。なお、図１３の判断方法は一例に過ぎず、例えば、ステップＳ８０の閾値を適宜、変更してよい。また、入館情報、ログイン情報及びセンサー検知情報に異なる重み付けをしてもよい（Ｐの増分を変える）。

【0151】

なお、担当者はアラーム詳細画面５２０から入館情報、ログイン情報及びセンサー検知情報を確認できる。また、入館やログインしている担当者と連絡を取ることもできる。よって、メンテナンス推定欄５２５の表示内容は正確でなくてもよい。しかし、メンテナンス推定部５５がメンテナンスの可能性が高いと判断すると、担当者がアラームの内容を確認せずにアラームを抑止する可能性もあるため、対応が必要な障害の可能性が高い側に判定することが有効である。

【0152】

また、ログインしてからの経過時間を考慮することも有効である。図１４を用いて説明する。図１４では、ステップＳ４０でログインあり又はログアウト後、５分以内かどうかが判定されている。すなわち、メンテナンス推定部５５は担当者がログインしている場合だけでなくログアウト後、間もない場合にメンテナンスの可能性があると推定する。なお、「ログアウト後、５分」は一例に過ぎず、ログアウト後の時間をパラメータとする任意の関数により判定してもよい。

【0153】

例えば、担当者がメンテナンスする場合、ログインしてからメンテナンスまでの時間は短いことが多い。一方、ログインしてから数時間後なら入館中でもメンテナンスの可能性は低い。したがって、ログインからアラーム発生までの時間をＰの増分に反映させることで、メンテナンスによるアラームかどうかを判定しやすくすることができる。

【0154】

≪事象詳細確認画面≫
続いて、図１５を用いて、担当者が図１０（ｂ）のメンテナンス推定欄５２５を押下した場合に表示される事象詳細確認画面５８０について説明する。なお、事象詳細確認画面５８０は図１０（ｂ）の他のボタンから遷移されてもよい（例えば横スクロール部５２６の事象詳細ボタン５２６ｆ）。

【0155】

図１５は事象詳細確認画面５８０の一例を示す図である。事象詳細確認画面５８０には、時系列に監視情報（図１５ではＣＰＵ使用率）が表示され、この監視情報の折線グラフ５８９上にイベントの発生を意味するイベントマーク５８１が表示されている。担当者は折線グラフ５８９をスクロールさせて任意の時刻の監視情報を見ることができる。なお、ユーザ端末７０が取得していない時刻の監視情報は、ユーザ端末７０が画面遷移させることなく管理支援システム５０から取得できる。

【0156】

また、事象詳細確認画面５８０には縦軸選択ボタン５８２、時間スケール調整ボタン５８３、表示イベント設定ボタン５８４、及び、閉じるボタン５８５が表示される。縦軸選択ボタン５８２は監視情報（ＣＰＵ使用率、メモリ使用率、ディスクＩ／Ｏ回数、ＨＤＤ空き容量、ネットワーク使用率など）のうち事象詳細確認画面５８０に表示されるものを担当者がマウスを用いて又はタッチパネルから選択するためのボタンである。同時に複数の監視情報を選択可能でもよい。なお、初期状態では最も新しいアラームの原因となった監視情報が縦軸で表示される（例えば、ＣＰＵ使用率がアラーム基準を超えた場合はＣＰＵ使用率）。アラームの原因となった監視情報がない場合、予め定められた監視情報が縦軸で表示される。

【0157】

時間スケール調整ボタン５８３は監視情報の表示範囲（最大時刻と最小時刻）を担当者が設定するためのボタンである。

【0158】

表示イベント設定ボタン５８４は、折線グラフ５８９上に表示されるイベントマーク５８１を担当者が設定するためのボタンである。表示されるイベントには、重要エラー、通常エラー、警告、注意、ログイン／ログアウト、入館／退館などがあるがこれらに限られるものではない。×印のイベントマーク５８１は警告を意味し、感嘆符のイベントマーク５８１は注意を意味する。なお、重要エラーは、アラームのうち予め定められている事象（例えば、温度異常などの物理的な障害）をいい、通常エラーはそれ以外をいう。警告は対応が必要な障害の可能性が高いアラームであり、注意はメンテナンスの可能性が高いアラームである。したがって、担当者はイベントマーク５８１として表示されイベントのレベルを選択できる。

【0159】

また、イベントマーク５８１を担当者がマウスを用いて又はタッチパネルから選択すると、イベント情報が表示される。イベント情報には、時刻、事象、内容、及び、状態が表示され、電話アイコン５８６、電子メールアイコン５８７、スパナアイコン５８８、及び、詳細ボタン５９０が表示される。時刻、内容、及び、状態についてはアラーム履歴ＤＢ３００４に登録されている。事象はイベントの内容を示すものなので、イベントマーク５８１の作成時に明らかになっている。

【0160】

電話アイコン５８６には、事象詳細確認画面５８０を表示している担当者と同じプロジェクト名に紐づけられている担当者の電話番号が埋め込まれている。電子メールアイコン５８７には、事象詳細確認画面５８０を表示している担当者と同じプロジェクト名に紐づけられている担当者のＥ−Ｍａｉｌアドレスが埋め込まれている。それぞれログイン又は入館している担当者の電話番号やＥ−Ｍａｉｌが強調して表示されてもよい。スパナアイコン５８８には図７で説明した担当者対応画面５０１がリンクされている。

【0161】

担当者が詳細ボタン５９０を押下すると、選択されているイベントマーク５８１が表示されている時刻において各データベースから取得可能な情報が表示される。例えば、該時刻に入館している担当者、ログインしている担当者、ラックの開閉状態、監視情報（数値）、撮影データなどが表示される。

【0162】

このように事象詳細確認画面５８０を表示した担当者は、時系列で各イベントと監視情報（リソース等）の状況を確認できる。監視情報にイベントマーク５８１が重ねて表示されるため、担当者はイベントと監視情報の対応を把握しやすい。

【0163】

事象詳細確認画面５８０によれば、担当者が入館、ログイン又はラックの開放の等を行っていない場合に生じたアラームの原因を調査しやすくなる。例えば、バッチ処理の動作異常が生じた場合を説明する。

【0164】

比較のため、従来における原因調査の手順を説明する。例えば、担当者が休日中にＷｅｂアプリの接続エラーに関するアラームを断続的に受信したものとする。関係者（同じプロジェクトの他の担当者）に連絡したが誰も作業をしていなかった。そこで、出社して監視情報のログを調査すると、最初にアラームが発生した時刻の１０分前からＣＰＵ使用率が異常に高くなっていることが分かった。さらに調査を継続すると、同時間にスケジュール起動したバッチプログラムの動作異常がＣＰＵ使用率を高くしていることが判明した。バッチプログラムを強制終了することで障害を復旧できたが、復旧までに長時間（数時間以上）を要してしまった。

【0165】

続いて、事象詳細確認画面５８０を用いたアラームの原因調査について説明する。担当者が休日中にＷｅｂアプリの接続エラーに関するアラームメールを断続的に受信した。ユーザ端末７０にアラーム詳細画面５２０を表示させることで、電話連絡することなく誰もメンテナンス作業をしていないことが分かる。次に、事象詳細確認画面５８０を表示させると、時系列のＣＰＵ使用率の上昇後にアラームが発生しており、関連性がある可能性があることが判明した。出社してアラーム発生時刻にＣＰＵ使用率が異常に高くなった原因を調べたところ、スケジュール起動したバッチプログラムの動作異常であることが判明した。バッチプログラムを強制終了することで障害を復旧した。復旧までに要した時間は１時間未満であった。

【0166】

このように、アラームの通知を受けた担当者は、管理支援システム５０にアクセスするだけで、アラームがメンテナンスによるものかどうかを判別できる。また、誰もメンテナンスしていない場合は、ユーザ端末７０に監視情報とアラームの関係を表示させることで、原因を推定できる。

【0167】

続いて、電話アイコン５８６及び電子メールアイコン５８７が押下された場合の画面について説明する。図１６（ａ）は電話アイコン５８６がマウス又はタッチパネルから選択された場合にユーザ端末７０に表示される電話連絡先一覧画面６２０の一例を示す。電話連絡先一覧画面６２０には１つ以上の電話連絡先６２１が表示される。電話連絡先６２１は、電話連絡先一覧画面６２０を表示している担当者と同じプロジェクトの他の担当者の電話番号である。電話連絡先６２１には連絡ボタン６２２が表示される。担当者が連絡ボタン６２２を押下すると、この操作だけで電話をかけることができる。なお、入館している他の担当者又はログインしている他の担当者がいる場合、該担当者の電話連絡先６２１が強調表示される（図１６（ａ）では「推奨」という文字が表示されている）。なお、電子メールアイコン５８７が押下された場合も同様の画面が表示される。

【0168】

次に、スパナアイコン５８８が押下された場合の画面について説明する。スパナアイコン５８８には図７で説明した担当者対応画面５０１がリンクされていると説明した。そして担当者対応画面５０１でアラーム抑止設定ボタン５０５が押下されると図１６（ｂ）のアラーム抑止申請画面６０１が表示される。

【0169】

アラーム抑止申請画面６０１はフェーズ表示欄６０２，及び、プロジェクト選択欄６０３を有する。フェーズ表示欄６０２はアラーム抑止の設定に必要な４つのフェーズのうち現在のフェーズを示す。プロジェクト選択欄６０３にはプロジェクト名が表示される。このプロジェクト名は、アラーム抑止申請画面６０１を表示させている担当者が所属するプロジェクトである。アラームが発報されているサーバに対応づけられたプロジェクトの場合は、強調表示されてもよい。

【0170】

担当者がプロジェクト選択欄６０３のプロジェクト名又は次へボタン６０４をマウスやタッチパネルを介して選択する。これにより図１６（ｃ）のアラーム抑止設定画面６１０が表示される。アラーム抑止設定画面６１０は抑止対象サーバ欄６１１、抑止期間欄６１２、理由欄６１３、備考欄６１４、及び、メール送信欄６１５を有する。抑止対象サーバ欄６１１には、アラーム抑止申請画面６０１で選択されたプロジェクト名に紐付いているサーバ名が表示される。その他の入力欄は担当者が任意に設定できる。

【0171】

このように、担当者は事象詳細確認画面５８０から少ない操作でアラーム抑止設定することができる。図７に示したように担当者対応画面５０１ではアラーム抑止だけでなく、関係者連絡、入館申請、及び、遠隔メンテナンスすることもできる。したがって、アラーム発報時に行われやすい初動作業をアラーム内容の確認画面（事象詳細確認画面５８０）から一元的に選択できる。これにより効率的な初動対応が可能になる。

【0172】

なお、事象詳細確認画面５８０から担当者対応画面５０１を経ることなくアラーム抑止申請画面６０１に画面が遷移してもよい。例えば、アラームがメンテナンスによるモノである可能性が高い場合（メンテナンス推定欄５２５でメンテナンスの可能性が高いと判断された場合）、事象詳細確認画面５８０から直接、アラーム抑止申請画面６０１に遷移してもよい。メンテナンスの場合、担当者はアラームを抑止する可能性が高いので、担当者が必要な操作手順を少なくできる。

【0173】

＜画面作成の動作手順＞
図１７を用いて図９のステップＳ１０の画面作成の動作手順について説明する。図１７は画面作成部５４がアラーム詳細画面５２０の画面情報を作成する手順を示すフローチャート図の一例である。

【0174】

管理支援システム５０の画面作成部５４は、アラーム詳細画面５２０を表示する担当者と同じプロジェクト名に紐づけられている担当者が入館しているか否かを判定する（Ｓ１０）。

【0175】

ステップＳ１０の判定がＹｅｓの場合、画面作成部５４は入館情報ボタン５２６ａに図１１（ａ）で説明した入館情報画面５３０をリンクさせる（Ｓ２０）。

【0176】

次に、管理支援システム５０の画面作成部５４は、アラーム詳細画面５２０を表示する担当者と同じプロジェクト名に紐づけられている担当者がログインしているか否かを判定する（Ｓ３０）。

【0177】

ステップＳ３０の判定がＹｅｓの場合、画面作成部５４はログイン情報ボタン５２６ｂに図１１（ｂ）で説明したログイン情報画面５４０をリンクさせる（Ｓ４０）。

【0178】

次に、管理支援システム５０の画面作成部５４は、カメラ情報ボタン５２６ｃに図１１（ｃ）（ｄ）でカメラ情報画面５５０をリンクさせる（Ｓ５０）。

【0179】

次に、管理支援システム５０の画面作成部５４は、センサー検知情報ボタン５２６ｄに図１２（ａ）で説明したセンサー検知情報画面５６０をリンクさせる（Ｓ６０）。

【0180】

次に、管理支援システム５０の画面作成部５４は、アラームが発報されているか否かを判定する（Ｓ７０）。これは、アラームが発報されていなくてもアラーム詳細画面５２０を表示することは可能なためである。

【0181】

ステップＳ７０の判定がＹｅｓの場合、管理支援システム５０の画面作成部５４は推奨作業情報画面５７０を作成し推奨作業ボタン５２６ｅにリンクさせる（Ｓ８０）。すなわち、ラック位置を示す地図を作成し、ラック状態情報５７２を配置する。また、電話アイコン８２にＴＥＬをメールアイコン８３にＥ−Ｍａｉｌアドレスをそれぞれリンクさせる。

【0182】

また、管理支援システム５０のメンテナンス推定部５５はアラームがメンテナンスによるものかどうかの可能性を推定する（Ｓ９０）。画面作成部５４は推定結果をメンテナンス推定欄５２５の内容と色に反映させる。

【0183】

次に、管理支援システム５０の画面作成部５４は事象詳細確認画面５８０を作成しメンテナンス推定欄５２５にリンクさせる（Ｓ１００）。ここではアラームが発報されているものとして説明する。
（１００−１）まず、アラーム履歴ＤＢ３００４を参照して、担当者が選択したアラーム番号に基づき事象詳細確認画面５８０の縦軸（監視情報）を決定する。アラームが監視情報以外を原因とする場合は予め定められた監視情報を縦軸に決定する。
（１００−２）アラームの直近の一定時間（例えば３０〜６０分）の監視情報を監視情報ＤＢ３００６から読み出す。そして、時間軸と縦軸の対応する位置に値を打点し、点と点を直線などで結ぶ。このような折線グラフ５８９はＪａｖａＳｃｒｉｐｔ（登録商標）のライブラリに時刻と値の組を設定することで作成できる。
（１００−３）イベントマーク５８１を表示するためのイベントを決定する。ここでは担当者が関係するイベントを予め設定しているものとする。
（１００−４）イベントと関係する情報をデータベースから読み出す。例えば、警告と注意のアラームが設定されている場合、アラーム履歴ＤＢ３００４から警告と注意のアラーム履歴情報を読み出す。
（１００−５）アラームの発生時刻における監視情報に重ねてイベントマーク５８１を表示させる記述を行う。すなわち、イベントマーク５８１の位置を決定する。
（１００−６）イベントマーク５８１に時間、事象、内容、及び、状態を埋め込み、また、電話アイコン５８６、電子メールアイコン５８７、スパナアイコン５８８及び詳細ボタン５９０を埋め込む。さらに詳細ボタン５９０に該時刻に入館している担当者、ログインしている担当者、ラックの開閉状態、監視情報（数値）、撮影データなどを埋め込む。

【0184】

以上のような処理により、事象詳細確認画面５８０の画面情報を作成してユーザ端末７０に送信できる。

【0185】

図１０〜図１２及び図１５にて説明したように、本実施形態の管理支援システム５０は担当者が初動判断したり初動作業を行うために必要な情報をアラーム詳細画面５２０でまとめて提供できる。例えば、メンテナンス推定欄５２５によりアラームがメンテナンスによる可能性が高いかどうかを一目で判断できる。また、アラーム詳細画面５２０から１回の操作で他の担当者の入館状況、ログイン状況、カメラ２１の撮影データ、及び、ラックの状態、を確認できる。したがって、短い時間又は少ない操作でメンテナンスによるアラームかどうかを担当者が判断できる。

【0186】

また、アラーム詳細画面５２０から１回の操作で推奨される初動作業を確認でき、入館又はログインしている担当者がいれば連絡先が表示されるので、メンテナンスしている可能性が高い担当者とすぐに連絡を取れる。したがって、メンテナンスしている可能性が高い担当者に対し短い時間又は少ない操作で確認することもできる。

【0187】

＜その他の適用例＞
以上、本発明を実施するための最良の形態について実施例を用いて説明したが、本発明はこうした実施例に何等限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変形及び置換を加えることができる。

【0188】

例えば、本実施形態では、アラームが通知された担当者が管理支援システム５０にログインすることで入館情報等が提供された。しかし、入館情報等は、アラームの通知の時点で担当者に提供されてもよい。すなわち、図９のステップＳ３で運用・監視システム３０がアラームと共に入館情報等を担当者のＥ−Ｍａｉｌアドレス宛に送信したり、ＳＮＳを利用して送信したりする。

【0189】

アラームの原因となるサーバに基づいてプロジェクト名が分かり、プロジェクト名に紐付いている担当者ＩＤを取得できる。この担当者ＩＤのうち入館情報に入館していることが記載されている担当者を入館情報ＤＢから読み出す。また、ログイン情報にログインしていることが記載されている担当者をログイン情報ＤＢ３００５から読み出す。また、サーバに紐付いているラックの開閉状態をセンサー検知情報ＤＢ３００８から読み出す。したがって、アラームを通知する段階で、運用・監視システム３０はアラームと共に入館状況、ログイン状況、及び、ラック状態を担当者に送信できる。

【0190】

また、本実施形態ではいくつかの画面を例示したが、これらは説明の便宜上、図示したものに過ぎず、画面に表示される内容やデザインは図示したものに限られない。すなわち、運用・監視システム３０が保持する情報であれば管理支援システム５０がユーザ端末７０に提供することができる。

【0191】

また、本実施形態ではデータセンター１１に設置された被監視システム１９について説明したが、データセンター１１には同等の機能を備えた施設が含まれる。すなわち、被監視システム１９が配置された施設がデータセンターと呼ばれていなくてもよい。また、例えば、自社内の被監視システムにも本実施形態は適用できる。すなわち、社員の自社への入室、被監視システム１９へのログイン、ラックの開閉状態を運用・管理システムが記録すれば、担当者としての社員にこれらの情報を提供できる。

【0192】

また、図５などの構成例は、運用・監視システム３０、入館管理システム２０、管理支援システム５０及びユーザ端末７０の処理の理解を容易にするために、主な機能に応じて分割したものである。例えば、運用・監視システム３０と管理支援システム５０が一体でもよい。また、入館管理システム２０と運用・監視システム３０とが一体でもよい。

【0193】

また、処理単位の分割の仕方や名称によって本願発明が制限されることはない。運用・監視システム３０、入館管理システム２０、及び、管理支援システム５０の処理は、処理内容に応じてさらに多くの処理単位に分割することもできる。また、１つの処理単位がさらに多くの処理を含むように分割することもできる。

【0194】

また、本実施形態では障害の発生時のアラームを例にして説明したが、災害の発生時に発報されるアラームに対しても自動的にシステムごとの条件と情報を抽出して適用できる。災害とは、例えば、水害、風害、砂嵐、塩害、土砂災害、雪害、雹、雷、震度やマグニチュードが閾値以上の地震、火山の噴火、隕石の落下、太陽活動、テロ、暴動、爆発などである。災害時にサーバの画像や稼動状況などが配信されれば、担当者が初動判断しやすくなる。この場合は、災害発生後の状況変化を判断するため、アラーム後の情報が有効である。

【符号の説明】

【0195】

１１ データセンター
１９ 被監視システム
２０ 入館管理システム
２１ カメラ
２２ センサー
５０ 管理支援システム
７０ ユーザ端末
８１ ラック
３００ 管理システム

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】