[go: up one dir, main page]

WO2018109825A1 - バージョン管理システムおよびバージョン管理方法 - Google Patents

バージョン管理システムおよびバージョン管理方法 Download PDF

Info

Publication number
WO2018109825A1
WO2018109825A1 PCT/JP2016/087020 JP2016087020W WO2018109825A1 WO 2018109825 A1 WO2018109825 A1 WO 2018109825A1 JP 2016087020 W JP2016087020 W JP 2016087020W WO 2018109825 A1 WO2018109825 A1 WO 2018109825A1
Authority
WO
WIPO (PCT)
Prior art keywords
function
version
predetermined
information
service
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/JP2016/087020
Other languages
English (en)
French (fr)
Inventor
瑛久 結城
秀一 洪
山田　達也
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to US15/757,089 priority Critical patent/US10747529B2/en
Priority to PCT/JP2016/087020 priority patent/WO2018109825A1/ja
Priority to JP2018507738A priority patent/JP6411696B1/ja
Publication of WO2018109825A1 publication Critical patent/WO2018109825A1/ja
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating

Definitions

  • the present invention relates to a version management system and a version management method.
  • the target system is updated about twice a year, and the update interval is often long. Therefore, when a problem occurs, the system and system operation can be continued by addressing the problem by restoring (restoring) the applications and middleware that configure the system to the previous state (version) that has been used. . For example, when there are version A that has been operating for the past 90 days and version B that has been operating for the past 30 days in an application constituting a certain system, version A is selected as a restore candidate.
  • the version management system of the present invention that solves the above problems includes a storage device that holds version history information of each service that provides a predetermined function in a predetermined system, and a system configuration of the system based on the version history information.
  • a process for generating a list of combination patterns in each version of the service, a process for excluding a pattern whose function degeneration rate is a predetermined level or more based on a predetermined necessary function among patterns included in the list, and the exclusion The process of identifying the pattern included in the list that has undergone the above process and having a similarity with a system configuration having a predetermined operation record in the past as a system configuration to be restored when a problem occurs is executed. And an arithmetic unit.
  • the version management method of the present invention is such that an information processing system including a storage device that holds version history information of each service that provides a predetermined function in a predetermined system is based on the version history information.
  • a process of generating a list of combination patterns in each version of each service as a configuration, and a process of excluding patterns having a function degeneration rate of a predetermined level or more based on a predetermined necessary function among patterns included in the list In addition, a process for specifying a system configuration that has a predetermined level of similarity to a system configuration having a predetermined operation record in the past as a system configuration to be restored when a problem occurs, among the patterns included in the list that has undergone the exclusion, It is characterized by performing.
  • FIG. 1 shows the example of a network structure containing the version management system of this embodiment. It is a figure which shows the hardware structural example of the version management system in this embodiment. It is a figure which shows Example 1 of system configuration information management DB in this embodiment. It is a figure which shows Example 2 of system configuration information management DB in this embodiment. It is a figure which shows Example 3 of system configuration information management DB in this embodiment. It is a figure which shows Example 4 of system configuration information management DB in this embodiment. It is a figure which shows the example of the structure selection policy in this embodiment. It is a figure which shows the example of a screen in this embodiment. It is a figure which shows Example 1 of function utilization frequency information DB in this embodiment.
  • Example 2 of the function utilization frequency information DB in this embodiment It is a figure which shows the example of the problem management DB in this embodiment. It is a figure which shows the example of the operation performance information DB in this embodiment. It is a figure which shows the example 1 of a flow in this embodiment. It is a figure which shows the example 2 of a flow in this embodiment. It is a figure which shows the example 3 of a flow in this embodiment. It is a figure which shows the example 4 of a flow in this embodiment. It is a figure which shows the example 5 of a flow in this embodiment. It is a figure which shows the example 6 of a flow in this embodiment. It is a figure which shows the example 7 of a flow in this embodiment. It is a figure which shows the example of the service combination candidate in this embodiment. It is a figure which shows the example 8 of a flow in this embodiment.
  • FIG. 1 is a diagram illustrating a network configuration example including a version management system 100 according to the present embodiment.
  • the version management system 100 shown in FIG. 1 makes it possible to provide a highly reliable system configuration by minimizing the degeneration rate of the provided functions in the event of a restoration measure accompanying the occurrence of a problem in the system being developed or released. For a computer system.
  • Such a version management system 100 can be assumed to be a server device connected to the development environment 200 and the production environment 300 via the network 10 so that data communication is possible.
  • the development environment 200 and the production environment 300 may be integrated with the version management system 100.
  • the version management system 100 illustrated in FIG. 1 includes a system configuration management unit 110, a system deployment unit 111, a system operation result collection unit 112, a system change detection unit 113, a system configuration selection unit 114, a function degeneration rate calculation unit 115, and a reliability.
  • Functions such as a calculation unit 116 and a policy setting unit 117 are implemented.
  • the version management system 100 holds data such as a system configuration information management DB 125, a configuration selection policy 126, a function usage frequency information DB 127, a problem management DB 128, an operation result information DB 129, and a service combination candidate 130.
  • the development environment 200 exists for each of the systems ⁇ to ⁇ to be developed. Further, such a development environment 200 is a server device on which an existing system development tool is mounted, and is an access target by a predetermined terminal of a person in charge of development. The result of the development work by the development staff using the system development tool, that is, the development content information is stored in the system development management DB 225.
  • the production environment 300 is an environment in which a system developed in the development environment 200 described above is deployed and actually released.
  • the production environment 300 is, for example, a business system for a business operator.
  • FIG. 1 shows an example of a production environment 300 in which “system ⁇ ” is deployed.
  • the system configuration of the “system ⁇ ” includes “service A”, “service B”, and “service C”. Each of these services provides a predetermined function.
  • the above-described production environment 300 includes a problem occurrence detection unit 310.
  • This problem occurrence detection unit 310 detects a problem such as a failure in the system (systems ⁇ to ⁇ ) released in the production environment 300 and notifies the version management system 100 of this.
  • the problem occurrence detection unit 310 adopts an existing failure occurrence detection tool as appropriate.
  • the hardware configuration of the version management system 100 is illustrated in FIG.
  • the version management system 100 includes a storage device 101 configured with an appropriate nonvolatile storage element such as a hard disk drive, a memory 103 configured with a volatile storage element such as a RAM, and a program 102 held in the storage device 101.
  • a CPU 104 (arithmetic unit) for performing overall control of the system itself by reading it into the memory 103 and performing various determinations, computations and control processes, and a communication device 105 connected to the network 10 and responsible for communication processing with other devices are provided. .
  • the above-mentioned storage device 101 includes the system configuration information management DB 125 (configuration table 1251, development information table 1252, API-function compatible) in addition to the program 102 that implements the functions 110 to 117 as the version management system of this embodiment.
  • Table 1253 and function holding table 1254 configuration selection policy 126
  • function usage frequency information DB 127 including API execution history information 1271 and function usage frequency information 1272
  • problem management DB 1208 and operation result information DB 129.
  • the service combination candidate 130 is stored in the memory 103 in accordance with a predetermined process. Details of these functions 110 to 117 and the data structure will be described later.
  • FIG. 3 shows an example of a table included in the system configuration management information DB 125 in this embodiment, and shows an example of the configuration information table 1251.
  • the configuration information table 1251 is a table that stores information related to the system configuration of the “system ⁇ ” described above.
  • the data structure is a collection of records including data such as deletion date 1501, update date 1502, service name 1503, version 1504, and update history 1505, with creation date 1500 as a key.
  • a system to be developed and released includes a plurality of services that can provide a predetermined function. Each service is version-managed for each update.
  • FIG. 4 shows an example of the development information table 1252 which is an example of a table included in the system configuration management information DB 125 in the present embodiment.
  • the development information table 1252 is a table that stores the development history of each service that constitutes the “system ⁇ ” described above.
  • the data structure is a collection of records composed of data such as service name 1601 and version 1602 with creation date 1600 as a key.
  • service A has a version “1.0.0” created in “2012/5/12 10:00: 00” and then “2012/5/14 15:00: It can be seen that the version has been updated to “1.0” at “00” and the version has been updated to “1.2.0” at “05/8/15 05:00:00”.
  • FIG. 5 shows an example of an API-function correspondence table 1253 which is an example of a table included in the system configuration management information DB 125 in the present embodiment.
  • the API-function correspondence table 1253 is a table that defines a correspondence relationship between an API provided externally by the system (system ⁇ or the like), a function corresponding to the API, and a service providing the function.
  • the data structure is a collection of records composed of data such as an API name 1801, a function name 1802, and a provider service 1803 with the creation date 1800 as a key.
  • FIG. 6 illustrates an example of a function holding table 1254 that is an example of a table included in the system configuration management information DB 125 according to the present embodiment.
  • This function holding table 1254 is a table that stores the update history of each function provided by the “system ⁇ ” described above.
  • FIG. 7 shows an example of the configuration selection policy 126 in this embodiment.
  • This configuration selection policy 126 is a table storing, for example, contents desired by developers as a system configuration to be deployed in the production environment 300 of the corresponding system when a system failure occurs, that is, a system configuration to be restored.
  • FIG. 9 is an example of a table included in the function usage frequency information DB 127 in the present embodiment, and shows an example of API execution history information 1271.
  • This API execution history information 1271 is a table that stores an API execution history in the “system ⁇ ” described above.
  • the data structure is a collection of records including data such as an end date and time 1301, an API name 1302, a provided service name 1303, and a version 1304, with the start date and time 1300 as a key.
  • FIG. 10 is an example of a table included in the function usage frequency information DB 127 in the present embodiment, and an example of the function usage frequency information 1272 is shown.
  • This function usage frequency information 1272 is a table that stores information on the ratio of the use of each function during a certain period in the above-mentioned “system ⁇ ”.
  • the data structure is a collection of records composed of data such as the provider service 1901 and the execution ratio 1902 with the function name 1900 as a key.
  • the data structure is a collection of records composed of data such as an occurrence service name 1401, a derived version 1402, a phenomenon 1403, and an influence rank 1404 with the occurrence date 1400 as a key.
  • the system configuration management unit 110 of the version management system 100 receives the system to be deployed (eg, system ⁇ ) and the reason for deployment from the development environment 200 or a predetermined terminal of the person in charge of development, and selects the system configuration using these as inputs.
  • a system configuration selection request is issued to the unit 114 (S200).
  • system configuration management unit 110 issues a system deployment request to the system deployment unit 111 with the deployment configuration received from the system configuration selection unit 114 and the deployment target system (for example, the system ⁇ in the production environment 300) as inputs. (S201).
  • FIG. 14 is a diagram showing a flow example 2 of the version management method in the present embodiment.
  • the system deployment unit 111 Upon receiving the system deployment request, the system deployment unit 111 executes deployment with respect to the deployment target system with the configuration specified in the above-described system deployment request (S300), and ends the processing.
  • FIG. 15 is a diagram showing a flow example 3 of the version management method in the present embodiment.
  • the CPU operating time and API execution history in the target system it is assumed that the CPU operating time and API execution history in the target system.
  • the system operation result collecting unit 112 updates the operation result information DB 129 from the information collected in S400 (S401). Specifically, using the version of the target system indicated by the collected information as a key, the record of the corresponding version is specified in the operation result information DB 129, and the operation time indicated by the collected information is added to the value of the operation result 1202 of the record. It becomes processing to do.
  • system operation result collecting unit 112 determines whether each of the above-described processes of S400 to S403 has been completed for all systems in the production environment 300 (S404).
  • the system operation result collecting unit 112 determines whether an end command is received from an appropriate function such as the system configuration management unit 110, for example. (S405).
  • FIG. 16 is a diagram showing a flow example 4 of the version management method in the present embodiment.
  • the problem occurrence detection unit 310 in the production environment 300 determines whether a problem such as a failure has been detected in any of the systems (systems ⁇ to ⁇ ) by monitoring the process and the syslog message (S500). .
  • the problem occurrence detection unit 310 determines the location and cause of the problem from the output message and the phenomenon that has occurred in the target system. And information such as the problem that occurred and the location (service / function) where the problem occurred, the date and time of occurrence, the phenomenon that occurred, the influence rank, etc. are registered in the problem management DB 128 (S501).
  • the problem occurrence detection unit 310 determines whether an end command has been received (S503).
  • the problem occurrence detection unit 310 returns the process to S500.
  • the system change detection unit 113 of the version management system 100 determines whether there is a change in the development target system (S600). This determination can be made based on whether or not an update notification of the development management DB 225 has been received from the development environment 200.
  • the system change detection unit 113 acquires the updated content in the development management DB 225 from the development environment 200, and the updated new system configuration The changed contents are registered in the system configuration information management DB 125 (S601).
  • system change detection unit 113 determines whether an end command has been received (S603).
  • FIG. 18 is a diagram showing a flow example 6 of the version management method in the present embodiment.
  • the system configuration selection unit 114 receives the notification in S502 in the above-described flow example 4 (FIG. 16) and the notification in S602 in the flow example 5 (FIG. 17), and has received this time. It is determined whether the notification is a normal update or a problem countermeasure (S700).
  • the system configuration selection unit 114 stores the configuration information table 1251 in the system configuration information management DB 125. Based on the management target system group including “system ⁇ ” to “system ⁇ ”, the overall average update interval (X) is calculated (S701).
  • the system configuration selection unit 114 returns the deployment configuration as a return value to the system configuration management unit 110 (S707), and ends the processing.
  • the deployment configuration to be returned here is a system configuration (system configuration to be restored) generated by the function degeneration rate calculation unit 115 in response to the function degeneration rate calculation request in S705 described above.
  • the function degeneration rate calculation unit 115 of the version management system 100 uses the configuration information table 1251 (FIG. 3) and the development information table 1252 (FIG. 4) to determine the service that configures the “system ⁇ ” to be deployed. Information and the version history of the service are acquired, and a service combination candidate 130 (FIG. 20), which is a table showing combinations of service versions that can be selected as the system configuration of “system ⁇ ”, is stored in the memory 103. Generate (S800).
  • the function degeneration rate calculation unit 115 performs filtering on each record of the above-described service combination candidate 130 according to the configuration selection policy 1102 in the configuration selection policy 126 (FIG. 7) (S801).
  • the function degeneration rate calculation unit 115 sets “service E” as a configuration that does not include “function E” based on the condition “exclude configuration that does not include function E” indicated by the policy with the next priority “003”.
  • the configuration not including the version “1.2.0” of “C” is excluded from the service combination candidates 130.
  • candidate IDs “16” and “17” are extracted from the records of the service combination candidates 130.
  • the function degeneration rate calculation unit 115 issues a reliability calculation request to the reliability calculation unit 116 with the “system ⁇ ” to be deployed and the system configuration candidate extracted by the filtering in S801 as inputs. (S802).
  • the version information “1.3.0” (service A: 1.1.0, service B), in which the reliability information obtained from the reliability calculation unit 116 is the configuration closest to the system configuration in the system configuration candidates. : 1.1.0, service C: 1.1.0).
  • the function degeneration rate calculation unit 115 selects the system configuration with the candidate ID “17” that is closer to the configuration of the above-described version “1.3.0” among the candidates as the one with the highest reliability.
  • the reliability used here is information calculated by the reliability calculation unit 116 in response to the reliability calculation request in S802 described above.
  • the function degeneration rate calculation unit 115 returns the system configuration registered in S803 to the system configuration selection unit 114 as a return value (S804), and ends the process.
  • the system configuration selection unit 114 returns the return value to the system configuration management unit 110 as a deployment configuration.
  • the system configuration management unit 110 issues a deployment request with the return value as an input to the system deployment unit 111.
  • the system deploying unit 111 deploys the above-described return value, that is, the system configuration registered by the function degeneration rate calculating unit 115 to the production environment 300 of “system ⁇ ” as the system configuration of the countermeasure version.
  • FIG. 21 is a diagram showing a flow example 8 of the version management method in the present embodiment.
  • the reliability calculation unit 116 includes a system configuration indicated by each candidate system configuration (candidate IDs “16” and “17”) and a system configuration having operation results (a configuration in which records are registered in the operation result information DB 129). ) And the reliability related to the system configuration of each candidate is calculated (S901).
  • the reliability calculation unit 116 is configured by only the versions that do not exceed the versions of the services of the above-described candidates (candidate IDs “16,“ 17 ”) among the records of the operation result information DB 129.
  • the value of the update date 1201 in the version 1202 of the existing record is extracted.
  • the version of each service in the candidate ID “16” is “service A”: “1.0.0”, “service B”: “1.1.0”, “service C”: “1.2.0”.
  • the version of each service with the candidate ID “17” is “service A”: “1.1.0”, “service B”: “1.1.0”, “service C”: “1. 2.0 ". Therefore, among the records of the operation result information DB 129, “Service A”: “1.1.0”, “Service B”: “1.1.0”, “Service C”: “1.2.0”
  • the update date and time from the records of version “1.0.0”, “1.1.0”, “1.2.0”, “1.3.0”, which is composed only of versions not exceeding A value of 1201 is extracted.
  • the version “1.0.0” is the update date “2012 05-13 10:00: 00”
  • the version “1.1.0” is the update date “2012 07-20 15:00”.
  • 0:00 ", version” 1.2.0 is updated date and time” 2012 07-28 05:00:00 "
  • version” 1.3.0 is updated date and time” 2012 08-14 15:00 ", etc. And can be extracted.
  • the reliability calculation unit 116 collates the value of the update date 1201 extracted above with the development information table 1252, and finds the date closest to the update date in the past date and time indicated by the update date 1201 as the creation date 1600.
  • the version 1602 of each service is identified, and the version of each service in each version 1202 of “system ⁇ ” is identified.
  • the update date “2012 08-14 15:00” of the version “1.3.0” of “System ⁇ ” is collated with the development information table 1252, and the update date “2012 08-14 15:00:
  • the version 1602 of each service in which the date and time closest to the update date and time in the past from “00” is the creation date and time 1600 is version “1.1.0” for “service A” and version “1.1.0” for “service B”.
  • version “1.1.0” and “service C” the version “1.1.0” is specified.
  • the reliability calculation unit 116 obtains the version of each service in each of the versions “1.0.0” to “1.3.0” of the “system ⁇ ” obtained as described above, and each candidate The degree of coincidence with the version of each service is determined as the reliability.
  • the version of each service of “system ⁇ ” version “1.3.0” (“service A”: “1.1.0”, “service B”: “1.1.0”, “service C” ”:“ 1.1.0 ”), and the version of each service in the candidate ID“ 16 ”“ Service A ”:“ 1.0.0 ”,“ Service B ”:“ 1.1.0 ”,“ “Service C”: “1.2.0”, the version matches with “Service B”, the reliability is “1/3”, and each candidate ID “17”
  • “Service A”: “1.1.0”, “Service B”: “1.1.0”, “Service C”: “1.2.0”) is collated, “Service A” and “Service B” have the same version and the reliability is determined to be “2/3”, etc. That. In this way, the reliability calculation unit 116 determines
  • the reliability calculation unit 116 compares the reliability with each candidate for each of the versions “1.0.0” to “1.3.0” of the “system ⁇ ” determined as described above.
  • the version with the highest reliability and the candidate for the reliability are identified. That is, the system configuration that has the operation record is identified as being closest to the system configuration of each candidate.
  • the version with the highest reliability is “1.3.0” (service A: 1.1.0, service B: 1.1.0, service C: 1.1.0).
  • the candidate for that object is “17”.
  • the reliability is “2/3”.
  • the reliability calculation unit 116 determines whether or not the reliability of each version of “system ⁇ ” “1.0.0” to “1.3.0”, that is, the reliability related to the entire system configuration to be processed has been completed (S902).
  • the reliability calculation unit 116 returns the process to S901.
  • the reliability calculation unit 116 gives the function degeneration rate calculation unit 115 the calculation result obtained in S901 (the maximum reliability and its reliability). (Candidate) is returned as a return value (S903), and the process ends.
  • a system configuration is generated based on information on services that can constitute the target system and the release history of each service, and a configuration that has not existed in the past can be a candidate for a countermeasure version when a failure occurs.
  • a countermeasure version candidate from a configuration where the function degeneration rate is below a predetermined level, select a configuration that has a past operation performance similar to the configuration that actually exists, that is, the operation performance is highly effective. I can do it.
  • the arithmetic device compares an average update interval of the system with an average update interval in a predetermined system group including the system, and the average update interval of the system is the system update interval. When it is shorter than the average update interval of the group, the generation process, the exclusion process, and the identification process may be executed.
  • the information processing system further holds information on execution history of the API related to the system in a predetermined period in the storage device, and the execution history is related to the API and the function.
  • the function executed during the predetermined period is identified and the identified function is compared with the predetermined information including the version and the relationship between the function and the service.
  • a process for determining the usage frequency may be further executed, and a process for excluding a pattern that does not include a function having a usage frequency equal to or higher than a predetermined level among the patterns included in the list may be further executed in the exclusion process. .

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Quality & Reliability (AREA)
  • Stored Programmes (AREA)
  • Retry When Errors Occur (AREA)

