JP6561212B2 - 問合せ対応システム及び方法 - Google Patents

Description

本発明は、概して、問合せに対する対応に関し、典型的には、障害に関する問合せに対する対応に関する。

例えば、特許文献１には、複数のアプリケーションのログを解析して異常事象を検知する技術が開示されている。

特開2016-24786号公報

ところで、一般に、開発チームが、サービスシステムの開発過程において、サービスシステムの構成変更（例えばソースコードの書き換え）を行い、構成変更後のサービスシステムをビルドし、ビルドされたサービスシステムの稼働をテストする。なお、本明細書では、「チーム」は、メンバが１人であっても複数人であってもよい。つまり、個人単独での開発であっても複数人共同での開発であっても、便宜上、開発の主体は「チーム」である。また、「サービスシステム」は、開発対象の総称である。サービスシステムは、典型的には、ソフトウェア（コンピュータプログラム）でよく、その一例としては、アプリケーションプログラム（例えばウェブサービスを提供するアプリケーションプログラム）又はミドルウェアでよい。

開発過程において、少なくとも障害が発生した場合にログメッセージが出力され蓄積される。開発過程においてログメッセージが出力されるケースは、典型的には、以下の３種類である。
（１）正常ケース（正しい値に対して処理がされた。）
（２）正常ケース（異常値に対して異常が通知されるという正常の処理がされた。）
（３）異常ケース（予期しない値によって処理が異常終了した。）

一方、サービスシステムの運用過程（例えば、利用者（エンドユーザ）によりサービスシステムが利用されている間）においても、少なくとも障害が発生した場合にログメッセージが出力される。

特許文献１に開示の技術を利用すれば、運用チーム（例えば、運用者又は利用者）がログメッセージを解析することで障害を検知することが期待できる。

しかし、通常、ログメッセージからは、障害の対処方法はわからない。

DevOpsという方法論、すなわち、開発チーム（例えば開発担当者）と運用チーム（例えば運用担当者）が連携して協力する開発及び運用の方法論が知られている。この手法によれば、運用過程でのログメッセージを開発過程において利用することが考えられる。しかし、運用過程において発生した障害の対処方法を知ることはできない。

この種の問題は、開発チーム及び運用チームのように異種の複数のチームが存在する環境に限らず、同種の複数のチームが存在する環境（例えば、複数の開発チームが１つのサービスシステムを開発する環境）においてもあり得る。

管理システムが、開発対象プログラムについて第１チームに関する処理により出力されたログ情報及びイシュー情報を管理する第１システムから抽出されたログチャンクとイシューチャンクとが紐付いた管理情報を構築する。管理システムは、問題に関する１以上のログメッセージである指定ログメッセージ群が関連付いた問合せを、サービスシステムについて第２チームに関するシステムである第２システムから受信した場合、指定ログメッセージ群を用いたログパターンマッチングにより、指定ログメッセージ群に適合するログメッセージ群を管理情報から検索する。管理システムは、見つかったログメッセージ群に対応した対処方法情報が表す対処方法を含んだ応答を第２システムに表示する。

異なるチームについて発生した問題に対する対応を特定することができる。

実施例に係る計算機システムの構成を示す。 管理システムの構成を示す。 サーバの構成を示す。 本実施例の概要を示す。 ログ管理テーブルの構成を示す。 イシュー管理テーブルの構成を示す。 ログイシュー管理テーブルの構成を示す。 辞書管理テーブルの構成を示す。 クエリ管理テーブルの構成を示す。 ログ格納処理の流れを示す。 紐付け処理の流れを示す。 クエリ処理の流れを示す。 一致が得られた場合の結果画面の一例を示す。 一致が得られなかった場合の結果画面の一例を示す。

発明を実行するための形態

以下、図面を参照して、異種の複数のチームが存在する環境に適用された本発明の一実施例を説明する。以下の実施例では、異種の複数のチームは、開発チームと運用チームである。なお、本発明は、そのような環境に加えて、同種の複数のチームが存在する環境にも適用である。

以下の説明では、「インタフェース部」は、１以上のインタフェースを含む。１以上のインタフェースは、１以上の同種のインタフェースデバイス（例えば１以上のＮＩＣ（Network Interface Card））であってもよいし２以上の異種のインタフェースデバイス（例えばＮＩＣとＨＢＡ（Host Bus Adapter））であってもよい。

また、以下の説明では、「記憶部」は、１以上のメモリを含む。少なくとも１つのメモリは、揮発性メモリであってもよいし不揮発性メモリであってもよい。記憶部は、１以上のメモリに加えて、１以上のＰＤＥＶを含んでもよい。「ＰＤＥＶ」は、物理的な記憶デバイスを意味し、典型的には、不揮発性の記憶デバイス（例えば補助記憶デバイス）でよい。ＰＤＥＶは、例えば、ＨＤＤ（Hard Disk Drive）又はＳＳＤ（Solid State Drive)でよい。

また、以下の説明では、「プロセッサ部」は、１以上のプロセッサを含む。少なくとも１つのプロセッサは、典型的には、ＣＰＵ（Central Processing Unit）である。プロセッサは、処理の一部または全部を行うハードウェア回路を含んでもよい。

また、以下の説明では、「プログラム」を主語として処理を説明する場合があるが、プログラムは、プロセッサ部によって実行されることで、定められた処理を、適宜に記憶部及びインタフェース部のうちの少なくとも１つを用いながら行うため、処理の主語が、プロセッサ部（或いは、プロセッサ部を有する計算機又は計算機システム）とされてもよい。プログラムは、プログラムソースから計算機にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバ又は計算機が読み取り可能な記憶メディアであってもよい。また、以下の説明において、２以上のプログラムが１つのプログラムとして実現されてもよいし、１つのプログラムが２以上のプログラムとして実現されてもよい。
また、以下の説明では、「ｘｘｘテーブル」といった表現にて情報を説明することがあるが、情報は、どのようなデータ構造で表現されていてもよい。すなわち、情報がデータ構造に依存しないことを示すために、「ｘｘｘテーブル」を「ｘｘｘ情報」と言うことができる。また、以下の説明において、各テーブルの構成は一例であり、１つのテーブルは、２以上のテーブルに分割されてもよいし、２以上のテーブルの全部又は一部が１つのテーブルであってもよい。

また、以下の説明では、「サーバストレージシステム」は、サーバシステム及びストレージシステムのうちの少なくとも１つを含んだシステムである。「サーバシステム」は、１以上の物理的なサーバ（例えばサーバのクラスタ）であってもよいし、少なくとも１つの仮想的なサーバ（例えばＶＭ（Virtual Machine））を含んでもよい。「ストレージシステム」は、１以上の物理的なストレージ装置であってもよいし、少なくとも１つの仮想的なストレージ装置（例えばＳＤＳ（Software Defined Storage））を含んでもよい。

