(57)【要約】【課題】システムでの問題発生に伴うリストア措置に際し、提供機能の縮退率を最小化し、信頼度が高いシステム構成を提供可能とする。【解決手段】バージョン管理システム１００において、所定システムで所定機能を提供する各サービスのバージョン履歴の情報を保持する記憶装置１０１と、前記バージョン履歴の情報に基づき、前記システムのシステム構成として各サービスの各バージョンでの組み合わせパターンのリストを生成する処理と、前記リストが含むパターンのうち、予め定めた必要機能を基準とした機能縮退率が所定レベル以上のパターンを除外する処理と、当該除外を経た前記リストが含むパターンのうち、過去に所定の稼働実績を有するシステム構成との類似性が最高のものを、問題発生時のリストア対象たるシステム構成として特定する処理を実行する演算装置１０４を含む構成とする。
2018109825.tif 000002
【特許請求の範囲】
【請求項１】
所定システムで所定機能を提供する各サービスのバージョン履歴の情報を保持する記憶装置と、
前記バージョン履歴の情報に基づき、前記システムのシステム構成として各サービスの各バージョンでの組み合わせパターンのリストを生成する処理と、前記リストが含むパターンのうち、予め定めた必要機能を基準とした機能縮退率が所定レベル以上のパターンを除外する処理と、当該除外を経た前記リストが含むパターンのうち、過去に所定の稼働実績を有するシステム構成との類似性が所定レベル以上のものを、問題発生時のリストア対象たるシステム構成として特定する処理と、を実行する演算装置と、
を備えることを特徴とするバージョン管理システム。
【請求項２】
前記記憶装置は、
前記システムに関するＡＰＩの所定期間における実行履歴の情報も更に保持するものであり、
前記演算装置は、
前記実行履歴を、ＡＰＩと機能との関係を定めた所定情報に照合して、前記所定期間に実行された機能を特定し、当該特定した機能を、機能とサービスとの関係をバージョンも含めて定めた所定情報に照合して、機能の利用頻度を判定する処理を更に実行し、
前記除外の処理に際し、前記リストが含むパターンのうち、前記利用頻度が所定レベル以上の機能を含まないパターンを除外する処理を更に実行するものである、
ことを特徴とする請求項１に記載のバージョン管理システム。
【請求項３】
前記演算装置は、
前記システムの平均更新間隔と、前記システムを含む所定のシステム群における平均更新間隔とを比較し、前記システムの平均更新間隔が前記システム群の平均更新間隔より短い場合に、前記生成する処理、前記除外する処理、および前記特定する処理、を実行するものである、
ことを特徴とする請求項１に記載のバージョン管理システム。
【請求項４】
所定システムで所定機能を提供する各サービスのバージョン履歴の情報を保持する記憶装置を備えた情報処理システムが、
前記バージョン履歴の情報に基づき、前記システムのシステム構成として各サービスの各バージョンでの組み合わせパターンのリストを生成する処理と、前記リストが含むパターンのうち、予め定めた必要機能を基準とした機能縮退率が所定レベル以上のパターンを除外する処理と、当該除外を経た前記リストが含むパターンのうち、過去に所定の稼働実績を有するシステム構成との類似性が所定レベル以上のものを、問題発生時のリストア対象たるシステム構成として特定する処理と、
を実行することを特徴とするバージョン管理方法。
【請求項５】
前記情報処理システムが、
前記記憶装置において、前記システムに関するＡＰＩの所定期間における実行履歴の情報も更に保持し、
前記実行履歴を、ＡＰＩと機能との関係を定めた所定情報に照合して、前記所定期間に実行された機能を特定し、当該特定した機能を、機能とサービスとの関係をバージョンも含めて定めた所定情報に照合して、機能の利用頻度を判定する処理を更に実行し、
前記除外の処理に際し、前記リストが含むパターンのうち、前記利用頻度が所定レベル以上の機能を含まないパターンを除外する処理を更に実行する、
ことを特徴とする請求項４に記載のバージョン管理方法。
【請求項６】
前記情報処理システムが、
前記システムの平均更新間隔と、前記システムを含む所定のシステム群における平均更新間隔とを比較し、前記システムの平均更新間隔が前記システム群の平均更新間隔より短い場合に、前記生成する処理、前記除外する処理、および前記特定する処理、を実行する、
ことを特徴とする請求項４に記載のバージョン管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、バージョン管理システムおよびバージョン管理方法に関する。
【背景技術】
【０００２】
近年、いわゆるＩｏＴ（Ｉｎｔｅｒｎｅｔ  Ｏｆ  Ｔｈｉｎｇｓ）やＦｉｎｔｅｃｈといった新技術に伴う事業分野が登場し、市場環境の変化が加速している。こうした環境下にあるＩＴ事業者においては、ＤｅｖＯｐｓ等の手法を適宜採用して、システム開発やリリースに伴う工程を迅速化し、対象システムの更新等も多頻度化する傾向にある。【０００３】
このように更新が行われるシステムに関して、問題発生時に適宜に対処して可用性を維持する従来技術として、例えば、アプリケーション毎に、結合するモジュールの情報を管理・更新し、またアプリケーション毎にモジュールの自動切替を行う条件を設定しておき、問題発生時や自動切替時には、この条件に従って、モジュールの切替を行うかどうか判定し、上記モジュール情報から切替えるべきモジュールのバージョンを決定してそのアプリケーションが結合するモジュールバージョンの切替を行うことで、他のアプリケーションへ影響することなく当該アプリケーションの問題を解決し、システムの安定稼働を図るシステム（特許文献１参照）などが提案されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００８−１０８１５５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
従来のシステム開発において、対象システムの更新は年に２回程度で、更新間隔が長いケースが多い。そのため、問題発生に伴い、該当システムを構成するアプリケーションやミドルウェアを、稼働実績のある以前の状態（バージョン）に戻す（リストア）ことで、当該問題に対処してシステム稼働を継続することができた。例えば、或るシステムを構成するアプリケーションに、過去９０日間稼働していたバージョンＡと過去３０日間稼働していたバージョンＢとがあった場合、リストア候補としてバージョンＡを選択する。【０００６】
ところが、上述したＤｅｖＯｐｓ等の採用によって開発、リリースが迅速化され、対象システムの更新が１日に１０回以上行われるといった環境に従来手法を適用した場合、問題が生じる。すなわち、稼働実績に基づいてリストア候補を選択し適用したとしても、当該候補の適用後のシステムでは必要な機能を提供出来なくなっているケースもありえる。つまり、提供機能が縮退してしまう恐れがある。【０００７】
そこで本発明の目的は、システムでの問題発生に伴うリストア措置に際し、提供機能の縮退率を最小化し、信頼度が高いシステム構成を提供可能とする技術を提供することにあ
【課題を解決するための手段】
【０００８】
上記課題を解決する本発明のバージョン管理システムは、所定システムで所定機能を提供する各サービスのバージョン履歴の情報を保持する記憶装置と、前記バージョン履歴の情報に基づき、前記システムのシステム構成として各サービスの各バージョンでの組み合わせパターンのリストを生成する処理と、前記リストが含むパターンのうち、予め定めた必要機能を基準とした機能縮退率が所定レベル以上のパターンを除外する処理と、当該除外を経た前記リストが含むパターンのうち、過去に所定の稼働実績を有するシステム構成との類似性が所定レベル以上のものを、問題発生時のリストア対象たるシステム構成として特定する処理と、を実行する演算装置と、を備えることを特徴とする。【０００９】
また、本発明のバージョン管理方法は、所定システムで所定機能を提供する各サービスのバージョン履歴の情報を保持する記憶装置を備えた情報処理システムが、前記バージョン履歴の情報に基づき、前記システムのシステム構成として各サービスの各バージョンでの組み合わせパターンのリストを生成する処理と、前記リストが含むパターンのうち、予め定めた必要機能を基準とした機能縮退率が所定レベル以上のパターンを除外する処理と、当該除外を経た前記リストが含むパターンのうち、過去に所定の稼働実績を有するシステム構成との類似性が所定レベル以上のものを、問題発生時のリストア対象たるシステム構成として特定する処理と、を実行することを特徴とする。
【発明の効果】
【００１０】
本発明によれば、システムでの問題発生に伴うリストア措置に際し、提供機能の縮退率を最小化し、信頼度が高いシステム構成を提供可能となる。
【図面の簡単な説明】
【００１１】
【図１】本実施形態のバージョン管理システムを含むネットワーク構成例を示す図である。
【図２】本実施形態におけるバージョン管理システムのハードウェア構成例を示す図である。
【図３】本実施形態におけるシステム構成情報管理ＤＢの例１を示す図である。
【図４】本実施形態におけるシステム構成情報管理ＤＢの例２を示す図である。
【図５】本実施形態におけるシステム構成情報管理ＤＢの例３を示す図である。
【図６】本実施形態におけるシステム構成情報管理ＤＢの例４を示す図である。
【図７】本実施形態における構成選択ポリシーの例を示す図である。
【図８】本実施形態における画面例を示す図である。
【図９】本実施形態における機能利用頻度情報ＤＢの例１を示す図である。
【図１０】本実施形態における機能利用頻度情報ＤＢの例２を示す図である。
【図１１】本実施形態における問題点管理ＤＢの例を示す図である。
【図１２】本実施形態における稼働実績情報ＤＢの例を示す図である。
【図１３】本実施形態におけるフロー例１を示す図である。
【図１４】本実施形態におけるフロー例２を示す図である。
【図１５】本実施形態におけるフロー例３を示す図である。
【図１６】本実施形態におけるフロー例４を示す図である。
【図１７】本実施形態におけるフロー例５を示す図である。
【図１８】本実施形態におけるフロー例６を示す図である。
【図１９】本実施形態におけるフロー例７を示す図である。
【図２０】本実施形態におけるサービス組み合わせ候補の例を示す図である。
【図２１】本実施形態におけるフロー例８を示す図である。
【発明を実施するための形態】
【００１２】
−−−ネットワーク構成−−−
以下に本発明の実施形態について図面を用いて詳細に説明する。図１は本実施形態のバージョン管理システム１００を含むネットワーク構成例を示す図である。図１に示すバージョン管理システム１００は、開発やリリースの対象となっているシステムでの問題発生に伴うリストア措置に際し、提供機能の縮退率を最小化し、信頼度が高いシステム構成を提供可能とするためのコンピュータシステムである。
【００１３】
こうしたバージョン管理システム１００は、ネットワーク１０を介して、開発環境２００、および本番環境３００とデータ通信可能に結ばれたサーバ装置を想定出来る。勿論、こうした開発環境２００および本番環境３００の少なくともいずれかが、バージョン管理システム１００と一体となった構成としてもよい。
【００１４】
図１で例示するバージョン管理システム１００は、システム構成管理部１１０、システムデプロイ部１１１、システム稼働実績採取部１１２、システム変更検知部１１３、システム構成選択部１１４、機能縮退率算出部１１５、信頼度算出部１１６、および、ポリシー設定部１１７、といった機能を実装している。
【００１５】
また、バージョン管理システム１００は、システム構成情報管理ＤＢ１２５、構成選択ポリシー１２６、機能利用頻度情報ＤＢ１２７、問題点管理ＤＢ１２８、稼働実績情報ＤＢ１２９、およびサービス組み合わせ候補１３０、といったデータ類を保持している。
【００１６】
こうした機能やデータ類の詳細と各間の関係については、以降の説明で具体的に示すものとする。
【００１７】
なお、開発環境２００は、開発対象となるシステムα〜γそれぞれに関して存在する。また、こうした開発環境２００は、既存のシステム開発用ツールが実装されたサーバ装置であり、開発担当者らの所定端末によるアクセス対象となる。開発担当者らによるシステム開発用ツールでの開発業務の成果、すなわち開発内容の情報は、システム開発管理ＤＢ２２５に格納される。
【００１８】
また、本番環境３００は、上述の開発環境２００で開発されたシステムをデプロイし、実際にリリースする環境である。この本番環境３００は、例えば、事業者における業務システムなどである。図１では、「システムα」がデプロイされた本番環境３００の例を示している。また、この「システムα」のシステム構成は、「サービスＡ」、「サービスＢ」、および「サービスＣ」を含んでいる。これらサービスは、それぞれに所定の機能を提供する。
【００１９】
また、上述の本番環境３００は、問題発生検知部３１０を備える。この問題発生検知部３１０は、本番環境３００においてリリースされたシステム（システムα〜γ）で、障害などの問題が発生した際にこれを検知し、バージョン管理システム１００に通知する。問題発生検知部３１０は、既存の障害発生検知ツールを適宜に採用したものである。
【００２０】
−−−ハードウェア構成−−−
また、バージョン管理システム１００のハードウェア構成は図２に例示するものとなる。本実施形態のバージョン管理システム１００は、ハードディスクドライブなど適宜な不揮発性記憶素子で構成される記憶装置１０１、ＲＡＭなど揮発性記憶素子で構成されるメモリ１０３、記憶装置１０１に保持されるプログラム１０２をメモリ１０３に読み出すなどして実行しシステム自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なうＣＰＵ１０４（演算装置）、ネットワーク１０と接続し他装置との通信処理を担う通信装置１０５を備える。
【００２１】
なお、上述の記憶装置１０１は、本実施形態のバージョン管理システムとしての機能１１０〜１１７を実装するプログラム１０２の他、システム構成情報管理ＤＢ１２５（構成所テーブル１２５１、開発情報テーブル１２５２、ＡＰＩ−機能対応テーブル１２５３、機能保持テーブル１２５４を含む）、構成選択ポリシー１２６、機能利用頻度情報ＤＢ１２７（ＡＰＩ実行履歴情報１２７１、機能利用頻度情報１２７２含む）、問題点管理ＤＢ１２８、および、稼働実績情報ＤＢ１２９、を少なくとも格納している。また、メモリ１０３には、所定の処理に伴い、サービス組み合わせ候補１３０が格納される。これらの機能１１０〜１１７、および、データ構成についての詳細は後述する。
【００２２】
−−−データ構成例−−−
続いて、本実施形態のバージョン管理システム１００が用いるデータベース類について説明する。
【００２３】
図３に本実施形態におけるシステム構成管理情報ＤＢ１２５が含むテーブルの一例であり、構成情報テーブル１２５１の例を示す。この構成情報テーブル１２５１は、上述の「システムα」のシステム構成に関する情報を格納したテーブルである。
【００２４】
そのデータ構造は、作成日時１５００をキーとして、削除日時１５０１、更新日時１５０２、サービス名１５０３、バージョン１５０４、および、更新履歴１５０５、といったデータから成るレコードの集合体である。ここで例示するように、開発、リリースの対象となるシステムは、所定の機能を提供可能な複数のサービスから構成される。また、各サービスは、更新毎にバージョン管理がされている。
【００２５】
図４に、本実施形態におけるシステム構成管理情報ＤＢ１２５が含むテーブルの一例であり、開発情報テーブル１２５２の例を示す。この開発情報テーブル１２５２は、上述の「システムα」を構成する各サービスの開発履歴を格納したテーブルである。
【００２６】
そのデータ構造は、作成日時１６００をキーとして、サービス名１６０１、および、そのバージョン１６０２といったデータから成るレコードの集合体である。図４の例において、例えば「サービスＡ」は、「２０１２／５／１２  １０：００：００」にバージョン「１．０．０」が作成された後、「２０１２／５／１４  １５：００：００」にバージョン「１．１．０」に更新され、また、「２０１２／８／１５  ０５：００：００」にバージョン「１．２．０」に更新されていることがわかる。
【００２７】
図５に、本実施形態におけるシステム構成管理情報ＤＢ１２５が含むテーブルの一例であり、ＡＰＩ−機能対応テーブル１２５３の例を示す。このＡＰＩ−機能対応テーブル１２５３は、当該システム（システムαなど）が外部に提供するＡＰＩと、このＡＰＩに対応する機能と、この機能を提供するサービスとの対応関係を定めたテーブルである。
【００２８】
そのデータ構造は、作成日時１８００をキーとして、ＡＰＩ名１８０１、機能名１８０２、および提供元サービス１８０３、といったデータから成るレコードの集合体である。
【００２９】
図６に、本実施形態におけるシステム構成管理情報ＤＢ１２５が含むテーブルの一例であり、機能保持テーブル１２５４の例を示す。この機能保持テーブル１２５４は、上述の「システムα」で提供する各機能の更新履歴を格納したテーブルである。
【００３０】
そのデータ構造は、作成日時２０００をキーとして、機能名２００１、提供元サービス２００２、そのバージョン２００３、といったデータから成るレコードの集合体である。図６の例において、例えば「機能Ａ」は、「サービスＡ」により提供され、「２０１２／５／１２  １０：００：００」にバージョン「１．０．０」が作成された後、「２０１２／５／１４  １５：００：００」にバージョン「１．１．０」に更新され、また、「２０１２／８／１５  ０５：００：００」にバージョン「１．２．０」に更新されていることがわかる。
【００３１】
図７に、本実施形態における構成選択ポリシー１２６の一例を示す。この構成選択ポリシー１２６は、例えばシステム障害発生時に、該当システムの本番環境３００にデプロイするシステム構成、すなわちリストア対象のシステム構成として開発担当者らが望む内容を格納したテーブルである。
【００３２】
そのデータ構造は、優先順位１１００をキーとして、適用対象１１０１、および構成選択ポリシー１１０２、といったデータから成るレコードの集合体である。また、この構成選択ポリシー１２６に設定する値を、上述の開発担当者の端末等から受け付けるための画面１０００の例を、図８に示す。
【００３３】
この画面１０００は、図７の構成選択ポリシー１２６のうち、優先順位「００２」の内容を、開発担当者が設定する際の画面となる。画面１０００は、適用対象１１０１に設定する値を受け付けるインターフェイスたる対象システム１００１、構成選択ポリシー１１０２に設定する値を受け付けるインターフェイスたる構成選択ポリシー１００２、サンプリング期間１００３、選択条件１００４、を含んでいる。開発担当者は、この画面１０００で必要な情報を入力し、ＯＫボタン１００５を押下して、入力内容をバージョン管理システム１００に通知する。キャンセルボタン１００６が押下されると、入力内容はクリアされ、バージョン管理システム１００への通知は実行されない。
【００３４】
図９に、本実施形態における機能利用頻度情報ＤＢ１２７が含むテーブルの一例であり、ＡＰＩ実行履歴情報１２７１の例を示す。このＡＰＩ実行履歴情報１２７１は、上述の「システムα」におけるＡＰＩの実行履歴を格納したテーブルである。
【００３５】
そのデータ構造は、開始日時１３００をキーとして、終了日時１３０１、ＡＰＩ名１３０２、提供サービス名１３０３、および、バージョン１３０４、といったデータから成るレコードの集合体である。
【００３６】
図１０に、本実施形態における機能利用頻度情報ＤＢ１２７が含むテーブルの一例であり、機能利用頻度情報１２７２の例を示す。この機能利用頻度情報１２７２は、上述の「システムα」にて一定期間中に各機能が利用された割合の情報を格納したテーブルである。
【００３７】
そのデータ構造は、機能名１９００をキーとして、提供元サービス１９０１、および、実行割合１９０２、といったデータから成るレコードの集合体である。
【００３８】
図１１に、本実施形態における問題点管理ＤＢ１２８の一例を示す。この問題点管理ＤＢ１２８は、本番環境３００の問題発生検知部３１０により「システムα」に関して通知された、問題発生内容の情報を格納したデータベースである。
【００３９】
そのデータ構造は、発生日時１４００をキーとして、発生サービス名１４０１、派生バージョン１４０２、現象１４０３、および、影響ランク１４０４、といったデータから成るレコードの集合体である。
【００４０】
図１２に、本実施形態における稼働実績情報ＤＢ１２９の一例を示す。この稼働実績情報ＤＢ１２９は、上述の「システムα」における各バージョン（この場合のバージョンは、システムαのバージョン）の稼働実績を格納したデータベースである。
【００４１】
そのデータ構造は、作成日時１２００をキーとして、更新日時１２０１、バージョン１２０２、および、稼働実績１２０３、といったデータから成るレコードの集合体である。
【００４２】
−−−フロー例１−−−
以下、本実施形態におけるバージョン管理方法の実際手順について図に基づき説明する。以下で説明するバージョン管理方法に対応する各種動作は、バージョン管理システム１００がメモリ１０３に読み出して実行するプログラムによって実現される。そして、これらのプログラムは、以下に説明される各種の動作を行うためのコードから構成されている。
【００４３】
図１３は、本実施形態におけるバージョン管理方法のフロー例１を示す図である。ここではまず、問題発生有無とは無関係の一般的なデプロイ手順について説明する。
【００４４】
バージョン管理システム１００のシステム構成管理部１１０は、例えば、開発環境２００ないし開発担当者の所定端末より、デプロイ対象のシステム（例：システムα）とデプロイ理由を受け付けて、これらを入力としてシステム構成選択部１１４へシステム構成選択要求を発行する（Ｓ２００）。
【００４５】
また、システム構成管理部１１０は、上述のシステム構成選択部１１４から受領したデプロイ構成とデプロイ対象システム（例：本番環境３００のうちシステムα）を入力としてシステムデプロイ部１１１へシステムデプロイ要求を発行する（Ｓ２０１）。
【００４６】
上述の各処理は、一般的なデプロイ手順に沿ったものであり、その詳細は省略する。
【００４７】
−−−フロー例２−−−
次に、上述のフロー例１でシステムデプロイ要求が発行されたシステムデプロイ部１１１での処理について説明する。図１４は本実施形態におけるバージョン管理方法のフロー例２を示す図である。
【００４８】
システムデプロイ要求を受けたシステムデプロイ部１１１は、デプロイ対象システムに対して、上述のシステムデプロイ要求で指定された構成でデプロイを実行し（Ｓ３００）、処理を終了する。
【００４９】
−−−フロー例３−−−
上述のフロー例２のように本番環境３００にデプロイされたシステムに関して、その稼働実績を採取し、管理する処理について説明する。図１５は本実施形態におけるバージョン管理方法のフロー例３を示す図である。なお、本実施形態における稼働実績の例では、対象システムにおけるＣＰＵの稼働時間と、ＡＰＩの実行履歴とを想定する。
【００５０】
バージョン管理システム１００のシステム稼働実績採取部１１２は、本番環境３００における対象システム（例：システムα）からシステムトレース、稼働統計情報、アプリケーションログ等を採取する（Ｓ４００）。こうしたログ類の採取に際しては、システム稼働実績採取部１１２が、該当本番環境３００に対してログの取得要求を送信して採取する場合や、或いは、本番環境３００における稼働監視ロボットから定期的にアップロードされる情報を取得するといった従来手法を適宜に採用すればよい。
【００５１】
また、システム稼働実績採取部１１２は、Ｓ４００で採取した情報から稼働実績情報ＤＢ１２９を更新する（Ｓ４０１）。具体的には、採取した情報が示す対象システムのバージョンをキーに、稼働実績情報ＤＢ１２９で該当バージョンのレコードを特定し、当該レコードの稼働実績１２０２の値に、採取した情報が示す稼働時間を加算する処理となる。
【００５２】
次に、システム稼働実績採取部１１２は、Ｓ４００で採取した情報から機能利用頻度情報ＤＢ１２７のＡＰＩ実行履歴情報１２７１を更新する（Ｓ４０３）。
【００５３】
また、システム稼働実績採取部１１２は、本番環境３００における全システムに関して、上述のＳ４００〜Ｓ４０３の各処理が完了したか判定する（Ｓ４０４）。
【００５４】
上述の判定の結果、完了していないと判定した場合（Ｓ４０４：ＮＯ）、システム稼働実績採取部１１２は、処理をＳ４００に戻す。
【００５５】
他方、上述の判定の結果、完了していると判定した場合（Ｓ４０４：ＹＥＳ）、システム稼働実績採取部１１２は、例えば、システム構成管理部１１０など適宜な機能から終了命令を受信したか判定する（Ｓ４０５）。
【００５６】
上述の判定の結果、終了命令を受信していない場合（Ｓ４０５：ＮＯ）、システム稼働実績採取部１１２は、処理をＳ４００に戻す。
【００５７】
他方、上述の判定の結果、終了命令を受信している場合（Ｓ４０５：ＹＥＳ）、システム稼働実績採取部１１２は、処理を終了する。
【００５８】
−−−フロー例４−−−
次に、上述のように本番環境３００にデプロイされたシステムで、障害等の問題が発生した場合の処理について説明する。図１６は本実施形態におけるバージョン管理方法のフロー例４を示す図である。
【００５９】
この場合、本番環境３００における問題発生検知部３１０は、プロセスやシスログメッセージを監視することで、いずれかのシステム（システムα〜γ）にて障害等の問題発生を検知したか判定する（Ｓ５００）。
【００６０】
上述の判定の結果、問題が発生していない場合（Ｓ５００：ＮＯ）、問題発生検知部３１０は、処理をＳ５０３に遷移させる。
【００６１】
他方、上述の判定の結果、例えば「システムα」で問題が発生している場合（Ｓ５００：ＹＥＳ）、問題発生検知部３１０は、対象システムにおける出力メッセージや生じた現象から問題の発生箇所及び原因を特定し、これら発生した問題と問題の発生箇所（サービス／機能）、発生日時、生じた現象、影響ランク等の情報を問題点管理ＤＢ１２８へ登録する（Ｓ５０１）。
【００６２】
次に、問題発生検知部３１０は、復旧対象システム（例：システムα）とデプロイ理由（例：問題対策）をシステム構成管理部へ通知する（Ｓ５０２）。
【００６３】
また、問題発生検知部３１０は、終了命令を受信したか判定する（Ｓ５０３）。
【００６４】
上述の判定の結果、終了命令を受信していない場合（Ｓ５０３：ＮＯ）、問題発生検知部３１０は、処理をＳ５００に戻す。
【００６５】
他方、上述の判定の結果、終了命令を受信していた場合（Ｓ５０３：ＹＥＳ）、問題発生検知部３１０は、処理を終了する。
【００６６】
−−−フロー例５−−−
次に、問題発生とは無関係に、開発担当者らによりシステム更新がなされた場合の処理について説明する。図１７は本実施形態におけるバージョン管理方法のフロー例５を示す図である。
【００６７】
この場合、バージョン管理システム１００のシステム変更検知部１１３は、開発対象のシステムに変更があるか判定する（Ｓ６００）。この判定は、開発環境２００から開発管理ＤＢ２２５の更新通知を受けた否か、でもって行う判定を想定出来る。
【００６８】
上述の判定の結果、変更がないと判定した場合（Ｓ６００：ＮＯ）、システム変更検知部１１３は、処理をＳ６０３に遷移させる。
【００６９】
他方、上述の判定の結果、判定があると判定した場合（Ｓ６００：ＹＥＳ）、システム変更検知部１１３は、開発管理ＤＢ２２５での更新内容を開発環境２００から取得し、更新された新しいシステム構成と変更内容をシステム構成情報管理ＤＢ１２５へ登録する（Ｓ６０１）。
【００７０】
次に、システム変更検知部１１３は、変更対象システムとデプロイ理由（例：通常更新）をシステム構成管理部１１０へ通知する（Ｓ６０２）。
【００７１】
また、システム変更検知部１１３は、終了命令を受信したか判定する（Ｓ６０３）。
【００７２】
上述の判定の結果、終了命令を受信していない場合（Ｓ６０３：ＮＯ）、システム変更検知部１１３は、処理をＳ６００に戻す。
【００７３】
他方、上述の判定の結果、終了命令を受信している場合（Ｓ６０３：ＹＥＳ）、システム変更検知部１１３は、処理を終了する。
【００７４】
−−−フロー例６−−−
次に、障害等の問題が発生し、デプロイ対象とされた本番環境３００における対象システム（例：システムα）に関し、新たに生成するリストア対象のシステム構成を特定する処理について説明する。図１８は本実施形態におけるバージョン管理方法のフロー例６を示す図である。
【００７５】
この場合、システム構成選択部１１４は、上述のフロー例４（図１６）におけるＳ５０２での通知、およびフロー例５（図１７）におけるＳ６０２での通知、のいずれかを受けて、今次受信した通知が通常更新か問題対策のいずれであるか判定する（Ｓ７００）。
【００７６】
上述の判定の結果、該当通知が「通常更新」、すなわち問題発生に伴うものではない場合（Ｓ７００：通常更新）、システム構成選択部１１４は、システム構成情報管理ＤＢ１２５に登録された、更新後の新しいシステム構成を選択し（Ｓ７０２）、処理をＳ７０７に遷移させる。
【００７７】
他方、上述の判定の結果、該当通知が「問題対策」、すなわち問題発生に伴うものである場合（Ｓ７００：問題対策）、システム構成選択部１１４は、システム構成情報管理ＤＢ１２５の構成情報テーブル１２５１に基づき、「システムα」〜「システムγ」を含む管理対象システム群に関して、全体の平均更新間隔（Ｘ）を算定する（Ｓ７０１）。
【００７８】
具体的には、管理対象システムそれぞれの構成情報テーブル１２５１から、作成日時１５００が所定期間（例：直近の１ヶ月）に属するレコード数（例：１０）を特定し、上述の所定期間を該当レコード数で除算することで、当該管理対象システムにおける該当期間での平均更新間隔を、３０日÷１０＝３日、などと算定する。こうして管理対象システムそれぞれの平均更新間隔を、β＝１０日、γ＝５日、などと算定し、更に、管理対象システムの間での平均更新間隔を、（３＋１０＋５）／３＝６日、などと算定する。
【００７９】
次に、システム構成選択部１１４は、システム構成情報管理ＤＢ１２５の構成情報テーブル１２５１に基づき、問題が発生したシステム（例：システムα）の平均更新間隔（Ｙ）を算定する（Ｓ７０３）。具体的には、管理対象システムたる「システムα」の構成情報テーブル１２５１において、作成日時１５００が所定期間（例：直近の１ヶ月）に属するレコード数（例：１０）を特定し、上述の所定期間を該当レコード数で除算することで、該当期間での平均更新間隔を、３０日÷１０＝３日、などと算定する。
【００８０】
続いて、システム構成選択部１１４は、上述のＳ７０１およびＳ７０３で算定した、平均更新間隔（Ｘ）と（Ｙ）とを比較し、（Ｘ）＞（Ｙ）の関係となっているか判定する（Ｓ７０４）。
【００８１】
上述の判定の結果、（Ｘ）＞（Ｙ）が成立していない場合（Ｓ７０４：ＮＯ）、すなわち、デプロイ対象の「システムα」の更新間隔が、その他のシステムにおける更新間隔以上である場合、システム構成選択部１１４は、デプロイ対象の「システムα」は更新頻度が従来程度のシステムであると判断し、該当システムの稼働実績情報ＤＢ１２９のうち最も稼働実績１２０２の値が大きいバージョンを選択し（Ｓ７０６）、処理をＳ７０７に遷移させる。
【００８２】
他方、上述の判定の結果、（Ｘ）＞（Ｙ）が成立している場合（Ｓ７０４：ＹＥＳ）、すなわち、デプロイ対象の「システムα」の更新間隔が、その他のシステムにおける更新間隔より短い場合、システム構成選択部１１４は、デプロイ対象の「システムα」は更新頻度が従来と異なるＤｅｖＯｐｓ型であると判断し、対象システムを入力として機能縮退率算出部１１５に対して機能縮退率算出要求を発行する（Ｓ７０５）。
【００８３】
次に、システム構成選択部１１４は、システム構成管理部１１０に対してデプロイ構成を返値として返却し（Ｓ７０７）、処理を終了する。ここで返却するデプロイ構成は、機能縮退率算出部１１５が、上述のＳ７０５における機能縮退率算出要求に応じて、生成したシステム構成（リストア対象のシステム構成）である。
【００８４】
−−−フロー例７−−−
次に、問題が発生してデプロイ対象とされたシステムに対し、リストアするシステム構成を生成する処理について説明する。図１９は本実施形態におけるバージョン管理方法のフロー例７を示す図である。
【００８５】
この場合、バージョン管理システム１００の機能縮退率算出部１１５は、構成情報テーブル１２５１（図３）及び開発情報テーブル１２５２（図４）に基づき、上述のデプロイ対象の「システムα」を構成するサービスの情報と、当該サービスのバージョン履歴とを取得し、メモリ１０３上に、「システムα」のシステム構成として選択可能なサービスの各バージョンの組み合わせを示すテーブルである、サービス組み合わせ候補１３０（図２０）を生成する（Ｓ８００）。
【００８６】
また、機能縮退率算出部１１５は、構成選択ポリシー１２６（図７）における構成選択ポリシー１１０２に従って、上述のサービス組み合わせ候補１３０の各レコードに対するフィルタリングを実行する（Ｓ８０１）。
【００８７】
図７の構成選択ポリシー１２６に従ったフィルタリングを行う場合、機能縮退率算出部１１５は、優先順位「００１」のポリシーが示す「問題点管理ＤＢに影響ランクＡＡ以上の現象が登録されているバージョンのサービスを含む構成は除外」との条件に基づき、問題点管理ＤＢ１２８（図１１）を参照し、影響ランクが「ＡＡＡ」であるバージョン「１．２．０」の「サービスＡ」を特定する。そこで機能縮退率算出部１１５は、サービス組み合わせ候補１３０の各レコードのうち、「サービスＡ」のバージョン「１．２．０」を含む構成を特定し、サービス組み合わせ候補１３０から除外する。
【００８８】
また、機能縮退率算出部１１５は、次なる優先順位「００２」のポリシーが示す「過去１ヶ月間の利用頻度上位２０％の機能を含まない構成を除外」との条件に基づき、直近の１ヶ月分のＡＰＩ実行履歴情報１２７１（図９）とＡＰＩ−機能対応テーブル１２５３（図５）を参照し、機能利用頻度情報１２７２（図１０）を作成する。具体的には、機能縮退率算出部１１５は、ＡＰＩ実行履歴情報１２７１における、直近の１ヶ月分のレコードそれぞれのＡＰＩ名１３０２の値をキーにレコード数を集計し、全ＡＰＩ名のレコード数に占める、各ＡＰＩ名のレコード数の割合を、実行割合１９０２の値として算定する。また、機能縮退率算出部１１５は、ＡＰＩ−機能対応テーブル１２５３を検索して、ＡＰＩ名に対応した機能名を特定し、この機能名により、上述で実行割合１９０２の値を算定した該当ＡＰＩ名と置換する。
【００８９】
また、機能縮退率算出部１１５は、機能保持テーブル１２５４（図６）を参照し、上述の機能利用頻度情報１２７２が示す各機能のうち、上位２０％の機能を保持している提供元サービス２００２とそのバージョン２００３の各値を取得する。図１０で例示した機能利用頻度情報１２７２の例では、機能「Ａ」〜「Ｄ」で利用頻度の９９％を占めており、機能「Ｄ」を提供している「サービスＢ」のバージョン「１．１．０」を含まない構成を、サービス組み合わせ候補１３０から除外する。
【００９０】
最後に、機能縮退率算出部１１５は、次なる優先順位「００３」のポリシーが示す「機能Ｅを含まない構成を除外」との条件に基づき、この「機能Ｅ」を含まない構成として「サービスＣ」のバージョン「１．２．０」を含まない構成を、サービス組み合わせ候補１３０から除外する。この除外により、サービス組み合わせ候補１３０のレコードのうち、候補ＩＤ「１６」、「１７」が抽出されることとなる。
【００９１】
次に、機能縮退率算出部１１５は、デプロイ対象の「システムα」と、Ｓ８０１のフィルタリングで抽出したシステム構成の候補とを入力として、信頼度算出部１１６に対して信頼度算出要求を発行する（Ｓ８０２）。
【００９２】
また、機能縮退率算出部１１５は、上述のシステム構成の各候補のうち、Ｓ８０２によって得た信頼度が最も高い候補を選択し、当該候補が示すシステム構成を、デプロイ対象の「システムα」に関して、システム構成情報管理ＤＢ１２５に登録する（Ｓ８０３）。
【００９３】
例えば、信頼度算出部１１６から得た信頼度の情報が、システム構成の候補におけるシステム構成と最も近い構成である、バージョン「１．３．０」（サービスＡ：１．１．０、サービスＢ：１．１．０、サービスＣ：１．１．０）に関する情報であったとする。この場合、機能縮退率算出部１１５は、候補のうち、上述のバージョン「１．３．０」の構成により近い、候補ＩＤ「１７」のシステム構成を、信頼度が最も高いものとして選択する。なお、ここで利用する信頼度は、信頼度算出部１１６が、上述のＳ８０２における信頼度算出要求に応じて算出した情報である。
【００９４】
次に、機能縮退率算出部１１５は、Ｓ８０３で登録したシステム構成を、返値としてシステム構成選択部１１４に返却し（Ｓ８０４）、処理を終了する。この返値の返却に伴い、システム構成選択部１１４は、当該返値をシステム構成管理部１１０にデプロイ構成として返却する。システム構成管理部１１０は、この返値を入力としたデプロイ要求をシステムデプロイ部１１１に発行する。システムデプロイ部１１１は、上述の返値、すなわち機能縮退率算出部１１５が登録したシステム構成を、対策版のシステム構成として、「システムα」の本番環境３００にデプロイすることとなる。
【００９５】
−−−フロー例８−−−
次に、上述のＳ８０２における信頼度算出要求に伴い、信頼度算出部１１６が実行する処理について説明する。図２１は本実施形態におけるバージョン管理方法のフロー例８を示す図である。
【００９６】
この場合、信頼度算出部１１６は、システム構成の各候補（候補ＩＤ「１６」、「１７」）が示すシステム構成と、稼働実績を有するシステム構成（稼働実績情報ＤＢ１２９にレコードが登録済みの構成）とを比較し、各候補のシステム構成に関する信頼度を算出する（Ｓ９０１）。
【００９７】
具体的には、信頼度算出部１１６は、稼働実績情報ＤＢ１２９の各レコードのうち、上述の各候補（候補ＩＤ「１６、「１７」）の各サービスのバージョンを超えないバージョンのみで構成されているレコードのバージョン１２０２における、更新日時１２０１の値を抽出する。
【００９８】
候補ＩＤ「１６」における各サービスのバージョンは、「サービスＡ」：「１．０．０」、「サービスＢ」：「１．１．０」、「サービスＣ」：「１．２．０」、同様に、候補ＩＤ「１７」における各サービスのバージョンは、「サービスＡ」：「１．１．０」、「サービスＢ」：「１．１．０」、「サービスＣ」：「１．２．０」、である。よって、稼働実績情報ＤＢ１２９の各レコードのうち、「サービスＡ」：「１．１．０」、「サービスＢ」：「１．１．０」、「サービスＣ」：「１．２．０」、を超えないバージョンのみで構成されている、バージョン「１．０．０」、「１．１．０」、「１．２．０」、「１．３．０」のレコードから、更新日時１２０１の値を抽出することになる。
【００９９】
図１２の例であれば、バージョン「１．０．０」は更新日時「２０１２  ０５−１３  １０：００：００」、バージョン「１．１．０」は更新日時「２０１２  ０７−２０  １５：００：００」、バージョン「１．２．０」は更新日時「２０１２  ０７−２８  ０５：００：００」、バージョン「１．３．０」は更新日時「２０１２  ０８−１４  １５：００：００」などと抽出出来る。
【０１００】
続いて信頼度算出部１１６は、上述で抽出した更新日時１２０１の値を、開発情報テーブル１２５２に照合し、更新日時１２０１が示す日時より過去の日時で当該更新日時に最も近い日時を作成日時１６００とする各サービスのバージョン１６０２を特定し、「システムα」のバージョン１２０２それぞれにおける、各サービスのバージョンを特定する。
【０１０１】
例えば、「システムα」のバージョン「１．３．０」の更新日時「２０１２  ０８−１４  １５：００：００」を、開発情報テーブル１２５２に照合し、更新日時「２０１２  ０８−１４  １５：００：００」より過去の日時で当該更新日時に最も近い日時を作成日時１６００とする各サービスのバージョン１６０２は、「サービスＡ」の場合はバージョン「１．１．０」、「サービスＢ」の場合はバージョン「１．１．０」、「サービスＣ」の場合はバージョン「１．１．０」、などと特定する。
【０１０２】
次に、信頼度算出部１１６は、上述のように得た、「システムα」のバージョン「１．０．０」〜「１．３．０」のそれぞれにおける各サービスのバージョンと、各候補における各サービスのバージョンとの一致度を信頼度として判定する。例えば、「システムα」のバージョン「１．３．０」の各サービスのバージョン（「サービスＡ」：「１．１．０」、「サービスＢ」：「１．１．０」、「サービスＣ」：「１．１．０」、）と、候補ＩＤ「１６」における各サービスのバージョン「サービスＡ」：「１．０．０」、「サービスＢ」：「１．１．０」、「サービスＣ」：「１．２．０」、とを照合した場合、「サービスＢ」でバージョンが一致しており、信頼度は「１／３」、また同様に、候補ＩＤ「１７」における各サービスのバージョン（「サービスＡ」：「１．１．０」、「サービスＢ」：「１．１．０」、「サービスＣ」：「１．２．０」、）とを照合した場合、「サービスＡ」および「サービスＢ」でバージョンが一致しており、信頼度は「２／３」、などと判定する。信頼度算出部１１６は、このように「システムα」の各バージョンについて、各候補の信頼度を判定する。
【０１０３】
続いて信頼度算出部１１６は、上述のように判定した、「システムα」のバージョン「１．０．０」〜「１．３．０」ごとに、各候補との信頼度を比較し、信頼度が最大のバージョンと、その信頼度の対象となった候補とを特定する。つまり、稼働実績があるシステム構成中で各候補のシステム構成と最も近いものを特定する。上述の例の場合、信頼度が最大のバージョンは「１．３．０」（サービスＡ：１．１．０、サービスＢ：１．１．０、サービスＣ：１．１．０）で、その対象となった候補は「１７」となる。また、その信頼度は「２／３」である。
【０１０４】
また、信頼度算出部１１６は、「システムα」の各バージョン「１．０．０」〜「１．３．０」、すなわち処理対象となる全システム構成に関する信頼度の特定が完了したか判定する（Ｓ９０２）。
【０１０５】
上述の判定の結果、完了していない場合（Ｓ９０２：ＮＯ）、信頼度算出部１１６は、処理をＳ９０１に戻す。
【０１０６】
他方、上述の判定の結果、完了している場合（Ｓ９０２：ＹＥＳ）、信頼度算出部１１６は、機能縮退率算出部１１５に対し、上述のＳ９０１で得た計算結果（最大の信頼度とその候補）を返値として返却し（Ｓ９０３）、処理を終了する。
【０１０７】
本実施形態によれば、対象システムを構成しうるサービスの情報及び各サービスのリリース履歴に基づいてシステム構成を生成し、過去に存在しなかった構成についても障害発生時の対策版候補と出来る。また、機能の縮退率が所定レベル以下となる構成から対策版候補を選択する際、過去の動作実績が実際に存在する構成と類似した、すなわち動作実績の有効性が高い構成を対策版として選定出来る。
【０１０８】
すなわち、システムでの問題発生に伴うリストア措置に際し、提供機能の縮退率を最小化し、信頼度が高いシステム構成を提供可能となる。
【０１０９】
本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態のバージョン管理システムにおいて、前記記憶装置は、前記システムに関するＡＰＩの所定期間における実行履歴の情報も更に保持するものであり、前記演算装置は、前記実行履歴を、ＡＰＩと機能との関係を定めた所定情報に照合して、前記所定期間に実行された機能を特定し、当該特定した機能を、機能とサービスとの関係をバージョンも含めて定めた所定情報に照合して、機能の利用頻度を判定する処理を更に実行し、前記除外の処理に際し、前記リストが含むパターンのうち、前記利用頻度が所定レベル以上の機能を含まないパターンを除外する処理を更に実行するものである、としてもよい。
【０１１０】
これによれば、必須機能として予め指定された機能の他、対象システムにおいて利用頻度が高い機能についても縮退しないよう対応することが出来る。
【０１１１】
また、本実施形態のバージョン管理システムにおいて、前記演算装置は、前記システムの平均更新間隔と、前記システムを含む所定のシステム群における平均更新間隔とを比較し、前記システムの平均更新間隔が前記システム群の平均更新間隔より短い場合に、前記生成する処理、前記除外する処理、および前記特定する処理、を実行するものである、としてもよい。
【０１１２】
これによれば、開発対象のシステムの更新頻度が従来よりも急速に高まっている現状を踏まえ、リストアによる機能縮退を的確に回避することが可能となる。
【０１１３】
また、本実施形態のバージョン管理方法において、前記情報処理システムが、前記記憶装置において、前記システムに関するＡＰＩの所定期間における実行履歴の情報も更に保持し、前記実行履歴を、ＡＰＩと機能との関係を定めた所定情報に照合して、前記所定期間に実行された機能を特定し、当該特定した機能を、機能とサービスとの関係をバージョンも含めて定めた所定情報に照合して、機能の利用頻度を判定する処理を更に実行し、前記除外の処理に際し、前記リストが含むパターンのうち、前記利用頻度が所定レベル以上の機能を含まないパターンを除外する処理を更に実行する、としてもよい。
【０１１４】
また、本実施形態のバージョン管理方法において、前記情報処理システムが、前記システムの平均更新間隔と、前記システムを含む所定のシステム群における平均更新間隔とを比較し、前記システムの平均更新間隔が前記システム群の平均更新間隔より短い場合に、前記生成する処理、前記除外する処理、および前記特定する処理、を実行する、としてもよい。
【符号の説明】
【０１１５】
１０  ネットワーク
１００  バージョン管理システム
１０１  記憶装置
１０２  プログラム
１０３  メモリ
１０４  ＣＰＵ（演算装置）
１０５  通信装置
１１０  システム構成管理部
１１１  システムデプロイ部
１１２  システム稼働実績採取部
１１３  システム変更検知部
１１４  システム構成選択部
１１５  機能縮退率算出部
１１６  信頼度算出部
１１７  ポリシー設定部
１２５  システム構成情報管理ＤＢ
１２５１  構成情報テーブル
１２５２  開発情報テーブル
１２５３  ＡＰＩ−機能対応テーブル
１２５４  機能保持テーブル
１２６  構成選択ポリシー
１２７  機能利用頻度情報ＤＢ
１２８  問題点管理ＤＢ
１２９  稼働実績情報ＤＢ
１３０  サービス組み合わせ候補（リスト）
２００  開発環境
２２５  システム開発管理ＤＢ
３００  本番環境
３１０  問題発生検知部
３２０  サービス
【図１】
2018109825.tif 000003
【図２】
2018109825.tif 000004
【図３】
2018109825.tif 000005
【図４】
2018109825.tif 000006
【図５】
2018109825.tif 000007
【図６】
2018109825.tif 000008
【図７】
2018109825.tif 000009
【図８】
2018109825.tif 000010
【図９】
2018109825.tif 000011
【図１０】
2018109825.tif 000012
【図１１】
2018109825.tif 000013
【図１２】
2018109825.tif 000014
【図１３】
2018109825.tif 000015
【図１４】
2018109825.tif 000016
【図１５】
2018109825.tif 000017
【図１６】
2018109825.tif 000018
【図１７】
2018109825.tif 000019
【図１８】
2018109825.tif 000020
【図１９】
2018109825.tif 000021
【図２０】
2018109825.tif 000022
【図２１】
2018109825.tif 000023
【国際調査報告】
2018109825.tif 000024
2018109825.tif 000025