Abstract

【課題】システムでの問題発生に伴うリストア措置に際し、提供機能の縮退率を最小化し、信頼度が高いシステム構成を提供可能とする。 【解決手段】バージョン管理システム１００において、所定システムで所定機能を提供する各サービスのバージョン履歴の情報を保持する記憶装置１０１と、前記バージョン履歴の情報に基づき、前記システムのシステム構成として各サービスの各バージョンでの組み合わせパターンのリストを生成する処理と、前記リストが含むパターンのうち、予め定めた必要機能を基準とした機能縮退率が所定レベル以上のパターンを除外する処理と、当該除外を経た前記リストが含むパターンのうち、過去に所定の稼働実績を有するシステム構成との類似性が最高のものを、問題発生時のリストア対象たるシステム構成として特定する処理を実行する演算装置１０４を含む構成とする。

Description

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

Claims (6)

  1. 　所定システムで所定機能を提供する各サービスのバージョン履歴の情報を保持する記憶装置と、
    　前記バージョン履歴の情報に基づき、前記システムのシステム構成として各サービスの各バージョンでの組み合わせパターンのリストを生成する処理と、前記リストが含むパターンのうち、予め定めた必要機能を基準とした機能縮退率が所定レベル以上のパターンを除外する処理と、当該除外を経た前記リストが含むパターンのうち、過去に所定の稼働実績を有するシステム構成との類似性が所定レベル以上のものを、問題発生時のリストア対象たるシステム構成として特定する処理と、を実行する演算装置と、
    　を備えることを特徴とするバージョン管理システム。
  2. 　前記記憶装置は、
    　前記システムに関するＡＰＩの所定期間における実行履歴の情報も更に保持するものであり、
    　前記演算装置は、
    　前記実行履歴を、ＡＰＩと機能との関係を定めた所定情報に照合して、前記所定期間に実行された機能を特定し、当該特定した機能を、機能とサービスとの関係をバージョンも含めて定めた所定情報に照合して、機能の利用頻度を判定する処理を更に実行し、
    　前記除外の処理に際し、前記リストが含むパターンのうち、前記利用頻度が所定レベル以上の機能を含まないパターンを除外する処理を更に実行するものである、
    　ことを特徴とする請求項１に記載のバージョン管理システム。
  3. 　前記演算装置は、
    　前記システムの平均更新間隔と、前記システムを含む所定のシステム群における平均更新間隔とを比較し、前記システムの平均更新間隔が前記システム群の平均更新間隔より短い場合に、前記生成する処理、前記除外する処理、および前記特定する処理、を実行するものである、
    　ことを特徴とする請求項１に記載のバージョン管理システム。
  4. 　所定システムで所定機能を提供する各サービスのバージョン履歴の情報を保持する記憶装置を備えた情報処理システムが、
    　前記バージョン履歴の情報に基づき、前記システムのシステム構成として各サービスの各バージョンでの組み合わせパターンのリストを生成する処理と、前記リストが含むパターンのうち、予め定めた必要機能を基準とした機能縮退率が所定レベル以上のパターンを除外する処理と、当該除外を経た前記リストが含むパターンのうち、過去に所定の稼働実績を有するシステム構成との類似性が所定レベル以上のものを、問題発生時のリストア対象たるシステム構成として特定する処理と、
    　を実行することを特徴とするバージョン管理方法。
  5. 　前記情報処理システムが、
    　前記記憶装置において、前記システムに関するＡＰＩの所定期間における実行履歴の情報も更に保持し、
    　前記実行履歴を、ＡＰＩと機能との関係を定めた所定情報に照合して、前記所定期間に実行された機能を特定し、当該特定した機能を、機能とサービスとの関係をバージョンも含めて定めた所定情報に照合して、機能の利用頻度を判定する処理を更に実行し、
    　前記除外の処理に際し、前記リストが含むパターンのうち、前記利用頻度が所定レベル以上の機能を含まないパターンを除外する処理を更に実行する、
    　ことを特徴とする請求項４に記載のバージョン管理方法。
  6. 　前記情報処理システムが、
    　前記システムの平均更新間隔と、前記システムを含む所定のシステム群における平均更新間隔とを比較し、前記システムの平均更新間隔が前記システム群の平均更新間隔より短い場合に、前記生成する処理、前記除外する処理、および前記特定する処理、を実行する、
    　ことを特徴とする請求項４に記載のバージョン管理方法。