また、以下の説明では、表示用情報を表示する一つ以上の計算機の集合が「管理システム」と呼ばれてよい。管理計算機が管理計算機の表示デバイスに情報を表示する場合は管理計算機が管理システムでよいし、管理計算機と表示用計算機の組み合わせが管理システムでもよい。また、管理処理の高速化や高信頼化のために複数の計算機で管理計算機と同等の処理が実現されてもよく、この場合は、それら複数の計算機（表示を表示用計算機が行う場合は表示用計算機も含め）が管理システムでよい。管理計算機による「表示用情報を表示する」とは、管理計算機が有する表示デバイスに表示用情報を表示することであってもよいし、管理計算機が遠隔の表示用計算機に表示用情報を送信することであってもよい。

また、以下の説明では、同種の要素を区別しないで説明する場合は、その要素の参照符号を使用し、同種の要素を区別して説明する場合は、その要素に割り振られた識別情報を使用することがある。例えば、サーバを特に区別しないで説明する場合には、サーバ１０２と記載し、個々のサーバを区別して説明する場合には、サーバ＃１、サーバ＃２のように記載することがある。

図１は、実施例に係る計算機システムの構成を示す。

計算機システムは、開発プラットフォーム１６０、開発者端末１８０、運用者端末１７０、管理システム１０１及びサーバストレージシステム１００を含む。サーバストレージシステム１００は、複数のサーバ（物理サーバ）１０２を含んだサーバシステムと、複数のＬＵ（Logical Unit）を提供するストレージシステムとを含む。ＬＵは、論理ボリュームと呼ばれてもよい。

開発プラットフォーム１６０は、１以上の計算機であり、サービスシステムの開発のためのプラットフォームである。

開発者端末１８０は、開発者の情報処理端末（例えばパーソナルコンピュータ）である。複数（又は１つ）の開発者端末１８０（開発者）が存在する。開発者は、少なくとも１つの開発チームのメンバである。開発チームは、開発プラットフォーム１６０を利用してサービスシステムを開発するチームである。

運用者端末１７０は、運用者の情報処理端末である。複数（又は１つ）の運用者端末１７０（運用者）が存在する。運用者は、少なくとも１つの運用チームのメンバである。運用チームは、サービスシステムを運用するチームである。運用者は、例えば、サービスシステムの管理者であってもよいし、サービスシステムの利用者であってもよい。

管理システム１０１は、１以上の計算機であり、問合せ対応システムの一例である。管理システム１０１は、ＮＷ−ＳＷ（管理用ネットワークの一例）１０３及びＮＷ−ＳＷ（業務用ネットワークの一例）１０４、の管理インタフェース１１４に接続されている。管理システム１０１は、ＮＷ−ＳＷ１０３及び１０４の各々にＶＬＡＮ（Virtual LAN）を設定することが可能である。「ＮＷ−ＳＷ」は、ネットワークスイッチの略語である。ＮＷ−ＳＷ１０３は、管理システム１０１が複数のサーバ１０２で稼動するＯＳ（Operating System）やアプリケーションの配布や電源制御等の運用管理をするためのネットワークである。ＮＷ−ＳＷ１０４は、サーバ１０２上で実行されるアプリケーションが使用するネットワークである。なお、ＮＷ−ＳＷ１０４は、ＷＡＮ（Wide Area Network）等に接続されてサーバシステムのクライアント計算機と通信を行う。

管理システム１０１は、ＦＣ−ＳＷ（ファイバーチャネル・スイッチ）１０８にも接続される。ＦＣ−ＳＷ５１１は、Ｉ／Ｏ（Input/Output）用ネットワークの一例である。管理システム１０１は、ＦＣ−ＳＷ１０８を介してストレージシステム１０５に接続される。

管理システム１０１は、サーバストレージシステム１００を管理する。管理システム１０１は、制御プログラム１１０を実行し、管理テーブル群１１１を管理する。

サーバストレージシステム１００において、各サーバ１０２は、後述するようにＶＭ（仮想マシン）を実行できる。複数のサーバ１０２は、ＰＣＩｅ（PCI-Express）−ＳＷ１０７と複数のＮＩＣ（Network Interface Card）１１２Ｆを介してＮＷ−ＳＷ１０３に接続され、ＰＣＩｅ−ＳＷ１０７と複数のＮＩＣ１１２Ｆを介して、ＮＷ−ＳＷ１０４に接続され、ＰＣＩｅ（PCI-Express）−ＳＷ１０７と複数のＨＢＡ（Host Bus Adapter）を介して、ＦＣ−ＳＷ１０８に接続される。ＮＩＣ及びＨＢＡは、Ｉ／Ｏデバイスの一例である。

計算機システムにおいて、管理用ネットワーク、業務用ネットワーク及びＩ／Ｏ用ネットワークは一体であってもよい。

図２は、管理システム１０１の構成を示す。

管理システム１０１は、インタフェース部、記憶部及びそれらに接続されたプロセッサ部を有する。インタフェース部は、例えば、ストレージサブシステム１０５へアクセスするためのディスクインタフェース２０３、ＮＷ−ＳＷ１０３及び１０４を介した通信のためのネットワークインタフェース２０４、及び、ＰＣＩｅ−ＳＷ１０７を介した通信のためのＰＣＩｅインタフェース２０５である。プロセッサ部は、例えば、ＣＰＵ２０１である。記憶部は、例えば、メモリ２０２である。メモリ２０２が、制御プログラム１１０、ＯＳ２１６、及び管理テーブル群１１１を記憶する。制御プログラム１１０及びＯＳ２１６がＣＰＵ２０１により実行される。管理テーブル群１１１の少なくとも一部が、メモリ２０２以外の図示しない記憶デバイス、又は、ストレージシステム１０５に格納されてもよい。

管理テーブル群１１１は、１以上のテーブルである。管理テーブル群１１１は、ログ管理テーブル２２１、イシュー管理テーブル２２２、ログイシュー管理テーブル２２３、辞書管理テーブル２２４及びクエリ管理テーブル２２５を含む。ログ管理テーブル２２１、イシュー管理テーブル２２２及びログイシュー管理テーブル２２３が、本実施例で言う「ノウハウＤＢ」を構成する。「ＤＢ」は、データベースの略語である。管理テーブル群１１１に登録されている情報は、管理プログラム１１０により収集された情報（生情報）であってもよいし、その情報の加工後の情報であってもよいし、管理システム１０１の図示しないコンソールからシステム管理者に入力された情報であってもよい。

図３は、サーバ１０２の構成を示す。

