(57)【特許請求の範囲】
【請求項１】
機器または機器に搭載される機能コンポーネントからなる複数の構成要素で構成される管理対象計算機システムの運用監視をおこなう統合運用監視システムであって、
前記管理対象システムでインシデントが発生した構成要素とインシデントの発生時刻を含むインシデント情報と、運用操作の対象となる構成要素、操作を指示した運用管理者、操作実行時刻を含む運用操作ログ情報を管理するデータ管理部と、
前記インシデント情報と運用操作ログ情報の関連度を求める関連度計算部と、
前記関連度計算部が求めた関連度を用いてインシデントに関連する可能性の高い運用操作ログを出力する関連度出力部を備え、
前記インシデント情報は前記インシデントに対応した複数の対応履歴情報を含み、
前記関連度計算部は対応履歴情報毎に前記インシデントと前記運用操作ログの関連度を求め、
前記関連度出力部は前記対応履歴情報毎に関連性の高い運用操作ログ情報を対応付けて出力し、
前記関連度は、第一の関連度、第二の関連度、第三の関連度を含み、
前記第一の関連度は、インシデントが発生した時刻と前記対応履歴情報を記録した時刻の一方と、運用操作を実行した時刻との関連度であって、
前記第二の関連度は、インシデントの発生した構成要素あるいは対応履歴情報の記録に含まれる構成要素と、運用操作を実行した構成要素との関連度であって、
前記第三の関連度は、インシデントの対応履歴を登録した運用管理者と、運用操作を行った運用管理者の関連度であって、
前記関連度計算部は、前記第一、第二、第三の関連度の少なくとも二つの関連度に基づいてインシデントと運用操作ログの関連度を求め、
前記データ管理部は、前記管理対象システムを構成する構成要素および構成要素間の依存関係を含むシステム構成情報と、前記管理対象システムを構成する構成要素の集合と、その運用を担当する運用担当者の集合の対応関係含む運用管理者情報を管理し、
前記第二の関連度は、さらに前記システム構成情報との関連度を含み、
前記第三の関連度は、さらに前記運用管理者情報との関連度を含み、
前記対応履歴情報はテキストによって記録された対応内容を含み、
前記関連度計算部は、対応履歴情報に含まれるテキストを分析して対応履歴情報の記録に含まれる構成要素を抽出し、
前記第二の関連度は、テキストを分析して抽出した対応履歴情報の記録に含まれる構成要素との関連度も含むことを特徴とする統合運用監視システム。
【請求項２】
機器または機器に搭載される機能コンポーネントからなる複数の構成要素で構成される管理対象計算機システムの運用監視をおこなう統合運用監視システムであって、
前記管理対象システムでインシデントが発生した構成要素とインシデントの発生時刻を含むインシデント情報と、運用操作の対象となる構成要素、操作を指示した運用管理者、操作実行時刻を含む運用操作ログ情報を管理するデータ管理部と、
前記インシデント情報と運用操作ログ情報の関連度を求める関連度計算部と、
前記関連度計算部が求めた関連度を用いてインシデントに関連する可能性の高い運用操作ログを出力する関連度出力部を備え、
前記インシデント情報は前記インシデントに対応した複数の対応履歴情報を含み、
前記関連度計算部は対応履歴情報毎に前記インシデントと前記運用操作ログの関連度を求め、
前記関連度出力部は前記対応履歴情報毎に関連性の高い運用操作ログ情報を対応付けて出力し、
前記関連度は、第一の関連度、第二の関連度、第三の関連度を含み、
前記第一の関連度は、インシデントが発生した時刻と前記対応履歴情報を記録した時刻の一方と、運用操作を実行した時刻との関連度であって、
前記第二の関連度は、インシデントの発生した構成要素あるいは対応履歴情報の記録に含まれる構成要素と、運用操作を実行した構成要素との関連度であって、
前記第三の関連度は、インシデントの対応履歴を登録した運用管理者と、運用操作を行った運用管理者の関連度であって、
前記関連度計算部は、前記第一、第二、第三の関連度の少なくとも二つの関連度に基づいてインシデントと運用操作ログの関連度を求め、
前記データ管理部は、前記管理対象システムを構成する構成要素および構成要素間の依存関係を含むシステム構成情報と、前記管理対象システムを構成する構成要素の集合と、その運用を担当する運用担当者の集合の対応関係含む運用管理者情報を管理し、
前記第二の関連度は、さらに前記システム構成情報との関連度を含み、
前記第三の関連度は、さらに前記運用管理者情報との関連度を含み、
前記データ管理部は、複数の運用操作ログのシーケンスを検索する条件を含むパターンマッチ情報とそのパターンにマッチした運用操作ログ情報に関する関連度を補正する補正値情報を含む運用操作パターン情報を管理し、
前記関連度計算部が求めた前記関連度を前記運用操作パターン情報に基づいて補正する関連度補正部を備え、
前記関連度補正部は、前記運用操作パターン情報にマッチした前記運用操作ログ情報の前記関連度に関して前記補正値情報に基づいて補正した値を関連度として求めることを特徴とする統合運用監視システム。
【請求項３】
運用操作パターン情報を生成するパターン生成部を備え、
パターン生成部は、前記関連度出力部によって出力されたインシデントに関連する可能性の高い運用操作ログを入力として前記運用操作パターン情報として第一の運用操作パターン情報を生成し、
前記関連度計算部は、第一の運用操作パターン情報にマッチした前記運用操作ログ情報の前記関連度がより大きくなるように補正した値を求めることを特徴とする請求項２に記載の統合運用監視システム。
【請求項４】
前記パターン生成部は、前記関連度出力部によって出力されたインシデントに関連する可能性の高い運用操作ログと前記運用操作ログ情報を入力として、いずれのインシデントにも関連する可能性の低い運用操作ログを抽出し、抽出された運用操作ログから、前記運用操作パターン情報として第二の運用操作パターン情報を生成し、
前記関連度計算部は、第二の運用操作パターン情報にマッチした前記運用操作ログ情報の前記関連度がより小さくなるように補正した値を求めることを特徴とする請求項３に記載の統合運用監視システム。
【請求項５】
機器または機器に搭載される機能コンポーネントからなる複数の構成要素で構成される管理対象計算機システムの運用監視をおこなう統合運用監視システムであって、
前記管理対象システムでインシデントが発生した構成要素とインシデントの発生時刻を含むインシデント情報と、運用操作の対象となる構成要素、操作を指示した運用管理者、操作実行時刻を含む運用操作ログ情報を管理するデータ管理部と、
前記インシデント情報と運用操作ログ情報の関連度を求める関連度計算部と、
前記関連度計算部が求めた関連度を用いてインシデントに関連する可能性の高い運用操作ログを出力する関連度出力部を備え、
前記インシデント情報は前記インシデントに対応した複数の対応履歴情報を含み、
前記関連度計算部は対応履歴情報毎に前記インシデントと前記運用操作ログの関連度を求め、
前記関連度出力部は前記対応履歴情報毎に関連性の高い運用操作ログ情報を対応付けて出力し、
前記関連度は、第一の関連度、第二の関連度、第三の関連度を含み、
前記第一の関連度は、インシデントが発生した時刻と前記対応履歴情報を記録した時刻の一方と、運用操作を実行した時刻との関連度であって、
前記第二の関連度は、インシデントの発生した構成要素あるいは対応履歴情報の記録に含まれる構成要素と、運用操作を実行した構成要素との関連度であって、
前記第三の関連度は、インシデントの対応履歴を登録した運用管理者と、運用操作を行った運用管理者の関連度であって、
前記関連度計算部は、前記第一、第二、第三の関連度の少なくとも二つの関連度に基づいてインシデントと運用操作ログの関連度を求め、
前記データ管理部は、前記管理対象システムを構成する構成要素および構成要素間の依存関係を含むシステム構成情報と、前記管理対象システムを構成する構成要素の集合と、その運用を担当する運用担当者の集合の対応関係含む運用管理者情報を管理し、
前記第二の関連度は、さらに前記システム構成情報との関連度を含み、
前記第三の関連度は、さらに前記運用管理者情報との関連度を含み、
前記関連度出力部は、前記関連度が所定の関連判定しきい値が超えたかどうかによって、運用操作ログがインシデントに関連する可能性が高いかどうかを判定することを特徴とする統合運用監視システム。
【請求項６】
機器または機器に搭載される機能コンポーネントからなる複数の構成要素で構成される管理対象計算機システムの運用監視をおこなう統合運用監視システムであって、
前記管理対象システムでインシデントが発生した構成要素とインシデントの発生時刻を含むインシデント情報と、運用操作の対象となる構成要素、操作を指示した運用管理者、操作実行時刻を含む運用操作ログ情報を管理するデータ管理部と、
前記インシデント情報と運用操作ログ情報の関連度を求める関連度計算部と、
前記関連度計算部が求めた関連度を用いてインシデントに関連する可能性の高い運用操作ログを出力する関連度出力部を備え、
前記インシデント情報は前記インシデントに対応した複数の対応履歴情報を含み、
前記関連度計算部は対応履歴情報毎に前記インシデントと前記運用操作ログの関連度を求め、
前記関連度出力部は前記対応履歴情報毎に関連性の高い運用操作ログ情報を対応付けて出力し、
前記関連度は、第一の関連度、第二の関連度、第三の関連度を含み、
前記第一の関連度は、インシデントが発生した時刻と前記対応履歴情報を記録した時刻の一方と、運用操作を実行した時刻との関連度であって、
前記第二の関連度は、インシデントの発生した構成要素あるいは対応履歴情報の記録に含まれる構成要素と、運用操作を実行した構成要素との関連度であって、
前記第三の関連度は、インシデントの対応履歴を登録した運用管理者と、運用操作を行った運用管理者の関連度であって、
前記関連度計算部は、前記第一、第二、第三の関連度の少なくとも二つの関連度に基づいてインシデントと運用操作ログの関連度を求め、
前記データ管理部は、前記管理対象システムを構成する構成要素および構成要素間の依存関係を含むシステム構成情報と、前記管理対象システムを構成する構成要素の集合と、その運用を担当する運用担当者の集合の対応関係含む運用管理者情報を管理し、
前記第二の関連度は、さらに前記システム構成情報との関連度を含み、
前記第三の関連度は、さらに前記運用管理者情報との関連度を含み、
前記関連度出力部は、前記関連度を出力するとき、インシデントと運用操作ログの関連が高いと判定された理由を付けて出力することを特徴とする統合運用監視システム。
【請求項７】
機器または機器に搭載される機能コンポーネントからなる複数の構成要素で構成される管理対象計算機システムのインシデントと運用操作ログの関連度計算方法であって、
データ管理部が前記管理対象計算機システムでインシデントが発生した構成要素とインシデントの発生時刻を含むインシデント情報と、運用操作の対象となる構成要素、操作を指示した運用管理者、操作実行時刻を含む運用操作ログ情報を取得し、
関連度計算部が前記インシデント情報と運用操作ログ情報の関連度を求め、
関連度出力部が前記関連度計算部の求めた関連度を用いてインシデントに関連する可能性が高い運用操作ログを出力し、
前記インシデント情報は前記インシデントに対応した複数の対応履歴情報を含み、
前記関連度計算部は対応履歴情報毎に前記インシデントと前記運用操作ログの関連度を求め、
前記関連度出力部は前記対応履歴情報毎に関連性が高い運用操作ログ情報を対応付けて出力し、
前記関連度は、第一の関連度、第二の関連度、第三の関連度を含み、
前記第一の関連度は、インシデントが発生した時刻と前記対応履歴情報を記録した時刻の一方と、運用操作を実行した時刻との関連度であって、
前記第二の関連度は、インシデントの発生した構成要素あるいは対応履歴情報の記録に含まれる構成要素と、運用操作を実行した構成要素との関連度であって、
前記第三の関連度は、インシデントの対応履歴を登録した運用管理者と、運用操作を行った運用管理者の関連度であって、
前記関連度計算部は、前記第一、第二、第三の関連度の少なくとも二つの関連度に基づいてインシデントと運用操作ログの関連度を求め、
前記データ管理部は、前記管理対象システムを構成する構成要素および構成要素間の依存関係を含むシステム構成情報と、前記管理対象システムを構成する構成要素の集合と、その運用を担当する運用担当者の集合の対応関係含む運用管理者情報を管理し、
前記第二の関連度は、さらに前記システム構成情報との関連度を含み、
前記第三の関連度は、さらに前記運用管理者情報との関連度を含み、
前記対応履歴情報はテキストによって記録された対応内容を含み、
前記関連度計算部は、対応履歴情報に含まれるテキストを分析して対応履歴情報の記録に含まれる構成要素を抽出し、
前記第二の関連度は、テキストを分析して抽出した対応履歴情報の記録に含まれる構成要素との関連度も含むことを特徴とする関連度計算方法。
【請求項８】
機器または機器に搭載される機能コンポーネントからなる複数の構成要素で構成される管理対象計算機システムのインシデントと運用操作ログの関連度計算方法であって、
データ管理部が前記管理対象計算機システムでインシデントが発生した構成要素とインシデントの発生時刻を含むインシデント情報と、運用操作の対象となる構成要素、操作を指示した運用管理者、操作実行時刻を含む運用操作ログ情報を取得し、
関連度計算部が前記インシデント情報と運用操作ログ情報の関連度を求め、
関連度出力部が前記関連度計算部の求めた関連度を用いてインシデントに関連する可能性が高い運用操作ログを出力し、
前記インシデント情報は前記インシデントに対応した複数の対応履歴情報を含み、
前記関連度計算部は対応履歴情報毎に前記インシデントと前記運用操作ログの関連度を求め、
前記関連度出力部は前記対応履歴情報毎に関連性が高い運用操作ログ情報を対応付けて出力し、
前記関連度は、第一の関連度、第二の関連度、第三の関連度を含み、
前記第一の関連度は、インシデントが発生した時刻と前記対応履歴情報を記録した時刻の一方と、運用操作を実行した時刻との関連度であって、
前記第二の関連度は、インシデントの発生した構成要素あるいは対応履歴情報の記録に含まれる構成要素と、運用操作を実行した構成要素との関連度であって、
前記第三の関連度は、インシデントの対応履歴を登録した運用管理者と、運用操作を行った運用管理者の関連度であって、
前記関連度計算部は、前記第一、第二、第三の関連度の少なくとも二つの関連度に基づいてインシデントと運用操作ログの関連度を求め、
前記データ管理部は、前記管理対象システムを構成する構成要素および構成要素間の依存関係を含むシステム構成情報と、前記管理対象システムを構成する構成要素の集合と、その運用を担当する運用担当者の集合の対応関係含む運用管理者情報を管理し、
前記第二の関連度は、さらに前記システム構成情報との関連度を含み、
前記第三の関連度は、さらに前記運用管理者情報との関連度を含み、
前記データ管理部は、複数の運用操作ログのシーケンスを検索する条件を含むパターンマッチ情報とそのパターンにマッチした運用操作ログ情報に関する関連度を補正する補正値情報を含む運用操作パターン情報を管理し、
前記関連度計算部が求めた前記関連度を前記運用操作パターン情報に基づいて補正する関連度補正部を備え、
前記関連度補正部は、前記運用操作パターン情報にマッチした前記運用操作ログ情報の前記関連度に関して前記補正値情報に基づいて補正した値を関連度として求めることを特徴とする関連度計算方法。
【請求項９】
機器または機器に搭載される機能コンポーネントからなる複数の構成要素で構成される管理対象計算機システムのインシデントと運用操作ログの関連度計算方法であって、
データ管理部が前記管理対象計算機システムでインシデントが発生した構成要素とインシデントの発生時刻を含むインシデント情報と、運用操作の対象となる構成要素、操作を指示した運用管理者、操作実行時刻を含む運用操作ログ情報を取得し、
関連度計算部が前記インシデント情報と運用操作ログ情報の関連度を求め、
関連度出力部が前記関連度計算部の求めた関連度を用いてインシデントに関連する可能性が高い運用操作ログを出力し、
前記インシデント情報は前記インシデントに対応した複数の対応履歴情報を含み、
前記関連度計算部は対応履歴情報毎に前記インシデントと前記運用操作ログの関連度を求め、
前記関連度出力部は前記対応履歴情報毎に関連性が高い運用操作ログ情報を対応付けて出力し、
前記関連度は、第一の関連度、第二の関連度、第三の関連度を含み、
前記第一の関連度は、インシデントが発生した時刻と前記対応履歴情報を記録した時刻の一方と、運用操作を実行した時刻との関連度であって、
前記第二の関連度は、インシデントの発生した構成要素あるいは対応履歴情報の記録に含まれる構成要素と、運用操作を実行した構成要素との関連度であって、
前記第三の関連度は、インシデントの対応履歴を登録した運用管理者と、運用操作を行った運用管理者の関連度であって、
前記関連度計算部は、前記第一、第二、第三の関連度の少なくとも二つの関連度に基づいてインシデントと運用操作ログの関連度を求め、
前記データ管理部は、前記管理対象システムを構成する構成要素および構成要素間の依存関係を含むシステム構成情報と、前記管理対象システムを構成する構成要素の集合と、その運用を担当する運用担当者の集合の対応関係含む運用管理者情報を管理し、
前記第二の関連度は、さらに前記システム構成情報との関連度を含み、
前記第三の関連度は、さらに前記運用管理者情報との関連度を含み、
前記関連度出力部は、前記関連度が所定の関連判定しきい値が超えたかどうかによって、運用操作ログがインシデントに関連する可能性が高いかどうかを判定することを特徴とする関連度計算方法。
【請求項１０】
機器または機器に搭載される機能コンポーネントからなる複数の構成要素で構成される管理対象計算機システムのインシデントと運用操作ログの関連度計算方法であって、
データ管理部が前記管理対象計算機システムでインシデントが発生した構成要素とインシデントの発生時刻を含むインシデント情報と、運用操作の対象となる構成要素、操作を指示した運用管理者、操作実行時刻を含む運用操作ログ情報を取得し、
関連度計算部が前記インシデント情報と運用操作ログ情報の関連度を求め、
関連度出力部が前記関連度計算部の求めた関連度を用いてインシデントに関連する可能性が高い運用操作ログを出力し、
前記インシデント情報は前記インシデントに対応した複数の対応履歴情報を含み、
前記関連度計算部は対応履歴情報毎に前記インシデントと前記運用操作ログの関連度を求め、
前記関連度出力部は前記対応履歴情報毎に関連性が高い運用操作ログ情報を対応付けて出力し、
前記関連度は、第一の関連度、第二の関連度、第三の関連度を含み、
前記第一の関連度は、インシデントが発生した時刻と前記対応履歴情報を記録した時刻の一方と、運用操作を実行した時刻との関連度であって、
前記第二の関連度は、インシデントの発生した構成要素あるいは対応履歴情報の記録に含まれる構成要素と、運用操作を実行した構成要素との関連度であって、
前記第三の関連度は、インシデントの対応履歴を登録した運用管理者と、運用操作を行った運用管理者の関連度であって、
前記関連度計算部は、前記第一、第二、第三の関連度の少なくとも二つの関連度に基づいてインシデントと運用操作ログの関連度を求め、
前記データ管理部は、前記管理対象システムを構成する構成要素および構成要素間の依存関係を含むシステム構成情報と、前記管理対象システムを構成する構成要素の集合と、その運用を担当する運用担当者の集合の対応関係含む運用管理者情報を管理し、
前記第二の関連度は、さらに前記システム構成情報との関連度を含み、
前記第三の関連度は、さらに前記運用管理者情報との関連度を含み、
前記関連度出力部は、前記関連度を出力するとき、インシデントと運用操作ログの関連が高いと判定された理由を付けて出力することを特徴とする関連度計算方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、特にシステム運用管理業務の支援技術に関する。
【背景技術】
【０００２】
コンピュータシステムの運用管理者は、コンピュータシステム上で発生した障害や異常をインシデントとして管理し、インシデントに対する対応作業としてインシデントに対する原因調査作業や障害対策作業等を実施する。
【０００３】
インシデント対応作業を支援するソフトウェアには、インシデント管理ソフトウェアや監視ソフトウェアがある。インシデント管理ソフトウェアは、インシデントを登録・管理する機能を提供する。運用管理者は、インシデント管理ソフトウェアを用いて、インシデントに対して行った対応作業を、インシデント対応履歴として記録する。  
インシデント対応履歴には、「いつ、誰が、何の作業を行ったのか」を記録する。
【０００４】
監視ソフトウェアは、障害/異常検出および原因分析を支援するソフトウェアである。監視ソフトウェアは、管理対象のハードウェアやソフトウェアと通信し、システムの稼働状況を示す稼働データを収集する。稼働データには、CPU使用率のような数値データや、アプリケーション（AP）の状態を表すテキストメッセージのような文字列データがある。また、収集した稼働データが予め指定された条件を満たした場合に運用管理者にアラートを送信し、インシデント管理ソフトウェアと連携してインシデントとして登録する。さらに、稼働データを線グラフなどの形に加工して、管理者の操作端末の画面上に表示する。
【０００５】
監視ソフトウェアとインシデント管理ソフトウェアは共に用いられることが多いため、両ソフトウェアを統合した製品も提案されている。以下では、このような製品を統合監視サーバと呼ぶ。
【０００６】
統合監視サーバを用いたインシデント対応作業では、運用管理者は、発生したインシデントを確認し、インシデントに関連する稼働データを調査することで原因分析を行い、その他の管理ツール等を用いて、管理対象のハードウェアやソフトウェアに対する対策作業を実施する。そして、対応作業内容をインシデント対応履歴として記録する。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開2014-115890
【発明の概要】
【発明が解決しようとする課題】
【０００８】
インシデントを管理する上では、インシデント対応履歴を詳細に記録することが重要である。インシデント対応履歴が詳細に記録されていれば、インシデント対応作業のエビデンスや過去に発生したインシデントと同様のインシデントが発生時の参考情報として利用できる。
【０００９】
しかしながら、インシデント対応履歴は運用管理者によって人手で記録されるため、記載内容が省略されるなどして、実際の作業との乖離が発生し得る。インシデントの対応履歴と実際の作業との乖離を小さくするには、インシデント対応履歴を統合監視サーバや管理ツールが記録する運用操作ログを活用することが考えられる。運用操作ログは、運用管理者による機器や管理ツールの操作履歴である。しかし、従来は、インシデント対応履歴と運用操作ログが関連づけられていない。そのため、運用管理者は人手でインシデントやその対応履歴に含まれる複数のキー情報を用いて、複数の運用操作ログに対する検索を行って運用操作ログを抽出する必要があった。
【００１０】
インシデントに関連する運用操作ログを自動的に抽出する従来技術として、特許文献１がある。特許文献1は、対応手順毎に事前定義した対応履歴テンプレートに基づいて、記入内容のひな形とログファイルから抽出した情報を合成し、インシデント対応履歴として自動入力する技術を開示する。
【００１１】
特許文献1によれば、対応手順が明確で事前定義できるインシデントに関連する運用操作ログが自動抽出/記録される。しかし、事前定義できず、対応手順が明確で無いインシデントに対しては適用できないという問題がある。
【００１２】
また、単純な自動抽出方法として、インシデント発生から解決までの期間に発生した運用操作ログをすべて集める方法が考えられる。この方法により、対応手順が明確でなくても、関連するログを集られる。しかし、その期間中に別の運用作業（別のインシデント対応作業や日々の運用作業）が実施されていた場合にはインシデントに無関係のログが抽出され、抽出されたログの精度が悪いという問題がある。
【００１３】
本発明の課題は、対応手順が明確で無いインシデントに関連する運用操作ログを精度良く自動抽出することである。
【課題を解決するための手段】
【００１４】
本発明では、インシデントに関連する運用操作ログ自動抽出方法として、インシデントおよびインシデント対応履歴と運用操作ログとを入力として、複数の観点での関連性からインシデントと運用操作ログ間の総合的な関連度を計算し、その関連度に基づいてインシデントに関連する運用操作ログを抽出する方法を開示する。
【００１５】
関連度の具体的な計算方法としては、管理対象システムに関するシステム構成情報、および運用管理者情報も入力として活用し、時刻、システム構成、運用管理者という3つの観点におけるインシデントの各対応履歴と運用操作ログの関連度を計算し、それらの関連を合成することによって、トータルの関連度を計算する方法を開示する。
【発明の効果】
【００１６】
運用管理者は、インシデントに関連する運用操作ログの収集、検索にかかる時間を短縮できる。
【図面の簡単な説明】
【００１７】
【図１】実施例１におけるコンピュータシステムを模式的に示す図である。
【図２】実施例１における統合監視サーバの物理的な構成を示すブロック図である。
【図３】管理対象システムを構成するインスタンス情報の例を表す図である。
【図４】インスタンス間のシステム依存関係の例を表す図である。
【図５】稼働データの例を示す図である。
【図６】運用管理者情報の例を示す図である。
【図７】インシデントの例を表す図である。
【図８】インシデント対応履歴の例を表す図である。
【図９（ａ）】統合監視サーバが出力する稼働データアクセスログの例を示す図である。
【図９（ｂ）】統合監視サーバが出力する稼働データアクセスログの例を示す図である。
【図１０】実施例１における関連度計算結果の例を示す図である。
【図１１】データ表示部におけるインシデント表示およびインシデントに関連する運用操作ログ表示画面の例である。
【図１２】データ表示部における稼働データ表示画面の例である。
【図１３】本実施例における関連運用操作ログ自動抽出部の関連度計算処理のフローチャートの一例である。
【図１４】本実施例の時刻に基づく関連度R1の計算において、時刻の近さを定量化する関数モデルの一例をグラフ表現したものである。
【図１５】本実施例における時刻に基づく関連度R1の計算処理の詳細フローチャートの一例である。
【図１６】本実施例におけるシステム構成に基づく関連度R2の計算処理の詳細フローチャートの一例である。
【図１７】本実施例における運用管理者に基づく関連度R3の計算処理の詳細フローチャートの一例である。
【図１８】本実施例におけるトータルの関連度Rxの計算処理の詳細フローチャートである。
【図１９】本実施例におけるデータ表示部によるインシデントに関連する運用操作ログ表示画面の生成のフローチャートの一例である。
【図２０】実施例２におけるコンピュータシステムを模式的に示す図である。
【図２１】運用操作ログ設定の例を示す図である。
【図２２】リモート接続端末が出力するコマンド操作ログの例を示す図である。
【図２３】ジョブ管理サーバが出力するジョブ実行ログの例を示す図である。
【図２４】VMM管理サーバが出力するVMM操作イベントログの例を示す図である。
【図２５】実施例２における関連度計算結果の例（図10に対する追加分）を示す図である。
【図２６】実施例３における統合監視サーバが出力する稼働データアクセスログの例（図9に対する追加分）を示す図である
【図２７】実施例３における関連度計算結果の例（図10に対する追加分）を示す図である。
【図２８】実施例４におけるコンピュータシステムを模式的に示す図である。
【図２９】実施例４における操作パターン情報の例を示す図である。
【図３０】実施例４におけるトータルの関連度Rxの計算処理の詳細フローチャートの中で操作パターンに基づいて関連度を補正する例である。
【図３１】実施例４における操作パターン自動生成部による運用操作パターン自動抽出・生成処理の一例である。
【発明を実施するための形態】
【実施例１】
【００１８】
本実施例の統合監視サーバは、インシデント情報、システム構成情報、運用管理者情報、および、運用操作ログを入力として、インシデントおよび対応履歴と運用操作ログとの間の時刻、システム構成、運用管理者に基づく関連度を計算し、その計算結果からインシデントに関連する運用操作ログの一覧を出力する機能を提供する。
【００１９】
実施例１では、インシデントに関連する稼働データアクセスログを一覧として出力する。
【００２０】
以下、図面を用いて実施例を説明する。
【００２１】
図1に、実施例１で想定するコンピュータシステムを模式的に示す。
コンピュータシステムは、統合監視サーバ3、管理DB 4、操作端末5、管理対象システム6によって構成される。これらの機器は、物理的な通信回線2を通して管理ネットワーク1に接続される。
【００２２】
管理対象システム6は、管理対象となるシステムを構成するコンポーネントの例である。管理対象システム6上には、物理マシン（Physical Machine, PM）63、仮想マシンモニタ（Virtual Machine Monitor, VMM）61、その上に搭載される仮想マシン（Virtual Machine, VM）62等のサーバコンポーネントが存在し、複数サーバにリクエストを振り分けるロードバランサ67といったコンポーネントが存在する。また、サーバ上にはOS 63-1、OS上に搭載されるミドルウェア64-1やAP 65-1といったコンポーネントが存在する。さらに、各コンポーネントから稼働データを取得するための監視エージェント66がコンポーネントとして存在する。各コンポーネントは管理対象システムの構成によって、複数個ずつ存在し得るが、図中では簡単のため、1個だけ記載している。
以降では、管理対象システム6を構成する機器または機器に搭載される機能コンポーネントのことを、構成要素と呼ぶ。
【００２３】
管理DB（DataBase） 4は、稼働データT100、インシデント情報T200、システム構成管理情報T500、運用管理者情報T800といった統合監視サーバ3がインシデント管理や稼働データ表示機能を提供するために必要な情報を格納・管理する。また、インシデントの関連付け対象となる運用操作ログT900を格納・管理する。さらに、関連度の計算方法や計算結果に関する情報も格納・管理する。
【００２４】
統合監視サーバ3は、稼働データ、インシデント情報、運用操作ログ等を収集、登録、表示する機能を提供するデータ管理部31と、データ管理部31が収集、登録したインシデント情報や運用操作ログを用いて、インシデントに関連する運用操作ログを抽出する関連運用操作ログ自動抽出部32から構成される。
【００２５】
データ管理部31は、データ収集部310とデータ登録部311、データ表示部312から構成される。
【００２６】
データ収集部310は、管理対象システムにある機器から稼働データやインシデントを収集するプログラムである。一般的な収集方法としては、各機器上でSimple Network Management Protocol（SNMP）や監視システム固有の監視エージェント66を動作させ、その監視エージェント66とデータ収集部310の間で通信することで稼働データやインシデントを収集する。本実施例におけるデータ収集部310では、収集した稼働データが予め指定された条件を満たした場合にインシデントを生成するインシデント検出機能も持つ。
【００２７】
データ登録部311は、データ収集部310が受信した稼働データやインシデント情報を、管理DB 4上に登録するプログラムである。また、データ登録部311は、データ管理部31のユーザとなる運用管理者からの入力操作によって、インシデント情報を、管理DB 4上に登録する。
【００２８】
データ表示部312は、ユーザとなる運用管理者からのリクエストに応じて、管理DB 4上に格納された情報を取得、画面上に表示する。例えば、データ表示部312は、操作端末5上のWebブラウザ51から稼働データやインシデントの表示リクエストを受けると、表示リクエストに含まれる検索条件に従って、管理DB 4から、稼働データT100やインシデント情報T200を取り出す。そして、取り出した稼働データT100やインシデント情報T200をリクエストに合わせて分析・加工し、その結果をWebブラウザ51上に表示する。また、データ表示部312は、このプログラムを介して行った、稼働データやインシデント表示の履歴をアクセスログT1000として管理DB 4上に記録する。
【００２９】
関連運用操作ログ自動抽出部32は、管理DB 4から取得したインシデント情報、システム構成情報、運用管理者情報、および、運用操作ログを入力としてインシデント（および対応履歴）と運用操作ログの間で関連度を計算し、計算結果が一定のしきい値を超えた場合に関連があると判定するプログラムである。関連運用操作ログ自動抽出部32は、関連度計算部320と関連度出力部327で構成される。
関連度計算部320は、時刻、システム構成、運用管理者の3つの観点に基づいてインシデントと運用操作ログの間の関連度を計算し、それらの結果を合成することによって、トータルの関連度を求める。関連度計算部320は、上記を計算するための各観点での計算部321−324を含む。計算部321-324の詳細は、後述する。
関連度出力部327は、関連度計算部320が計算した結果を出力する機能を提供し、たとえば、本発明では管理DB4に計算結果を格納する。
管理DB4は、稼動データT100、インシデント情報T200、システム構成情報T500、運用管理者情報T800、運用操作ログT900、関連度計算結果T1200で構成される。管理DB4に格納される各種情報は、データ収集部311により収集された情報、運用管理者がデータ管理部31を介して入力した情報などである。他の管理ツールによる自動収集および手動入力によって情報が格納されてもよい。本実施例では、管理DB 4上で各種情報を表形式で格納する。しかし、本発明の実施例は、表形式のデータに限定されるものではない。例えば、木構造のデータであっても、テキストのデータであっても、後述する各情報に相当するデータがあれば、本発明を適用できる。
図2は、実施例1における統合監視サーバ3の物理的な構成を示すブロック図である。統合監視サーバ3は、インタフェース（I/F）100、プロセッサ101、およびメモリ102を備える計算機である。I/F 100、プロセッサ101、メモリ102はデータバス103によって接続される。統合監視サーバ3は、I/F 100を介して、管理ネットワーク1と通信する。プロセッサ101は、CPU等の演算装置である。メモリ102は、プログラムおよびデータを保持するための記憶領域である。プロセッサ101は、メモリ102からデータバス34を介してプログラムを読み出し、実行する。  
図3および図4は、管理DB 4に格納するシステム構成情報T500の一例である。システム構成情報T500は、インスタンス情報T600、システム依存関係T700を含む。本実施例では、管理対象システムにおける現在の構成要素に関する情報が管理される。
【００３０】
以降では、必要に応じて管理対象システムのことを単に「システム」と略称する。
また、管理対象システムを一意に識別するための名称を「システム名」と呼ぶ。管理対象システム上の機器のことを「インスタンス」と呼び、インスタンスを一意に識別するための名称を「インスタンス名」と呼ぶ。インスタンス名としては、FQDN（Fully Qualified Domain Name）で記述されたホスト名や、IPアドレスなどがあり得る。
【００３１】
図3は、管理DB 4に格納するインスタンス情報T600の一例である。列T601は、インスタンスの属するシステム名である。列T602は、インスタンス名である。列T603は、インスタンスがシステムの中で果たす役割を示す情報である。役割には、「ロードバランサの仮想ホスト」、「APサーバ」、「DBサーバ」など、論理的な役割を特定する情報が格納される。列T604の区分は、役割を分類した情報である。この例では、エンドユーザに対してサービスを提供するために用意されたインスタンスには「サービス」が、他のインスタンスを管理するために用意されたインスタンスには「管理」が設定されている。
【００３２】
管理対象システム6が複雑化/大規模化した場合には、管理ツールの負荷を分散させるために同種の管理ツールを複数用意することがある。そのため、どの管理サーバがどのインスタンスの運用管理を行うかの情報（以下、管理系の情報と呼ぶ）も含めてシステム構成情報を管理する必要があり得る。そのため、本実施例では管理系を含めたインスタンス情報を管理する。ただし、本実施例では単一の統合監視サーバ3がサービスを構成するすべてのインスタンスに対する監視を行う。
【００３３】
そのため、区分「管理」にインスタンス情報は特に用いなくても対象インスタンスとの関係が明らかである。したがって、統合監視サーバ3の運用操作ログT900のみを対象とする実施例１においては、区分が「サービス」に設定されたインスタンスの情報だけを用いる。区分が「管理」に設定されたインスタンスの情報は実施例２にて用いる。
【００３４】
図4は、管理DB 4に格納するシステム依存関係T700の一例であり、システムを構成する構成要素間の依存関係（例：接続関係）が管理される。本実施例ではインスタンス間の依存関係が管理される。列T701は、インスタンスの属するシステム名である。列T702は、依存先のインスタンス名である。列T703は、依存元のインスタンス名である。依存元には複数のインスタンス名も設定される。列T704は、依存関係を説明する依存内容である。
【００３５】
例えば、行T750は、ロードバランサの仮想ホスト「ap1server」がAPサーバ「ap1server1」と「ap1sever」に接続して「負荷分散」している依存関係を示す。また行T751ではAPサーバ「ap1server1」がDBサーバ「dbserver1」に接続して「DBアクセス」している依存関係を示す。
【００３６】
システム依存関係T700においても、インスタンス情報T600と同様に、サービスを構成するインスタンスだけでなく、管理系のインスタンスの依存関係を保持している。管理系のインスタンスの依存関係（具体的には依存内容T704が「管理対象」に設定された依存関係）は、統合監視サーバ3の運用操作ログのみを対象とする実施例１では用いず、実施例２で用いる。
【００３７】
図5は、管理DB 4に格納する稼働データT100の一例である。稼働データT100は、管理対象システム上の機器から収集された稼働データそのもの、あるいは、そのデータ構造を分析し、テーブル形式に加工した情報である。
【００３８】
本実施例では、稼働データには、システム名、インスタンス名、および稼働データの種類の情報が付与される。ここで稼働データの種類を一意に識別するための名称を「稼働データ種別名」と呼ぶ。稼働データ種別は、ハードウェア装置（例えば、ネットワーク装置）に関するデータや、VMMに関するデータ、VM（およびVM上に搭載されるOS）に関するデータ、そのOS上の複数アプリケーションから共通して利用されるミドルウェア（DB、Webコンテナなど）に関するデータ、およびAP固有のデータがある。データ種別名は、「service1のヘルスチェック」、「OSのCPU利用率」、「APサーバの同時接続数」、「service1のWeb APログ」など、これらの種別が特定できる文字列データである。
【００３９】
列T101は、稼働データが計測された時刻を示す。列T102、T103、T104はそれぞれ、稼働データの出力元となるシステム名、インスタンス名、データ種別名である。列T105は、この稼働データに含まれる計測時刻以外の詳細データである。この例では、時刻以外のデータをキーと値のペアを「キー＝値」の形式で示している。
【００４０】
ここで、稼働データの具体例を説明すると、行T150は、2015年4月10日の9時0分0秒に、ロードバランサの仮想ホストap1serverに対して行ったservice1のヘルスチェックの結果が正常で、その応答時間が200秒かかったことを示す。
【００４１】
図6は、管理DB 4に格納する運用管理者情報T800の一例である。列T801の運用管理者名は、運用管理者を一意に識別するための名称である。列T802の運用担当グループは、運用管理者が所属する運用担当のグループを特定するための情報である。列T803は運用管理者が運用操作権限のあるインスタンスである。T803には1つ以上のインスタンス名が、インスタンス情報T600と対応が取れるように設定される。なお、本実施例では、運用担当グループ毎に運用権限のあるインスタンスが設定される想定である。列T804は、統合監視サーバの個人アカウント名を示し、運用管理者名T801と対応する情報となっている。各運用管理者は、統合監視サーバ3の各機能利用時（例：データ表示部312へのログイン等）にこのアカウント名を利用する。また、稼働データへのアクセスログT1000にはこのアカウント名の情報も出力される。
【００４２】
本運用管理情報T800には、統合監視サーバ3以外のアカウント情報が併せて管理されていてもよい。列T805の管理ツールの共通アカウント名には、統合監視サーバ3以外の各種管理ツールを利用するためのアカウント名を示す。今回は例を簡単にするために、各種管理ツールのアカウントとしては運用担当グループ毎に設定された共通アカウントを用いることとする。そのため、運用担当グループT802と対応する情報になっている。なお、管理ツールの共通アカウント名T805は、統合監視サーバ3の運用操作ログのみを対象とする実施例１では利用せず、実施例２にて利用する。
【００４３】
ここで、運用管理者情報T800の具体例を説明すると、行T850とT851は、それぞれ運用管理者「user1」および「user2」に関する情報を示す。「user1」と「user2」は共に運用担当グループ「group1」に所属し、service1のすべてのインスタンスに対してアクセス権があることを示す。
【００４４】
なお、今回の実施例では、説明を簡単にするため、運用管理者が1つの運用担当グループに所属する単純な2階層によって管理する例を示している。3階層以上の構造を持ち、一人の運用管理者が複数の運用担当グループに所属させ、運用管理者ごとに役割情報を設定した複雑な運用管理者情報を用いてもよい。
図7、図8は、管理DB4に格納するインシデント情報T200の一例である。インシデント情報T200は、インシデントT300と、インシデント対応履歴T400を含む。
【００４５】
図7は、管理DB 4に格納するインシデントT300の一例である。インシデントT300には、インシデントを説明する基本的な情報と最新のステータス情報が登録される。列T301のインシデントIDは管理DB 4に登録されるインシデントを一意に識別するための情報である。本実施例では、インシデントIDは管理DB 4上で自動採番されることとする。列T302の発生日時は、インシデントが発生した時刻を示す。列T303の最新ステータスはインシデントの最新ステータス情報を示し、インシデント発生時には「未対応」が、インシデント対応中には「対応中」、インシデント解決後には「解決」が設定される。インシデントT300に格納する情報のうち、最新ステータスT303だけが発生後に更新される情報である。列T304のシステム名は、インシデントが発生したシステム名である。列T305の重要度はインシデントの重要度を表す情報であり、緊急対応が必要なインシデントには「障害」や緊急対応が必要と限らないインシデントには「警告」が設定される。列T306の発生インスタンスは、インシデントの発生したインスタンス名を示す。列T307の稼働データ種別はインシデントの発生した稼働データ種別を示す。列T304, T306, T307は、稼働データT100の列T102, T103, T104と対応している。列T308のインシデントメッセージは、インシデントの内容を表すテキストである。
【００４６】
ここで、インシデントT300の具体例を説明すると、行T350は、インシデントID 100が付与されたインシデントであり、2015年4月10日の9時0分0秒に、ロードバランサの仮想ホストap1serverにおいてservice1のヘルスチェックの応答時間がしきい値150秒を超えたために発生したインシデントであることを示している。このインシデントT350は、稼働データT100の例で示した行T150に対するしきい値判定を行った結果、発生したインシデントである。
【００４７】
図8は、インシデント対応履歴T400の例である。インシデント対応履歴T401は運用管理者によって記入された情報が記録される。この例では、各行が、あるインシデントに対して行ったひとつの対応作業を表している。列T401のインシデントIDは、この対応履歴に記載した作業の対象となるインシデントのIDであり、インシデントT300の列T401と対応した情報である。列T402のインシデント対応IDは、インシデントID T401に対する各対応履歴を一意に識別するための情報である。本実施例では、インシデント対応IDは、管理DB 4上で自動採番され、インシデントIDごとに1から順に加算した値が順番に付与される。列T403の対応日時は、この対応作業が行われて完了した時刻（通常はこの対応履歴が記録された時刻）を示す。列T404の対応者はこの対応作業を行った運用管理者名である。列T405のステータスはこの対応作業完了後のインシデントのステータスを示す。本実施例ではインシデント対応履歴登録と同時にインシデントT300の最新ステータスT303も更新される。列T406の対応内容は、対応作業の内容を記載したテキストである。
【００４８】
ここで、インシデント対応履歴T400の具体例を説明する。行T450〜T454はインシデントT300の行T350に示したインシデント（ID 100）に関する解決に至るまでの経緯を示す対応履歴である。例えば、行T450（インシデント対応ID 1）は、2015年4月10日の9時30分0秒に運用管理者user1が行った対応作業を示す。この対応作業では、原因調査のために、統合監視サーバ3のデータ管理部31を用いて稼働データを調査し、その結果として「APサーバap1server1, ap1server2の負荷が高まっていることを確認した」ことを記録した履歴である。
【００４９】
インシデント対応履歴は運用担当者によって手入力されるため、作業内容の抽象化/簡略化や作業内容の抜け漏れが発生することで、記載内容と実際の作業内容との間で乖離が発生し得る（例えば、行T453の対応内容には未記入の実際には稼働データの調査も行った等）。インシデント対応履歴の記載内容と実際の作業内容との間に乖離があると、対応履歴の記載内容だけをエビデンスとして用いることや、作業ノウハウとして再利用することは難しい。そのため、本発明のインシデントに関連する運用操作ログ自動抽出方法では、関連する運用操作ログは対応履歴に未記載の内容であっても発見できる。
【００５０】
以下では、インシデントの関連付け対象となる運用操作ログT900について説明する。実施例１では、統合監視サーバ3のデータ表示部312を介して運用管理者の行った稼働データへのアクセスログT1000を運用操作ログT900として用いる例を示す。
【００５１】
図9は、稼働データへのアクセスログT1000の一例である。本実施例の説明において必要のないアクセスログについては記載を省略するが、実際には「…」で記載した間にその他の無関係のアクセスログが出力されている。
【００５２】
以降では、稼働データへのアクセスログのことを単に「アクセスログ」と記載する。
アクセスログT1000は、運用管理者がデータ表示部312を介して稼働データT100やインシデント情報T200にアクセスした履歴を格納する。データ表示部312を介したアクセスには、各稼働データやインシデント情報の表示の要求等が含まれる。アクセスログT1000は、運用管理者がデータ表示部312にデータの表示等を入力するたびに、データ表示部312によって生成される。
【００５３】
列T1001のログIDは、アクセスログは管理DB 4に登録されるアクセスログを一意に識別するための情報である。本実施例では、ログIDは管理DB 4上で自動採番されることとする。列T1002の操作日時は、データ表示部312を介して、運用管理者がデータへアクセスした時刻を示す。列T1003は表示された稼働データに関するシステム名を示す。列T1004はこのアクセスを行った運用管理者を示す。列T1005のセッションIDは、一定の短時間内に連続して行われたアクセスを関連付けるためのセッション情報を識別する情報を示す。データ表示部312がWeb APの場合にはこの列にはHTTPcookieに含まれるセッション情報が含まれる。
【００５４】
列T1006の運用操作詳細はこのアクセスにおける表示の要求等の詳細情報が含まれる。運用操作詳細の内容は表示画面によって異なるため、複数のキーと値のペアを「キー＝値」の形式で格納している。運用操作詳細の内容には、例えば、「表示画面」、「対象インスタンス」、「稼働データ種別」、「検索時刻条件」、「選択されたインシデントID」が含まれる。「表示画面」は表示された画面の種類を示す。「対象インスタンス」と「稼働データ種別」は、画面に表示された稼働データのインスタンス名およびデータ種別名を示す。「検索時刻条件」は、稼働データの表示期間である。運用操作詳細はそれ以外にも稼働データを絞り込むための検索条件等が格納され得る。なお、今回の実施例に記載のアクセスログでは運用操作詳細に対象インスタンスを必ず含むこととする。
ここで、アクセスログの具体例を説明すると、行T1050は、2015年4月10日の9時15分0秒に、運用管理者user1がインシデントID 100のインシデントを表示したことを示している。また、行T1051は、2015年4月10日の9時16分0秒に、運用管理者user1が稼働データ表示として応答データ表示を行い、ロードバランサの仮想ホストap1serverに対して行ったservice1のヘルスチェックの結果を示す応答データを表示したことを示している。ここで、行T1051は行T1050のインシデント表示から続けて、稼働データを調査した場合の例である。そのため、選択されたインシデントIDとして「100」が設定されている。一方、行T1056のアクセスログは行1051と同一の運用管理者とセッションIDにも関わらず、選択されたインシデントIDが存在しない。これは、間に、データ表示部312のホーム画面（初期画面）に戻る等して、インシデントID 100とは関係のない稼働データ調査を行った例を示している。
【００５５】
本実施例に記載のデータ表示部312では、インシデント表示から続けて稼働データ調査を行っている間は、明示的にインシデントが選択されている状態のため、選択されたインシデントIDが記録される。しかし、途中でホーム画面（初期画面）に戻る等して、インシデントID 100とは関係のない稼働データ調査を行った場合には、再びインシデント表示から選択されない限りは関連有無を判別する手段が無いため、選択されたインシデントIDが記録されない。
【００５６】
本発明を用いなくても、上記のように選択されたインシデントIDが明示的に指定されていれば、インシデントと運用操作ログを関連付けられる。しかし、インシデントに関する稼働データ調査を中断・再開した場合（例えば、行T1054が該当）のように暗黙的に関連性がある場合には対応できない。本発明のインシデントに関連する運用操作ログ自動抽出方法では、上記のように暗黙的に関連がある運用操作ログについても発見可能とする。
【００５７】
本実施例では、インシデントに関連する運用操作ログ自動抽出方法として、これまでに説明した各種情報を入力としてインシデント（および対応履歴）と運用操作ログの間で関連度を計算して、計算した関連度が一定のしきい値を超えた場合に関連があると判定する。
本実施例では、時刻、システム構成、運用管理者の3つの観点に基づいてインシデントと運用操作ログの間の関連度を計算して、それらの結果を合成することによって、トータルの関連度を求める。
【００５８】
なお、本実施例の各関連度は1〜100の間で正規化された値としてスコアリングする。値が大きいほど関連が強いことを示す。また、関連度が関連判定しきい値RTを超えた場合に関連ありと判定するがRTの値を「70」として設定する。
【００５９】
本実施例における各種関連度の説明と計算方針は以下のとおりである。
[時刻に基づく関連度R1]：
・説明： インシデントと運用操作ログの時刻的な近さを示す指標。
・計算方針： 運用操作ログの操作日時が、インシデント対応履歴の対応日時に近いほど関連度が大きい。 
[システム構成に基づく関連度R2]：
・説明： インシデントと運用操作ログに含まれるシステム構成情報の接続関係の近さ（システム空間の近さ）を示す指標である。
・計算方針： 運用操作ログの対象インスタンスが、インシデントの発生インスタンスあるいは対応履歴中に記載のインスタンスと接続ホップ数が近いほど関連度は大きい。 
[運用管理者に基づく関連度R3]：
・説明： インシデントと運用操作ログに含まれる運用担当者の担当範囲の近さ（ユーザ空間の近さ）を示す指標である。
・計算方針： 運用操作ログの操作を実行した運用管理者と各インシデント対応履歴の対応者の所属が近いほど関連度が大きい。 
[トータルの関連度Rx]：
・説明：時刻、システム構成、運用管理者の全観点で関連があることを示す指標である。・計算方針：R1、R2、R3を合成した値が大きいほど関連度が大きい。
【００６０】
上記の計算方針や具体的な計算処理のロジックは統合監視サーバ3の中にバンドルしても構わないし、外部定義したものを用いても構わない。外部定義をすることによる利点としては、計算方針やロジックの変更や追加に用意に対応できる点があげられる。
【００６１】
図10は、上記で説明した関連度計算方法にしたがって計算した結果を格納した関連度計算結果T1200の一例である。図10には、図6と図7に示したインシデントID 1のインシデントと図9で記載したアクセスログT1000に対応する計算結果のみを記載している。実際にはインシデントIDとログIDの組合せに対する計算結果が格納される。
さらに、ログIDとインシデントIDの組合せに対してトータルの関連度Rxが最も大きい値だった結果のみを最終的に保持する例を記載している。もしデータ保存容量に余裕があれば、ログIDとインシデントIDおよびインシデント対応IDの組み合わせに対する計算結果を残しても構わない。逆にデータ保存容量を節約したい場合には、さらに関連ありと判定された結果だけを保持してもよい。
【００６２】
列T1201のログIDは、関連度計算対象となったログのログIDを示す。アクセスログT1000のログID T1001に対応する情報である。列T1202のインシデントIDは、関連度計算対象となったインシデントのインシデントIDを示す。インシデントT300のインシデントID T301に対応する情報である。列T1203のインシデント対応IDは、関連度計算対象となったインシデント対応履歴の対応履歴IDを示す。インシデント対応履歴T400のインシデント対応ID T402に対応する情報である。今回の例では、各インシデントについて最も関連度Rxが大きいインシデント対応IDの結果のみが記録される。
列T1205およびT1206は、時刻に基づく関連度R1の計算結果の値およびその理由である。列T1207およびT1208は、システム構成に基づく関連度R2の計算結果の値およびその理由である。列T1209およびT1210は、運用管理者に基づく関連度R3の計算結果の値およびその理由である。列T1211およびT1212は、トータルの関連度Rxの計算結果の値、および関連判定しきい値RTによる判定に基づく関連有無である。
【００６３】
ここで、関連度計算結果T1200の具体例を説明する。行T1253では、ログID 1003のアクセスログがインシデントID 100との関連について、インシデント対応ID 1の対応と最も関連があり、そのトータルの関連度Rxの値が「100」となり、しきい値判定の結果「関連あり」と判断された結果を示している。時刻に関する関連度R1は、アクセスログが「対応ID 1の15分前に発生」したという理由により値が「100」、システム構成に基づく関連度R2は、インシデントに関連するインスタンスに接続ホップ数が近い「ap1sever1 ap1server2の情報を閲覧」したという理由により値が「100」、運用担当者に基づく関連度R3は、アクセスログの運用担当者がインシデント対応履歴の「対応者と一致」したという理由により値が「100」となっている。
【００６４】
行T1255では、ログID 1020のアクセスログはインシデントID 100との関連において、インシデント対応ID 1の対応と最も関連があり、そのトータルの関連度Rxの値が「21」となり、しきい値判定の結果「関連なし」と判断された結果を示している。この例ではR1とR2の値は大きいが、R3の関連理由が「-」すなわち関連が小さいと見なされ、値が「1」となったために、Rxの値も小さくなっている。
【００６５】
なお、今回、関連度計算結果T1200は、説明をわかりやすくするために管理DB 4上に記録して用いる例を記載したが、管理DB4上には記録せずにすべてインメモリで処理しても構わない。
【００６６】
以降では、統合監視サーバ3におけるインシデントと稼働データの表示機能や運用操作ログ出力について表示画面例を用いて説明する。
データ表示部312は、ログイン画面を表示し、運用管理者からのアカウント名およびパスワードの入力を受け付けてユーザ認証を行い、入力されたアカウント名に応じて、運用管理者情報T800の運用操作権限のあるインスタンスを参照して、権限のあるインスタンスに関する情報のみを表示する。ユーザ認証後は、データ表示部312は、稼働データ表示のホーム画面を表示し、ホーム画面には閲覧権限のあるデータ種別やインスタンスに対応する稼働データ表示画面へのリンクや検索インタフェース、インシデント情報を表示するインシデント表示画面へのリンクや検索インタフェースが表示される。運用管理者の選択に従って後述の稼働データ表示画面やインシデント表示画面が表示され、これらの表示画面は相互に移動できる。
【００６７】
図11は、データ表示部312におけるインシデントおよび関連する運用操作ログ表示画面の例である。インシデント表示画面には、インシデントT300およびそのインシデント対応履歴T400が表示される。
【００６８】
表示画面上部にあるテーブルには、指定されたインシデントT300の情報を表示される。表示画面中央部にあるテーブルにはそのインシデントの対応履歴T400の情報が表示される。この例では、図6, 6に示したインシデントID 1のインシデントT300および対応履歴T400の内容を表示している。
【００６９】
表示画面上部にある「インシデント検索」ボタンを押すと検索機能を利用できる。具体的には、検索用のユーザインタフェースが表示され、インシデントの日時範囲やキーワード指定によってインシデントが検索でき、検索されたインシデント一覧から別のインシデントを選択できる。また、中央部にある「対応履歴追加」「選択した対応履歴修正」ボタンを押すことで、インシデント対応履歴登録用のユーザインタフェースが表示され、インシデント対応履歴の追加/更新登録できる。上部にある「インシデントに関連する稼働データ調査」を押すことで、このインシデントに関連する稼働データへのリンク一覧が表示され、そのリンクを押下することで、以降は、このインシデントを選択した状態を保持したまま稼働データ表示画面を表示できる。
表示画面下部にあるテーブルには、現在表示しているインシデントT200およびインシデント対応履歴IDに関連する運用操作ログを一覧表示した結果である。この例では、関連ありと判定された運用操作ログが関連するインシデント対応IDと操作日時順にすべて表示されている。なお、この例は、インシデントID 1のインシデントに関連する運用操作ログ一覧となっているが、運用操作ログ2件を除いて表示は省略する。1件目のログID 1061の結果、すなわち、図9のアクセスログT1000の行T1062および図10の関連度計算結果T1200の行T1262に対応する結果になっている。また、2件目については、後述の実施例２において関連付けられた運用操作ログの結果となっている。
【００７０】
図12は、データ表示部312における稼働データ表示画面の例である。稼働データ表示画面には、表示リクエストに含まれる検索条件にしたがった稼働データT100が表示される。また、インシデントが選択された状態で遷移してきた場合には、インシデントT200の情報も表示される。
【００７１】
表示画面上部にあるテーブルには、インシデントが選択された状態で遷移してきた場合に、そのインシデントT300の情報が表示される。インシデントが選択された状態でない場合には、このテーブルは表示されない。  その下の枠内は稼働データ表示部分である。枠内の上部のグラフは指定された検索条件に従って、管理DB 4から、稼働データT100を取得・分析・加工して出力されたグラフである。表示画面下部にあるテーブルもグラフと同様に稼働データT100を取得・分析・加工して出力されたテーブルである。
【００７２】
表示画面中央部にある「関連する稼働データへ移動」というユーザインタフェースは、現在閲覧している稼働データに関連する別の稼働データに移動するためのリンクである。例えば、現在表示しているインスタンスと直接の依存関係がある全インスタンスの全稼働データ種別の一覧が提示され、リンクを同一することで、同一時間帯の別の稼働データに遷移することができる。また、稼働データ表示部分の上部にある「[前日][翌日][月間表示][年間表示]」リンクは同一稼働データの別の時間帯や時刻範囲の情報に移動するためのユーザインタフェースである。
運用管理者は、上記のインシデントおよび稼働データ表示画面にアクセスして、稼働データを次々とたどることによって、インシデントに関連する稼働データを調査する。
【００７３】
以降では、本発明の実施例１におけるインシデントに関連する運用操作ログの自動抽出処理について、フローチャートを用いて説明する。
【００７４】
図13は、本発明の実施例１における関連運用操作ログ自動抽出部32の関連度計算処理のフローチャートの一例である。関連度計算処理は、データ管理部31を介して計算に必要なデータを取得するデータ管理ステップ（S101〜S104）と、関連度計算部320が計算処理を行う関連度計算ステップ（S105, S20, S30, S40 ,S50 ,S106）と、計算結果を出力・保持する結果出力ステップ(S21, S31, S41, S51)から成る。
【００７５】
最初に、管理DB 4上のインシデントT200およびインシデント対応履歴T300から、関連度計算対象となる1件のインシデントINCおよび、INCのインシデントIDをキーにインシデント対応履歴のリストINC_HISTORIESを取得する（S101）。具体例で説明すると、図6のインシデントT300の行T350を対象（INC）とした場合にはインシデントIDは「100」となり、INC_HISTORIESは図7のインシデント対応履歴T400の行T450〜T454となる。
次に、管理DB 4上のインスタンス情報T600およびシステム依存関係T700からINCに含まれるシステム名に対応するシステム構成情報の集合SYS_SETを取得する（S102）。具体例で説明すると、図6のインシデントID 100のインシデントT350を対象（INC）とした場合、システム名は「service1」である。実施例１では、区分が「サービス」と設定されたインスタンス情報を用いる。システム名「service1」と区分「サービス」をキーに図4のインスタンス情報T600を検索すると、インスタンスとして、行T650〜行656が取得される。これらがシステム「service1」のサービスを構成するすべてのインスタンスとなる。システム依存関係T700については、依存内容が「管理対象」かつシステム名「service1」をキーに検索すると、サービスを構成するインスタンスに関する依存関係を取得できる。SYS_SETにはこれらの情報を保持する。
【００７６】
さらに、管理DB 4上の運用担当者情報T800から INCに含まれるシステム名に対応する運用担当者情報のリストUSERSを取得する（S103）。 
具体例で説明すると、図6のインシデントID 100のインシデントT350を対象（INC）とした場合、システム名は「service1」である。「service1」をキーに図6の運用者情報T800を検索すると運用操作権限のあるインスタンスT803に基づいて運用管理者として行T850〜行854を取得する。
続いて、S101〜S103で取得した情報を用いて 管理DB 4上の運用操作ログT900から関連抽出対象となるログをすべて取得する。具体的には、実施例１では運用操作ログT900として管理DB 4上のアクセスログT1000から、INCの発生日時T302からINC_HISTORIES中の最新のインシデント対応履歴の対応日時T403までの期間に発生したログをすべて取得する（S104）。以下、取得した運用操作ログのリストをLOGSと呼ぶ。
【００７７】
具体例で説明すると、インシデントID 100の場合には、発生日時は「2015年4月10日の9時15分0秒」から、最新のインシデント対応履歴（インシデント対応ID 5）の対応日時「2015年4月12日の17時10分0秒」までの間に発生したアクセスログT1000をすべて取得する。図9に記載したアクセスログはすべて上記期間内に含まれるため、行T1050〜T1071をすべて取得する。なお、今回の例では、説明に必要なアクセスログ以外は記載を省略しているため、実際には、インシデントとは関連のない、他のより多くのアクセスログも取得する可能性がある。
【００７８】
続いて、関連度計算部320は、LOGSの中から未計算の1件の運用操作ログLOGを取得する（S105）。
【００７９】
そして、選択されたLOGとS103までに取得した情報とLOGを用いて、時刻に基づく関連度R1、システム構成に基づく関連度R2、 運用管理者に基づく関連度R3をそれぞれ計算し（S20, S30, S40）、各結果を、関連度出力部327を介して管理DB 4上の関連度計算結果T1200に格納する（S21, S31, S41）。 さらに、上記で計算した関連度R1〜R3を合成してトータルの関連度Rxを計算して（S50）、その結果を、関連度出力部327を介して管理DB上の関連度計算結果T1200に格納する（S51）。これらS20〜S51の計算処理の詳細については後述する。
【００８０】
選択されたLOGに対して上記の一連の計算を実施した後に、LOGS中に未計算の運用操作ログがあればS105以降を繰り返す（S106）。また、上記では運用操作ログを検索する条件に最新のインシデント対応履歴の対応日時を用いる。さらに、後述の計算処理の説明に述べるとおりインシデント対応履歴毎に関連度を計算できる。すなわち、解決途上のインシデントに対しても本発明を適用できる。
【００８１】
以降では、時刻に基づく関連度R1の計算方法の詳細を説明する。本実施例のR1は、インシデントと運用操作ログの時刻的な近さを定量化するために、運用操作ログの操作日時がインシデント対応履歴の対応日時に近いほど関連度が大きくなるように値を計算する。
図14は、時刻に基づく関連度R1の計算において時刻的な近さを定量化する関数モデルの一例をグラフ表現したものである。本実施例では、ある特定のインシデント対応履歴においてその対応日時T1とひとつ前のインシデント対応履歴の間での対応日時T0の間を時刻の関連がある期間として、運用操作ログの操作日時TLが今回の対応日時T1に近ければ近いほど関連度の値が100に近づくような関数を用いる。関数モデルではT0とT1の期間が短い場合の傾きが急になりすぎることを防ぐために、活性期間Aを設定し、TA（＝T1−A）からT1の期間中は関連度が100になり、T0からTAの期間は1から100に線形に変化するような関数モデルを用いる。なお、活性期間Aには0以上の任意の値を設定できるが、本実施例では30分間に設定する。
【００８２】
図15は、関連運用操作ログ自動抽出部32の時刻に基づく関連度R1の計算処理S20, S21の詳細フローチャートの一例である。 図15は、図14に示した関数モデルを計算ロジックとして実装した場合の一例となっている。
【００８３】
関連度計算部320は、S103までに取得したINC_HISTORIESの中から未検証のうち、対応日時の最も早い対応履歴INC_H1を取得する（S201）。
【００８４】
続いて、関連度計算部320は、INC_HISTORIES を参照してINC_H1の1つ前の対応履歴INC_H0が存在するかどうかを判定し（S202）、存在する場合には、前回の対応日時T0として、INC_H0の対応日時を設定する（S203）。存在しない場合には、前回の対応日時T0として、INCの発生日時を設定する（S204）。
そして、前回の対応日時T0, 今回(INC_H1)の対応日時T1, LOGの操作日時TLを対応時刻範囲内での時刻の近さを示す関数f_r1(T0, T1, TL)に入力し、 対象となるインシデントINC、インシデント対応履歴INC_H1、運用操作ログLOGに関する時刻に基づく関連度R1を計算する（S205）。 
ここで時刻の近さを示す関数f_r1(T0, T1, TL)は以下のとおりである（ここでTAはT1から活性期間Aを遡った日時）。
【００８５】
【数１】
0006517677.tif 000002
【００８６】
続いて、S205で計算したINC、INC_H1、LOGに関する関連度R1の値とその理由を、関連度出力部327を介して管理DB 4上の関連度計算結果T1200に格納する（S206）。「理由」には、f_r1(T0, T1, TL)が1以外、すなわち、関連があると見なされた場合に「対応ID {INC_H1のインシデント対応ID}の{TA−TL}前に発生」の形式で生成した文字列を登録する。ここで中括弧{  }で囲まれた部分は各種情報から取得・計算した値を示す。
【００８７】
その後、INC_HISTORIESに未検証の対応履歴があるかを判定し、もし未検証の対応履歴が存在すれば、S201以降を繰り返す（S207）。
【００８８】
ここで時刻に基づく関連度R1の計算について具体例を用いて説明する。ログID 1090のLOGとインシデントID 100のINCとインシデント対応ID 5のINC_H1の場合を例にとると、T1は「2015年4月12日の17時0分0秒」、T0は「2015年4月11日の2時0分0秒」となる。TLは「2015年4月12日の8時0分5秒」でR1の値は「77」となる。この例のように、T0とT1の間が1日以上空いているが、TLが相対的にT1に近い場合には関連度が高く計算される。
本実施例にて記載したR1の計算方法において、T1から活性期間Aを遡った日時TAの代わりにアクセスログにおけるインシデント表示を使っても良い。この例については実施例３にて記載する。
【００８９】
以降では、システム構成に基づく関連度R2の計算方法の詳細を説明する。本実施例のR2はインシデントと運用操作ログに含まれるシステム構成情報の接続関係の近さを定量化するために、運用操作ログの対象インスタンスが、インシデントの発生インスタンスや対応履歴中に記載のインスタンスと接続ホップ数が近いほど関連度を大きい値として計算する。
【００９０】
図16は、関連運用操作ログ自動抽出部32のシステム構成に基づく関連度R2の計算処理S30, S31の詳細フローチャートの一例である。本実施例では、関連がないと判断する接続ホップ数の境界値HOPをあらかじめ定義しておき、ある特定のインシデントおよびインシデント対応履歴に含まれるインスタンスと、運用操作ログの対象インスタンスの間の接続ホップ数HLが「0」すなわち同一のインスタンスの場合に関連度の値が「100」、HLが「HOP」の場合に関連度の値がちょうど「1」になるような一次関数モデルを用いることとする。なおHLが「HOP」以上の場合にも関連度の値は「1」となる。なお、本実施例では接続ホップ数の境界値HOPを「4」に設定する。HOPには0以上の任意の値を設定できる。
関連度計算部320は、INC_HISTORIESの中から未検証のうち、対応日時の最も早い対応履歴INC_H1を取得する（S301）。以降では、INC、INC_H1、LOGを対象にシステム構成に関する関連度R2を計算する。
【００９１】
今回の計算対象となるR2の値を上限値UPPER_LIMITで初期化する（S302）。本実施例ではUPPER_LIMITは「100」である。
次に、関連度計算部320は、関連インスタンスリストINS_LIST を初期化し、INCの発生インスタンスT306をINS_LISTに追加する（S303）。
さらに、INC_H1の対応内容T406のテキストに含まれるインスタンス名を抽出し、抽出されたインスタンス名をINS_LISTに追加する（S304）。
【００９２】
ここで対応内容T406のテキストに含まれるインスタンス名を抽出する具体的な方法としては、SYS_SETに含まれるサービスを構成するインスタンスに関するインスタンス情報T600の各インスタンス名T602の全部あるいは一部をキーとして、対応内容T406のテキストを検索して抽出する等の方法があげられる。あるいは、対応内容T406から「APサーバ」等の役割情報を抽出して、インスタンス情報T600の役割T603が一致するインスタンスを取得しても良い。本実施例では前述の方法を用いる。
なお、S304の処理は実施しなくても関連度R2を計算できる。その場合には全ての対応履歴においてINCの発生インスタンスだけが利用されるため、関連度R2の計算の精度が落ちるが、その分少ない計算処理量で値を求められる。
続いて、LOGの対象インスタンスがINS_LISTに含まれるかどうかを判定する（S305）。
【００９３】
含まれる場合、現在の関連度R2の値と理由をINC、INC_H1、LOGに関する関連度R2の値として、関連度出力部327を介して管理DB 4上の関連度計算結果T1200に格納し（S306）、S311の処理を行う。ここで理由には「{S304の処理で含まれていたインスタンス名}の情報を閲覧」の形式で生成した文字列を登録する。ここで中括弧{  }で囲まれた部分は各種情報から取得・計算した値を示す。
【００９４】
含まれない場合には、関連度計算部320は、現在の関連度R2の値からホップ数に基づく減算値REDUCTION_BY_HOPを減算する（S307）。本実施例では接続ホップ数の境界値HOPを「4」に基づいて、REDUCTION_BY_HOPを「25」と設定する。関連運用操作ログ自動抽出部32は、現在の関連度R2の値が下限値LOWER_LIMIT以下かどうかを判定する（S308）。本実施例ではLOWER_LIMITは「1」である。
【００９５】
もし、R2の値が下限値よりも大きい場合には、INS_LISTとSYS_SETを比較してINS_LISTの各インスタンスと依存関係のあるインスタンスをすべて取得し、INS_LISTを置き換えて（S309）、S305以降の処理を再び行う。本実施例では依存関係の有無は、システム依存関係T700の依存先T702と依存元T703の双方向を用いることとする。すなわち、INS_LIST中のインスタンス名が依存先T702と依存元T703中のインスタンスいずれか一致した場合に依存関係のあるインスタンスと見なす。
【００９６】
もし、R2の値が下限値以下の場合には、現在の関連度R2の値を下限値LOWER_LIMITに更新して（S310）、S306の計算結果を格納する。
【００９７】
上記の処理によって、INC、INC_H1、LOGを対象にシステム構成に関する関連度R2を計算した後で、INC_HISTORIESに未検証の対応履歴があればS301以降の処理を繰り返す（S311）。
【００９８】
ここでシステム構成に基づく関連度R2の計算について具体例を用いて説明する。
【００９９】
ログID 1010のLOG、インシデントID 100のINC、インシデント対応ID 1のINC_H1の場合を例にとると、対象インスタンスは運用操作詳細T1005より「dbserver1」となる。初期のINS_LIST「ap1server」、「ap1server1」、「ap1server2」には含まれないため、関連度R2の値が減算されて「75」となる。INS_LISTとSYS_SETを比較してINS_LISTの各インスタンスと依存関係のあるインスタンスを取得すると、「ap1server1」「ap1server2」「dbserver1」「vmm1」が抽出される。これらのインスタンスでINS_LISTを更新してLOGの対象インスタンスと比較をすると「dbserver1」が含まれるため、関連度は「75」となる。本実施例にて記載したR2の計算方法は一例である。
例えば、システム構成情報に依存の方向性や依存の強さを表す数値を持たせて、上記関連度R2の計算の精度向上のために、これらの情報を用いても良い。
以降では、運用管理者に基づく関連度R3の計算方法の詳細を説明する。本実施例のR3はインシデントと運用操作ログに含まれる運用担当者の担当範囲の近さを定量化するために、運用操作ログの操作を実行した運用管理者と各インシデント対応履歴の対応者の所属が近いほど関連度が高いとして計算する。
【０１００】
運用管理者に基づく関連度R3の計算における運用担当者の担当範囲の近さを定量化する関数モデルは、R2の関数モデルとほぼ同様に所属のホップ数に基づく一次関数モデルを用いることとする。本実施例では、運用管理者情報T800に記載のとおり、運用管理者と所属する運用担当グループという単純な2階層によって管理する例を用いるため、ホップ数の境界値は「2」となる。つまり、インシデント対応履歴の対応者と運用操作ログの運用管理者が一致すればR3は「100」、グループが一致すれば「50」、両方とも一致しなければ「1」となる。
【０１０１】
図17は、関連運用操作ログ自動抽出部32の運用管理者に基づく関連度R3の計算処理S40, S41の詳細フローチャートの一例である。
【０１０２】
関連度計算部320は、INC_HISTORIESの中から未検証のうち、対応日時の最も早い対応履歴INC_H1を取得する（S401）。
【０１０３】
次に、関連度R3の値を上限値UPPER_LIMITで初期化する（S402）。
【０１０４】
続いて、対象となるLOGを出力した管理ツールにおいて、他の管理管理者との共通アカウントを利用するかを判定する（S403）。統合管理サーバ3では、運用管理者毎の個別アカウントを利用するため、S403の判定結果は「NO」となる。そのため、実施例１では判定結果は常に「YES」となる。一方、統合監視サーバ3以外の各種管理ツールでは、運用担当グループ毎に設定された共通アカウントを用いるため、S403の判定結果は「YES」となる。なお、統合監視サーバ3以外の各種管理ツールを用いる例は、実施例２にて示す。
【０１０５】
S403の判定結果が「NO」の場合には、LOGの操作を行った運用管理者T1004とINC_H1の対応者T404が一致しているかを判定する（S404）。
【０１０６】
S404の判定結果が「YES」の場合には、現在の関連度R3の値（すなわちUPPER_LIMIT＝100）とその理由を、INC, INC_H1, LOGに 関する関連度R3の計算結果として管理DB 4上の関連度計算結果T1200に格納する（S405）。 ここで理由としては「対応者と一致」という文字列を登録する。
【０１０７】
S404の判定結果が「NO」の場合には、INC_H1中の対応者とUSERSを比較して、対応者と同一運用担当グループの運用管理者一覧USERS2を取得する（S406）。そして、LOGの操作を行った運用管理者T1004がUSERS2に含まれるかを判定する（S407）。
S407の判定結果が「YES」の場合には、現在の関連度R3から運用階層に基づく減算値REDUCTION_BY_USERで減算する（S408）。本実施例では、REDUCTION_BY_USERは「50」に設定される。そして、現在の関連度R3の値（UPPER_LIMIT−REDUCTION_BY_USER＝100−50=50）とその理由を、INC, INC_H1, LOGに関する関連度R3の計算結果として、管理DB 4上の関連度計算結果T1200に格納する（S405）。 ここで理由としては「対応者とグループが一致」という文字列を登録する。
【０１０８】
S407の判定結果が「NO」の場合には、運用管理者については関連がないとみなされて、関連度R3の値を下限値のLOWER＿LIMITに設定する（S409）。そして、現在の関連度R3の値（すなわちLOWER＿LIMIT＝1）を、INC, INC_H1, LOGに関する関連度R3の計算結果として関連度出力部327を介して管理DB 4上の関連度計算結果T1200に格納する（S405）。 ここで理由としては関係がないことを示す「−」という文字列を登録する。
【０１０９】
S403の判定結果が「YES」の場合には、INC_H1の対応者T404が利用する共通アカウントT805をUSERSから取得して、 LOGの操作を行った共通アカウントと一致するかを判定する（S410）。そして、S410の判定結果が「YES」であればS408、S405と処理を行い、S410の判定結果が「NO」であればS409、S405と処理を行う。
【０１１０】
以上の通り、INC, INC_H1, LOGに関する関連度R3の計算処理を行った後、INC_HISTORIESに未検証の対応履歴があるかを判定し、未検証の対応履歴がある場合にはS401に戻って処理を繰り返す（S411）。
【０１１１】
以降では、トータルの関連度Rxの計算方法の詳細を説明する。本実施例のRxは時刻、システム構成、運用管理者のすべての観点で関連があることを定量的に示するために、R1、R2、R3のすべてが大きいときに値が大きくなるように計算する。本実施例では、これを満たすための合成関数F_rx(r1, r2, r3)として以下の相乗平均を用いる（ここでr1, r2, r3はそれぞれR1、R2、R3の値）。
【０１１２】
【数２】
0006517677.tif 000003
【０１１３】
上記は合成関数の一例であり、各観点の関連度が合成できれば、別の関数を用いてもよい。例えば、重み係数W1, W2, W3を用いて以下の加重平均を用いてもよい。
【０１１４】
【数３】
0006517677.tif 000004
【０１１５】
加重平均を用いることで、重要な観点毎の重要度に応じて重みづけを行って関連度を計算できる。
【０１１６】
図18は、関連運用操作ログ自動抽出部32のトータルの関連度Rxの計算処理S50, S51の詳細フローチャートの一例である。 図18は、前述の合成関数として前述の相乗平均を用いて実装した場合の一例となっている。
【０１１７】
関連度計算部320は、INC_HISTORIESの中から未検証のうち、対応日時の最も早い対応履歴INC_H1を取得する（S501）。
【０１１８】
次に、データ管理部31を介して、管理DB 4上の関連度計算結果T1200からINC, INC_H1, LOGに対応する各関連度R1, R2, R3を取得する（S502）。
さらに、各関連度R1, R2, R3を合成関数f_rx(r1, r2, r3)に入力してトータルの関連度Rxを計算する（S503）。 
ここで、S501〜S503について具体例を説明すると、ログID 1050のLOG、インシデントID 100のINC、インシデント対応ID 1のINC_H1の場合には、関連度計算結果T1200の行T1259の列T1205, T1207, T1209をそれぞれ関連度R1、R2、R3の値として取得する。取得した値を合成関数にあてはめると
【数４】
0006517677.tif 000005
となる。
続いて、S503で計算したRxの値が関連判定しきい値RT以上かどうかを判定し（S504）、判定結果が「YES」の場合には関連有無として「関連あり」を（S505）、「NO」の場合には「関連なし」を設定する（S506）。先に述べた具体例の場合には、
【数５】
0006517677.tif 000006
となるため「関連あり」が設定される。
その後、計算した関連度Rxの値および関連有無の情報をINC, INC_H1, LOGの関連度Rxの計算結果として、関連度出力部327を介して、管理DB 4上の関連度計算結果T1200に格納する（S508）。
【０１１９】
以上のとおり、INC, INC_H1, LOGの関連度Rxの計算を行った後で、関連度計算部320は、INC_HISTORIESに未検証の対応履歴があるかを判定し、未検証の対応履歴がある場合には、S501以降の処理を繰り返す（S508）。
【０１２０】
また、INC_HISTORIES中のすべての対応履歴に対するRxの計算が終わった後で、管理DB 4上のINC, LOG, INC_HISTORIES中のすべての対応履歴に対応する関連計算結果を参照し、トータルの関連度Rxが最も大きい1件以外を、関連度出力部327を介して管理DB 4上から削除する（S509）。
【０１２１】
S509の具体例を説明すると、（図10に示した関連度計算結果T1200は最終結果のため記載がないが、）ログID 1003のLOG、インシデントID 100のINCの場合を例にとると、インシデント対応ID 1〜5に対応する関連度Rxの結果はそれぞれ「100」「58」「50」「50」「67」となる。この場合には関連度Rxが最も大きい1件としてインシデント対応ID 1に対応する結果だけを残し（行T1253）、その他の結果を管理DB 4上から削除する。
【０１２２】
以上、本実施例に記載したトータルの関連度Rxの計算方法により、時間、システム構成、運用担当者の各観点で同時に関連が強い場合にのみ関連度が大きくなる。
【０１２３】
以上で示した関連度計算方法は一例であり、本発明は上記計算方法に限定されるものでは無い。インシデントおよびインシデント対応履歴と運用操作ログとを入力として、複数の観点での関連性からインシデントと運用操作ログ間の関連度を計算できるのであれば、別の計算方法を用いてもよい。
【０１２４】
図19は、本実施例におけるデータ表示部312によるインシデントに関連する運用操作ログ表示画面の生成のフローチャートの一例である。
運用管理者が表示対象のインシデントを選択すると、選択されたインシデントのIDをキーに、管理DB 4上のインシデントT300およびインシデント対応履歴T400から、キーに対応するインシデントINCおよびその対応履歴のリストINC_HISTORIESを取得する（S601）。
【０１２５】
次に、INCとINC_HISTORIESをキーに 管理DB 4上の関連度計算結果T1200からINCに関する関連度計算結果の集合RESULTSを取得する（S602）。具体例として、インシデントID 100のインシデント（行350）の場合、RESULTSとして行T1250〜T1271を取得する。
【０１２６】
続いて、RESULTS中の各関連度計算結果に含まれるログID T1201をキーにして、管理DB 4上の運用操作ログT900から対応するログのリストLOGSを取得する（S603）。 具体例として、運用操作ログT900として、インシデントID 100の一つの対応結果である行T1253の場合、ログIDは1003となり、図9のアクセスログT1000中の行 T1053を取得する。インシデントID 100のRESULTSすべてに対応する運用操作ログT900としては、アクセスログT1000の行T1050〜T1071を取得する。
【０１２７】
次に、上記で取得したRESULTSとLOGSをマージした表示用の一時テーブルRESULT_TABLEを生成し（S604）、RESULT_TABLEを用いて表示画面を生成して出力する（S605）。生成される表示画面の具体例は図11に示した通りである。
なお、このインシデントに関連する運用操作ログ表示画面の生成処理は、図13の関連度計算処理の後続で実施しても構わない。
【０１２８】
本実施例におけるインシデント対応履歴T400では、列T402からT405以外の情報は、対応内容T406中にテキストとして記載される想定である。しかし、関連付けをするために用いる情報を明示的に別列に分けてもよい。例えば、対応作業の対象となったインスタンス名や調査対象とした稼働データ種別名を列としてもよい。これにより運用管理者による記入の手間や記入内容の制約が増えるが、これらの情報を対応内容中のテキストから抽出して用いる場合に比べて関連付けの精度高められる。
【０１２９】
また、インシデント対応履歴T400では、ひとつのインシデントに対して行った作業を複数の行に分けて管理する。これに対して、作業履歴を一つの行にまとめたとしても、その行の中で時刻と作業内容毎にグルーピングされた情報をパースできれば、本発明を適用できる。
【実施例２】
【０１３０】
実施例２では、インシデントの関連付け対象となる運用操作ログとして、稼働データのアクセスログに加えて、その他の管理ツールを介した運用操作ログ（コマンド実行ログや操作イベントログ）も用いる場合の例を示す。
【０１３１】
図20に、実施例２で想定するコンピュータシステムを模式的に示す。コンピュータシステムの構成は、実施例１と概ね同様である。ただし、各種管理ツール用のサーバおよび端末7〜9が追加され、管理DB 4 上のシステム構成情報T500および運用操作ログT900上に各種管理ツールに関する情報が追加されている点が異なる。以降では異なる部分についてのみ説明し、実施例１と同様の部分についての説明は省略する。
【０１３２】
各種管理ツールを搭載したサーバおよび端末としては、リモート操作ツール71を搭載したリモート操作端末7、ジョブ管理ツール81を搭載したジョブ管理サーバ8、VMM管理ツール91を搭載したVMM管理サーバ9が追加されている。運用管理者は、操作端末5を介して、これらの管理ツールの機能を利用して、管理対象システム6上の各インスタンスに対する運用操作を行う。リモート操作ツール71を搭載したリモート接続端末7は、管理対象システム6上の各インスタンスにリモートアクセスして操作を行う機能を提供する。本実施例ではリモート操作ツール71としては、例えばSSH（Secure SHell）クライアントツール等が挙げられる。ジョブ管理ツール81を搭載したジョブ管理サーバ8は管理対象システム6上の各インスタンスに対してジョブ実行およびその実行状態の管理を行う機能を提供する。ここでジョブとは、インスタンスに対する複数の操作や処理を作業ごとにまとめた単位である。ジョブはバッチやスクリプトおよびその組合せによって定義され、これをコンピュータが実行することによって作業を自動実行できる。ジョブ管理ツール8におけるジョブの実行方法としては、スケジュール実行、事前に設定した条件を満たした場合のトリガー実行、運用管理者の手動による即時実行などが考えられる。インシデント対応では対策作業に用いることが多いため、運用管理者の手動実行による即時実行が主な操作となる。VMM管理ツール91を搭載したVMM管理サーバ9は、VMM 61およびVMM 62を運用管理する機能を提供する。VMM管理ツール91を用いることによって、VMM 61およびVM 62の起動/停止やVM 61の追加/削除/割当てリソースの変更等といった操作を行える。
【０１３３】
次に、管理DB 4 上のシステム構成情報T500について述べる。実施例２のシステム構成情報T500では、運用操作ログ設定T1300が追加される。
図21は運用操作ログ設定T1300の一例である。運用操作ログ設定T1300は、管理サーバ/端末とその運用操作ログ種別名の対応関係を記載した情報である。列T1301の管理サーバ/端末の役割は管理ツールの役割に関する情報であり、インスタンス情報T600の役割T603に対応する。列T1302の運用操作ログ種別名は管理サーバ/端末が出力するログ種別名を一意に特定するための情報であり、本実施例に示す管理サーバ/端末が出力する後述の運用操作ログT900には対応する情報が付与される。
【０１３４】
この運用操作ログ設定T1300およびインスタンス情報T600およびシステム依存関係T700に含まれる管理系インスタンスの情報は、管理サーバ/端末（のインスタンス）と管理対象となるインスタンスおよび運用操作ログの種別名を紐付けるために用いる。
【０１３５】
続いて、管理DB 4 上の運用操作ログT900について述べる。実施例２では、各管理ツールを用いた運用操作履歴を記録する運用操作ログとして、コマンド操作ログT1400、ジョブ実行ログT1500、VMMイベント操作ログT1600が追加される。これらの運用操作ログは各管理ツールによって出力されて管理DB 4上に転送・登録される。実施例２では、その具体的な方法として、各管理ツールによって管理サーバ/端末のインスタンス上に一旦出力された運用操作ログT500を、稼働データT100と同様に監視エージェント66およびデータ収集部310を介して管理DB 4上に転送/登録する（図中では各サーバ/端末上の監視エージェントの記載は省略）。
【０１３６】
以降、追加された運用操作ログT900にはアクセスログT1000と同様にログを一意に識別する情報としてログIDが保持される。本実施例では、これらのログIDには運用操作ログT900全体で一意なIDが付与される。例えば、アクセスログT1000のログIDとコマンド操作ログのログIDの値が重複することはない。これにより、運用操作ログT900の種類が増えても、実施例１のログIDを用いた処理フローチャートや計算結果がそのまま適用できる。
【０１３７】
図22は、コマンド操作ログT1400の一例である。コマンド操作ログT1400は、運用管理者がリモート操作ツール71を介して、管理対象となるインスタンスにリモートアクセスして実行したコマンド操作の履歴を格納する。コマンド操作ログT1400は、運用管理者がリモート操作ツール71を介したコマンド入力をするたびに、リモート操作ツール71によって出力される。
列T1401のログIDは、管理DB 4に登録されるコマンド操作ログを一意に識別するための情報である。本実施例では、ログIDは管理DB 4上で自動採番されることとする。また、他の運用操作ログ（例えばアクセスログ）とログIDは重複しないこととする。列T1402の管理サーバ/端末のインスタンス名は、このログを出力したリモート操作端末7のインスタンス名である。列T1403の運用操作ログ種別名は、コマンド操作ログのログ種別名である。これは運用操作ログ設定T1300の列T1302に対応している。列T1404の操作日時は、このログが出力された時刻を示す。列T1405は運用操作対象となるシステム名を示す。列T1406の運用操作アカウントはこの運用操作を行ったアカウント名を示す。実施例２で追加した管理ツールでは運用担当グループごとに用意された共通アカウントを用いる（図6の運用管理情報T800の列T805が対応する情報である）。列T1407のセッションIDは、一定の短時間内に連続して行われたアクセスを関連付けるためのセッション情報を識別する情報を示す。リモート操作ツール71がSSHクライアントの場合には、この列にはSSHによるログインからログアウトまでのセッションを識別する情報が含まれる。列T1006の運用操作詳細はこの操作における操作対象インスタンスやコマンド内容等の詳細情報が含まれる。運用操作詳細の内容は操作によって異なるため、複数のキーと値のペアを「キー＝値」の形式で格納している。運用操作詳細の内容には、例えば、「対象インスタンス」、「コマンド」、「コマンド引数」が含まれる。「対象インスタンス」は、操作対象となるインスタンス名を示す。「コマンド」は、実行されたコマンドを示す。また「コマンド引数」はそのコマンドに与えられた引数を示す。本実施例では「コマンド」、「コマンド引数」は日本語の説明に置き換えて表現をしているが、実際には、例えば、OS内部の機能として実装されたコマンドやスクリプトをコマンドライン上で行ったものである。管理DB  4に格納する際には、コマンドライン上の元のデータを記載しても、説明に置き換えたデータを記載してもよい。また、今回の運用操作詳細にはコマンドの操作内容のみが記載されているが、コマンド実行結果の出力（例：コンソールへの標準出力）も合わせて記載してもよい。なお、本実施例に記載のコマンド操作ログでは運用操作詳細に対象インスタンスを必ず含むこととする。
ここで、コマンド操作ログの具体例を説明すると、行T1453は、2015年4月11日の1時0分0秒に、運用管理グループgroup1に所属する運用管理者が共通のアカウントを使って、リモート操作端末のインスタンスterminal1からインスタンスap1server1にアクセスしてAPサーバ設定ファイルを編集した履歴を示している。
【０１３８】
図23は、ジョブ実行ログT1500の一例である。ジョブ実行ログT1500は、ジョブ管理ツール81を介して、管理対象となるインスタンスに対するジョブを実行した履歴を格納する。ジョブ実行ログT1500は、ジョブ管理ツール81を介して、ジョブが実行されるたびに、ジョブ管理ツール81によって出力される。ジョブ実行ログT1500に含まれる情報は、セッションIDが無いことと、運用操作詳細の内容の例が「コマンド」、「コマンド引数」ではなく「ジョブ」、「ジョブ引数」に変わっていることを除き、コマンド操作ログT1400と同様のため、詳細な説明は省略する。
【０１３９】
図24は、VMM操作イベントログT1600の一例である。VMM操作イベントログT1600は、VMM管理ツール91を介して、管理対象となるVMMやVMに対して行った操作の履歴を格納する。VMM操作イベントログT1600は、VMM管理ツール91を介して、操作が行われるたびに、VMM管理ツール91によって出力される。VMM操作イベントログT1600に含まれる情報は、セッションIDが無いことと、運用操作詳細の内容の例が「コマンド」、「コマンド引数」ではなく「イベント」に変わっていることを除いて、コマンド操作ログT1400と同様のため、詳細な説明は省略する。
【０１４０】
ここで、図22−23の運用操作ログは、管理サーバ/端末のインスタンス名と運用操作ログ種別名を有しているのに対して、図9のアクセスログT1000では有していない。これは実施例１では不要であったためである。しかし、実施例２においては、他の運用操作ログと同様に扱うことを可能とするために、図9のアクセスログT1000に対して管理サーバ/端末のインスタンス名と運用操作ログ種別名の情報を追加してもよい。本実施例の例の場合、全アクセスログT1000の管理サーバ/端末のインスタンス名は「moni1」、運用操作ログ種別名は「稼働データアクセスログ」となる。
【０１４１】
なお、運用操作ログT900は今回管理ツールごとに別々のテーブルに格納する例を示しているが、管理ツールごとのログ種別を識別して検索可能であれば一つのテーブル上に格納してもよい。
【０１４２】
以降では、本発明の実施例２におけるインシデントに関連する運用操作ログの自動抽出処理について説明する。
【０１４３】
実施例２の運用操作ログ自動抽出部32による関連度計算処理は、運用操作ログT900として、アクセスログT1000だけでなく、コマンド操作ログT1400、ジョブ実行ログT1500、VMMイベント操作ログT1600を用いる点が異なるが、それ以外については、図13−図19に示した本発明の実施例１における処理内容とほぼ同様である。以下、それ以外の細かい差分をのみを説明する。
【０１４４】
図13に示した関連度計算処理のフローチャート中のS102においては、システム構成情報T500として、区分が「サービス」だけでなく「管理」となっているインスタンス情報T600およびそのシステム依存関係T700も取得する。また、運用操作ログ設定T1300も取得する。
【０１４５】
また、S104で取得する運用操作ログT900としては、アクセスログT1000だけでなく、その他のログ（具体的にはコマンド操作ログT1400、ジョブ実行ログT1500、VMMイベント操作ログT1600）も取得する。S102で取得した管理系を含めたシステム構成情報T500を用いれば、管理サーバ/端末（のインスタンス）と、管理対象インスタンスおよび運用操作ログの種別名を紐付けられるため、これらをキーとすることで、対象インシデントおよびシステムに関係する運用操作ログを絞り込んで取得できる。
さらに、図17に示した運用管理情報に基づく関連度R3の計算処理のフローチャートにおいては、コマンド操作ログT1400、ジョブ実行ログT1500、VMMイベント操作ログT1600の場合には、運用管理グループ共通のアカウントが利用されるため、S403による判定結果が「YES」となって、その後の処理が行われる。
上述以外の処理については、本発明の実施例１と同様である。
【０１４６】
図25には、図6と図7に示したインシデントID 1のインシデントと図22−図24に示した運用操作ログに対応する計算結果を格納した関連度計算結果T1200の例を示す。格納される情報は図10に示した関連度計算結果T1200の例と同様である。
【０１４７】
実施例１、２に記載したとおり、インシデントに関連する運用操作ログ自動抽出方法として、本発明の運用操作ログ自動抽出部32は、インシデント情報T200（インシデントT300およびインシデント対応履歴T400）、運用操作ログT900を入力として、複数の観点での関連性からインシデントと運用操作ログ間の総合的な関連度を計算し、その関連度に基づいてインシデントに関連する運用操作ログを抽出する。関連度の計算では、管理対象システムに関するシステム構成情報T500、および運用管理者情報T800の情報も入力として活用し、時刻、システム構成、運用管理者という3つの観点におけるインシデントの各対応履歴と運用操作ログの関連度を計算し、それらの関連度を合成してトータルの関連度を計算する。
本実施例ではインシデント毎に関連する作業や運用操作を明示的に事前定義/指定することなく、インシデントに関連する運用操作ログを抽出できる。
また、時刻、システム構成、運用管理者等の複数の観点に基づいて、インンシデントの各対応履歴と各運用操作ログとの間の関連性を抽出するため、インシデント発生から解決までの期間に発生した運用操作ログをすべて抽出する場合に比べて精度が向上する。
さらに、インシデント対応履歴の記載内容と実際の作業内容との間に乖離があった場合に、対応履歴に未記載の内容についても関連付けられた運用操作ログから発見できる。例えば、図8のインシデント対応履歴T400の行T453(対応ID 4)には記載されていない「稼働データの調査」に該当する運用操作ログが図10の関連度計算結果T1200の行1266に示す通り、関連ありとして抽出される。
運用管理者はインシデントを指定するだけで関連操作ログを取得できるため、インシデントに関連する運用操作ログの収集、検索にかかる時間の短縮できる。
【０１４８】
取得された運用操作ログに含まれる無関係な情報が減るため、運用操作ログを活用したノウハウ分析処理の精度を向上させられる。
【実施例３】
【０１４９】
実施例３では、実施例１における関連度計算方法のバリエーションとして、時刻に基づく関連度R1の計算において、稼働データのアクセスログ中に含まれるインシデント表示のアクセスログを活用する例を示す。
【０１５０】
実施例３で想定するコンピュータシステムと同様である。また、計算処理方法についても、時刻に基づく関連度R1の計算処理の一部を除いて、実施例１と同様である。以降では、異なる部分および効果を示す上で必要な部分のみ説明し、実施例１と同様の部分についての説明は省略する。
【０１５１】
実施例３の時刻に基づく関連度R1の計算方法では、実施例１にて説明した活性期間Aを予め決めるのではなくインシデント表示のアクセスログがあった場合にはその操作時刻を用いて活性期間Aを決定する。これはインシデントを参照した後、そのインシデントに関連する対応作業を行う可能性が高いという考えに基づく。
【０１５２】
具体的な処理としては、関連運用操作ログ自動抽出部32はS205の前処理として、データ管理部31を介し、LOGSの中からT0とT1の期間のアクセスログを順に参照して、INCのインシデントIDのインシデント表示を行ったアクセスログを1件検索する。本実施例では、運用操作詳細T1006中の「表示画面」が「インシデント表示」かつ「選択されたインシデントID」がINCのインシデントIDと一致するアクセスログが該当する。該当するアクセスログが見つかった場合、そのアクセスログの操作日時からT1の期間を活性期間Aに設定して、以降のS206までの計算処理を実行する。見つからなかった場合、元々のAの値を用いる。それ以外の処理は実施例１と同様である。
以下、具体例を用いて説明する。実施例１の計算方法を用いた場合と実施例３の計算方法を対比させながら述べる。
稼働データへのアクセスログT1000として、図9に示す稼働データへのアクセスログに加えて、図26に示す稼働データへのアクセスログT1000がある場合を想定する。図25に示したアクセスログ（行T1097とT1098）は、インシデントID 1のインシデントが発生したときに、運用管理者「user1」が偶然に別の目的でこのインシデントに関連のあるインスタンスを調査していた場合を想定したログの例である。この例では、このログの操作の後続として、インシデントID 1に関する稼働データ調査を行っている。つまり、図25に示したアクセスログはインシデントID 1との関連はない。
しかし、実施例１に記載した方法で計算すると、行T1097とT1098のアクセスログは、インシデントが発生してから最初のインシデント対応履歴が登録されるまでの期間に発生したアクセスログであり、予め決めた活性期間30分内に含まれるために、R1がそれぞれ「90」、「79」と大きな値となり、結果としてトータルの関連度Rxから「関連あり」と判定されてしまう。
【０１５３】
これらのアクセスログは、時刻以外のシステム構成、運用管理者の各観点でもID 1のインシデントと近いため、関連ありと判定されることはやむを得ない部分があるが、なるべくはこのように誤判定されるノイズも減らしたい。実施例３に記載の例は上記を解決するための一つの手段である。
【０１５４】
実施例３に記載した方法で計算すると、インシデントID 1のインシデント表示を行ったアクセスログとして、図9の行T1050が抽出される。このアクセスログの操作日時は「2015年4月10日の9時15分0秒」であり、T1の15分前にあたる。つまり、活性期間は「30分」から「15分」に一時的に変更される。T1097とT1098のアクセスログは変更された活性期間には含まれないため、R1がそれぞれ「33」、「60」と実施例１と比べて小さい値となり、結果としてRxから「関連なし」と判定される。上記の例で示した追加分のアクセスログの関連度計算結果T1200は図27に示すとおりである。
【０１５５】
なお、上記では、実施例１に適用する例を示したが、実施例２への適用も可能である。その場合には、アクセスログT1000を参照してインシデント表示のアクセスログを検索/活用する点は同様で、ログLOGSがその他の運用操作ログT500（例：ジョブ実行ログT1500）も対象となる点が異なる。
【０１５６】
以上のようにして、関連運用操作ログ自動抽出部32は、実施例１における関連度計算方法に加えて、稼働データのアクセスログ中に含まれるインシデント表示のアクセスログを活用して関連度を計算する。これにより、第1〜2の実施例に比べて、より高い精度で時刻に基づく関連抽出を行える。
【実施例４】
【０１５７】
実施例４では、関連度計算方法のバリエーションとして、運用管理者によって入力あるいはプログラムによって自動生成された運用操作のパターン情報を入力として関連度を補正する例を示す。
【０１５８】
実施例４によれば、運用管理者の手作業によって関連有無を判別した入力情報を関連度計算にフィードバックできる。さらに、機械的な運用操作ログの分析結果に基づいて関連度を補正できる。
【０１５９】
図28に、実施例４で想定するコンピュータシステムを模式的に示す。コンピュータシステムの構成は、実施例２と概ね同様である。運用操作のパターン情報、そのパターン情報を活用して関連度を補正する処理部分、操作パターン生成する処理部分が追加されている点が異なる。以降では異なる部分についてのみ説明し、実施例２と同様の部分についての説明は省略する。
【０１６０】
管理DB4上に追加されている操作パターン情報T1700は、運用管理者による入力、あるいはプログラムによって自動生成された運用操作のパターン情報である。本実施例では、操作パターン情報T1700は、データ管理部31を介して入出力される。
【０１６１】
図29は、実施例４における操作パターン情報T1700の例を示す図である。
【０１６２】
列T1701のパターンIDはこの操作パターンを一意に識別するための情報であり、システムによって自動的に採番される。列T1702のシステム名は、この操作パターンの対象となるシステム名である。列T1703の操作区分は、この操作パターンがインシデントに関係のある操作かどうかを識別した情報であり、インシデントに関係ない日々の運用作業の一部の場合には「日々運用」が、インシデント対応作業の一部の場合には「インシデント対応」が設定される。列T1704の操作パターンの内容は、運用操作のパターンを表現するために、一つ以上の一連の運用操作ログを記載される。この例では、大カッコで囲んだ情報が一つの運用操作ログを示し、矢印がその順番を示す。なお、操作パターンの内容中の運用操作ログは先に述べた運用操作ログT900の各行に対する完全/部分一致条件をキー＝値の形式で記載されている。部分一致条件を記載するために一部の情報は抽象化されている。列T1705の関連度補正係数は、この操作パターンにマッチングした運用操作ログの関連度の値に対する補正係数である。
【０１６３】
ここで、具体例をあげて説明すると、行T1701は、システムservice1のひとつの日々運用作業のパターン（パターンID 1）を示す。操作パターンの内容では、稼働データ表示において、インスタンスdbserver1の稼働データ種別OSのディスク利用容量と、インスタンスcmdserver1の 稼働データ種別OSのCPU利用率の前日分の稼働データを順番に閲覧したパターンを示す。ここで、検索時刻条件の「前日」は、運用操作ログT900の具体的な日付に対して抽象化された情報である。
【０１６４】
行T1702は、システムservice1のひとつのインシデント対応の操作パターン（パターンID 10）を表す。操作パターンの内容では、リモート操作端末を介したコマンド操作で、APサーバのAPサーバ設定ファイルを編集し、設定ファイルの同時接続数を確認した操作パターンを表す。ここで、対象インスタンス名の「APサーバ」は、運用操作ログT900の具体的なインスタンス名に対して、インスタンス情報T600の役割T603で抽象化された情報である。
実施例４の関連度運用操作ログ抽出部32は、新たに追加された操作パターン情報に基づいて関連度を補正するプログラムである操作パターンに基づく関連度補正部326を用いて関連度計算の中でトータルの関連度の補正を行う。
【０１６５】
図30に実施例４におけるトータルの関連度Rxの計算処理の詳細フローチャートの中で操作パターンに基づいて関連度を補正する例を示す。この処理は操作パターン情報に基づく関連度補正部分（図中点線内）を除いて、図18に示したトータルの関連度Rxの計算処理と同様である。ここでは差分のみを説明する。
【０１６６】
S503を行った後で、関連度運用操作ログ抽出部32の操作パターンに基づく関連度補正部326は、データ管理部31を介して、管理DB 4上からINCのシステムに関連する操作パターン情報T1700をすべて取得する（S801）。続いて、LOGSに対して、S801で取得した操作パターン情報T1700のパターンマッチングを行う（S802）。マッチングは、例えば、同一セッション上での運用操作ログとパターンを比較することに寄って行う。そして、マッチングしたパターンのうち、LOGを含むパターンの関連度補正係数を用いて関連度Rxを補正する（S804）。ここでもし関連度が1〜100の範囲を超えた場合にはそれぞれ下限値/上限値に修正する。その後は、図18に示したトータルの関連度Rxの関連度判定と管理DB 4へ結果を格納する。
【０１６７】
上記をインシデントID 1のインシデントT200の場合を具体例に説明すると、例えば、パターンID 1とパターンID 10の操作パターン情報T1700が取得される。これに対して、LOGSに対するパターンマッチを行うと、実施例３で追加したアクセスログT1097とT1098がパターンID 1の操作パターンにマッチする。そのため、本パターンにおける関連度補正係数T1705を用いて関連度を補正する。ここまでの関連度が実施例３ではなく、実施例１に記載の方法で計算されていたとすると、トータルの関連度はそれぞれ「90×補正係数0.1＝9」、「79×補正係数≒8」となる。アクセスログT1097とT1098の操作が日々運用作業であり、そのパターンが登録されていれば、実施例３の方法を用いなくても、関連ありと誤判定されなくなる。また、図22に記載のコマンド操作ログT1400のT1453とT1454はパターンID 10の操作パターンにマッチする。このパターンの
本パターンにおける関連度補正係数T1705を用いて関連度を補正すると、「77×補正係数1.2＝92」となる。インシデント対応のパターンを登録することでその運用操作ログの関連度を強くできるため、この例のように関連判定しきい値に近い部分にある運用操作ログの関連度抽出精度を上げられる。
【０１６８】
操作パターン情報T1700の生成方法としては、運用管理者がデータ管理部31を介してすべての情報を手動登録する方法、あるいは生成済みの情報の一部を手動更新する方法、運用管理者がインシデントに関連する運用操作ログ表示画面から関連が無い不要なログを除外選択した結果を記録しその選択情報からプログラムが自動生成する方法、プログラムが運用操作ログと計算済みの関連度計算結果から自動生成する方法が考えられる。
【０１６９】
ここでは、操作パターン情報T1700を自動生成する方法の一例として、実施例４の関連度運用操作ログ抽出部32に、新たに追加された操作パターンを自動生成するプログラムである操作パターン自動生成部325によって、運用操作ログと計算済みの関連度計算結果から運用操作パターンを自動生成する処理を示す。図31はその処理フローチャートの一例である。
操作パターン自動生成部325は、データ管理部31を介して、管理DB 4上からすべての運用操作ログT900と関連度計算結果T1200を取得する（S901）。そして、関連度計算結果T1200を用いて、取得した運用操作ログT900を「関連あり」と判定されたログの集合R_LOGSと、「関連なし」と判定されたログの集合NR_LOGSに分ける（S902）。 
以降では、インシデントに関連があると判定されたR_LOGは「インシデント対応」に関する運用操作であり、関連が無いと判定されたNR_LOGは「日々運用」に関する運用操作であると見なして「インシデント対応」と「日々運用」の操作パターンを抽出生成する。
【０１７０】
まず、インシデント対応の操作パターン抽出・生成の処理を行う。操作パターン自動生成部325は、R_LOGSとその関連度計算結果T1200から、R_LOGSを操作順のかたまり毎に分ける（S903）。その分け方としては、例えば、インシデントID, インシデント対応ID, セッション情報, 操作した運用担当者の組合せごとにグルーピングする等が考えられる。以下、操作順のかたまりを操作シーケンスと呼び、抽出された操作シーケンスの集合をOPS＿SETと呼ぶ。
【０１７１】
次に、操作パターン自動生成部325は、S903で抽出されたOPS＿SET中の操作シーケンス同士をログの内容の一部を具体的な情報から抽象化情報に変換（例えば、絶対時刻を相対的な時刻（前日、翌日等）に変換、インスタンス名を役割に変換、等）した上で比較することによって共通操作を抽出する（S904）。
【０１７２】
さらに、操作パターン自動生成部325は、S904で抽出された共通操作の内容とその出現回数を用いて、操作区分「インシデント対応」の操作パターン情報T1700を生成して、データ管理部31を介して、管理DB 4に登録する。例えば、図22に記載のコマンド操作ログT1400のT1453〜T1454とT1455〜1456から共通操作を抽出すると、図29のパターンID 10の操作パターンの内容と同様になる。出現回数が2回で1回ごとに0.1係数を補正したとすると、関連度補正係数は「1.2」となる。このような処理により、パターンID 10と同様な操作パターン情報T1700を生成することができる。
【０１７３】
このようにして、インシデント対応の操作パターン抽出・生成の処理を行う。
【０１７４】
以降の処理S906〜S908では、NR_LOGSを用いて日々運用の操作パターン抽出・生成の処理を行う。処理は概ね前述のS903〜S905と同様である。ただし、S907の操作シーケンス生成においては、分け方にインシデントIDとインシデント対応IDを用いない（用いることができない）点は異なる。
【０１７５】
以上で述べた操作パターン自動生成方法は単純な一例である。そのため、他の一般的なパターンマッチ手法などを用いても構わない。
【０１７６】
実施例４によって、運用管理者の手作業や機械的な運用操作ログの分析に基づく操作パターンに基づいて関連度を補正することで、さらに関連抽出の精度を上げられる。
【０１７７】
本発明の実施例では、発明を実施するための最良の形態として、システム運用監視業務におけるインシデント管理を例に説明した。しかし、本発明の実施例はコールセンターやカスタマサポート等のヘルプデスク業務におけるインシデント対応管理においても適用可能である。
以上、本発明の実施例について図面を参照して詳述してきたが、具体的な構成はこの実施例に限られるものではなく、この発明の要旨を逸脱しない範囲の設計なども含まれる。
【符号の説明】
【０１７８】
1…管理ネットワーク、2…物理的な通信回線、3…統合監視サーバ、100…I/F、101…プロセッサ、102…メモリ、103…データバス、31…データ管理部、310…データ収集部、311…データ登録部、312…データ表示部、32…関連運用操作ログ抽出部、320…関連度計算部、321…時刻に基づく関連度計算部、322…システム構成に基づく関連度計算部 、323…運用管理者に基づく関連度計算部、324…トータルの関連度計算部、325…操作パターン自動生成部、326…操作パターンに基づく関連度補正部、327…関連度出力部、4…管理DB、5…操作端末、51…Webブラウザ、6…管理対象システム、61…VMM、62…サーバ（VM/PM）、63…OS、64…ミドルウェア、65…アプリケーション、66…監視エージェント、67…ロードバランサ、7…リモート操作端末、71…リモート操作ツール、8…ジョブ管理サーバ、81…ジョブ管理ツール、9  …VMM管理サーバ、91…VMM管理ツール、T100…稼働データ 、T200…インシデント情報、T300…インシデント、T400…インシデント対応履歴 、T500…システム構成情報、T600…インスタンス情報、T700…システム依存関係、T800…運用管理者情報、T900…運用操作ログ、T1000…稼働データアクセスログ、T1100…関連度計算ルール、T1200…関連度計算結果、T1300…運用操作ログ設定 、T1400…コマンド操作ログ、T1500…ジョブ実行ログ、T1600…VMMイベント操作ログ、T1700…操作パターン情報
【図１】
0006517677.tif 000007
【図２】
0006517677.tif 000008
【図３】
0006517677.tif 000009
【図４】
0006517677.tif 000010
【図５】
0006517677.tif 000011
【図６】
0006517677.tif 000012
【図７】
0006517677.tif 000013
【図８】
0006517677.tif 000014
【図９（ａ）】
0006517677.tif 000015
【図９（ｂ）】
0006517677.tif 000016
【図１０】
0006517677.tif 000017
【図１１】
0006517677.tif 000018
【図１２】
0006517677.tif 000019
【図１３】
0006517677.tif 000020
【図１４】
0006517677.tif 000021
【図１５】
0006517677.tif 000022
【図１６】
0006517677.tif 000023
【図１７】
0006517677.tif 000024
【図１８】
0006517677.tif 000025
【図１９】
0006517677.tif 000026
【図２０】
0006517677.tif 000027
【図２１】
0006517677.tif 000028
【図２２】
0006517677.tif 000029
【図２３】
0006517677.tif 000030
【図２４】
0006517677.tif 000031
【図２５】
0006517677.tif 000032
【図２６】
0006517677.tif 000033
【図２７】
0006517677.tif 000034
【図２８】
0006517677.tif 000035
【図２９】
0006517677.tif 000036
【図３０】
0006517677.tif 000037
【図３１】
0006517677.tif 000038