PCT/JP2016/087020 2016-12-13 2016-12-13 バージョン管理システムおよびバージョン管理方法 Ceased WO2018109825A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US15/757,089 US10747529B2 (en) 2016-12-13 2016-12-13 Version management system and version management method
PCT/JP2016/087020 WO2018109825A1 (ja) 2016-12-13 2016-12-13 バージョン管理システムおよびバージョン管理方法
JP2018507738A JP6411696B1 (ja) 2016-12-13 2016-12-13 バージョン管理システムおよびバージョン管理方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2016/087020 WO2018109825A1 (ja) 2016-12-13 2016-12-13 バージョン管理システムおよびバージョン管理方法

Publications (1)

Publication Number Publication Date
WO2018109825A1 true WO2018109825A1 (ja) 2018-06-21

Family

ID=62559691

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2016/087020 Ceased WO2018109825A1 (ja) 2016-12-13 2016-12-13 バージョン管理システムおよびバージョン管理方法

Country Status (3)

Country Link
US (1) US10747529B2 (ja)
JP (1) JP6411696B1 (ja)
WO (1) WO2018109825A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112148329A (zh) * 2020-09-18 2020-12-29 湖南联盛网络科技股份有限公司 代码版本自动化更新方法、装置、计算机设备及存储介质

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11398900B2 (en) 2018-06-21 2022-07-26 Oracle International Corporation Cloud based key management
US11258604B2 (en) * 2018-10-19 2022-02-22 Oracle International Corporation Rewiring cryptographic key management system service instances
US11546315B2 (en) * 2020-05-28 2023-01-03 Hewlett Packard Enterprise Development Lp Authentication key-based DLL service
JP7157792B2 (ja) * 2020-12-16 2022-10-20 株式会社日立製作所 リモート作業支援装置及び方法
US11809861B2 (en) * 2021-06-09 2023-11-07 Red Hat, Inc. Development environment organizer with enhanced state switching and sharing
US11792135B2 (en) * 2022-03-07 2023-10-17 Bank Of America Corporation Automated process scheduling in a computer network
US20250181347A1 (en) * 2023-12-05 2025-06-05 Mastercard International Incorporated Version management systems, methods, and interfaces

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08194671A (ja) * 1995-01-13 1996-07-30 Nippon Telegr & Teleph Corp <Ntt> システムバージョンに基づく切り戻し方式
JP2010128851A (ja) * 2008-11-28 2010-06-10 Omron Corp 管理サーバ、オンラインシステム、および管理プログラム
WO2013094003A1 (ja) * 2011-12-19 2013-06-27 富士通株式会社 ソフトウェアのインストール順序を決定する方法、プログラム、及び装置

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6754848B1 (en) * 1999-09-30 2004-06-22 International Business Machines Corporation Method, system and program products for operationally migrating a cluster through emulation
US8285876B2 (en) * 2004-03-19 2012-10-09 International Business Machines Corporation J2EE application versioning strategy
JP2008108155A (ja) 2006-10-27 2008-05-08 Hitachi Ltd 稼働実績情報に基づくモジュール切替システム
EP2513787A1 (en) * 2009-12-18 2012-10-24 Syddansk Universitet Method, computer program product, and system for non-blocking dynamic update of statically typed class-based object-oriented software

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08194671A (ja) * 1995-01-13 1996-07-30 Nippon Telegr & Teleph Corp <Ntt> システムバージョンに基づく切り戻し方式
JP2010128851A (ja) * 2008-11-28 2010-06-10 Omron Corp 管理サーバ、オンラインシステム、および管理プログラム
WO2013094003A1 (ja) * 2011-12-19 2013-06-27 富士通株式会社 ソフトウェアのインストール順序を決定する方法、プログラム、及び装置

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112148329A (zh) * 2020-09-18 2020-12-29 湖南联盛网络科技股份有限公司 代码版本自动化更新方法、装置、计算机设备及存储介质
CN112148329B (zh) * 2020-09-18 2023-03-28 湖南联盛网络科技股份有限公司 代码版本自动化更新方法、装置、计算机设备及存储介质