サーバ１０２は、ディスクインタフェース３０３、ネットワークインタフェース３０４、ＰＣＩｅインタフェース３０５、メモリ３０２、それらに接続されたＣＰＵ３０１を有する。インタフェース３０３〜３０５は、インタフェース２０３〜２０５とそれぞれ同じ機能を有する。メモリ３０２は、ＯＳ３１６及びハイパバイザ３１５を実行する。ハイパバイザ３１５は、ＶＭ３１４の生成、起動、終了及び削除を制御する。ＶＭ３１４が、業務アプリケーション（プログラム）３４１、ＯＳ（例えばゲストＯＳ）３３１及び監視プログラム３４２を実行する。監視プログラム３４２が、業務アプリ３４１及びＯＳ３３１等の構成要素の状況を監視し、その状況を表すログメッセージを出力する。

例えば、サーバストレージシステム１００は、ＬＰＡＲ（Logical Partitioning）により複数のサブシステムに分割されてよい。それら複数のサブシステムが、開発系としてのサブシステムと、本番系としてのサブシステムとを含んでよい。

開発ＶＭ（開発系に配置されたＶＭ）３１４に、開発プラットフォーム１６０からデプロイされた業務アプリケーションである開発業務アプリケーション３４１が、開発対象のサービスシステムとしてビルドされてよい。開発業務アプリケーション３４１は、テストにおいて、ビルド、起動及び終了等の制御がされる。開発ＶＭ３１４内の監視プログラム３４２が、開発業務アプリケーション３４１の稼働状況に関するログメッセージを、開発プラットフォーム１６０に送信する。開発系からのログメッセージは、開発プラットフォーム１６０に蓄積される。

本番ＶＭ（本番系に配置されたＶＭ）３１４により、運用対象のサービスシステムとしての業務アプリケーションである運用業務アプリケーション３４１が実行されてよい。運用ＶＭ３１４内の監視プログラム３４２が、運用業務アプリケーション３４１の稼働状況に関するログメッセージを、運用者端末１７０（又は、利用者の情報処理端末である利用者端末（図示せず））に送信してよい。

図４は、本実施例の概要を示す。図４において、実線矢印は、開発過程での処理を意味し、破線矢印は、運用過程での処理を意味する。

本実施例では、大きく、開発過程と運用過程とに分かれているが、開発過程の結果を運用過程において利用することができ、運用過程の結果を将来の開発過程（例えばパッチの開発）に利用することができるようになっている。

＜開発過程＞

開発プラットフォーム１６０では、一例として、バージョン管理プログラム４２１、ビルド支援プログラム４２２、テストプログラム４２３及びコードレビュープログラム４２６が、開発プラットフォーム１６０における図示しないプロセッサ部により実行される。また、開発プラットフォーム１６０により、ログＤＢ４２５及びイシューＤＢ４２４が管理される。ログＤＢ４２５及びイシューＤＢ４２４は、開発プラットフォーム１６０にあってもよいし、開発プラットフォーム１６０の外部ストレージにあってもよい。

バージョン管理プログラム４２１は、開発対象であるサービスシステム（例えば業務アプリケーション３４１）のバージョンを管理する。バージョン管理プログラム４２１の一例として、ｇｉｔ、すなわち、プログラムソース等の変更履歴を管理する分散型のバージョン管理システムを採用できる。バージョン管理プログラム４２１は、例えば、誰がいつ新しいコードをコミットしたかを管理する。バージョン管理プログラム４２１に対するコード変更は、例えば、そのプログラム４２１でサポートされているリクエスト、例えば、プッシュを用いて実行される。開発過程では、例えば、以下の処理が実行される。その処理において、適宜、ログメッセージがログＤＢ４２５に格納されたり、イシューメッセージがイシューＤＢに格納されたりする。
（Ｓ１）バージョン管理プログラム４２１に対するコード変更が、プッシュされる。
（Ｓ２）プッシュされたコードに従うプログラム（サービスシステム）がビルドされる。
（Ｓ３）ビルドされたプログラム（サービスシステム）がテストされる。
（Ｓ４）（Ｓ３）の結果がＯＫであれば、マージリクエストが発行（プルリクエスト）される。マージは例えば人手で実行される。
（Ｓ５）マージされたコードが、プッシュされる。マージされたコードについて（Ｓ２）及び（Ｓ３）が実行される。その（Ｓ３）の結果がＯＫであれば、終了する。

ビルド支援プログラム４２２は、バージョン管理プログラム４２１における更新後プログラムコードに従うプログラム（サービスシステム）をビルドしたり、ビルドしたプログラムをサーバストレージシステム１００にデプロイしたり、デプロイしたプログラムのテストをテストプログラム４２３に依頼したりする。ビルド支援プログラム４２２の一例として、Ｊｅｎｋｉｎｓを採用できる。

テストプログラム４２３は、デプロイされたプログラム（業務アプリケーション３４１）をテストする。

コードレビュープログラム４２６は、開発対象のプログラムのコード（例えば、更新前後のコード（更新前後の差分を含む））を開発者端末１８０に表示する。表示対象のコードは、バージョン管理プログラム４２１により管理されているプログラムコードでよい。コードレビュープログラム４２６の一例として、ｇｅｒｒｉｔを採用することができる。

バージョン管理プログラム４２１、ビルド支援プログラム４２２及びテストプログラム４２３のうちの少なくとも１つにより、少なくとも障害が生じた場合にログメッセージが出力され、出力されたログメッセージが、ログＤＢ４２５に格納される。本実施例では、正常か障害かに関わらずテストプログラム４２３によりログメッセージが出力されログＤＢ４２３に格納される。

バージョン管理プログラム４２１、ビルド支援プログラム４２２及びテストプログラム４２３のうちの少なくとも１つにより、何らかのイシューが生じた場合にイシューメッセージが出力され、出力されたイシューメッセージが、イシューＤＢ４２４に格納される。「イシュー」は、障害を意味してもよいし、障害よりも軽い異常を意味してもよい。本実施例では、ビルド支援プログラム４２２及びテストプログラム４２３によりイシューメッセージがイシューＤＢ４２３に格納される。イシューメッセージは、ログメッセージを含む。つまり、障害のようなイシューが生じた場合、ログメッセージに加えて、ログメッセージを含んだイシューメッセージが出力される。

ログメッセージは、事象といった所定の単位で管理される。本実施例では、ログメッセージは、事象毎に管理される。１つの事象に関連付いた１以上のログメッセージを、「ログメッセージ群」と呼ぶことができる。ログメッセージ群を含んだ１つのチャンクを、「ログチャンク」と呼ぶことができる。なお、「事象」とは、本実施例では、テストに相当するが、ビルドやデプロイといったジョブであってもよい。「ジョブ」は、ビルド支援プログラム４２２のようなプログラムの実行単位であってよい。

