(57)【特許請求の範囲】
【請求項１】
対象システムの障害を含むインシデントをインシデント情報として第１のデータベースに管理するインシデント管理システムであって、
前記対象システムの構成を構成情報として第２のデータベースに管理する構成管理システムと連携し、
担当者の端末に対して情報の画面を提供するサービスポータルシステムと連携し、
前記対象システムの障害を含むインシデントを監視する障害監視システムと連携し、
本インシデント管理システムは、
前記対象システムの構成、障害影響範囲及び障害影響先サービスを含むインシデント状況を可視化する画面を、前記構成情報及び前記インシデント情報を用いて作成し、前記担当者の端末に提供する第１の機能と、
前記担当者の操作に基づき、前記対象システムにおける障害許容性を考慮して設計される構成部位を含む構成を、構成管理モデルとして前記構成情報に設定する第２の機能と、を有し、
前記構成管理モデルでは、前記障害許容性を考慮して設計される構成部位を含む各構成部位を第１の構成アイテムとして設定し、前記第１の構成アイテムについての障害許容性を第２の構成アイテムとして設定し、前記第１、第２の構成アイテムを含む構成アイテム間の依存関係性をリンクとして設定し、
前記第１の機能による画面では、前記構成アイテムをリンクで接続した構造で、前記対象システムの構成管理モデル、障害箇所を含む障害影響範囲の構成アイテム及び障害影響先サービスを含むインシデント状況を表示すること、を特徴とするインシデント管理システム。
【請求項２】
請求項１記載のインシデント管理システムにおいて、
（Ｓ１）前記対象システムでの障害を検知し障害情報を取得する処理部、
（Ｓ２）前記対象システムの構成情報を取得する処理部、
（Ｓ３）前記対象システムの障害箇所を含む構成部位に対する初期診断を実行する処理部、
（Ｓ４）前記初期診断の実行結果の情報を取得する処理部、
（Ｓ５）上記（Ｓ４）の情報を用いて、前記障害による障害影響範囲に含まれる第１の構成アイテム及び第２の構成アイテムを抽出する処理部、
（Ｓ６）上記（Ｓ４）の情報を用いて、前記障害による障害影響範囲に含まれる第２の構成アイテムのステータスを、障害許容性の設計情報に従って把握する処理部、
（Ｓ７）上記（Ｓ６）の情報を用いて、前記障害への対策に関する優先度、及び目標解決時間、更にはエスカレーションの有無、を算出する処理部、
（Ｓ８）上記（Ｓ７）までの結果を前記インシデント情報及び構成情報に反映し、前記構成管理モデル上に前記障害影響範囲及び障害影響先サービスを含む障害状況をマッピングした情報を作成する処理部、
（Ｓ９）上記（Ｓ８）で作成した情報を用いて、前記対象システムでの障害状況を可視化する画面を前記担当者に対して提供する処理部、を有すること、を特徴とするインシデント管理システム。
【請求項３】
請求項２記載のインシデント管理システムにおいて、
前記（Ｓ５），（Ｓ６）の処理に係わり、前記第２の構成アイテムについて、前記ステータスの決定方法を前記障害許容性の設計情報として設定しておき、
前記ステータスは、障害許容性の度合いに応じた、正常、縮退、低下、停止を含む複数のステータス値を有し、
前記構成アイテム間のリンクは、上位の構成アイテムと下位の構成アイテムを接続し、
前記リンクのステータスは、下位の構成アイテムのステータスに応じて決定され、
前記構成アイテムは、それぞれレイヤに属し、レイヤの上位の構成アイテムのステータスは、レイヤの下位の構成アイテムのステータスに応じて決定され、
上位の構成アイテムのステータスを、前記リンクで接続されるすべての下位の構成アイテムのステータスの値を用いた計算により決定すること、を特徴とするインシデント管理システム。
【請求項４】
請求項１記載のインシデント管理システムにおいて、
前記画面では、前記構成アイテムを示すアイコンごと、及び前記リンクを示す線ごとに、ステータスに応じた色で表示すること、を特徴とするインシデント管理システム。
【請求項５】
請求項１記載のインシデント管理システムにおいて、
前記画面では、前記構成アイテムを示すアイコンごとに、当該構成アイテムに関連付けられる担当者の情報を表示すること、を特徴とするインシデント管理システム。
【請求項６】
請求項１記載のインシデント管理システムにおいて、
前記画面として、前記構成情報を表示する第１の画面と、前記インシデント情報を表示する第２の画面と、を有し、
前記第１の画面に、前記対象システムの構成管理モデル及び障害影響範囲を含むインシデント状況を表示すること、を特徴とするインシデント管理システム。
【請求項７】
請求項１記載のインシデント管理システムにおいて、
前記障害への対策に関する優先度、及び目標解決時間、更にはエスカレーションの有無、を算出する処理部を含む分析部を有し、
前記分析部の処理では、
前記第２の構成アイテムのステータスを用いて、当該インシデントの対策の緊急度（α）を算出し、
前記第２の構成アイテムのステータスを用いて、当該インシデントの対策のインパクトレベル（β）を算出し、
上記緊急度（α）とインパクトレベル（β）を用いて、前記優先度を算出し、
前記優先度に対応付けて、目標解決時間を決定し、
前記優先度に対応付けて、エスカレーションの有無を決定し、
前記障害影響範囲による障害影響先となる上位のサービスのステータス及び数を含む情報を算出すること、を特徴とするインシデント管理システム。
【請求項８】
対象システムの障害を含むインシデントをインシデント情報として第１のデータベースに管理するインシデント管理システムにおける障害影響範囲可視化方法であって、
前記インシデント管理システムは、前記対象システムの構成を構成情報として第２のデータベースに管理する構成管理システム、担当者の端末に対して情報の画面を提供するサービスポータルシステム、及び、前記対象システムの障害を含むインシデントを監視する障害監視システムと連携し、
前記インシデント管理システムは、前記担当者の操作に基づき、前記対象システムにおける障害許容性を考慮して設計される構成部位を含む構成を、構成管理モデルとして前記構成情報に設定する機能と、前記対象システムの構成、障害影響範囲及び障害影響先サービスを含むインシデント状況を可視化する画面を、前記構成情報及び前記インシデント情報を用いて作成し、前記担当者の端末に提供する機能と、を有し、
前記構成管理モデルでは、前記障害許容性を考慮して設計される構成部位を含む各構成部位を第１の構成アイテムとして設定し、前記第１の構成アイテムについての障害許容性を第２の構成アイテムとして設定し、前記第１、第２の構成アイテムを含む構成アイテム間の依存関係性をリンクとして設定し、
前記画面では、前記構成アイテムをリンクで接続した構造で、前記対象システムの構成管理モデル、障害箇所を含む障害影響範囲の構成アイテム及び障害影響先サービスを含むインシデント状況を表示し、
前記インシデント管理システムは、
（Ｓ１）前記対象システムでの障害を検知し障害情報を取得する処理、
（Ｓ２）前記対象システムの構成情報を取得する処理、
（Ｓ３）前記対象システムの障害箇所を含む構成部位に対する初期診断を実行する処理、
（Ｓ４）前記初期診断の実行結果の情報を取得する処理、
（Ｓ５）上記（Ｓ４）の情報を用いて、前記障害による障害影響範囲に含まれる第１の構成アイテム及び第２の構成アイテムを抽出する処理、
（Ｓ６）上記（Ｓ４）の情報を用いて、前記障害による障害影響範囲に含まれる第２の構成アイテムのステータスを、障害許容性の設計情報に従って把握する処理、
（Ｓ７）上記（Ｓ６）の情報を用いて、前記障害への対策に関する優先度、及び目標解決時間、更にはエスカレーションの有無、を算出する処理、
（Ｓ８）上記（Ｓ７）までの結果を前記インシデント情報及び構成情報に反映し、前記構成管理モデル上に前記障害影響範囲及び障害影響先サービスを含む障害状況をマッピングした情報を作成する処理、
（Ｓ９）上記（Ｓ８）で作成した情報を用いて、前記サービスポータルシステムで、前記対象システムでの障害状況を可視化する画面を前記担当者に対して提供する処理、を行うこと、を特徴とする障害影響範囲可視化方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＴサービス運用管理におけるインシデント管理システムなどの技術に関し、特に、対象システムの構成や障害状況などを把握・可視化する技術などに関する。
【背景技術】
【０００２】
ＩＴサービス運用管理におけるインシデント管理などに係わる基準として、ＩＴＩＬ（Information Technology Infrastructure Library）Version3などがある。インシデント管理システムでは、管理対象の情報処理システム（対象システム）で発生する障害などのインシデントをインシデント情報として記録・管理し、インシデントへの対策（対応）やエスカレーションに連携する。
【０００３】
対象システムでは、クラウド環境の発展などに伴い、仮想サーバや並列分散処理などの技術が適用されている。また、対象システムでは、サービスレベルなどに基づいて、サーバやデータベースなどの構成部位（構成アイテム）は、障害許容性（フォールト・トレランス等）や性能などを考慮して、多重化構成などで設計・実装されている。
【０００４】
先行技術例として、特開２００７−２５７２４４号公報（特許文献１）（障害影響範囲特定システム等）、特開２００９−１８１５３７号公報（特許文献２）（インシデント管理システム等）などがある。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００７−２５７２４４号公報
【特許文献２】特開２００９−１８１５３７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
従来のインシデント管理システム（及び構成管理システム等の関連システム）では、課題として、対象システムでの障害（インシデント）の発生時の影響範囲や影響先（上位のサービスなど）、及び緊急度やインパクトレベルなどを、担当者（インシデント管理者）が即座に把握することが難しい。よって、それらの把握に基づく優先度などに即した迅速なエスカレーション及び対策の実施などが難しい。特に、対象システムの構成部位が障害許容性などに応じた多重化構成などを採る場合、構成部位（構成アイテム）間での影響関係などが複雑であるため、上記の課題が顕著である。
【０００７】
上記課題に対し、対象システムの障害影響範囲などの状況や構成（インシデント状況や運用状況）を画面で可視化する技術などが有効なものとして考えられる。しかし、従来技術では、クラウド環境や障害許容性などを考慮して設計・実装された構成の対象システムにおける障害影響範囲などの状況や構成を画面でわかりやすく可視化する技術について検討・実現が不十分である。
【０００８】
本発明の主な目的は、上記インシデント管理システム等に係わり、クラウド環境や障害許容性などを考慮した構成の対象システムにおける、障害影響範囲などの状況や構成、及びインシデント・対策の優先度などの情報を画面で可視化することで、担当者が上記状況などを即座にわかりやすく把握でき、迅速なエスカレーション及び対策の実施などが実現できる技術を提供することである。
【課題を解決するための手段】
【０００９】
上記目的を達成するために、本発明の代表的な実施の形態は、インシデント管理システム等であって、以下に示す構成を有することを特徴とする。
【００１０】
本インシデント管理システムは、対象システムの障害を含むインシデントをインシデント情報として第１のデータベースに管理し、前記対象システムの構成を構成情報として第２のデータベースに管理する構成管理システムと連携し、担当者の端末に対して情報の画面を提供するサービスポータルシステムと連携し、前記対象システムの障害を含むインシデントを監視する障害監視システムと連携する。本インシデント管理システムは、前記対象システムの構成、障害影響範囲及び障害影響先サービスを含むインシデント状況を可視化する画面を、前記構成情報及び前記インシデント情報を用いて作成し、前記担当者の端末に提供する第１の機能と、前記対象システムにおける障害許容性を考慮して設計される構成部位を含む構成を、構成管理モデルとして前記構成情報に設定する第２の機能と、を有する。
【００１１】
そして、前記構成管理モデルでは、前記障害許容性を考慮して設計される構成部位を含む各構成部位を第１の構成アイテムとして設定し、前記第１の構成アイテムについての障害許容性を第２の構成アイテムとして設定し、前記第１、第２の構成アイテムを含む構成アイテム間の依存関係性をリンクとして設定する。前記第１の機能による画面では、前記構成アイテムをリンクで接続した構造で、前記対象システムの構成管理モデル、障害影響範囲及び障害影響先サービスを含むインシデント状況を表示する。
【発明の効果】
【００１２】
本発明の代表的なものによれば、インシデント管理システム等に係わり、クラウド環境や障害許容性などを考慮した構成の対象システムにおける、障害影響範囲などの状況や構成、及びインシデント・対策の優先度などの情報を画面で可視化することで、担当者が上記状況などを即座にわかりやすく把握でき、迅速なエスカレーション及び対策の実施などが実現できる。
【図面の簡単な説明】
【００１３】
【図１】本発明の一実施の形態のインシデント管理システムを含むコンピュータシステム全体の概要構成例を示す図である。
【図２】本実施の形態のインシデント管理システムに係わる各部の構成例を示す図である。
【図３】本実施の形態における対象システムの構成管理モデル及び正常時の状況を可視化する画面例を示す図である。
【図４】本実施の形態における対象システムの構成管理モデル及び障害時の状況を可視化する画面例を示す図である。
【図５】（ａ）〜（ｆ）は、本実施の形態における対象システムの障害許容性構成アイテム（ＦＴＣＩ）の障害許容情報の例を示す図である。
【図６】本実施の形態における構成情報（構成アイテム情報）等の例を示す図である。
【図７】本実施の形態における構成アイテムのステータス決定方法の例を示す図である。
【図８】本実施の形態における構成アイテム間の依存関係性の情報の例を示す図である。
【図９】本実施の形態における構成管理モデル（一部）の例を示す図である。
【図１０】本実施の形態における優先度算出方法などを示す図である。
【図１１】本実施の形態におけるインシデント情報の例を示す図である。
【図１２】本実施の形態におけるインシデント画面の例を示す図である。
【図１３】従来技術例における画面例を示す図である。
【発明を実施するための形態】
【００１４】
以下、本発明の実施の形態（インシデント管理システム、障害影響範囲可視化方法）を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一符号を付し、その繰り返しの説明は省略する。
【００１５】
［概要等］
本実施の形態の概要や特徴などは以下である（図１，図３，図４等）。主な特徴として、本インシデント管理システム１０は、障害影響範囲可視化機能１０１を有し、また、構成管理システム２０は、障害許容性構成アイテム（ＦＴＣＩ）設定機能１０２を有する（図１）。障害影響範囲可視化機能１０１は、対象システム１の構成及び障害状況（障害影響範囲など）を画面で可視化する機能である。ＦＴＣＩ設定機能１０２は、対象システム１の構成情報（構成管理モデル）において、サーバ等の構成部位（構成アイテム：ＣＩ）の「障害許容性」（障害許容性などを考慮した設計・実装の構成）を、一種の構成アイテム（障害許容性構成アイテム：ＦＴＣＩ）として設定する機能である。
【００１６】
構成アイテム（ＣＩ）とは、構成管理モデル（構成情報）及び画面（図３等）において、対象システム１を構成するサーバ等の構成部位であり、画面に表示する対象となる要素である。ＣＩは、カテゴリ等に応じて、特定のアイコンなどの表現で表示される。ＣＩ間の依存関係性（リンク）も線などで可視化される。ＣＩ及びリンクを含んで成る構成管理モデルが設定される。
【００１７】
「障害許容性」とは、本技術分野における公知の用語（フォールト・トレランス等）に従ったものであり、対象システム１における障害許容性や性能やサービスレベルなどを考慮した設計・実装の構成に相当し、例えば冗長構成など（物理的・仮想的な多重化・クラスタリングなど）の公知の各種技術が該当する。「障害許容性」は、対象システム１（ＣＩ）の設計情報の１つであり、ＦＴＣＩ設定機能１０２を用いて、担当者３等により、ＦＴＣＩとして設定が可能となっている。
【００１８】
画面（図３，図４等）では、ＦＴＣＩを含む構成管理モデル上に、本システムでの分析結果など（障害状況など）がマッピングされた情報が可視化される。これにより担当者３は障害影響範囲やエスカレーション先などをわかりやすく即座に把握することができる。
【００１９】
［システム構成］
図１で、本インシデント管理システム１０を含むコンピュータシステム全体の概要構成例を示す。本インシデント管理システム１０は、構成管理システム２０、サービスポータルシステム３０、障害監視システム４０等と連携するシステムである。運用管理・監視、インシデント管理、及び構成管理などのプロセス間の連携がシステム化されている。対象システム１は、インシデント管理運用の対象となる情報処理システム（稼働システム）である。担当者３は、サービスポータルシステム３０を利用するユーザやその端末などである。図１のように各システム間は通信可能に接続される。なお各システム（１０，２０，３０，４０等）を一体化したシステムとしてもよいし、適宜分割した構成としてもよい。
【００２０】
○対象システム１：  対象システム１は、例えば、ネットワーク機器（スイッチ等）、サーバ、ストレージ、データベース、ミドルウェア、アプリケーション、等の構成部位を含んで成り、所定のサービス（サービス処理）を実現する。各構成部位は、例えばログ情報や障害メッセージを保持または出力する。
【００２１】
○インシデント管理システム１０：  インシデント管理システム１０は、サーバシステム等により構成され、基本的な機能として、インシデント管理データベース（ＤＢ）５１に障害情報を含むインシデント情報を管理（登録・検索など）する。インシデント情報は、障害情報、稼働情報（初期診断実行結果情報）、分析結果（優先度など）、等の情報が含まれる（後述、図１１等）。またインシデント情報は、対策情報、担当者情報などが含まれ得る（又は関連付けられる）。ＤＢ５１のインシデント情報（ｂ２）をもとにインシデント画面Ｇ２が構成される。
【００２２】
またインシデント管理システム１０では、構成管理システム２０で管理される対象システム１の構成（構成管理モデル）に関して、障害監視システム４０での対象システム１の障害監視に基づき、初期診断や分析処理により、構成・運用状況、障害などのインシデントの状況を把握する（障害構成情報ｂ３やインシデント情報ｂ２に反映される）。
【００２３】
担当者３等により、インシデント画面Ｇ２を通じて、対象システム１での障害などのインシデントに関して、対策情報（対策手順、説明など）や関連情報などを登録したり、検索したりすることができる。
【００２４】
図２には、インシデント管理システム１０の各部の詳細構成例などを示す。インシデント管理システム１０は、障害情報取得部１１、構成情報取得部１２、初期診断部１３、分析部１４｛障害影響範囲ＣＩ抽出部１５、ＦＴＣＩ状況把握部１６、優先度算出部１７｝、情報登録部１８、等を有する構成である。各部はソフトウェアプログラム等により実現される。
【００２５】
分析部１４は、インシデント分析の一部（ＦＴＣＩを含む対象システム１の障害（インシデント）の影響などの分析）をシステム化した処理部である。分析部１４は、検知された障害（インシデント）について障害影響範囲などを把握する機能、及び複数の障害（インシデント）について優先順位付けのための優先度などを算出する機能などを含む。各部の詳細については後述のフローで説明する。
【００２６】
○構成管理システム２０：  構成管理システム２０は、サーバシステム等により構成され、基本的な機能として、対象システム１や障害監視システム４０等から取得・収集した構成情報や、担当者３等により設定される構成情報を、構成管理データベース（ＤＢ）５２に管理（登録・検索など）する。構成情報は、ＣＩ情報（ＦＴＣＩ情報を含む）などが含まれる。構成情報を用いて、対象システム１の障害許容性などを含む構成が、構成管理モデルとしてモデル化される。また構成情報は、担当者情報などが含まれ得る（又は関連付けられる）。ＤＢ５２の構成情報（ｂ１）をもとに構成情報画面Ｇ１が構成される。
【００２７】
担当者３等により、構成情報画面Ｇ１を通じて、対象システム１の構成（構成管理モデル）に関して、構成アイテム（ＣＩ）及びＣＩ間の依存関係性（リンク）、上位のサービスとの関係性、などを構成情報（構成管理モデル情報）として設定することができる。特に、担当者３等により、ＦＴＣＩ設定機能１０２を用いて、構成管理モデルに、ＣＩの冗長構成の関係性など、ＦＴＣＩの情報（後述、図５）を設定することができる。
【００２８】
また例えば構成管理システム２０では、対象システム１の構成部位（ＣＩ）やそのカテゴリ等に対して、所定の担当者３（エスカレーション先を含む）を関連付け管理することができる。担当者情報は、例えば、通知先のアドレス、組織における所属、名前、担当の構成部位（ＣＩ）などの情報を有する。構成情報やインシデント情報には、必要に応じて担当者情報が関連付けられる。
【００２９】
また上記の構成情報は、担当者３等による手動操作での設定に限らず、一部自動的な処理による登録なども可能である。例えば、構成管理システム２０は、対象システム１から構成情報を取得・収集してＤＢ５２に反映する（ａ２）。また障害監視システム４０との連携により同様に構成情報を取得してもよい（図１のａ３）。例えば対象システム１の構成部位間での公知のディスカバリコマンド実行などによって構成情報の自動収集なども可能である。
【００３０】
○サービスポータルシステム３０：  サービスポータルシステム３０は、サーバシステム等により構成され、図２の画面提供部３１（例えばＷｅｂサーバ等による）を有し、各システム（１０，２０）の情報（構成情報ｂ１，インシデント情報ｂ２，障害構成情報ｂ３等）を用いて、担当者３等が閲覧するための各種の画面（Ｇ１，Ｇ２等）をＷｅｂページ等で構成し、担当者３の端末に提供する。画面を構成する元となる情報は、インシデント管理システム１０（情報登録部１８）側から提供される。
【００３１】
本実施の形態では、画面として、構成情報画面Ｇ１，インシデント画面Ｇ２を有する。特に、構成情報画面Ｇ１では、構成情報ｂ１、障害構成情報ｂ３をもとに、対象システム１に関する従来の構成情報（ＦＴＣＩ等は無し）を表示可能とするだけでなく、ＦＴＣＩを含む各ＣＩ及びリンクの構成（構成管理モデル）、及びその上にマッピングされる障害状況など（障害箇所・障害影響範囲・障害影響先サービスなど、及び担当者情報など）を可視化する（後述、図３，図４等）。インシデント画面Ｇ２では、インシデント情報ｂ２をもとに、優先度、目標解決時間、担当者情報などを含むインシデント情報を表示する（後述、図１１，図１２等）。障害構成情報ｂ３は、構成管理モデル（構成情報ｂ１）上に、分析部１４での分析結果による障害状況（障害影響範囲などを含む）や関連情報などをマッピングした情報である。
【００３２】
なお、障害構成情報ｂ３については、インシデント管理システム１０からサービスポータルシステム３０へ提供する形に限らず、構成管理システム２０から提供する形などとしてもよい。その場合、構成管理システム２０内（ＤＢ５２）で、障害構成情報ｂ３を含む構成管理モデルを管理する。また構成情報画面Ｇ１とは別に障害構成情報ｂ３用の画面などを提供してもよい。
【００３３】
担当者３の端末に対する画面の提供の仕方（ＧＵＩ）としては、対象システム１の構成・状況の変動に応じて画面表示内容を更新表示する。例えば、所定のＷｅｂページのウィンドウ（画面Ｇ１等）で常に対象システム１の構成や障害状況を表示する。そして構成や障害状況の変動に応じて上記表示内容を更新する。あるいはユーザ操作に応じて必要な時だけ画面を表示してもよい。また例えば障害検知（Ｓ１）に伴うアラートによって自動的に画面を表示してもよい。また画面Ｇ１と画面Ｇ２の間で表示を遷移してもよいし、表示内容を統合してもよい。また例えば、時点ごとに構成・状況を履歴（スナップ）として保存しておき、指定の時点の情報を表示可能としてもよい。
【００３４】
○障害監視システム４０：  障害監視システム４０は、公知の各種技術により構成可能であり、例えば、対象システム１に対して、サーバ・ストレージの監視及び構成情報収集、ネットワークの監視及び構成情報収集、及び監視に基づく障害ログ解析、等の処理機能を有する。なお他のシステム（１０，２０）に障害監視システム４０の処理機能を備えてもよい。障害監視システム４０は、対象システム１の構成部位からログ・障害メッセージ（ａ１）等を収集し、それによる障害情報（例えば障害ログ解析による障害検知・障害箇所情報など）をインシデント管理システム１０に通知する（Ｓ１）。また障害監視システム４０は、対象システム１の構成部位の構成情報を収集し、構成管理システム２０に提供してもよい（ａ３）。
【００３５】
○担当者３：  担当者３は、サービスポータルシステム３０を利用する担当者及びその端末等を示す。担当者３は、エスカレーション先を含む。担当者３は、Ｗｅｂブラウザ等を備える端末から、サービスポータルシステム３０へアクセスし、構成情報画面Ｇ１、インシデント画面Ｇ２を含む各種の画面（Ｗｅｂページ等）を閲覧することができる。担当者３の端末は、画面提供部３１への要求に応じて上記画面を取得して表示したり、あるいは自動的に画面の表示更新内容データを取得して表示内容を更新する。
【００３６】
担当者３として、Ｕは、初期診断担当者である。Ａ，Ｂ，Ｃは、各種のエスカレーション先の担当者である。Ａは機能的エスカレーション先を示し、対象システム１の構成部位に関連付けられる開発者・保守運用者などである。Ｂ，Ｃは階層的エスカレーション先を示し、組織の上司−部下といった階層的な関係者を示す。エスカレーション先は各種を設けて管理してもよい。例えば、階層的エスカレーション先の第１の種別（Ｂ）として管理（本システム）側の担当者、第２の種別（Ｃ）として顧客（対象システム１）側の担当者、等である。Ｅ１はＵからＡへのエスカレーション（通知など）を示す。Ｅ２はＵからＢまたはＣへのエスカレーション（通知など）を示す。
【００３７】
［管理運用フロー］
本実施の形態のインシデント管理システム１０及び障害影響範囲可視化方法におけるインシデント管理運用フローの概要は以下である。なお本管理運用フローは、ＩＴＩＬ Version3に準拠したものとなっている。
【００３８】
（０）ＦＴＣＩを含む構成管理モデルの設定  （その他、構成情報（ｂ１）の取得等）
（１−１）障害（インシデント）の検知  （その他、インシデントの識別・記録等）
（１−２）初期診断  （その他、障害ログ解析等）
（２−１）分析による障害状況などの把握：  障害影響範囲・影響先、ＦＴＣＩ状況などの把握
（２−２）分析によるインシデントの優先順位付け（対策方針決定）：  優先度・目標解決時間・エスカレーション先などの決定
（３−１）上記分析結果などを反映した情報の作成・登録：  構成管理モデル上に障害状況などをマッピング（障害構成情報ｂ３）、及び対応するインシデント情報（ｂ２）
（３−２）画面提供：  上記の情報（ｂ３，ｂ２）を可視化する画面（構成情報画面Ｇ１，インシデント画面Ｇ２）を構成し担当者３へ提供
（４−１）１次対応：  担当者３（初期診断担当者Ｕなど）により上記画面（Ｇ１，Ｇ２）で構成・障害状況・対策方針などを把握し、必要に応じて各種のエスカレーション（Ｅ１，Ｅ２）を実行
（４−２）２次対応：  エスカレーション先の担当者３（Ａ，Ｂ，Ｃ）により、上記画面（Ｇ１，Ｇ２）で構成・障害状況・対策方針などを把握し、必要に応じて対策などを実施。
【００３９】
上記（４−２）では、例えば、機能的エスカレーション先の担当者（Ａ）により、画面Ｇ２での障害メッセージの確認や、画面Ｇ１の障害影響範囲などを対象とした調査などを行い、例えばサーバプログラム修正など、障害への対策を実施する。これにより、当該障害の復旧など（問題解決）の場合、当該インシデントがクローズされる。なおインシデント情報（ｂ２）の登録（更新）は随時行われ、インシデントのステータスは随時更新される。
【００４０】
［処理フロー］
図１，図２を用いて、上記管理運用フローに基づく本システムの処理フローにおける、対象システム１での障害発生時における主な処理の流れ（ステップＳ０〜Ｓ９で示す）について説明する。
【００４１】
（Ｓ０：構成設定）  準備・前提の１つとして、構成管理システム２０（ＤＢ５２）に対し、対象システム１の構成（構成管理モデル）を設定する。例えば、担当者３等により、構成情報画面Ｇ１を用いて、各構成要素をＣＩとして設定し、ＣＩ間の依存関係性（リンク）を設定し、またＦＴＣＩ設定機能１０２を用いて、構成要素（ＣＩ）の障害許容性をＦＴＣＩとして設定することにより、構成管理モデルを構成情報として設定する。
【００４２】
（Ｓ１：障害検知）  インシデント管理システム１０（障害情報取得部１１）は、障害監視システム４０を用いて対象システム１の障害を検知する。障害検知をトリガにしてＳ２以降の処理を実行する。例えば、対象システム１から障害監視システム４０へ障害情報（障害メッセージ等）が出力される（図２のａ１）。障害監視システム４０から障害情報取得部１１へ障害情報（障害メッセージ等）が出力される。障害情報取得部１１は、受信（取得）した障害情報をＤＢ５１へインシデント情報として登録してもよい。障害情報取得部１１は、例えば、障害ログ解析などにより、障害メッセージから障害箇所のＣＩを抽出してもよい。
【００４３】
（Ｓ２：構成情報取得）  インシデント管理システム１０（構成情報取得部１２）は、構成管理システム２０（ＤＢ５２）から、日次などの所定のタイミングで、対象システム１の構成情報（構成管理モデル情報）を取得する。あるいは、構成が変更されたタイミングなどで構成情報を取得してもよい。取得した構成情報を以下の処理で用いる。
【００４４】
（Ｓ３：初期診断実行）  Ｓ１をもとに、インシデント管理システム１０（初期診断部１３）は、対象システム１（Ｓ１の障害検知箇所を含む、診断対象とする例えば対象システム１の全体または一部）に対して、初期診断（初期診断スクリプト）を実行する。初期診断スクリプトは、診断対象の部位のカテゴリ（サーバ、データベース等）毎に対応したスクリプトプログラムである。
【００４５】
（Ｓ４：初期診断結果取得）  インシデント管理システム１０（初期診断部１３）は、対象システム１から、上記Ｓ３の初期診断スクリプトの実行結果（稼働情報）を取得する。これにより対象システム１の稼働状況を把握する（障害箇所（ＣＩ）の把握を含む）。Ｓ４の結果情報は、ＤＢ５１の該当インシデント情報に反映してもよい。
【００４６】
次に、Ｓ４までの情報に基づき、以下のＳ５〜Ｓ７で、分析部１４により、当該障害（インシデント）に関する分析処理を行う。これにより、Ｓ５では障害影響範囲のＣＩを把握し、Ｓ６ではＦＴＣＩの状況（ステータス）を把握し、Ｓ７では、優先度（Ｐ）や目標解決時間（Ｔ）などを決定する。
【００４７】
（Ｓ５：障害影響範囲ＣＩ抽出）  障害影響範囲ＣＩ抽出部１５は、Ｓ４，Ｓ２の情報などを用いて、当該障害箇所に係わる障害影響範囲のＣＩ（ＦＴＣＩを含む）を抽出する（後述、図４等）。
【００４８】
（Ｓ６：ＦＴＣＩ状況把握）  ＦＴＣＩ状況把握部１６は、Ｓ４，Ｓ５，Ｓ２の情報などを用いて、ＦＴＣＩの状況（障害許容状況）をステータスとして決定する（後述、図４，図７等）。
【００４９】
また上記Ｓ５，Ｓ６の処理に基づいて、分析部１４は、下位のＦＴＣＩのステータス等に応じて、障害影響先となる上位のサービス（サービスＣＩ）のステータスや数（Ｎ）などを把握する。
【００５０】
（Ｓ７：優先度算出）  優先度算出部１７は、Ｓ４〜Ｓ６，Ｓ２の情報などを用いて、対象システム１の現在のサービスレベルやＦＴＣＩを含む各ＣＩの状況（例えばＣＩのステータス：「正常」、「縮退」、「低下」、「停止」等）などを総合的に考慮して、緊急度（α）やインパクトレベル（β）を算出する。そして、これらの情報（α，β）を用いて、当該障害（インシデント）への対策の優先度（Ｐ）を算出する。更に、優先度（Ｐ）に応じた目標解決時間（Ｔ）や、エスカレーション有無などを決定する（後述、図１０等）。
【００５１】
（Ｓ８：情報登録）  インシデント管理システム１０（情報登録部１８）は、上記Ｓ７までの処理で得た各種情報（障害箇所、障害影響範囲、ＣＩ及びリンクのステータス、障害影響先サービス数（Ｎ）、優先度（Ｐ）、目標解決時間（Ｔ）など）を用いて、障害構成情報ｂ３やインシデント情報ｂ２を作成または更新し、ＤＢ５１，ＤＢ５２等に対して登録する。Ｓ５〜Ｓ７の分析結果（障害状況など）は、Ｓ２の構成管理モデル（構成情報ｂ１）上にマッピングされ、障害構成情報ｂ３となる。
【００５２】
サービスポータルシステム３０側は、インシデント管理システム１０（情報登録部１８）等に対して上記の情報（ｂ３，ｂ２）を必要に応じて要求して取得する。あるいは、サービスポータルシステム３０側で障害構成情報ｂ３の作成などを行う形態の場合は、情報登録部１８は、上記の情報（ｂ３，ｂ２）をサービスポータルシステム３０へ送信して登録してもよい。これにより画面（Ｇ１，Ｇ２）が構成・提供可能となる。
【００５３】
（Ｓ９：画面提供）  サービスポータルシステム３０（画面提供部３１）は、上記の障害構成情報ｂ３を用いることで、構成・障害状況などを可視化する構成情報画面Ｇ１を構成し担当者３に対して提供する。また、インシデント情報ｂ２を用いることでインシデント画面Ｇ２を構成し担当者３に対して提供する。初期診断担当者Ｕなどの担当者３は、構成情報画面Ｇ１の参照により、対象システム１の構成・障害状況（障害影響範囲を含む）・関連情報（担当者情報などを含む）などを把握でき、インシデント画面Ｇ２の参照により、詳細なインシデント情報を把握できる。
【００５４】
［処理例（ａ）］
前記初期診断（Ｓ３，Ｓ４）〜ＦＴＣＩ状況把握（Ｓ６）に係わる詳細処理例は以下である。これは、対象システム１の状況に応じて各ＣＩ及びリンクのステータスを更新する処理例であり、図６〜図８等のデータ情報（後述）を用いる。
【００５５】
（１）初期診断スクリプト実行：  前記Ｓ３で、初期診断部１３は、障害検知（Ｓ１）に基づく診断対象の各構成部位（ＣＩ）に対し、当該ＣＩのカテゴリ毎に対応付けられたスクリプトを、図６の初期診断スクリプトパラメータを引数にして実行する。前記Ｓ４で、Ｓ３の実行結果（稼働情報）は図６の構成情報に格納される。
【００５６】
（２）ＣＩステータスの登録：  障害影響範囲ＣＩ抽出部１５は、障害箇所に関係する各ＣＩ（ここではＦＴＣＩを除くＣＩ）に対し、上記（１）の結果情報をもとに、図６，図７のステータス決定方法に従い決定されるステータスを、当該ＣＩのステータスとして登録する。
【００５７】
（３）依存関係性ステータスの登録：  障害影響範囲ＣＩ抽出部１５は、障害箇所に関係する各ＣＩ間の依存関係性（リンク）に対し、当該ＣＩのレイヤ番号（図６）の大きい方（即ち下位）のＣＩのステータスを、当該依存関係性（リンク）のステータス（「依存関係性ステータス」）として登録する（図８，図９）。
【００５８】
（４）ＦＴＣＩステータスの登録：  ＦＴＣＩ状況把握部１６は、障害箇所・障害影響範囲に関係する各ＦＴＣＩに対し、図６，図７のステータス決定方法に従い決定されるステータスを、当該ＦＴＣＩのステータスに登録する。
【００５９】
［処理例（ｂ）］
前記情報登録（Ｓ８）〜画面提供（Ｓ９）の詳細処理例は以下である。図６〜図８等のデータ情報（後述）を用いる。インシデント管理システム１０（情報登録部１８等）は、ＤＢ５１，ＤＢ５２等に対して、随時（例えば構成・状況の変動に応じたタイミング）、画面（Ｇ１，Ｇ２等）の提供・内容更新のための情報（ｂ１〜ｂ３等）を作成・登録・提供する処理を行う。以下例えば情報登録部１８による処理である。
【００６０】
（１）画面Ｇ１（障害構成情報ｂ３）におけるＣＩアイコン（ＦＴＣＩアイコンを含む）の表示状態を、当該ＣＩ（ＦＴＣＩ）のステータス（図６）の変動に応じて変更する。例えば、該当ＣＩのステータスが「正常」から「異常」／「停止」へ変動したことに応じて、該当ＣＩアイコンの表示色を青から赤へ変更する処理を行う。
【００６１】
（２）画面Ｇ１（障害構成情報ｂ３）におけるＣＩ間の依存関係性（リンク）の表示状態を、当該依存関係性（リンク）のステータス（図８）の変動に応じて変更する。上記（１）の変更に併せて（２）の変更を行う。例えば、該当の依存関係性のステータスを、下位ＣＩのステータスに応じて決定・変更する処理を行う。
【００６２】
（３）上記（１），（２）の変更の情報を用いて、画面Ｇ１用の障害構成情報ｂ３、及び画面Ｇ２用のインシデント情報ｂ２等を作成または更新し、ＤＢ５１，ＤＢ５２等に対して登録する。これにより、サービスポータルシステム３０（画面提供部３１）では、上記情報を用いて、図３，図４の例のような画面Ｇ１等を提供可能とする。
【００６３】
また上記情報の他にも同様に、画面内に表示する各種の情報（例えば、図３内の担当者のアイコンの表示用の情報や、ＣＩステータスの表示用の情報や、障害箇所、障害影響範囲、障害影響先サービスなどの表示用の情報など）を作成・登録・提供する。
【００６４】
［画面（１）］
図３，図４等は表示画面例を示し、あわせて対象システム１の構成例も示されている。図３には、障害構成情報ｂ３を可視化する画面（構成情報画面Ｇ１）の第１の例（対象システム１が正常時の場合）を示す。本画面では、障害構成情報ｂ３等に基づき、複数のＣＩ（ＣＩアイコン）間が依存関係性を示すリンク（線）で接続された構造を表示する。
【００６５】
画面の上方ほどレイヤ番号（図６）が小さい上位のＣＩ（“Service”，“Cluster”等）を示し、下方ほどレイヤ番号が大きい下位のＣＩ（“Physical Server”，“L2Switch”等）を示す。論理的な単位・仮想的な単位（サービス、仮想サーバ、アプリケーション等）ほどレイヤが上位に設定され、物理的な単位（サーバ機器やネットワーク機器など）ほどレイヤが下位に設定される。図３では、下位から順に例えば、“Terminal”（端末），“L3Switch”,“L2Switch”,“Physical Server”（物理サーバ），“Hypervisor”（サーバ仮想化ソフトウェア），“DB Server”（仮想化サーバ），“DataBase”，“Cluster”（障害許容性）等のＣＩを有する。雲のアイコンは対象システム１で提供される上位のサービス（サービスＣＩ）を示す。
【００６６】
各ＣＩやリンクについては、名称、カテゴリ、ステータス、その他に応じて、色やアイコンや文字情報、大きさ、その他など、表現を変えて表示する。例えば図３では、ステータスが「正常」であるＣＩ及びリンクを実線や青で表示する。
【００６７】
またＦＴＣＩについては、通常のＣＩ（非ＦＴＣＩ）と区別できるように特定のアイコン（図３の例では八角形のアイコン）で表示する。４０１〜４１４等はＦＴＣＩを示す。それ以外は通常のＣＩ（非ＦＴＣＩ）を示す。ＦＴＣＩに付随する障害許容情報については後述する（図５）。
【００６８】
各ＣＩやリンクの表示の仕方は、本システムに対して入力・設定が可能である。
【００６９】
また各ＣＩアイコンに対しては、当該ＣＩに関連付けられる関連情報を適宜表示する。例えば担当者３のマウス操作（ＣＩアイコンへのマウスオーバやクリック等）により、当該ＣＩの関連情報をポップアップなどの形で表示する。例えば、当該ＣＩに関連付けられるインシデント情報を表示、あるいはインシデント画面Ｇ２へリンクする。また例えば、当該ＦＴＣＩに関連付けられる障害許容情報を表示する。
【００７０】
また例えば、当該ＣＩに関連付けられる担当者３の情報を表示する。図３の例では、ＣＩアイコンの右上（Ａ：例えばオレンジ色）や左上（Ｂ，Ｃ：例えば緑色）などに担当者アイコンを表示し、当該担当者アイコンの操作により担当者３の情報を表示する。ＦＴＣＩアイコンや、サービスＣＩアイコン毎に、存在する種別の担当者３のアイコンが表示される。
【００７１】
［画面（２）］
図４には、図３と同じ前提で、障害構成情報ｂ３を可視化する画面（構成情報画面Ｇ１）の第２の例（対象システム１での障害発生時の場合）を示す。図３の構成管理モデル上に障害状況（障害影響範囲など）などが反映された内容である。ＣＩ名称などは略す。図４の例では、各リンクの線をステータスに応じた線種（「正常」は実線、「縮退」は破線、「低下」は１点鎖線、「停止」は点線）で表示している。
【００７２】
障害箇所、障害影響範囲、障害影響先サービスなどを、特定のアイコンや囲み等の表現によって表示する。表現は例えば障害度合いが深刻なもの（ステータス値が大きいものに対応する）ほど目立つようにする。
【００７３】
５０１〜５０５等は、前記Ｓ１等に基づく障害箇所（ＣＩ，リンク）を示す。また、障害影響範囲ＣＩ（前記Ｓ５）については、例えば、該当の各ＣＩが囲みで表示される。囲みの種類や色はステータスに応じたものにする。図４の例では、ステータスが「停止」中の障害影響範囲のＣＩをそれぞれ実線の囲みで強調するように表示している。同様に「低下」や「縮退」の範囲についてもそれぞれ表示してもよい。色で表現する場合は例えば、ＣＩ及びリンクのステータスが「正常」の場合は青、「縮退」は紫、「低下」は黄、「停止」は赤、などで表示する。また各ＣＩのステータス等の情報をポップアップ等で表示してもよい。
【００７４】
５００は、障害影響範囲の一例（一部のみ）であり、５０１の障害箇所（物理サーバ）から上位への障害影響によりＦＴＣＩ４０１，４０２までの範囲を示している。このように複数のＣＩやリンクを包含した範囲を表示してもよい。また、ＦＴＣＩの上位のサービス（本例では６０１，６０２の２つ）も障害影響を受けている。図４の例では、ステータスが「停止」の各サービス（６０１，６０２）について、障害影響先サービスとして囲みで表示している。また、障害影響サービス数（Ｎ）などのサービス状況の情報をポップアップ等で表示してもよい。
【００７５】
図４の例では、ＦＴＣＩ４０１，４０２等は、ステータスが「停止（３）」である。ＦＴＣＩ４０３は「縮退（１）」である。ＦＴＣＩ４０４は「低下（２）」である。ＦＴＣＩ４０５〜４０８は「正常（０）」である。ＦＴＣＩ４０９は「縮退（１）」である。ＦＴＣＩ４１１，４１２，４１３，４１４は「正常（０）」である。上位の２つのサービス６０１，６０２は、ステータスが「停止（３）」である。障害影響サービス数（Ｎ）（「停止」のもの）は２である。
【００７６】
担当者３は、画面Ｇ１で、色の違いや囲みや特定のアイコンや表示情報を見ることで、障害影響範囲などをわかりやすく把握することができる。構成部位（ＣＩ）に関連付けられた形で各種情報が参照可能であるため、担当者３による状況把握などが容易化・迅速化できる。例えば初期診断担当者Ｕは、障害影響範囲などに該当しているＣＩアイコンやその担当者アイコンに触れると、対応するインシデント情報や、存在する各種のエスカレーション先（Ａ，Ｂ，Ｃ）などの担当者３の情報を見ることができ、また対応するエスカレーション動作（通知）へ連携することもできる。
【００７７】
［画面（３）］
図１３は、一般的な従来技術例における対象システム構成を可視化する画面例を示す。従来技術例ではＣＩ間の依存関係性（リンク）が表示されていないので、障害箇所の影響先が把握できない。また、従来技術例ではＦＴＣＩは無いので、冗長構成箇所が障害になった場合の上位レイヤへの影響度などが把握できない。一方、本実施の形態ではＣＩ間の依存関係性（リンク）とＦＴＣＩがあるため、障害箇所の影響先とサービス等の上位レイヤへの影響度などを把握することができる。なお特許文献１，２等の先行技術例でも、ＦＴＣＩ等を表示する機能は持っていない。
【００７８】
［ＦＴＣＩ情報］
図５には、図３の構成に対応した各ＦＴＣＩの障害許容情報の例について示す。ＦＴＣＩでは、それぞれ、属性情報として、障害許容性に関する設計情報（「障害許容情報」）が入力・設定される。障害許容情報は、対象システム１の構成に応じて異なる設計情報であり、担当者３等により設定可能である（ＦＴＣＩ設定機能１０２）。また、関連するＣＩ（上位、下位）との関係性なども依存関係性（リンク）の形で設定される。またＦＴＣＩに関する担当者３（Ａ，Ｂ，Ｃ等）が存在する場合はその担当者情報が関連付けられる。
【００７９】
図５（ａ）に示した、４０１，４０２等のＦＴＣＩ（アイコン表示名称：“Cluster”）では、ＤＢアクセス（ServiceからDBへのアクセス）に関して負荷分散などのための二重化構成（クラスタリング構成）である。この二重化構成で、片方の系のみが障害状態（片系障害）の場合は「縮退」（サービス許容）、両方の系が障害状態（両系障害）の場合は「停止」（サービス停止）、といった情報が設定される。
【００８０】
図５（ｂ）に示した、４０３，４０４等のＦＴＣＩ（“Cluster”）では、Middleware（MW）アクセス（ServiceからMiddlewareへのアクセス）に関して負荷分散などのための三重化構成（クラスタリング構成）である。この三重化構成で、一重障害の場合は「縮退」（サービス許容）、二重障害の場合は「低下」（サービス低下）、三重障害の場合は「停止」（サービス停止）、といった情報が設定される。
【００８１】
図５（ｃ）に示した、４０５〜４０９等のＦＴＣＩ（“Cluster”）では、L2Switch−Physical Server（PS）間が二重化構成である。この二重化構成で、片系障害の場合は「縮退」、両系障害の場合は「上位のＦＴＣＩに依存」（上位のＦＴＣＩのステータスに応じて当該ステータスが決定される等）、といった情報が設定される。
【００８２】
図５（ｄ）に示した、４１１，４１２等のＦＴＣＩ（“Cluster”）では、L2Switch−Storage間が二重化構成である。この二重化構成で、片系障害の場合は「縮退」、両系障害の場合は「停止」（サービス停止（全体））、といった情報が設定される。
【００８３】
図５（ｅ）に示した、４１３のＦＴＣＩ（“Cluster”）では、L2Switchが二重化構成である。この二重化構成で、片系障害の場合は「縮退」、両系障害の場合は「停止」（サービス停止（全体））、といった情報が設定される。
【００８４】
図５（ｆ）に示した、４１４のＦＴＣＩ（“Cluster”）では、L3Switchが二重化構成である。この二重化構成で、片系障害の場合は「縮退」、両系障害の場合は「停止」（サービス停止（全体））、といった情報が設定される。
【００８５】
［ＣＩ情報］
図６は、構成情報（ＣＩ情報）のデータ構造例（テーブル）を示す。項目として、ＣＩ＿ＩＤ、カテゴリ名、レイヤ番号、初期診断スクリプトパラメータ、機能的エスカレーション（Ａ）、階層的エスカレーション＃１（Ｂ）、階層的エスカレーション＃２（Ｃ）、ステータス決定方法、ステータス、初期診断スクリプト実行結果、等を有する。
【００８６】
ＣＩ＿ＩＤはＣＩの識別子である。カテゴリ名は、ＣＩのカテゴリ（種別）を示し、ＤＢサーバ、ＤＢ、ミドルウェア、サービス、等の他に、「障害許容性」（ＦＴＣＩ）を有する。ＦＴＣＩについては更にＦＴＣＩの種別など（例えば図５のような各ＦＴＣＩ）を設けて管理してもよい。
【００８７】
レイヤ番号は、ＣＩの属するレイヤを示し、ＣＩ間の上位・下位などの関係性に関する情報である。レイヤの数値が小さい方が上位、大きい方が下位である。レイヤに応じて構成管理モデルが作成・表示される。またＣＩのステータスなどはレイヤを考慮して決定される。本例では、レイヤ１：サービス、レイヤ１．５：ＦＴＣＩ、レイヤ２：ＤＢ，ミドルウェア等、レイヤ３：ＤＢサーバ，Ｗｅｂサーバ等、といったように規定されている。
【００８８】
初期診断スクリプトパラメータは、初期診断処理（Ｓ３）で引数として用いるパラメータ情報を示す。例えばＩＰやユーザ・パスワードなどの情報である。初期診断スクリプト実行結果は、初期診断処理の結果（Ｓ４）の情報を示す。これらはインシデント情報にも格納される。
【００８９】
機能的エスカレーション（Ａ）は、当該ＣＩ（構成部位）に関連付けられる、機能的エスカレーション先の担当者３の情報を示す。Ａ１〜Ａ３は個別の担当者を示す。階層的エスカレーション（Ｂ）は、第１種の階層的エスカレーション先として、管理（本システム）側の担当者（例えば上司）の情報を示す。Ｂ１〜Ｂ３は個別の担当者を示す。階層的エスカレーション（Ｃ）は、第２種の階層的エスカレーション先として、顧客（対象システム１）側の担当者（例えば上司）の情報を示す。Ｃ１は個別の担当者を示す。
【００９０】
ステータス決定方法は、次の項目であるステータスの値の決定方法を示す（詳しくは図７）。例えば、カテゴリがＤＢサーバ，ＤＢ，ミドルウェア等のＣＩでは、（ａ）の方法を適用し、ＩＤが“0126”のＦＴＣＩ（４０１）では（ｂ）の方法を適用し、ＩＤが“0130”のＦＴＣＩ（４０３）では（ｃ）の方法を適用し、サービスＣＩでは（ｄ）の方法を適用する等、ＣＩ及びカテゴリ毎に異なる設定が可能である。ステータスは、当該ＣＩの状況を示し、例えば「正常（０）」、「縮退（１）」、「低下（２）」、「停止（３）」、「異常（１）」などを有する。特にＦＴＣＩの場合、ステータスは障害許容状況を示す。ステータスの括弧の値は、カテゴリや方法ごとに、ステータスを識別する番号を示す。障害度合い等が大きいほどこのステータス値（ステータス番号）が大きくなるように定義されている。
【００９１】
図７は、ステータス決定方法の例を示す。
【００９２】
（ａ）の方法では、対象ＣＩの初期診断スクリプト実行結果において、正常終了の場合は、ステータスを「正常（０）」とし、異常終了の場合はステータスを「異常（１）」とする。これは単純な２値の定義の例であるが、ＣＩや方法に応じて多値で定義する形にしてもよい。
【００９３】
（ｂ）の方法では、下位ＣＩの正常稼働率（ｒとする）において、１００％の場合は「正常（０）」、５０％以上で１００％未満の場合は「縮退（１）」、０％の場合は「停止（３）」とする。ｒは各ＣＩのステータス値から算出できる。
【００９４】
（ｃ）の方法では、下位ＣＩの正常稼働率（ｒ）において、１００％の場合は「正常（０）」、６５％以上で１００％未満の場合は「縮退（１）」、１％以上で６５％未満の場合は「低下（２）」、０％の場合は「停止（３）」とする。
【００９５】
（ｄ）の方法では、下位ＣＩのステータス番号が１番大きいステータス（障害度合い等が１番大きいもの）を継承する。例えば、図４の左側のサービスＣＩ（６０１）の場合、一方の下位ＣＩ（４０１）は「停止（３）」、他方の下位ＣＩ（４０３）は「縮退（１）」であるため、大きい方である「停止（３）」の方が継承されて当該サービスＣＩのステータスに設定される。
【００９６】
［依存関係性］
図８は、ＣＩ間の依存関係性（リンク）のデータ構造例（テーブル）を示す。図８の値は、図９の構成管理モデルの例（一部）と対応した値である。図９でＣＩ及びリンク（線）の隣の数値はＩＤを示す。各ＣＩ間の線が依存関係性（リンク）を示している。なお依存関係性（リンク）についてもＣＩの一種に含める（依存関係性ＣＩとする）。
【００９７】
図８で、項目として、依存関係性（リンク）＿ＩＤ，第１のＣＩ（下位ＣＩ）＿ＩＤ、第２のＣＩ（上位ＣＩ）＿ＩＤ、依存関係性ステータス（＝下位ＣＩステータス）を有する。
【００９８】
図９の例では、あるサービス（0131）の下位に、ＦＴＣＩとして“Cluster”（0126）と“Cluster”（0130）の２つがある。ＦＴＣＩ“Cluster”（0126）は、二重化構成であり、下位に、２つのＤＢ（0124，0125）がある。ＤＢ（0124）の下位にＤＢサーバ（0123）がある。ＦＴＣＩ“Cluster”（0130）は、三重化構成であり、下位に、３つのミドルウェア（0127，0128，0129）がある。各ＣＩ・リンクをステータスに応じた表現で示している。吹き出しはステータスを示す。特にステータスが「異常」のＣＩを点線で示している。
【００９９】
図９のように、例えばＩＤ“1233”の依存関係性（リンク）は、ＩＤ“0123”のＤＢサーバである第１のＣＩ（下位ＣＩ）と、ＩＤ“0124”のＤＢである第２のＣＩ（上位ＣＩ）との依存関係性（リンク）を示し、当該依存関係性（リンク）ステータスは、下位ＣＩのステータスと同じ「異常」（例：赤）である。
【０１００】
ステータスの例として、“Cluster”（0126）における一方側のＤＢサーバ（0123）及びそのＤＢ（0124）では「異常」（例：赤）であり、他方側のＤＢ（0125）では「正常」（例：青）である。“Cluster”（0126）は、片系障害であるため、「縮退」（例：紫）である。また、“Cluster”（0130）における第１のミドルウェア（0127）は「正常」（例：青）であり、第２、第３のミドルウェア（0128，0129）は「異常」（例：赤）である。“Cluster”（0130）は、二重障害であるため、「低下」（例：黄）である。サービス（0131）は、“Cluster”（0130）の方のステータスの継承により「低下」（例：黄）となる。
【０１０１】
［優先度などの算出］
図１０に、優先度算出部１７（前記Ｓ７）における優先度（Ｐ）などの算出方法を示す。図１０（ａ）は、緊急度（α）の算出方法（一例）を示す。障害影響範囲（前記Ｓ５）におけるＦＴＣＩのステータスや障害許容情報に応じて緊急度（α）を決定する。条件として、ＦＴＣＩのステータスにおいて、「正常（０）」か「縮退（１）」がある場合は、α＝１とする。「停止（３）」が無く「低下（２）」がある場合は、α＝２とする。「停止（３）」がある場合は、α＝３とする。
【０１０２】
図１０（ｂ）は、インパクトレベル（β）の算出方法（一例）を示す。ステータス決定方法（図７）に応じて異なる。ＦＴＣＩのステータスや障害許容情報などを用いて、各ステータスのＦＴＣＩの数や障害影響サービス数などの状況に応じてインパクトレベル（β）を算出する。例えば図７の（ｃ）の方法の場合（ステータス値は正常（０），縮退（１），低下（２），停止（３）の４値）、条件（式）として、ＦＴＣＩのステータスにおいて、［縮退（１）のＦＴＣＩ数（ｎ１）］×係数ａ１（例：１）＋［低下（２）のＦＴＣＩ数（ｎ２）］×係数ａ２（例：５）＋［停止（３）のＦＴＣＩ数（ｎ３）］×係数ａ３（例：１０）である。本式による数値をインパクトレベル（β）とする。各重み付け係数（ａ１〜ａ３）の値は一例である。
【０１０３】
同様に例えば（ｂ）の方法の場合（ステータス値は正常（０），縮退（１），停止（３）の３値）、上記式は、β＝［縮退（１）のＦＴＣＩ数（ｎ１）］×係数ａ１＋［停止（３）のＦＴＣＩ数（ｎ３）］×係数ａ３といったようになる。
【０１０４】
図１０（ｃ）は、優先度（Ｐ）などの算出方法（一例）を示す。上記α，βの値を用いる。条件として、α×β≦９の場合、優先度（Ｐ）＝「低」とする。１０≦α×β≦２９の場合、優先度（Ｐ）＝「中」とする。３０≦α×βの場合、優先度（Ｐ）＝「高」とする。
【０１０５】
また、優先度（Ｐ）に対応して、当該障害（インシデント）への対策における目標解決時間（Ｔ）を求める。本例では、Ｐ＝「低」の場合は１２時間、Ｐ＝「中」の場合は６時間、Ｐ＝「高」の場合は２時間、といったように対応付けている。
【０１０６】
また、優先度（Ｐ）に対応して、前述の各種のエスカレーション（Ａ〜Ｃ）の有無などを求める。例えば、Ｐ＝「低」の場合、階層的エスカレーション＃１（Ｂ）及び階層的エスカレーション＃２（Ｃ）ともに無しである。Ｐ＝「中」の場合、＃１（Ｂ）（管理側への連絡等）を有りにする。更に、Ｐ＝「高」の場合、＃２（Ｃ）（顧客側への連絡等）も有りにする。
【０１０７】
またその他、前記Ｓ５で抽出した障害影響範囲ＣＩや前記Ｓ６で決定したＦＴＣＩステータス等をもとに、障害影響サービス数（Ｎ）を算出する。例えば、サービスＣＩの下位のＦＴＣＩのステータスなどに応じて当該サービスＣＩのステータスを決定する。そしてサービスＣＩのステータス（「縮退」、「低下」、「停止」など）毎に、障害影響サービス数（Ｎ）をカウントする。
【０１０８】
情報登録部１８等は、上記で得た各情報を含めて記述したインシデント情報ｂ２を、ＤＢ５１等に登録する。
【０１０９】
［インシデント情報］
図１１に、インシデント情報（ｂ２）のデータ構造例（テーブル）を示す。図１２は、図１１に対応するインシデント画面Ｇ２の例（フォーマット）を示す。インシデント情報において、項目として、インシデントＩＤ，緊急度（α），インパクトレベル（β），障害影響サービス数（Ｎ），優先度（Ｐ），目標解決時間（Ｔ），階層的エスカレーション＃１（Ｂ），＃２（Ｃ）、等を有する。各項目には前述した処理で得た情報が格納される。インシデントＩＤやその他の従来のインシデント情報と同様の項目（ステータス、タイトル、カテゴリ、構成部位（ＣＩ）、日時、説明情報など）も格納・管理される。障害影響サービス数（Ｎ）についてはステータスごとの値を格納する。図１２のインシデント画面Ｇ２では、図１１のインシデント情報をもとに情報が表示される。担当者３は、画面Ｇ２でインシデント情報を参照したり、値を入力することができる。他にも例えば、当該ＣＩに関連付けられる担当者３の情報など（機能的エスカレーション（Ａ）の担当者３や当該担当者３（Ａ）による対策情報など）を管理・表示してもよい。
【０１１０】
［具体例］
前述したフロー（Ｓ０〜Ｓ９）に沿った具体例を以下に示す。
【０１１１】
（Ｓ０）図３で示されるような構成管理モデルを設定する。
【０１１２】
（Ｓ１）障害検知（障害情報）により、障害箇所のＣＩが例えば図４の５０１（物理サーバ）であるとする。他の障害箇所（５０２等）がある場合も同様の考え方である。
【０１１３】
（Ｓ２）障害箇所（５０１）を含む関連するＣＩ情報（全部または一部）を取得する。少なくとも上位・下位でつながるＣＩ及びリンクの情報が取得される。
【０１１４】
（Ｓ３），（Ｓ４）障害箇所（５０１）を含む対象に対する初期診断実行結果を得る。
【０１１５】
（Ｓ５）上記結果から、障害箇所（５０１）を含む障害影響範囲のＣＩを抽出する。例えば図４の障害影響範囲５００のＣＩが抽出される。障害箇所などの下位ＣＩから、依存関係性（リンク）でつながる上位ＣＩへ、障害の影響が伝播する。処理例としては、上位ＣＩのステータスが、リンクで接続されるすべての下位ＣＩのステータスの値を用いた前述の計算に応じて決定される。障害影響範囲５００は、上位のＦＴＣＩ（例えば４０１，４０２）までを含めた場合である。
【０１１６】
（Ｓ６）上記障害影響範囲に係わるＦＴＣＩ（例えば４０１，４０２)について、障害許容状況を把握する。例えば４０１について、図６，図７の方法（ｂ）を用いてステータスを決定する。まず、４０１の下位の一方の障害箇所（５０１）の障害の影響のみを考えた場合、４０１のステータスは、片系障害なので「縮退（１）」になる。また４０１の下位のもう一方の障害箇所（５０２）の障害の影響を加えて考えた場合、４０１のステータスは、両系障害なので「停止（３）」になる。４０２のＦＴＣＩについても同様に、「停止（３）」になる。
【０１１７】
また、障害影響範囲５００における更に上位のサービス（６０１，６０２）についても、障害影響先（障害影響サービス）として、下位のＦＴＣＩ（４０１，４０２）のステータス等をもとに、ステータス（「停止」）やその数（Ｎ＝２）などが求まる。
【０１１８】
（Ｓ７）上記の障害箇所（５０１）及びそれに基づくＦＴＣＩ(４０１，４０２)を含む障害影響範囲５００に係わるインシデントに関して、優先度（Ｐ）を求める。まず、緊急度（α）は、４０１，４０２のステータスが共に「停止（３）」の場合、α＝３となる。
【０１１９】
次に、上記障害影響範囲５００に係わるインシデントにおけるインパクトレベル（β）は、方法（ｂ）に応じた所定の条件（式）から、例えばβ＝２×１＋１×５＋２×１０＝２７となる。
【０１２０】
次に、上記障害影響範囲５００に係わるインシデントにおける優先度（Ｐ）は、α×β＝３×２７＝８１，３０≦α×βであるから、Ｐ＝「高」となる。あわせて、Ｔ＝２時間、階層的エスカレーション＃１（Ｂ）：有り、階層的エスカレーション＃２（Ｃ）：有り、と求まる。
【０１２１】
（Ｓ８）上記Ｓ７までの結果を、当該インシデント情報ｂ２に反映・登録し、また、障害構成情報ｂ３（図３の構成管理モデル上に上記障害影響範囲５００を含む状況をマッピングした情報など）を構成し、ＤＢ５１等に登録する。
【０１２２】
（Ｓ９）上記によりサービスポータルシステム３０で担当者３に対し図４のような内容を持つ画面Ｇ１が提供される。
【０１２３】
［効果等］
以上、本実施の形態によれば、インシデント管理システム１０等に係わり、クラウド環境や障害許容性などを考慮した構成の対象システム１における、障害影響範囲などの状況や構成、及びインシデント・対策の優先度などの情報を画面（Ｇ１，Ｇ２）で可視化することで、担当者３が上記状況などを即座にわかりやすく把握でき、迅速なエスカレーション（情報伝達）及び対策の実施などが実現できる。
【０１２４】
担当者３は、障害検知（Ｓ１）時、図４等の画面（Ｇ１）を見ることで、ＦＴＣＩを含む構成における障害箇所・障害影響範囲・障害影響先サービス、ＦＴＣＩステータスなどを、色やアイコンなどによってわかりやすく把握でき、あわせてインシデント情報（Ｇ２）を見ることで、当該障害影響範囲や優先度（Ｐ）などの情報に基づき、１次切り分けやエスカレーション等の対応を容易化・迅速化できる。
【０１２５】
本実施の形態では、特に、ＦＴＣＩを設けた仕組みにより、対象システム１で提供するサービスの継続可能性（サービスレベル等）との兼ね合いで、仮想サーバ等の障害影響範囲のＣＩだけでなく、それによる障害影響先となるサービス（ＦＴＣＩの上位のサービスＣＩなど）の状況を、各サービスのステータスや障害影響サービス数（Ｎ）などの可視化によって把握することができる。
【０１２６】
［他の実施の形態］
（１）  対象システム１の構成部位の障害許容性をＣＩ（ＦＴＣＩ）としてモデル化したが、障害許容性以外にも、構成部位の性能（性能指標）などの他の非機能項目（設計情報）をＣＩとしてモデル化してもよい。
【０１２７】
（２）  障害情報（Ｓ１）に基づく初期診断（Ｓ３，Ｓ４）の際に、対象システム１の全ＣＩに対して診断実行し、その結果から障害箇所ＣＩなどを発見・特定する形だけでなく、一部の特定のＣＩに対して診断を実行する形態としてもよい。例えば、障害情報（Ｓ１）から、障害等が推定される一部の特定のＣＩを特定（絞り込み）し、その特定のＣＩを診断対象とする。
【０１２８】
（３）  障害情報（Ｓ１）等をもとに、自動的に、ＤＢ５１内の既存インシデント情報（履歴）を検索したり、障害パターン解析などを行い、インシデント情報に関連付けられる又は含まれる対策手順などの対策情報を取得し、あわせて画面（Ｇ１，Ｇ２）で提示してもよい。
【０１２９】
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。
【産業上の利用可能性】
【０１３０】
本発明は、統合運用管理システム、インシデント管理システム、構成管理システム、サービスポータルシステム、障害監視システムなどに利用可能である。
【符号の説明】
【０１３１】
１…対象システム（稼働システム）、３…担当者、１０…インシデント管理システム、１１…障害情報取得部、１２…構成情報取得部、１３…初期診断部、１５…障害影響範囲ＣＩ抽出部、１６…ＦＴＣＩ状況把握部、１７…優先度算出部、１８…情報登録部、２０…構成管理システム、３０…サービスポータルシステム、３１…画面提供部、４０…障害監視システム、５１…インシデント管理データベース（ＤＢ）、５２…構成管理データベース（ＤＢ）、１０１…障害影響範囲可視化機能、１０２…ＦＴＣＩ設定機能。
【図２】
0005469011.tif 000002
【図５】
0005469011.tif 000003
【図６】
0005469011.tif 000004
【図７】
0005469011.tif 000005
【図８】
0005469011.tif 000006
【図９】
0005469011.tif 000007
【図１０】
0005469011.tif 000008
【図１１】
0005469011.tif 000009
【図１２】
0005469011.tif 000010
【図１】
0005469011.tif 000011
【図３】
0005469011.tif 000012
【図４】
0005469011.tif 000013
【図１３】
0005469011.tif 000014