(57)【特許請求の範囲】
【請求項１】
情報処理システムで発生したインシデントの対処に伴って、当該インシデントに関与する前記情報処理システムのハードウェアまたはソフトウェアからなる構成要素を変更した場合に、その変更履歴を格納するシステム管理データベースと、
前記システム管理データベースを参照して、各構成要素についてインシデントの対処に伴って変更された回数を計数し、当該回数が所定の通知基準回数以上となる構成要素を特定する変更実績解析部と、
前記変更実績解析部が特定した構成要素を通知する通知部とを含み、
前記システム管理データベースはさらに、前記変更実績解析部が特定した構成要素と、その構成要素を前記通知部が通知した日付とを関連づけて格納し、
前記通知部は、前記変更実績解析部が特定した構成要素を通知した日付から所定の期間経過した場合、当該構成要素は通知しないことを特徴とするシステム管理支援装置。
【請求項２】
前記変更実績解析部は、変更された回数が所定の通知基準回数以上である構成要素を特定する際に、特定を実施する時点からさかのぼって所定の変更計数期間内にあった変更を計数することを特徴とする請求項１に記載のシステム管理支援装置。
【請求項３】
前記通知基準回数は前記情報処理システムを構成する構成要素毎に定められており、
前記変更実績解析部は、計数した構成要素の変更回数が、当該構成要素用に定められた前記通知基準回数以上であるか否かを比較することを特徴とする請求項１または２に記載のシステム管理支援装置。
【請求項４】
プロセッサに実行させるシステム管理支援方法であって、
情報処理システムで発生したインシデントの対処に伴って、当該インシデントに関与する前記情報処理システムのハードウェアまたはソフトウェアからなる構成要素を変更した場合にその変更履歴を格納するシステム管理データベースを参照して、前記情報処理システムを構成する構成要素についてインシデントの対処に伴って変更された回数を計数するステップと、
変更された回数が所定の通知基準回数以上となる構成要素を特定するステップと、
特定した構成要素を通知するステップとを含み、
前記システム管理データベースはさらに、特定した構成要素と、その構成要素を通知した日付とを関連づけて格納し、
前記通知するステップは、特定した構成要素を通知した日付から所定の期間経過した場合、当該構成要素は通知しないことを特徴とするシステム管理支援方法。
【請求項５】
システム管理支援機能をコンピュータに実現させるプログラムであって、当該機能は、
情報処理システムで発生したインシデントの対処に伴って、当該インシデントに関与する前記情報処理システムのハードウェアまたはソフトウェアからなる構成要素を変更した場合にその変更履歴を格納するシステム管理データベースを参照して、前記情報処理システムを構成する構成要素についてインシデントの対処に伴って変更された回数を計数する機能と、
変更された回数が所定の通知基準回数以上である構成要素を特定する機能と、
特定した構成要素を通知する機能とを含み、
前記システム管理データベースはさらに、特定した構成要素と、その構成要素を通知した日付とを関連づけて格納し、
前記通知する機能は、特定した構成要素を通知した日付から所定の期間経過した場合、当該構成要素は通知しないことを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はデータ処理技術に関し、特に、情報処理システムの構成要素の管理を支援する技術に関する。
【背景技術】
【０００２】
近年、例えばネットショッピングサービス等、ネットワークを利用したサービスが広く社会に浸透してきている。これらのサービスを運用する情報処理システムは、複数のブレードサーバやストレージ、ネットワークスイッチ等を構成要素とする大規模で複雑なシステムとなる傾向にある。
【０００３】
このような情報処理システムを構成する各構成要素について、その構成要素同士の関連性等を考慮してサービスに及ぼす影響度を算出し、その影響度とサービスの重要度とに基づいて、構成要素の優先度を算出する技術が提案されている（特許文献１参照）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００８−２１７２８５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
サービスを運用中に何らかのインシデントが発生し、その対処として構成要素を変更する場合、上述した優先度に応じて対処の順番を決定することができる。ところが、上述の優先度は、運用中のサービスを維持する上で重要な構成要素を示唆するものの、問題が発生する前に問題を起こす可能性のある構成要素を示唆するものではない。大規模な情報処理システムは問題対処に時間がかかる場合もあり、問題が発生してから対処するのではなく、未然に問題の発生を防止することが求められている。
【０００６】
本発明はこうした課題に鑑みてなされたものであり、その主な目的は、情報処理システムにおいてボトルネックとなり得る構成要素の特定を支援するための技術を提供することにある。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、本発明のある態様のシステム管理支援装置は、情報処理システムで発生したインシデントの対処に伴って、当該インシデントに関与する前記情報処理システムのハードウェアまたはソフトウェアからなる構成要素を変更した場合にその変更履歴を格納するシステム管理データベースと、前記システム管理データベースを参照して、各構成要素についてインシデントの対処に伴って変更された回数を計数し、当該回数が所定の通知基準回数以上となる構成要素を特定する変更実績解析部と、前記変更実績解析部が特定した構成要素を通知する通知部とを含む。
【０００８】
上記課題を解決するために、本発明の別の態様はシステム管理支援方法である。この方法は、情報処理システムで発生したインシデント対処に伴って、当該インシデントに関与する前記情報処理システムのハードウェアまたはソフトウェアからなる構成要素を変更した回数を計数し、当該回数が所定の通知基準回数以上となる構成要素を特定して前記情報処理システムのボトルネックを検出することをプロセッサに実行させる。
【０００９】
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、システム、プログラム、プログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【００１０】
本発明によれば、情報処理システムにおいてボトルネックとなり得る構成要素の候補の特定を支援するための技術を提供できる。
【図面の簡単な説明】
【００１１】
【図１】実施の形態に係る情報処理システムの機能構成を模式的に示す図である。
【図２】仮想マシンを実行するブレードの内部構成を模式的に示す図である。
【図３】実施の形態に係る情報処理システムの構成情報を管理する構成情報マスタのデータ構造を模式的に示す図である。
【図４】実施の形態に係る情報処理システムの構成要素の変更履歴を管理する変更履歴マスタのデータ構造を模式的に示す図である。
【図５】実施の形態に係る情報処理システムの構成要素同士のつながり、および構成要素とインシデントとの関連を管理する関連管理マスタのデータ構造を模式的に示す図である。
【図６】実施の形態に係る情報処理システムの構成要素のうちボトルネックとなり得る構成要素の候補を管理するボトルネック候補マスタのデータ構造を模式的に示す図である。
【図７】ボトルネックとなり得る構成要素の候補を示す画面の一例を示す図である。
【図８】実施の形態に係るシステム管理支援装置における処理の流れを示すフローチャートである。
【発明を実施するための形態】
【００１２】
実施の形態に係る情報処理システム５００は、ＩＴサービス企業（例えばＳＩ企業）に構築されたコンピュータシステムである。実施の形態に係るシステム管理支援装置１００は、情報処理システム５００で発生したインシデントや、そのインシデントの対処に伴ってされた情報処理システム５００の各構成要素の変更を管理する。ここで情報処理システム５００の「構成要素」とは、情報処理システムを運用する際に必要なハードウェアや、ファームウェアを含むソフトウェアのことをいう。以下では、主にインシデント管理の構成について説明するが、問題管理においても同様の構成が適用できることは当業者には理解されるところである。
【００１３】
図１は、実施の形態に係る情報処理システム５００の機能構成を模式的に示す図である。情報処理システム５００は、ブレード群２００、ネットワークスイッチ群３００、ストレージ群４００、およびシステム管理支援装置１００を含む。
【００１４】
図１は、実施の形態に係る情報処理システム５００を実現するための機能構成を示しており、その他の構成は省略している。図１において、さまざまな処理を行う機能ブロックとして記載される各要素は、ハードウェア的には、ＣＰＵ、メインメモリ、その他のＬＳＩ（Large Scale Integration）で構成することができ、ソフトウェア的には、メインメモリにロードされたプログラムなどによって実現される。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組み合わせによっていろいろな形で実現できることは当業者には理解されるところであり、いずれかに限定されるものではない。
【００１５】
ブレード群２００の各構成要素は、データベースサーバやウェブサーバ等の各種サーバプログラムを実行するブレードサーバ（以下、単に「ブレード」という。）である。このため、ブレード群２００は、第１ブレード２１０、第２ブレード２２０と続き、第Ｌブレード２３０に至るまでのＬ個のブレードを含む。ここでＬはブレード群２００に含まれるブレードサーバの数である。Ｌの値は、例えば情報処理システム５００が提供するサービスの規模等を勘案して実験により定めればよい。
【００１６】
図２は、仮想マシンを実行するブレードの内部構成を模式的に示す図である。実施の形態に係るブレード群２００に含まれる各ブレードは仮想化機能を有しており、仮想マシン２５０を実行してデータベースサーバ２５２やウェブサーバ２５４等の各種サーバプログラムを実行する。仮想マシン２５０は、仮想マシン２５０と現実のブレードとを接続する仮想的な第１ネットワークインタフェース２５６を含み、ブレードが有する現実のネットワークインタフェースである第２ネットワークインタフェース２６０を介してネットワークスイッチ群３００と接続する。仮想マシン２５０とネットワークスイッチ群３００との接続方法は、例えば仮想マシン２５０から直接第２ネットワークインタフェース２６０に接続する等いくつかの方法が考えられるが、本実施の形態のテーマではないので説明は割愛する。
【００１７】
図１の説明に戻る。ストレージ群４００は、例えば顧客情報や商品情報、広告等、情報処理システム５００がサービスを提供するために必要な種々の情報を格納する。このため、ストレージ群４００は、第１ストレージ４１０、第２ストレージ４２０と続き第Ｍストレージ４３０に至るまでのＭ個のネットワークスイッチを含む。ここでＭはストレージ群４００に含まれるストレージの数である。Ｍの値は、Ｌの値と同様に、例えば情報処理システム５００が提供するサービスの規模や冗長性の度合い等を勘案して実験により定めればよい。
【００１８】
ネットワークスイッチ群３００は、ブレード群２００に含まれる各ブレードサーバとストレージ群４００に含まれる各ストレージとを中継するネットワークスイッチ群である。ネットワークスイッチ群３００は、第１スイッチ３１０、第２スイッチ３２０と続き、第Ｎスイッチ３３０に至るまでのＮ個のネットワークスイッチを含む。ここでＮはネットワークスイッチ群３００に含まれるネットワークスイッチの数である。Ｎの値は、ＬやＭの値と同様に、例えば情報処理システム５００が提供するサービスの規模や冗長性の度合い等を勘案して実験により定めればよい。
【００１９】
システム管理支援装置１００は、情報処理システム５００において発生するインシデントと、そのインシデントに関与した構成要素との関連を管理する。ここで情報処理システム５００における構成要素とは、ブレード群２００に含まれる各ブレードおよびそこで実行されるサーバプログラムやネットワークインタフェース、ネットワークスイッチ群３００に含まれる各ネットワークスイッチ、ストレージ群４００に含まれる各ストレージ等である。システム管理支援装置１００は、インシデント管理部１０、システム管理データベース２０、変更実績解析部３０、および通知部４０を含む。
【００２０】
システム管理データベース２０は、情報処理システム５００の各構成要素の変更を管理するために利用される各種テーブルである、構成情報マスタ２２、関連管理マスタ２４、変更履歴マスタ２６、およびボトルネック候補マスタ２８を含む。
【００２１】
図３は、実施の形態に係る情報処理システム５００の構成情報を管理する構成情報マスタ２２のデータ構造を模式的に示す図である。構成情報マスタ２２は、情報処理システム５００の各構成要素の名前（例えば、第１ウェブサーバ、第３ブレード等）と、それらの構成要素に一意に定められた構成情報ＩＤ（IDentification）とを対応づけて格納する。構成情報マスタ２２はまた、構成情報ＩＤと、その構成情報ＩＤに対応する構成要素が情報処理システム５００に設置されてから現在に至るまでに何回変更されたかを示す「総変更回数」とを対応づけて格納する。構成情報マスタ２２はさらに、構成情報ＩＤと「期間内変更回数」とを対応づけて格納する。「期間内変更回数」および「総変更回数」の詳細は後述する。
【００２２】
図４は、実施の形態に係る情報処理システム５００の構成要素の変更履歴を管理する変更履歴マスタ２６のデータ構造を模式的に示す図である。変更履歴マスタ２６は、何らかのインシデントが発生してその対処のため構成要素を変更したときに、その構成要素の構成情報ＩＤと変更日付とを対応づけて格納する。例えば、図４に示す変更履歴マスタ２６の例において、履歴情報ＩＤ０００１は、発生したインシデントに関与したその構成情報ＩＤ０００６に係る第１スイッチ３１０が、２０１０年１０月１１日に変更されたことを示している。
【００２３】
図５は、実施の形態に係る情報処理システム５００の構成要素同士のつながり、および構成要素とインシデントとの関連を統一的に管理する関連管理マスタ２４のデータ構造を模式的に示す図である。関連管理マスタ２４において、項目「関連元種別」と「関連先種別」とがともに「構成管理」となっている行は、構成要素同士のつながりを示す。例えば、図５に示す関連管理マスタ２４の例において、関連管理ＩＤが０００１の行は「関連元種別」と「関連先種別」とがともに「構成管理」となっている。これは図３に示す構成情報マスタ２２の例における構成情報ＩＤ０００１（第１ウェブサーバ）と、構成情報ＩＤ０００６（第１スイッチ）とが構成上つながりを持っていることを示している。
【００２４】
また関連管理マスタ２４において、項目「関連元種別」と「関連先種別」とのいずれか一方が「構成管理」であり、もう一方が「インシデント管理」となっている行は、インシデントと、そのインシデントに関与した構成要素を示す。例えば、図５に示す関連管理マスタ２４の例において、関連管理ＩＤが０００２の行は「関連元種別」が「構成管理」であり、「関連先種別」が「インシデント管理」となっている。これは図３に示す構成情報マスタ２２の例における構成情報ＩＤ０００６（第１スイッチ）が、図４に示す変更履歴マスタ２６の例における履歴情報ＩＤ０００１に係るインシデントに関与したことを示す。
【００２５】
このように、関連管理マスタ２４は、情報処理システム５００の構成要素同士のつながり、および構成要素とインシデントとの関連を統一的に管理するために利用することができる。
【００２６】
以下、情報処理システム５００がネットショッピングを提供するシステムである場合を例として、実施の形態に係るシステム管理支援装置１００を具体的に説明する。当然ながら、情報処理システム５００はネットオークションサービスやソーシャルネットワークサービス（Social Network Service;ＳＮＳ）等、他のサービスを提供する場合についても同様の構成が適用できることは当業者には理解されるところである。
【００２７】
インターネット等のネットワークを介して情報処理システム５００が提供するネットションピングを利用するユーザから、ネットションピングサイトへのアクセスができないというインシデントが発生したとする。情報処理システム５００を管理または保守する担当者（以下、単に「担当者」という。）が原因を調査した結果、第３ブレードと第１スイッチ３１０の３番ポートとの間のリンクダウンであることが判明した。そこでその対処として、第３ブレードと第１スイッチ３１０とを結ぶネットワークケーブルを交換して第１スイッチ３１０を再起動したところ、リンクダウンは解消したとする。このとき、インシデント管理部１０は、変更履歴マスタ２６に第１スイッチ３１０の変更履歴を格納する。インシデント管理部１０はさらに、関連管理マスタ２４に、インシデントに第１スイッチ３１０が関与したこと、およびインシデントに第３ブレードが関与したことを格納する。
【００２８】
後日、ネットショッピングサイトでの決算処理のレスポンスが非常に遅いという別のインシデントが発生し、調査の結果、第１ストレージ４１０と第１スイッチ３１０とをつなぐ１番ポートが高負荷アクセスとなっていることが判明したとする。そこで、第１スイッチ３１０における１番ポートの接続を４番ポートの接続に変更したところ、決算処理のレスポンス速度が回復したとする。このとき、インシデント管理部１０は、変更履歴マスタ２６に第１スイッチ３１０の変更履歴を格納する。インシデント管理部１０はさらに、関連管理マスタ２４に、インシデントに第１スイッチ３１０が関与したこと、およびインシデントに第１ストレージ４１０が関与したことを格納する。
【００２９】
変更実績解析部３０は、システム管理データベース２０中の関連管理マスタ２４を参照して、情報処理システム５００を構成する各構成要素についてインシデントの対処に伴って変更された回数を計数する。上記の例の場合、第１スイッチ３１０の変更回数は２回であり、第３ブレードおよび第１ストレージ４１０の変更回数はそれぞれ１回である。
【００３０】
上述したふたつのインシデントの例は、ショッピングサイトへの接続の問題と決算処理のレスポンスの問題であり、一見直接のつながりはない。しかしながら、これらのインシデントの対処として第１スイッチ３１０の変更が行われている。このように、異なるインシデントへの対処として、いずれについても変更が行われた構成要素は、その構成要素に何らかの根本的な問題があり、情報処理システム５００を運用する上でボトルネックとなる可能性がある。以下、本明細書において、情報処理システム５００を運用する上でボトルネックとなる可能性がある構成要素を、単に「ボトルネック候補」と呼ぶことがある。
【００３１】
変更実績解析部３０は、変更のあった回数が所定の通知基準回数以上となる構成要素を特定する。ここで「通知基準回数」とは、情報処理システム５００を構成する構成要素のうち、情報処理システム５００を運用する上でボトルネックとなり得る候補として、担当者に通知すべきか否かを決定するために定められた基準回数である。通知基準回数は、運用するサービスの使用頻度や構成要素の堅牢性等を考慮して実験により定まればよいが、通知基準回数の一例としては２回である。図示はしないが、通知基準回数はシステム管理データベース２０内に格納されている。
【００３２】
このように、変更実績解析部３０が、過去にあったインシデントとそのインシデントに関与した構成要素、および対処のために変更した回数を解析することにより、情報処理システム５００を運用する上でボトルネックとなり得る根本的な問題を抱えた構成要素をあぶり出すことが可能となる。
【００３３】
ここで変更実績解析部３０は、構成変更された回数が所定の通知基準回数以上である構成要素を特定する際に、特定を実施する時点からさかのぼって所定の変更計数期間内にあった変更のみを計数し、変更計数期間よりも過去にあった変更については計数しないようにしてもよい。これにより、過去に多くの変更を要した構成要素があったとしてもある時点で根本的な問題が解決し、その後は問題を起こさないような構成要素がボトルネック候補として通知されることを防止できる。したがって、「変更計数期間」とは、構成要素をボトルネック候補として特定する際に、変更回数として加算すべき変更か否かを決定するための基準期間である。変更計数期間は情報処理システム５００が提供するサービス内容や構成要素の堅牢性等を鑑みて実験により定めればよいが、一例としては３ヶ月である。
【００３４】
変更実績解析部３０は、変更計数期間内に変更された回数を、前述した構成情報マスタ２２内の「期間内変更回数」に格納する。変更実績解析部３０はまた、構成要素が情報処理システム５００に設置されてから現在に至るまでの間にあった変更回数を、構成情報マスタ２２内の「総変更回数」に格納する。
【００３５】
インシデント管理部１０は、変更実績解析部３０が特定したボトルネック候補を、ボトルネック候補マスタ２８に格納する。図６は、ボトルネック候補を管理するボトルネック候補マスタ２８のデータ構造を模式的に示す図である。ボトルネック候補マスタ２８は、ボトルネック候補となる構成要素に対応する構成情報ＩＤと、そのボトルネック候補について調査等の対応をしたか否かを表すステータス、対応が終了している場合には対応日とを関連付け、ボトルネック候補を一意に表すボトルネック候補ＩＤを付して格納する。
【００３６】
通知部４０は、変更実績解析部３０が特定した構成要素を情報処理システム５００のボトルネック候補として通知する。通知の仕方としては、例えば情報処理システム５００の担当者に電子メールを送信する方法で行われる。あるいは、ボトルネック候補を示す専用のサイトを用意し、担当者がそこにアクセスすることで画面として提示してもよい。通知部４０がボトルネック候補を最初に通知した日付は、ボトルネック候補マスタ２８中に「通知日」として、その構成要素と関連づけて格納される。
【００３７】
図７は、ボトルネックとなり得る構成要素の候補を示す画面の一例を示す図である。図７に示す画面の例では、トップページとして、ボトルネック候補を含む情報処理システム名およびその名称が、それらを一意に表すＩＤとともに一覧表示される。名称にはリンクが張られており、画面の閲覧者がリンクをクリックすることによってその情報処理システム５００に対応するボトルネック候補マスタ２８の内容を表示する専用の画面（図示せず）が表示される。
【００３８】
情報処理システム５００の担当者は、通知部４０からのボトルネック候補の通知を確認することで、第１スイッチ３１０がボトルネック候補であることを認識したとする。情報処理システム５００の担当者が第１スイッチ３１０を詳細に調査したところ、第１スイッチ３１０のファームウェアに不具合を見つけたとする。そこで第１スイッチ３１０のファームウェアにパッチを当てることでファームウェアに不具合が解決した場合、担当者はその旨をインシデント管理部１０に入力する。インシデント管理部１０は、第１スイッチ３１０のファームウェアを変更したことを関連管理マスタ２４および変更履歴マスタ２６に格納し、ボトルネック候補マスタ２８のステータスおよび対応日を更新する。これにより、ボトルネック候補を示す画面を見た別の担当者が、担当済みのボトルネック候補を重複して調査することを防止できる。
【００３９】
図８は、実施の形態に係るシステム管理支援装置１００における処理の流れを示すフローチャートである。本フローチャートにおける処理は、例えばシステム管理支援装置１００の電源が投入されたときに開始する。以下に示すフローチャートは情報処理システム５００の運用中の処理フローを表すものであり、例えば構成情報マスタ２２や関連管理マスタ２４への情報処理システム５００の構成情報の入力は完了していることを前提とする。
【００４０】
情報処理システム５００の運用中にインシデントが発生すると（Ｓ１０）、インシデント管理部１０は、関連管理マスタ２４にインシデントとそのインシデントに関与した構成要素とを対応づけて格納する（Ｓ１２）。
【００４１】
インシデントに対処するために、情報処理システム５００の担当者がそのインシデントに関与した構成要素を変更した場合（Ｓ１４のＹ）、担当者は変更の情報をインシデント管理部１０に入力し、インシデント管理部１０は、変更履歴マスタ２６を更新する（Ｓ１６）。インシデントに対処するために、情報処理システム５００の担当者がそのインシデントに関与した構成要素を変更しない場合（Ｓ１４のＮ）、インシデント管理部１０は変更履歴マスタ２６を更新しない。
【００４２】
変更実績解析部３０は、情報処理システム５００を構成するある構成要素について、関連管理マスタ２４を参照してインシデントに関与したケースを特定する。変更実績解析部３０は、構成要素がインシデントに関与している場合、変更履歴マスタ２６を参照して、そのインシデントの対処に伴ってその構成要素が変更されたか否かを特定する。変更実績解析部３０は、情報処理システム５００を構成する全ての構成要素について上述の処理を繰り返すことで、構成要素の変更回数Ｐを計数する（Ｓ１８）。
【００４３】
続いて変更実績解析部３０は、システム管理データベース２０から、通知基準回数Ｔを取得する（Ｓ２０）。変更実績解析部３０は、計数した変更回数Ｐと、取得した通知基準回数Ｔとを比較して大小関係を取得する（Ｓ２２）。
【００４４】
計数した変更回数Ｐが取得した通知基準回数Ｔ以上である場合（Ｓ２４のＹ）、変更実績解析部３０はボトルネック候補マスタ２８を更新する（Ｓ２６）。通知部４０は、変更回数Ｐが通知基準回数Ｔ以上となった構成要素をボトルネック候補として通知する（Ｓ２８）。
【００４５】
計数した変更回数Ｐが取得した通知基準回数Ｔ未満である場合（Ｓ２４のＮ）、あるいは通知部４０がボトルネック候補を通知した後、変更実績解析部３０は構成情報マスタ２２内の「期間内変更回数」および「総変更回数」を更新する（Ｓ３０）。
【００４６】
以上の処理を繰り返すことにより、実施の形態に係るシステム管理支援装置１００は、情報処理システム５００を構成する構成要素の変更を管理し、そのボトルネック候補を特定する。
【００４７】
以上の構成による動作は以下のとおりである。情報処理システム５００を構築した際に、担当者は情報処理システム５００の構成情報を構成情報マスタ２２および関連管理マスタ２４に入力する。インシデント管理部１０は、情報処理システム５００の運用中に生じたインシデントやそのインシデントの対処に伴ってされた構成要素の変更を関連管理マスタ２４および変更履歴マスタ２６を用いて管理する。これにより、変更実績解析部３０は、変更回数を計数することで、情報処理システム５００のボトルネックとなり得る構成要素を特定する。情報処理システム５００の担当者はボトルネック候補を解析することで、問題が起こる前に事前に対処策を講じることができる。
【００４８】
以上説明したように、実施の形態のシステム管理支援装置１００によれば、情報処理システム５００においてボトルネックとなり得る構成要素の特定を支援することができる。これにより、情報処理システム５００の運用中に問題が起こる前にボトルネック候補を調査し、問題があれば事前に対処することができる。
【００４９】
以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【００５０】
第１の変形例を説明する。上述したとおり、システム管理データベース２０内のボトルネック候補マスタ２８は、ボトルネック候補を担当者に最初に通知した日付を通知日として格納している。通知部４０は、ボトルネック候補として最初に通知した通知日から、ボトルネック候補期間として定められた所定の期間経過した場合、その構成要素はボトルネック候補として通知しないようにしてもよい。ここで「ボトルネック候補期間」とは、変更実績解析部３０が特定した構成要素が、ボトルネック候補とみなされる期間として定められた期間であり、例えば３ヶ月である。
【００５１】
変更実績解析部３０が特定した構成要素はあくまでもボトルネックの候補であるので、所定の期間、情報処理システム５００の運用に支障をきたさないのであれば、その構成要素はボトルネックである可能性が低いと考えられる。そこでボトルネック候補期間を導入し、その期間を経過したボトルネック候補を担当者に通知しないようにすることにより、担当者がボトルネックである可能性の低い構成要素を解析する手間を省略することができる。
【００５２】
第２の変形例を説明する。上記の説明では、情報処理システム５００を構成する全ての構成要素について共通の通知基準回数を設定する場合について説明したが、通知基準回数として構成要素毎に異なる値を定めてもよい。この場合、変更実績解析部３０は構成要素毎に定められた通知基準回数をシステム管理データベース２０から取得し、計数した構成要素の変更回数が、その構成要素用に定められた通知基準回数以上であるか否かを比較する。
【００５３】
例えばブレード上でローカルに実行されるオペレーティングシステムや、そのオペレーティングシステム上で実行される仮想マシン２５０はソフトウェアであるため、ブレードに内蔵されるハードウェアである第２ネットワークインタフェース２６０と比較すると、変更回数が多くなる傾向にある。ハードウェアの場合は物理的に削除したり交換したりする場合に変更となるのに対し、ソフトウェアの場合はそのソフトウェア自体を入れ替える場合のみならず、オンラインアップデートによる修正も変更実績となるからである。
【００５４】
そこで、情報処理システム５００を構成する構成要素それぞれについて、構成要素がハードウェアであるのかソフトウェアであるのかも含めて、構成要素自体の性質や構成要素の堅牢性、使用頻度等を勘案し、各構成要素に適した通知基準回数を実験により定めておく。全ての構成要素について共通の通知基準回数を設定する場合と比較して、変更実績解析部３０によるボトルネック候補の特定精度をより高めることができる。
【００５５】
請求項に記載の各構成要件が果たすべき機能は、実施の形態および変形例において示された各構成要素の単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。
【符号の説明】
【００５６】
１０  インシデント管理部、  ２０  システム管理データベース、  ２２  構成情報マスタ、  ２４  関連管理マスタ、  ２６  変更履歴マスタ、  ２８  ボトルネック候補マスタ、  ３０  変更実績解析部、  ４０  通知部、  １００  システム管理支援装置、  ２００  ブレード群、  ２５０  仮想マシン、  ２５２  データベースサーバ、  ２５４  ウェブサーバ、  ２５６  第１ネットワークインタフェース、  ２６０  第２ネットワークインタフェース、  ３００  ネットワークスイッチ群、  ４００  ストレージ群、  ５００  情報処理システム、  ５００  期間情報処理システム。
【図１】
0005847497.tif 000002
【図２】
0005847497.tif 000003
【図３】
0005847497.tif 000004
【図４】
0005847497.tif 000005
【図５】
0005847497.tif 000006
【図６】
0005847497.tif 000007
【図７】
0005847497.tif 000008
【図８】
0005847497.tif 000009