イシューメッセージは、イシュー毎に管理される。イシューメッセージは、テストやジョブ等においてfailとなった場合に出力される。イシューメッセージは１以上のログメッセージを含む。イシューメッセージを含んだ１つのチャンクを、「イシューチャンク」と呼ぶことができる。イシューチャンクには、イシューに対する対処方法を表す情報が含まれている。

制御プログラム１１０は、ログメッセージを例えばログチャンク単位でログＤＢ４２５から読み出す。また、制御プログラム１１０が、イシューメッセージを例えばイシューチャンク単位でイシューＤＢ４２４から読み出す。制御プログラム１１０は、１つ以上のログチャンク内のログメッセージ群と、１つ以上のイシューチャンク内のログメッセージ群との比較、すなわち、ログパターンマッチングを行う。制御プログラム１１０は、適合したログチャンク及びイシューチャンクを互いに紐付ける。例えば、１つ以上のログチャンク内のログメッセージ群及び１つ以上のイシューチャンク内のログメッセージ群から、それぞれ、grep等により検索キーとなる単語（例えばユニークな単語）が抽出され、抽出された単語が一致した場合に、ログチャンク及びイシューチャンクが互いに紐付けられる。ログチャンクとイシューチャンクの紐付けが、ノウハウＤＢ４３３に格納される。なお、ログチャンクとイシューチャンクの紐付け（ノウハウＤＢ４３３の更新）は、定期的に行われてもよいし、コードのプッシュ（そのプッシュが原因で発生するプルリクエスト）が行われた場合に行われてもよい。

なお、本実施例では、ログチャンクは、事象毎に存在し、イシューチャンクは、イシュー毎に存在する。１つの事象に１以上のイシューが関連していることもあれば、１つのイシューが複数の事象を引き起こすこともある。このため、事象：イシューは、１：１であってもよいし、Ｎ：１であってもよいし、１：Ｍであってもよいし、Ｎ：Ｍであってもよい（Ｎ及びＭは、２以上の整数）。

また、本実施例では、制御プログラム１１０は、読み出されたログチャンク及びイシューチャンクの各々におけるログメッセージのうちノイズに該当するメッセージ項目をマスクするマスク処理を実行する。制御プログラム１１０は、マスク処理後のログメッセージ群を用いてログパターンマッチングを行う。これにより、ログパターンマッチングの精度を高めること、言い換えれば、ログチャンクとイシューチャンクとの紐付けの精度を高めることができる。本実施例において「ノイズ」とは、ログパターンマッチングの精度を低下する原因と定義されたメッセージ項目、言い換えれば、ログパターンマッチングの目的に関与する度合いが低いと定義されたメッセージ項目である。本実施例では、ノイズに該当するメッセージ項目は、環境依存のメッセージ項目である。「環境依存のメッセージ項目」とは、同一のメッセージ項目であっても環境が異なると値が異なるメッセージ項目であって、例えば、ホスト名、ＩＰアドレス及び時刻等がある。制御プログラム１１０は、ログメッセージ中のいずれの項目が環境依存のメッセージ項目であるかを、辞書管理テーブル２２４を参照することにより特定する。なお、本実施例では、マスク処理後のログメッセージは、ログ管理テーブル２２１とイシュー管理テーブル２２２のいずれにも格納されるが、ログ管理テーブル２２１のみに格納されてもよい。その場合、運用過程において、マスク処理が必要なログメッセージが関連付けられたクエリの処理においては、そのログメッセージのマスク処理後のログメッセージ（又はそれのハッシュ値）をキーにログ管理テーブル２２１から検索がされてよい。ヒットしたハッシュ値があれば、そのハッシュ値に対応した事象ＩＤに対応するイシューＩＤをキーに、イシュー管理テーブル２２２から検索がされてよい。一方、マスク処理が不要なログメッセージ（例えばエラーコードのみ）が関連付けられたクエリの処理においては、そのログメッセージ（又はそれのハッシュ値）をキーに、ログ管理テーブル２２１ではなくイシュー管理テーブル２２２から検索がされてよい。

＜運用過程＞

開発が完了しリリースされたプログラム（業務アプリケーション３４１）の運用が開始された以降、その運用において何らかの障害が発生したとする。その場合、制御プログラム１１０は、運用者端末１７０のような外部システムから、発生した障害のログメッセージ群が関連付いたクエリを受信する。外部システムは、運用者端末１７０に代えて又は加えて、障害の根本原因を分析するＲＣＡ（Root Cause Analysis）システムのような分析システムであってもよい。

制御プログラム１１０は、クエリに関連付いているログメッセージ群をキーに、ノウハウＤＢ４３３から、そのログメッセージ群に適合するログメッセージ群を探す。キーにされるログメッセージ群は、辞書管理テーブル２２４を参照することによりログメッセージ群（クエリに関連付いたログメッセージ群）に対してマスク処理が施された後のログメッセージ群である。

制御プログラム１１０は、検索結果に従うクエリ応答を、クエリの発行元（運用者端末１７０のような外部システム）に応答する。

適合するログメッセージ群（完全一致したログメッセージ群、又は、類似度が所定値以上のログメッセージ群）が見つかった場合、クエリ応答には、その適合するログメッセージ群に関連付いている対処方法等の情報が含まれている。運用者は、その対処方法等を基に、発生した障害の対処方法等を知ることができる。

適合するログメッセージ群が見つからなかった場合、運用者端末１７０のような外部システム（又は、制御プログラム１１０）は、クエリに関連付けられたログメッセージ群を所定のシステムに転送する。「所定のシステム」は、開発プラットフォーム１６０であってもよいし、開発プラットフォーム１６０へ情報を転送する中間システムであってもよい。いずれにしても、適合するログメッセージ群が見つからなかった場合、クエリに関連付けられたログメッセージ群が開発プラットフォーム１６０に入力されることになる。この場合、入力されたログメッセージ群と、そのログメッセージ群が開発過程において出力されなかったことを意味する情報とが、コードレビュープログラム４２６により、いずれかの開発者端末１８０に表示される。開発者は、その表示を見て、開発されたプログラム（業務アプリケーション３４１）のパッチを開発する等の対策を講じることができる。

以下、各管理テーブルの構成を説明する。

図５は、ログ管理テーブル２２１の構成を示す。

ログ管理テーブル２２１は、ログメッセージ群の構成及びログメッセージ順序等の情報を保持する。具体的には、ログ管理テーブル２２１は、事象毎にエントリを有する。各エントリに、事象ＩＤ５０１、テナントＩＤ５０２、ハッシュ値５０３、メッセージ群５０４及びメッセージ内容５０５といった情報が保持される。