Also Published As

Publication number Publication date
US10747529B2 (en) 2020-08-18
US20200225938A1 (en) 2020-07-16
JPWO2018109825A1 (ja) 2018-12-13
JP6411696B1 (ja) 2018-10-24

Similar Documents

Publication Publication Date Title
JP6411696B1 (ja) バージョン管理システムおよびバージョン管理方法
US11108859B2 (en) Intelligent backup and recovery of cloud computing environment
US11416344B2 (en) Partial database restoration
US10303539B2 (en) Automatic troubleshooting from computer system monitoring data based on analyzing sequences of changes
JP5075736B2 (ja) 仮想サーバのシステム障害回復方法及びそのシステム
CN109240886B (zh) 异常处理方法、装置、计算机设备以及存储介质
US8589727B1 (en) Methods and apparatus for providing continuous availability of applications
US20160055044A1 (en) Fault analysis method, fault analysis system, and storage medium
JP2006031109A (ja) 管理システム及び管理方法
JPWO2004061681A1 (ja) 運用管理方法および運用管理サーバ
EP3591530B1 (en) Intelligent backup and recovery of cloud computing environment
JP6447258B2 (ja) 管理プログラム、管理方法、および管理装置
JP6561212B2 (ja) 問合せ対応システム及び方法
JP2019057139A (ja) 運用管理システム、監視サーバ、方法およびプログラム
JP4983795B2 (ja) システム管理プログラム、システム管理装置およびシステム管理方法
Amvrosiadis et al. Getting back up: Understanding how enterprise data backups fail
JP5417264B2 (ja) 分析情報提供方法
CN113760608B (zh) 数据恢复方法和装置、电子设备和存储介质
US9690639B2 (en) Failure detecting apparatus and failure detecting method using patterns indicating occurrences of failures
US12135619B2 (en) Application discovery using access pattern history
CN111090491A (zh) 虚拟机任务状态的恢复方法、装置及电子设备
WO2020100634A1 (ja) 復旧支援装置、復旧支援方法及びプログラム
JP6504611B2 (ja) 監視装置、情報監視システム、監視装置の制御方法、及びプログラム
US12001271B2 (en) Network monitoring apparatus, method, and program
JP5466740B2 (ja) 仮想サーバのシステム障害回復方法及びそのシステム

Legal Events

Date Code Title Description
ENP Entry into the national phase

Ref document number: 2018507738

Country of ref document: JP

Kind code of ref document: A

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16923726

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16923726

Country of ref document: EP

Kind code of ref document: A1