事象ＩＤ５０１は、事象のＩＤ（識別情報）である。事象ＩＤは、開発プラットフォーム６００内のテストプログラム４２３により割り振られたＩＤであってもよいし、制御プログラム１１０により割り振られたＩＤであってもよい。テナントＩＤ５０２は、テナント（チーム又はチーム内のメンバ）のＩＤである。ハッシュ値５０３は、マスク処理されたログメッセージ群のハッシュ値である。メッセージ群５０４は、ログメッセージ群を構成する１以上のログメッセージにそれぞれ対応した１以上のメッセージＩＤである。メッセージ群５０４において、メッセージＩＤの順序は、ログメッセージ群におけるログメッセージの順序と同じである。メッセージＩＤは、ログメッセージの発生元により割り振られたＩＤであってもよいし、ログメッセージの正規化処理において制御プログラム１１０により割り振られたＩＤであってもよい。メッセージ内容５０５は、ログメッセージ群を構成する１以上のログメッセージ（生データ、又は、生データに対してフォーマット変換等の所定の正規化処理が施されたログメッセージ）と、その１以上のログメッセージにそれぞれ対応した１以上のマスクログメッセージとを含む。「マスクログメッセージ」とは、マスク処理が施されたログメッセージである。

図６は、イシュー管理テーブル２２２の構成を示す。

イシュー管理テーブル２２２は、発生したイシューと対処方法（解決策）とを表す情報を保持する。具体的には、イシュー管理テーブル２２２は、イシュー毎にエントリを有する。各エントリに、イシューＩＤ６０１、対処方法６０２、ハッシュ値６０９、メッセージ群６０３、メッセージ内容６０４、ジョブＩＤ６０５、担当者ＩＤ６０６，時刻６０７及びバグＩＤ６０８といった情報が保持される。

イシューＩＤ６０１は、イシューのＩＤである。イシューＩＤは、開発プラットフォーム６００内のビルド支援プログラム４２やテストプログラム４２３により割り振られたＩＤであってもよいし、制御プログラム１１０により割り振られたＩＤであってもよい。対処方法６０２は、イシューを解決するために施した処置である対処方法を表す。ハッシュ値６０９は、マスク処理されたログメッセージ群のハッシュ値である。メッセージ群６０３は、イシューに伴い発生した１以上のログメッセージにそれぞれ対応した１以上のメッセージＩＤである。メッセージ内容６０４は、メッセージ群６０３における１以上のログメッセージ（生データ、又は、生データに対して正規化処理が施されたログメッセージ）と、その１以上のログメッセージにそれぞれ対応した１以上のマスクログメッセージとを含む。ジョブＩＤ６０５は、イシューが発生した原因となったジョブ（例えば、ビルド支援プログラム４２やテストプログラム４２３の実行単位）のＩＤである。担当者ＩＤ６０６は、ジョブを実行させた開発担当者のＩＤである。時刻６０７は、イシューが発生した時刻を表す。バグＩＤ６０８は、イシューとして発したバグのＩＤである。バグＩＤに、バグの内容（実体）が関連付けられていてよい。

メッセージ内容６０４内のログメッセージと、ログ管理テーブル２２１におけるメッセージ内容５０５内のログメッセージは、同一メッセージであっても、完全には一致しないことがあり得る。具体的には、例えば、イシューＤＢ４２４に格納されるログメッセージには、イシューが発生した契機で人手または簡易自動（例えば、時刻などで機械的に切り取る）で情報が入力されるためである。例えば、ログＤＢ４２５に格納されるログメッセージにはノイズが相対的に少なく（例えばノイズが無く）、イシューＤＢ４２４に格納されるログメッセージにはノイズが相対的に多くてよい。このため、単純に、ログＤＢ４２５内のログメッセージ群とイシューＤＢ４２４内のログメッセージ群とを比較するログパターンマッチングを行っても、適合が得られるべきであっても適合が得られないことがある。本実施例では、上述したマスク処理をログメッセージ群に施した後にログパターンマッチングが行われるため、適合が得られるべきであっても適合が得られないといったことが生じる可能性を軽減できる。

図７は、ログイシュー管理テーブル２２３の構成を示す。

ログイシュー管理テーブル２２３は、ログチャンクとイシューチャンクとの紐付け、すなわち、事象とイシューとの紐付けを表す情報を保持する。具体的には、ログインシュー管理テーブル２２３は、事象毎にエントリを有する。各エントリに、事象ＩＤ７０１及びイシューＩＤ７０２といった情報が保持される。事象ＩＤ７０１は、事象のＩＤである。イシューＩＤ７０２は、イシューのＩＤである。１つのエントリにおいて、１つの事象ＩＤと１つのイシューＩＤ、１つの事象ＩＤとＭ個のイシューＩＤ、Ｎ個の事象ＩＤと１つのイシューＩＤ、又は、Ｎ個の事象ＩＤとＭ個のイシューＩＤが登録される。すなわち、事象ＩＤ：イシューＩＤは、１：１であってもよいし、Ｎ：１であってもよいし、１：Ｍであってもよいし、Ｎ：Ｍであってもよい（Ｎ及びＭは、２以上の整数）。

図８は、辞書管理テーブル２２４の構成を示す。

辞書管理テーブル２２４は、ログメッセージのフォーマットに関する情報や環境依存のメッセージ項目に関する情報（例えば、定型文）を保持する。環境依存のメッセージ項目ではない非環境依存のメッセージ項目は、本実施例では、「特定」のメッセージ項目である。特定のメッセージ項目については、フォーマットが決まっている場合に、そのメッセージ項目の値を使って特徴点を計算することができる。特に、メッセージＩＤを抜き出せれば、メッセージ群５０４及び６０３を容易に作成可能である。

辞書管理テーブル２２４は、メッセージ項目毎にエントリを有する。各エントリには、辞書ＩＤ８０１、テナントＩＤ８０２、分類８０３、項目８０４及び特徴８０５といった情報が保持される。

辞書ＩＤ８０１は、辞書ＩＤ（例えばエントリの通し番号）である。テナントＩＤは、テナントのＩＤである。例えば、項目８０４が同じであってもテナントが異なっていれば特徴８０５（例えば項目のフォーマットや特徴（情報の取り方））が異なっていてもよい。分類８０３は、「環境依存」又は「特定」といったメッセージ項目種別を表す。項目８０４は、メッセージ項目の項目名を表す。特徴８０５は、メッセージ項目８０５のフォーマットや特徴を表す。

図９は、クエリ管理テーブル２２５の構成を示す。

クエリ管理テーブル２２５は、クエリに関する情報を保持する。具体的には、クエリ管理テーブル２２５は、クエリ毎にエントリを有する。各エントリには、クエリＩＤ９０１、テナントＩＤ９０２、処理方式９０３及び曖昧検索９０４といった情報が保持される。

クエリＩＤ９０１は、クエリのＩＤである。テナントＩＤ９０２は、クエリを発行したテナント（例えば、運用者、又は、運用者が属する運用チーム）のＩＤである。処理方式９０３は、クエリ（クエリに関連付いた１以上のログメッセージ）の処理方式（例えば「リアルタイム」又は「バッチ」）を表す。処理方式は、運用者等により手動で指定されてよい。曖昧検索９０４は、曖昧検索の有無を表す。

処理方式「リアルタイム」によれば、クエリに関連付いている１以上のログメッセージで構成されたログメッセージ群をキーとした検索が、クエリに応答してリアルタイムで実行され、検索結果に従うクエリ応答が返される。一方、処理方式「バッチ」によれば、クエリに関連付いている１以上のログメッセージで構成されたログメッセージ群をキーとした検索が、クエリに応答してバッチで実行され、検索結果に従うクエリ応答が返される。クエリに関連付けられるログメッセージ群の量が比較的小さい場合には、処理方式「リアルタイム」が好ましい。クエリに関連付けられるログメッセージ群の量が比較的多い場合やログメッセージ群を並列処理したい場合には、処理方式「バッチ」が好ましい。

曖昧検索「無し」は、完全一致が得られた場合に適合となる。曖昧検索「有り」は、部分一致が得られた場合に適合となる。なお、メッセージ群５０４に含まれるメッセージの１つ１つを完全一致で検索する方法と曖昧検索する方法がある。曖昧検索の場合、メッセージの順序入れ替えやメッセージの欠落が発生した入力に対して、部分一致で結果を返す方法だけでなく、一致度を数値化して検索結果を返す方法でもよい。

以下、開発過程と運用過程とに分けて、本実施例で行われる処理を説明する。

＜開発過程＞

図１０は、ログ格納処理の流れを示す。

ログ格納処理は、ログメッセージ群のハッシュ値をノウハウＤＢに格納する処理である。以下、ログメッセージ群の読出し元を、ログＤＢ４２５とイシューＤＢ４２４とに分けて説明する。ログ格納処理は、ログＤＢ４２５とイシューＤＢ４２４のいずれかに事象単位又はイシュー単位のログメッセージが格納される都度に行われてもよいし、一定時間毎に行われてもよい。

＜＜ログメッセージ群の読出し元がログＤＢ４２５＞＞

制御プログラム１１０は、ログＤＢ４２５からログメッセージをログチャンク単位（事象単位）で読み出しメモリ３０２に格納する（Ｓ１００１）。制御プログラム１１０は、辞書管理テーブル２２４を参照して、読み出されたログメッセージにマスク処理を施す（Ｓ１００２）。具体的には、制御プログラム１１０は、ログメッセージのうち、辞書管理テーブル２２４を基に環境依存のメッセージ項目と特定された項目をマスクする。制御プログラム１１０は、事象に関連付いたマスクログメッセージ群のハッシュ値を算出する。制御プログラム１１０は、下記を、ログ管理テーブル２２１に登録する（Ｓ１００４）。
・事象ＩＤ５０１：事象のＩＤ、
・テナントＩＤ５０２：テナントのＩＤ、
・ハッシュ値５０３：算出されたハッシュ値、
・メッセージ群５０４：事象に関連付いたログメッセージ群を構成する１以上のログメッセージにそれぞれ対応した１以上のメッセージＩＤ、
・メッセージ内容５０５：事象に関連付いたログメッセージ群の内容、及び、事象に関連付いたマスクログメッセージ群の内容。

＜＜ログメッセージ群の読出し元がイシューＤＢ４２４＞＞

制御プログラム１１０は、イシューＤＢ４２４からログメッセージをイシューチャンク単位（イシュー単位）で読み出しメモリ３０２に格納する（Ｓ１００１）。制御プログラム１１０は、辞書管理テーブル２２４を参照して、読み出されたログメッセージにマスク処理を施す（Ｓ１００２）。制御プログラム１１０は、事象に関連付いたマスクログメッセージ群のハッシュ値を算出する。制御プログラム１１０は、下記を、イシュー管理テーブル２２２に登録する（Ｓ１００４）。
・イシューＩＤ６０１：イシューのＩＤ、
・対処方法６０２：対処方法（例えば、イシューチャンクに含まれており開発者等により手動で入力された情報）、
・ハッシュ値６０９：算出されたハッシュ値、
・メッセージ群６０３：イシューに関連付いたログメッセージ群を構成する１以上のログメッセージにそれぞれ対応した１以上のメッセージＩＤ、
・メッセージ内容６０４：イシューに関連付いたログメッセージ群の内容、及び、イシューに関連付いたマスクログメッセージ群の内容、
・ジョブＩＤ６０５：イシューに関連付いたジョブのＩＤ、
・担当者ＩＤ６０６：ジョブを実行させた開発担当者のＩＤ、
・時刻６０７：イシューが発生した時刻（イシューチャンクに含まれている時刻）、
・バグＩＤ６０８：イシューに関連付いているバグのＩＤ。

図１１は、紐付け処理の流れを示す。

紐付け処理は、事象とイシューとの紐付けを行う処理である。紐付け処理は、ログ管理テーブル２２１又はイシュー管理テーブル２２２に情報が追加される都度に行われてもよいし、一定時間毎に行われてもよい。

制御プログラム１１０は、対象イシューＩＤに対応したハッシュ値６０９及びメッセージ群６０３を読み出す（Ｓ１１０１）。「対象イシューＩＤ」とは、所定の条件に該当するイシューのイシューＩＤである。「所定の条件に該当するイシュー」とは、例えば、時刻６０７が所定の時間帯（例えば現在時刻から一定時間過去）に属し、紐付けがされていないイシューである。

制御プログラム１１０は、読み出されたハッシュ値６０９に一致するハッシュ値５０３、又は、読み出されたメッセージ群６０３に完全一致（又は類似度が所定値以上の部分一致）するメッセージ群５０４を探す（Ｓ１１０２）。

制御プログラム１１０は、ハッシュ値５０３又はメッセージ群５０４が見つかった場合、見つかったハッシュ値５０３又はメッセージ群５０４に対応する事象ＩＤと、対象イシューＩＤとを、ログイシュー管理テーブル２２３に登録する。

紐付け処理では、１つのイシューＩＤについて、１又は複数の事象がＳ１１０２の検索範囲とされてもよいし、複数のイシューＩＤについて、１又は複数の事象がＳ１１０２の検索範囲とされてもよい。これにより、ログイシュー管理テーブル２２３に登録される事象ＩＤ及びイシューＩＤが、１：１、Ｎ：１、１：Ｍ又はＮ：Ｍになる。

また、事象について、Ｓ１１０２の検索範囲は、対象イシューＩＤに対応した時刻６０７を基準とした所定の時間帯に属する時刻に発行されたログメッセージを含んだログメッセージ群のみであってもよい。この場合、ログ管理テーブル２２１に、時刻カラムが設けられ、エントリが、時刻の昇順又は降順で並んでいてよい。

＜運用過程＞

図１２は、クエリ処理の流れを示す。クエリ処理は、ログメッセージ群（例えば、発生した障害に対応したログメッセージ群）が関連付けられたクエリを受信した場合に開始される。

制御プログラム１１０は、受信したクエリを解釈し、解釈結果を、クエリ管理テーブル２２５に登録する（Ｓ１２０１）。クエリ管理テーブル２２５には、クエリＩＤ９０１、テナントＩＤ９０２、処理方式９０３及び曖昧検索９０４が登録される。登録される情報９０２〜９０４は、受信したクエリに関連付いている情報である。また、Ｓ１２０１の解釈により、メッセージ群（受信したクエリに関連付いているログメッセージ群の１以上のメッセージＩＤ）が特定される。

制御プログラム１１０は、受信したクエリに対応した処理方式が「リアルタイム」か「バッチ」かを判断する（Ｓ１２０２）。

受信したクエリに対応した処理方式が「リアルタイム」の場合、制御プログラム１１０は、受信したクエリに関連付いているログメッセージ群における各ログメッセージにマスク処理を施す（Ｓ１２０３）。制御プログラム１１０は、そのマスク処理後のログメッセージ群のハッシュ値を算出する（Ｓ１２０４）。制御プログラム１１０は、（ｘ１）算出されたハッシュ値に一致するハッシュ値５０３、（ｘ２）Ｓ１２０１の解釈により特定されたメッセージ群（１以上のメッセージＩＤ）と完全一致する１以上のメッセージ群５０４、及び、（ｘ３）Ｓ１２０１の解釈により特定されたメッセージ群（１以上のメッセージＩＤ）と部分一致（例えば類似度は所定値以上）するメッセージ群５０４、を検索する（Ｓ１２０５）。曖昧検索「無し」の場合、（ｘ３）の検索は実行されない。

（ｘ１）〜（ｘ３）のうちの少なくとも１つが見つかった場合（Ｓ１２０６：Ｙｅｓ）、制御プログラム１１０は、Ｓ１２０７を実行する。すなわち、制御プログラム１１０は、見つかった情報に対応した事象ＩＤに紐付いているイシューＩＤをログイシュー管理テーブル２２３から特定する。制御プログラム１１０は、特定されたイシューＩＤに対応した情報６０１〜６０８のうちの少なくとも対処方法６０３をイシュー管理テーブル２２２から特定し、特定した対処方法６０３等を含んだクエリ応答を、クエリの発行元に返却する。クエリ応答に含まれている情報が、クエリの発行元（例えば運用者端末１７０）に表示される。表示画面の一例を図１３に示す。これにより、クエリの発行元（例えば運用者）が、障害の対処方法を知ることができる。

（ｘ１）〜（ｘ３）のうちのいずれも見つからなかった場合（Ｓ１２０６：Ｎｏ）、制御プログラム１１０は、該当無しを含んだクエリ応答を、クエリの発行元に返却する（Ｓ１２１５）。そのクエリ応答に含まれている情報が、クエリの発行元（例えば運用者端末１７０）に表示される。表示画面の一例を図１４に示す。図４に示したように、運用者（又は、該当無しを検知した制御プログラム１１０）は、クエリに関連付けられているログメッセージ群を所定のシステム（例えばコードレビュープログラム４２６）に転送してよい。そのログメッセージ群は、いずれかの開発者端末１８０を通じて開発者向けに表示される。開発者は、そのログメッセージ群を基に、パッチのような対策を講じることができる。

受信したクエリに対応した処理方式が「バッチ」の場合、制御プログラム１１０は、受信したクエリに関連付いているログメッセージ群を基に障害箇所を特定する（Ｓ１２１１）。制御プログラム１１０は、受信したクエリに関連付いているログメッセージ群である指定ログメッセージ群と、特定された障害箇所に関連するログメッセージ群である関連ログメッセージ群とを特定し、その各ログメッセージ群についてＳ１２１２〜Ｓ１２１４を実行する（ループ（Ａ））。「関連ログメッセージ群」は、例えば、バージョン管理プログラム４２１により管理されているツリー構造の更新履歴を参照することで、特定可能である。すなわち、「関連ログメッセージ群」は、障害ログメッセージ群に対応したノードの上位ノード（例えば親ノード）又は下位ノード（例えば子ノード）に対応したログメッセージ群でよい。

ループ（Ａ）において、各ログメッセージ群について、Ｓ１２１２〜Ｓ１２１４は、Ｓ１２０３〜Ｓ１２０５とそれぞれ同様である。

ループ（Ａ）の終了後、少なくとも１つのログメッセージ群について（ｘ１）〜（ｘ３）の少なくとも１つが見つかった場合、Ｓ１２０７が実行される。ループ（Ａ）の終了後、いずれのログメッセージ群についても（ｘ１）〜（ｘ３）のいずれも見つからなかった場合、Ｓ１２１５が実行される。

本実施例によれば、開発過程において発生した２種類のログ情報（事象に関するログ情報とイシューに関するログ情報）を紐付けたノウハウＤＢ４３３が構築される。これにより、開発過程とは別の運用過程（開発チームとは別種のチームである運用チーム）において障害等の問題が発生しても、その問題に関する情報をキーにノウハウＤＢ４３３を参照することで、運用過程よりも前の開発過程において得られた知識としての対処方法を取得することができる。言い換えれば、その問題が運用過程において初めて発生した問題であったとしても、開発過程において発生した問題であれば、対処方法を知ることができる。

また、一般に、運用者が単にログメッセージ群を見ても障害の対処方法を予測することは困難であるが、本実施例によれば、運用過程で発生したログメッセージ群を関連付けたクエリを出すことによって、そのログメッセージ群のログパターンマッチングが行われ、そのマッチングの結果として、開発過程で得られた対処方法を知ることができる。これにより、ログメッセージ群に基づいて対処方法を知ることは容易である。

また、開発過程と運用過程のように、異種の複数のチーム間では、問題の定義が異なることがある。例えば、開発過程では、コードＫが入力されたらエラーが出力されることが正常であり、運用過程では、コードＫが入力されることによってエラーが出力されることが異常（問題）であることがある（言い換えればコードＫが入力されることが問題）。このように、問題の定義の違いがあっても、上述したログメッセージ群のマッチングの結果として、クエリに対する応答が返されるので、利便性が高い。

そして、ログメッセージ群のマッチングは、マスクログメッセージ群を用いたログパターンマッチングである。すなわち、環境依存のメッセージ項目というノイズがマスクされ、マスクされた後のログメッセージ群を用いてパターンマッチングが行われる。このため、マッチングの精度を高めることができる。

また、本実施例によれば、例えば、アプリケーション開発において、アプリケーションのトラブルシューティングを容易にすることができる。つまり、トラブルシューティングが対処方法として開発過程において準備されていればよい。

また、本実施例によれば、例えば、本番運用時のトラブルシューティングを容易にすることもできる。

以上、一実施例を説明したが、本発明の範囲をその実施例にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実行することが可能である。例えば、以下の少なくとも１つが可能である。

例えば、大規模アプリケーション開発におけるシステムのトラブルシューティングを容易にすることができる。つまり、同種の複数のチームの一例である複数の開発チームでアプリケーションを開発する環境において、いずれかの開発チームで得られた問題とその対処方法を他の開発チームで利用することができる。

また、例えば、ノウハウＤＢ４３３が複数バージョン用意されてよい。それらのバージョンと、バージョン管理プログラム４２１により管理されているバージョンとが紐付けられてよい。バージョン管理プログラム４２１により管理されているバージョンであって指定されたバージョンに紐付いたバージョンのノウハウＤＢが、参照対象のノウハウＤＢであってよい。

１０１：管理システム

Claims (10)

1. 開発対象プログラムであるサービスシステムについて第１チームに関する処理により出力されたログ情報及びイシュー情報を管理するシステムである第１システムと、前記サービスシステムについて第２チームに関するシステムである第２システムとに接続されたインタフェース部と、
   前記インタフェース部に接続されたプロセッサ部と
   を有し、
   前記プロセッサ部が、
   （Ａ）前記第１システムから抽出された１以上のログチャンクと１以上のイシューチャンクとが紐付いた情報である管理情報を構築し、
   ログチャンクは、事象毎の情報であって、事象に関連付いた１以上のログメッセージである事象ログメッセージ群を含み、
   イシューチャンクは、イシュー毎の情報であって、イシューに関連付いた１以上のログメッセージであるイシューログメッセージ群と、そのイシューの対処方法を表す情報である対処方法情報とを含み、
   （Ｂ）問題に関する１以上のログメッセージである指定ログメッセージ群が関連付いた問合せを前記第２システムから受信した場合、前記指定ログメッセージ群を用いたログパターンマッチングにより、前記指定ログメッセージ群に適合するログメッセージ群を前記管理情報から検索し、
   （Ｃ）見つかったログメッセージ群に対応した対処方法情報が表す対処方法を含んだ応答を前記第２システムに表示する、
   問合せ対応システム。
2. 前記管理情報において紐付いている１以上のログチャンクと１以上のイシューチャンクは、その１以上のログチャンク内の１以上の事象ログメッセージ群と、その１以上のイシューチャンク内の１以上のイシューログメッセージ群とのログパターンマッチングの結果として適合が得られたチャンクである、
   請求項１記載の問合せ対応システム。
3. 前記プロセッサ部は、（Ａ）の紐付けのログパターンマッチングと（Ｂ）のログパターンマッチングのいずれも、マスクログメッセージ群のログパターンマッチングであり、
   前記マスクログメッセージ群は、ログメッセージのうち環境依存のメッセージ項目がマスクされたログメッセージ群である、
   請求項２記載の問合せ対応システム。
4. （Ｂ）の検索の結果としてログメッセージ群が見つからなかった場合、前記プロセッサ部は、前記指定ログメッセージ群を前記第１チームに転送することを提示した応答を前記第２システムに表示する、
   請求項１記載の問合せ対応システム。
5. 前記第１チーム及び前記第２チームは、異種のチームである、
   請求項１記載の問合せ対応システム。
6. 前記第１チームは、開発のチームであり、
   前記第２チームは、運用のチームである、
   請求項５記載の問合せ対応システム。
7. 前記第１チーム及び前記第２チームは、同種のチームである、
   請求項１記載の問合せ対応システム。
8. 前記第１チーム及び前記第２チームは、開発のチームである、
   請求項７記載の問合せ対応システム。
9. （Ａ）開発対象プログラムであるサービスシステムについて第１チームに関する処理により出力されたログ情報及びイシュー情報を管理するシステムである第１システムから抽出された１以上のログチャンクと１以上のイシューチャンクとが紐付いた情報である管理情報を構築し、
   ログチャンクは、事象毎の情報であって、事象に関連付いた１以上のログメッセージである事象ログメッセージ群を含み、
   イシューチャンクは、イシュー毎の情報であって、イシューに関連付いた１以上のログメッセージであるイシューログメッセージ群と、そのイシューの対処方法を表す情報である対処方法情報とを含み、
   （Ｂ）問題に関する１以上のログメッセージである指定ログメッセージ群が関連付いた問合せを、前記サービスシステムについて第２チームに関するシステムである第２システムから受信した場合、前記指定ログメッセージ群を用いたログパターンマッチングにより、前記指定ログメッセージ群に適合するログメッセージ群を前記管理情報から検索し、
   （Ｃ）見つかったログメッセージ群に対応した対処方法情報が表す対処方法を含んだ応答を前記第２システムに表示する、
   問合せ対応方法。
10. （Ａ）開発対象プログラムであるサービスシステムについて第１チームに関する処理により出力されたログ情報及びイシュー情報を管理するシステムである第１システムから抽出された１以上のログチャンクと１以上のイシューチャンクとが紐付いた情報である管理情報を構築し、
    ログチャンクは、事象毎の情報であって、事象に関連付いた１以上のログメッセージである事象ログメッセージ群を含み、
    イシューチャンクは、イシュー毎の情報であって、イシューに関連付いた１以上のログメッセージであるイシューログメッセージ群と、そのイシューの対処方法を表す情報である対処方法情報とを含み、
    （Ｂ）問題に関する１以上のログメッセージである指定ログメッセージ群が関連付いた問合せを、前記サービスシステムについて第２チームに関するシステムである第２システムから受信した場合、前記指定ログメッセージ群を用いたログパターンマッチングにより、前記指定ログメッセージ群に適合するログメッセージ群を前記管理情報から検索し、
    （Ｃ）見つかったログメッセージ群に対応した対処方法情報が表す対処方法を含んだ応答を前記第２システムに表示する、
    ことをコンピュータに実行させるコンピュータプログラムを記録したコンピュータ読取り可能な記録媒体。