Computer system and method of managing operation history of infrastructure

Abstract

To manage an infrastructure operation history using IaC.SOLUTION: A computer system is connected to infrastructures which provide resources for implementing services, a version management system which manages versions of a manifest file in which settings for configuring the services are described, and an infrastructure management system which generates commands for the infrastructures on the basis of the manifest file and outputs the commands to the infrastructures. The computer system receives a notification including a change ID corresponding to a version of the manifest file from the version management system in accordance with update of the manifest file and transmits an instruction to execute a change operation including the change ID, to the infrastructure management system so that an operation history of the change operation associated with a command and the change ID is stored.SELECTED DRAWING: Figure 5

Description

[Technical field]

[0001] The present invention relates to a technology for managing operation history of a system that manages a platform using IaC (Infrastructure as Code). [Background technology]

[0002] In recent years, the use of cloud systems has expanded to meet business agility needs, and the number of cases where multiple platforms, such as on-premise systems and cloud systems, are combined is also increasing.

[0003] Since the configuration of an infrastructure is frequently changed, it is important to understand the configuration of the infrastructure. The technology described in Patent Document 1 is known as a technology for presenting information about the infrastructure configuration.

[0004] Patent document 1 states that "We provide a cloud service providing system that can grasp the configuration history of a cloud environment. To this end, we have a cloud connection information receiving unit, a configuration saving processing unit, a configuration history display processing unit, a cloud connection information receiving unit, a cloud connection information DB, a configuration information acquisition processing unit, a cloud configuration history DB, and a configuration history acquisition processing unit. We then obtain cloud connection information using the user's cloud ID, identify the cloud service providing system from which to obtain the cloud configuration information from the obtained cloud connection information, obtain the cloud configuration information, and store it in the cloud configuration history DB. Based on the cloud information to display the configuration received from the user, the configuration history is obtained from the cloud configuration history DB, and a configuration diagram is generated and displayed with component icons for each component." [Prior art documents] [Patent documents]

[0005] [Patent Document 1] International Publication No. 2016 / 103422 Summary of the Invention [Problem to be solved by the invention]

[0006] IaC is known as a technology that supports the construction of services on an infrastructure. Users can automatically construct services on an infrastructure by inputting a manifest file, which describes the settings for constructing the service as code, into an IaC tool. In the following explanation, the manifest file will be referred to as a manifest.

[0007] In order to realize the contents of the manifest, the IaC tool generates and executes commands that can be executed on the platform. Users cannot understand the commands (operations) that the IaC tool executes. This poses the issue of being unable to verify if a failure occurs.

[0008] The present invention aims to provide a technique for understanding the operation content of an IaC tool based on a manifest. [Means for solving the problem]

[0009] A representative example of the invention disclosed in the present application is as follows: A computer system is connected to an infrastructure that provides resources for realizing a service, a version control system that manages the version of a manifest file describing settings for constructing the service, and an infrastructure management system that generates commands for the infrastructure based on the manifest file and outputs the commands to the infrastructure, and receives a notification including a change ID corresponding to the version of the manifest file from the version control system as the manifest file is updated, and transmits an instruction to execute a change operation including the change ID to the infrastructure management system so that an operation history of the change operation that associates the command and the change ID is saved. Effect of the Invention

[0010] According to the present invention, since the operation history of the change operation can be saved in association with the change ID, it is possible to grasp the operation contents of the infrastructure management system (IaC tool). Problems, configurations, and effects other than those described above will become clear from the following description of the embodiment. [Brief description of the drawings]

[0011] [Figure 1] FIG. 1 illustrates an example of a system configuration according to a first embodiment. [Diagram 2] FIG. 2 is a diagram illustrating an example of a service configuration according to a first embodiment. [Diagram 3] FIG. 13 is a diagram illustrating an example of a manifest according to the first embodiment. [Figure 4] FIG. 13 is a diagram illustrating an example of a data structure of object state information according to the first embodiment. [Diagram 5] FIG. 13 is a sequence diagram illustrating a process flow accompanying a manifest update of a storage service in the system of the first embodiment. [Figure 6] FIG. 13 is a diagram illustrating an example of a command transmitted to the board of the first embodiment. [Figure 7] FIG. 2 is a diagram illustrating an example of a data structure of an operation history DB according to the first embodiment. [Figure 8] 11 is a flowchart illustrating an example of an exclusive control process executed by an object state management part according to the first embodiment. [Figure 9A] 11 is a diagram illustrating an example of a change in object state information in the exclusive control process of the first embodiment. FIG. [Figure 9B] 11 is a diagram illustrating an example of a change in object state information in the exclusive control process of the first embodiment. FIG. [Figure 9C] 11 is a diagram illustrating an example of a change in object state information in the exclusive control process of the first embodiment. FIG. [Figure 9D] 11 is a diagram illustrating an example of a change in object state information in the exclusive control process of the first embodiment. FIG. [Figure 9E] 11 is a diagram illustrating an example of a change in object state information in the exclusive control process of the first embodiment. FIG. [Figure 10]FIG. 13 is a sequence diagram illustrating a process flow accompanying a manifest update of a storage service in the system of the first embodiment. [Figure 11] FIG. 2 is a diagram illustrating an example of a data structure of configuration information according to the first embodiment. [Figure 12] FIG. 11 is a sequence diagram illustrating a flow of an operation history acquisition process in the system according to the first embodiment. [Figure 13] 11 is a flowchart illustrating an example of an operation history extraction process executed by an operation history extraction unit according to the first embodiment. [Figure 14] 11 is a flowchart illustrating an example of an operation history extraction process executed by an operation history extraction unit according to the first embodiment. [Figure 15] 11 is a diagram illustrating an example of a data structure of extraction information generated by an operation history extraction unit according to the first embodiment. FIG. [Figure 16] 11 is a flowchart illustrating an example of a display information generating process executed by a configuration diagram generating unit according to the first embodiment. [Figure 17] FIG. 11 is a diagram illustrating an example of a screen displayed on a user terminal according to the first embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. However, the present invention should not be interpreted as being limited to the description of the embodiment shown below. It will be easily understood by those skilled in the art that the specific configuration can be changed without departing from the concept or purpose of the present invention.

[0013] In the configurations of the invention described below, the same or similar configurations or functions are given the same reference numerals, and duplicated explanations are omitted.

[0014] In this specification, the terms "first," "second," "third," and the like are used to identify components and do not necessarily limit the number or order. EXAMPLES

[0015] Fig. 1 is a diagram illustrating an example of a system configuration according to the first embodiment. Fig. 2 is a diagram illustrating an example of a service configuration according to the first embodiment. Fig. 3 is a diagram illustrating an example of a manifest according to the first embodiment.

[0016] The system is composed of a version control system 100, multiple boards 101, and a user terminal 102. The version control system 100, the multiple boards 101, and the user terminal 102 are connected via a network 103 such as a LAN (Local Area Network). The network 103 may be connected by either a wired or wireless method.

[0017] The version control system 100 manages the manifest and its version. The version control system 100 has a management unit 110, and also holds a manifest change history DB 111. The management unit 110 manages the manifest. For example, the management unit 110 accepts a manifest from the user terminal 102, assigns identification information (change ID) corresponding to the version to the manifest, and stores it in the manifest change history DB 111. The management unit 110 also checks the changes between the accepted manifest and the registered manifest, and transmits configuration change information to the platform 101 if there is a change.

[0018] The platform 101 is a system that provides resources for implementing a service. The platform 101 may be either an on-premise platform or a cloud platform. In this embodiment, an example of the platform 101 that provides resources for implementing a storage service that provides volumes will be described. The platform 101 includes a storage system 120 that provides resources. There may be two or more storage systems 120. The platform 101 also includes an operation history management system 121 and a configuration management system 122.

[0019] The operation history management system 121 manages the operation history of operations on the board 101. The operation history management system 121 holds an operation history DB .

[0020] The configuration management system 122 changes and manages the configuration of the storage service. The configuration management system 122 has, as functional units (modules), a configuration change information acquisition unit 140, a change operation execution unit 141, an object state management unit 142, a configuration management unit 143, an operation history extraction unit 144, and a configuration diagram generation unit 145.

[0021] The configuration management unit 143 manages the configuration of the storage service. The configuration management unit 143 manages the configuration information 160. As shown in FIG. 2, a storage service is composed of multiple components (objects). "Vol" is an object corresponding to a volume provided to a user, "Ten" is an object corresponding to a storage pool that generates a volume, and "SC" is an object corresponding to a cluster composed of multiple drives. As shown in FIG. 2, the objects have a hierarchical structure, and there is a dependency between objects between hierarchies. In this embodiment, it is assumed that a manifest such as that shown in FIG. 3 is defined for each object.

[0022] The object state manager 142 manages the operational states of the objects that make up the storage service. The object state manager 142 manages the object state information 150. The object state information 150 is generated when the storage service is constructed, and is updated whenever the manifest is updated.

[0023] The configuration change information acquisition unit 140 acquires configuration change information from the version control system 100. The change operation execution unit 141 is a functional unit corresponding to an IaC tool, generates a command based on a manifest, and outputs the command to the board 101.

[0024] The operation history extraction unit 144 extracts the operation history. The configuration diagram generation unit 145 generates a diagram (configuration diagram) of the object configuration of the storage service at a certain point in time.

[0025] The operation history management system 121 of at least one board 101 may manage the operation histories of all boards 101. Also, the configuration management system 122 of at least one board 101 may manage the configurations of all boards 101.

[0026] It should be noted that the operation history management system 121 and the configuration management system 122 do not necessarily have to be included in the platform 101 .

[0027] Regarding the functional units of the configuration management system 122, multiple functional units may be integrated into one functional unit, or one functional unit may be divided into multiple functional units for each function.

[0028] The configuration management system 122 does not have to include the change operation execution unit 141. In this case, the change operation execution unit 141 is included in the platform 101 or another system.

[0029] FIG. 4 is a diagram illustrating an example of the data structure of the object state information 150 according to the first embodiment.

[0030] Object state information 150 stores entries including object name 401 and state 402. There is one entry for one object. State 402 stores information indicating whether a change operation can be performed on the object corresponding to object name 401. If a change operation can be performed on the object, "operation possible" is stored, and if a change operation cannot be performed on the object, "operation not possible" is stored.

[0031] First, a method for acquiring an operation history of a change operation accompanying an update of a manifest will be described. Fig. 5 is a sequence diagram illustrating a process flow accompanying a manifest update of a storage service in the system of the first embodiment. Fig. 6 is a diagram illustrating an example of a command transmitted to the platform 101 of the first embodiment. Fig. 7 is a diagram illustrating an example of a data structure of an operation history DB 130 of the first embodiment.

[0032] When the version control system 100 receives an updated manifest (step S101), it transmits configuration change information including a change ID corresponding to the version of the manifest to the object state management unit 142 (step S102). The configuration change information also includes the object name.

[0033] The object state management unit 142 executes an exclusive control process for controlling the execution of a change operation of the object corresponding to the updated manifest (step S103). If the change operation is executable, the object state management unit 142 transmits configuration change information together with a change ID to the configuration change information acquisition unit 140 (step S104).

[0034] The configuration change information acquisition unit 140 acquires the updated manifest from the version control system 100 (step S105), and transmits an execution instruction to the change operation execution unit 141 together with the change ID and the manifest (step S106).

[0035] The change operation execution unit 141 generates a command based on the manifest, and transmits the command together with the change ID to the board 101 (step S107). The change operation execution unit 141 also transmits an end notification to the object state management unit 142 (step S108).

[0036] After carrying out the change operation in accordance with the command, the board 101 transmits an operation history including the change ID and the content of the change operation based on the command to the operation history management system 121 (step S109).

[0037] For example, when a command as shown in FIG. 6 is executed, an operation history as shown in FIG.

[0038] The operation history DB 130 stores entries including a time 701, an operation content 702, a change ID 703, an operation target 704, and an object name 705. Note that the fields included in the entries are merely examples and are not limited to these.

[0039] Fig. 8 is a flowchart illustrating an example of the exclusive control process executed by the object state management part 142 of the embodiment 1. Fig. 9A, Fig. 9B, Fig. 9C, Fig. 9D, and Fig. 9E are diagrams illustrating an example of the change in the object state information 150 in the exclusive control process of the embodiment 1.

[0040] When the object state management unit 142 receives configuration change information (step S201), it refers to the object state information 150 and judges whether or not an entry for the object to be operated exists (step S202).

[0041] If an entry for the object to be operated is present in the object state information 150, the object state management section 142 judges whether the state 402 of the object is "operable" (step S203).

[0042] If the object state 402 is not "operable", the object state management unit 142 returns to step S203 after a certain period of time has elapsed. If the object state 402 is "operable", the object state management unit 142 proceeds to step S206.

[0043] If it is determined in step S202 that there is no entry for the object to be operated in object state information 150, object state management unit 142 updates state 402 of the parent object of that object to "inoperable" (step S204), and adds an entry for that object to object state information 150 (step S205). After that, object state management unit 142 proceeds to step S206.

[0044] In step S205, object state management section 142 adds an entry to object state information 150, and sets the name of the object to be operated on as object name 401 of the added entry.

[0045] In step S206, the object state management section 142 updates the state 402 of the object to be operated to "inoperable" (step S206).

[0046] The object state management unit 142 transmits the configuration change information to the configuration change information acquisition unit 140 (step S207). The process of step S207 corresponds to the process of step S104. After that, the object state management unit 142 monitors for an end notification.

[0047] The object state management unit 142 determines whether or not an end notification has been received (step S208).

[0048] If the end notification has not been received, the object state management section 142 returns to step S208 after a certain period of time has elapsed.

[0049] When the end notification is received, the object state management unit 142 updates the state 402 of the object to be operated to "operable" (step S209). If the state 402 of the parent object has also been updated, the object state management unit 142 also updates the state 402 of the parent object to "operable".

[0050] Although the number of hierarchical layers requiring exclusive control is one, the number of hierarchical layers for which exclusive control is performed may be changed depending on the operation content.

[0051] Here, the exclusive control process will be explained using a concrete example, assuming that the object state information 150 is in the state shown in FIG.

[0052] When a manifest (first manifest) for adding volume "Vol D" from storage pool "Ten A" is added for the first time, object state management unit 142 updates state 402 of parent object "Ten A" to "inoperable" (step S204). Object state management unit 142 also adds an entry for object "Vol D" (step S205) and sets state 402 to "inoperable" (step S206).

[0053] As a result of the above processing, the object state information 150 becomes as shown in FIG. 9B.

[0054] Before receiving the end notification of the first manifest, a manifest (second manifest) for expanding the storage pool "Tne A" and a manifest (third manifest) for expanding the storage pool "Tne B" are added. For the second manifest, since the state 402 of the object "Ten A" is "unoperable", the object state management unit 142 waits until the state 402 of the object "Ten A" becomes "operable" (step S203). For the third manifest, since the state 402 of the object "Ten B" is "operable", the object state management unit 142 updates the state 402 to "unoperable" (step S206).

[0055] As a result of the above processing, object state information 150 becomes as shown in FIG. 9C.

[0056] In this way, modification operations of objects that do not require mutual exclusion are executed in parallel, whereas modification operations of objects that require mutual exclusion are controlled so as not to be executed in parallel.

[0057] When an end notification is received for the first manifest, the object state management unit 142 updates the states 402 of the objects "Ten A" and "Vol D" to "operable" (step S209).

[0058] As a result of the above processing, the object state information 150 becomes as shown in FIG. 9D.

[0059] Regarding the second manifest, since the status 402 of the object "Ten A" has become "operable", the object state management unit 142 updates the status 402 of the object "Ten A" to "inoperable" (step S206). Also, when an end notification is received for the third manifest, the object state management unit 142 updates the status 402 of the object "Ten B" to "operable" (step S209).

[0060] As a result of the above processing, object state information 150 becomes as shown in FIG. 9E.

[0061] Fig. 10 is a sequence diagram explaining the flow of processing accompanying the update of the manifest of the storage service in the system of the embodiment 1. Fig. 11 is a diagram showing an example of the data structure of the configuration information 160 of the embodiment 1.

[0062] The process shown in FIG. 10 is executed in parallel with the process shown in FIG.

[0063] When the manifest is updated (step S301), the version control system 100 transmits configuration change information to the configuration management unit 143 (step S302).

[0064] The configuration management unit 143 acquires the updated manifest and the manifests of the related objects from the version control system 100 (step S303). Note that the manifests of the related objects can be acquired by searching based on the names of the parent objects included in the manifests.

[0065] The configuration management unit 143 generates the configuration information 160 based on the acquired manifest (step S304).

[0066] The configuration information 160 stores entries including an object name 1101 and a parent object name 1102. One entry exists for one object. Note that the fields included in the entry are merely an example and are not limited to this.

[0067] Next, a method for acquiring an operation history related to an operation for changing the configuration of a storage service will be described with reference to Fig. 12. Fig. 12 is a sequence diagram illustrating the flow of an operation history acquisition process in the system of the first embodiment.

[0068] The user transmits an extraction instruction to the configuration diagram generating unit 145 using the user terminal 102 (step S401). The extraction instruction includes an object name and information specifying the acquisition range of the operation history. The acquisition range of the operation history can be specified by specifying a set of change IDs or by specifying a time range.

[0069] The configuration diagram generating unit 145 transfers the received extraction instruction to the operation history extracting unit 144 (step S402).

[0070] When the operation history extraction unit 144 receives the extraction instruction, it executes an operation history extraction process (step S403). In the operation history extraction process, the operation history extraction unit 144 accesses the version control system 100 as necessary and acquires a change ID (step S404).

[0071] The operation history extraction unit 144 transmits extraction information 1500 (see FIG. 15) that stores the extraction results to the configuration diagram generation unit 145 (step S405).

[0072] The configuration diagram generating unit 145 executes a display information generating process to display the extraction result (step S406) The configuration diagram generating unit 145 transmits the display information to the user terminal 102 (step S407).

[0073] 13 and 14 are flowcharts illustrating an example of an operation history extraction process executed by the operation history extraction unit 144 of the first embodiment. Fig. 15 is a diagram illustrating an example of a data structure of extraction information 1500 generated by the operation history extraction unit 144 of the first embodiment.

[0074] FIG. 13 shows the operation history extraction process when a set of change IDs is specified, and FIG. 14 shows the operation history extraction process when a time range is specified.

[0075] First, the extraction information 1500 will be described. The extraction information 1500 stores the extracted operation history. The extraction information 1500 includes a time 1501, an operation content 1502, a change ID 1503, and an operation attribute 1504. The time 1501, the operation content 1502, and the change ID 1503 are the same fields as the time 701, the operation content 702, and the change ID 703. The operation attribute 1504 is a field that stores information indicating whether the operation history is an operation history of a change operation executed by a command generated based on a manifest. If the operation history is an operation history of a change operation executed by a command generated based on a manifest, "normal" is stored, and if the operation history is not an operation history of a change operation executed by a command generated based on a manifest, "suspicious" is stored.

[0076] First, the operation history extraction process of FIG. 13 will be described.

[0077] The operation history extraction unit 144 accesses the version control system 100 based on the set of change IDs, and sets a time range (step S501).

[0078] Specifically, the operation history extraction unit 144 acquires the manifest registration time for each pair of change IDs, and sets a time range determined by the two registration times.

[0079] The operation history extraction unit 144 accesses the version control system 100 based on the time range, and identifies the change ID to be processed (step S502).

[0080] Specifically, the operation history extraction unit 144 identifies a manifest of the target object whose registration time falls within the determined time range, and obtains the change ID of the manifest.

[0081] The operation history extraction unit 144 extracts an operation history including the identified change ID from the operation history DB 130 (step S503). The operation history extraction unit 144 registers the extracted operation history in the extraction information 1500. At this time, the operation attribute 1504 is set to "normal".

[0082] The operation history extraction unit 144 extracts operation histories that are operations performed on the target object within the time range and do not include a change ID or that include a change ID other than the specified change ID (step S504). The operation history extraction unit 144 registers the extracted operation histories in the extraction information 1500. At this time, the operation attribute 1504 is set to "suspect".

[0083] The operation history extraction unit 144 sorts the operation histories of the extracted information 1500 in chronological order and outputs them (step S505).

[0084] It is not necessary to execute step S504. In this case, only the operation history including the identified change ID is extracted.

[0085] Next, the operation history extraction process of Fig. 14 will be described. The operation history extraction process of Fig. 14 does not include step S501. In step S502, the operation history extraction unit 144 identifies the change ID of the processing target based on the specified time range. The other processes are the same as those described in Fig. 13.

[0086] Fig. 16 is a flowchart illustrating an example of a display information generating process executed by the configuration diagram generating unit 145 according to the first embodiment. Fig. 17 is a diagram illustrating an example of a screen displayed on the user terminal 102 according to the first embodiment.

[0087] The configuration diagram generating unit 145 refers to the extracted information 1500 and identifies the latest change ID (step S601). Specifically, the configuration diagram generating unit 145 searches for an entry in which a change ID is stored in the change ID 1503 and the operation attribute 1504 is “normal”, and identifies the latest change ID based on the time 1501 of the searched entry.

[0088] The configuration diagram generating unit 145 acquires the configuration information 160 corresponding to the latest change ID (step S602).

[0089] The configuration diagram generating unit 145 generates display information using the extracted information 1500 and the configuration information 160 (step S603). For example, the configuration diagram generating unit 145 generates a configuration diagram that visualizes the object configuration of the storage service based on the configuration information 160, and generates display information for superimposing and displaying the extracted information 1500 on the configuration diagram.

[0090] 17 is displayed on the user terminal 102 based on the display information. The screen 1700 includes display areas 1701 and 1702. The display area 1701 is an area for displaying information related to an extraction instruction. The display area 1702 is an area for displaying the extraction results of the configuration of an object and the operation history.

[0091] According to the present invention, the operation history of the change operation accompanying the update of the manifest can be managed so as to be distinguished from other operation histories. Since the operation history of the change operation can be extracted based on the change ID, the change operation by the change operation execution unit 141 can be grasped in detail. In addition, by extracting the operation history of other operations during the execution of the change operation, it becomes possible to verify the change operation, check for unauthorized operations, and the like.

[0092] The present invention is not limited to the above-mentioned embodiment, but includes various modified examples. For example, the above-mentioned embodiment describes the configuration in detail to easily explain the present invention, and the present invention is not necessarily limited to the configuration including all the described configurations. Also, it is possible to add, delete, or replace a part of the configuration of each embodiment with another configuration.

[0093] In addition, each of the above configurations, functions, processing units, processing means, etc. may be realized in part or in whole by hardware, for example, by designing them as integrated circuits. The present invention can also be realized by software program code that realizes the functions of the embodiments. In this case, a storage medium on which the program code is recorded is provided to a computer, and a processor included in the computer reads the program code stored in the storage medium. In this case, the program code itself read from the storage medium realizes the functions of the above-mentioned embodiments, and the program code itself and the storage medium storing it constitute the present invention. Examples of storage media for supplying such program code include flexible disks, CD-ROMs, DVD-ROMs, hard disks, SSDs (Solid State Drives), optical disks, magneto-optical disks, CD-Rs, magnetic tapes, non-volatile memory cards, ROMs, etc.

[0094] Furthermore, the program code for realizing the functions described in this embodiment can be implemented in a wide range of program or script languages, such as assembler, C / C++, perl, Shell, PHP, Python, Java (registered trademark), etc.

[0095] Furthermore, the program code of the software that realizes the functions of the embodiments may be distributed over a network and stored in a storage means such as a computer's hard disk or memory, or in a storage medium such as a CD-RW or CD-R, and the processor of the computer may read out and execute the program code stored in the storage means or storage medium.

[0096] In the above-mentioned embodiment, the control lines and information lines are shown as those considered necessary for the explanation, and not all the control lines and information lines are shown in the product. All the components may be connected to each other. [Explanation of symbols]

[0097] 100 Version Control Systems 101 Foundation 102 User terminal 103 Network 110 Management Department 111 Manifest change history DB 120 Storage System 121 Operation History Management System 122 Configuration Management Systems 130 Operation History DB 140 Configuration change information acquisition unit 141 Change operation execution unit 142 Object State Management Unit 143 Configuration Management Department 144 Operation History Extraction Unit 145 Configuration diagram generation unit 150 Object Status Information 160 Configuration Information 1500 Extracted Information 1700 screens

Claims

1. 1. A computer system comprising: A platform that provides the resources to realize the service, A version control system that manages the version of a manifest file that describes settings for constructing the service; a platform management system that generates commands for the platform based on the manifest file and outputs the commands to the platform; receiving a notification from the version control system, the notification including a change ID corresponding to a version of the manifest file, in association with an update of the manifest file; A computer system characterized in that an instruction to execute a change operation including the change ID is sent to the infrastructure management system so that an operation history of the change operation associated with the command and the change ID is saved.

2. 2. The computer system of claim 1, a database that stores an operation history of the operations performed by the board is connected to the board in an accessible manner; A computer system characterized in that, when an instruction to output the operation history of a change operation accompanying an update of the manifest file is received, the computer system extracts the operation history associated with the change ID from the database and outputs it.

3. 3. The computer system of claim 2, The service is composed of a plurality of objects, the plurality of objects are in a hierarchical structure, There is a dependency relationship between the objects in different hierarchical levels, a manifest file exists for each of the objects; The computer system comprises: When the notification is received, determining whether or not exclusive control is required for the object that is changed with the update of the manifest file and the object that has a dependency relationship with the object; A computer system characterized by sending an instruction to execute the change operation when it is determined that exclusive control is not necessary for the object that is changed due to the update of the manifest file and the object that has a dependency on the object.

4. 4. The computer system of claim 3, The operation history is data configured from fields for storing a time, an operation content, the object to be operated, and the change ID, The output instruction includes identification information of the object and the two change IDs, The computer system comprises: accessing the version control system to identify the registration times of the manifest file corresponding to the two change IDs included in the output instruction; obtain the change ID of the manifest file of the object specified by the output instruction, the manifest file having a registration time included in a time period determined by the two specified registration times; a computer system for extracting from the database the operation history including either the change ID included in the output instruction or the change ID acquired from the version control system;

5. 5. The computer system of claim 4, A computer system characterized by extracting from the database the operation history relating to the object specified by the output instruction, wherein the time is included in the time zone and does not include the change ID, or includes the change ID included in the output instruction and the change ID obtained from the version control system.

6. 4. The computer system of claim 3, The operation history is data configured from fields for storing a time, an operation content, the object to be operated, and the change ID, the output instruction includes identification information of the object and a time period; The computer system comprises: accessing the version control system to obtain the change ID of the manifest file of the object specified by the output instruction, the manifest file having a registration time included in the time period; A computer system comprising: a database for extracting, from the database, the operation history including any of the change IDs obtained from the version control system.

7. 7. The computer system of claim 6, A computer system characterized by extracting from the database the operation history in which the time is included in the time zone and does not include the change ID or includes the change ID that is different from the change ID obtained from the version control system.

8. 4. The computer system of claim 3, When the notification is received, accessing the version control system to obtain the updated manifest file and the manifest files of other objects of the service that are composed of the object corresponding to the updated manifest file; Using the acquired manifest files, generate configuration information representing a configuration of the objects that configure the service, and store the generated configuration information in association with the change ID; When the output instruction is received, the latest change ID is identified from among the plurality of change IDs; a computer system that generates and outputs display information for displaying the configuration information associated with the identified change ID and the extracted operation history.

9. A method for managing an operation history of a platform executed by a computer system, comprising: The computer system comprises: A platform that provides the resources to realize the service, A version control system that manages the version of a manifest file that describes settings for constructing the service; a platform management system that generates commands for the platform based on the manifest file and outputs the commands to the platform; The method for managing the operation history of the board includes: a first step of receiving, by the computer system, a notification from the version control system in association with an update of the manifest file, the notification including a change ID corresponding to the version of the manifest file; A method for managing the operation history of an infrastructure, characterized in that it includes a second step in which the computer system sends an instruction to execute a change operation including the change ID to the infrastructure management system so that an operation history of the change operation associated with the command and the change ID is saved.

10. A method for managing an operation history of a board according to claim 9, comprising: the computer system is connected to a database that stores an operation history of operations performed by the platform so as to be accessible to the database; The method for managing the operation history of an infrastructure is characterized in that it includes a third step in which, when an instruction to output the operation history of a change operation accompanying an update of the manifest file is received, the computer system extracts the operation history associated with the change ID from the database and outputs it.

11. A method for managing a board operation history according to claim 10, comprising: The service is composed of a plurality of objects, the plurality of objects are in a hierarchical structure, There is a dependency relationship between the objects in different hierarchical levels, a manifest file exists for each of the objects; The second step includes: a step of determining whether or not exclusive control is required for the object that is changed in association with the update of the manifest file and for the object that has a dependency relationship with the object; A method for managing the operation history of an infrastructure, comprising: when it is determined that exclusive control is not necessary for the object that is changed due to the update of the manifest file and the object that has a dependency on the object, the computer system sends an instruction to execute the change operation.

12. A method for managing a board operation history according to claim 11, comprising: The operation history is data configured from fields for storing a time, an operation content, the object to be operated, and the change ID, The output instruction includes identification information of the object and the two change IDs, The third step includes: a step of the computer system accessing the version control system to identify registration times of the manifest file corresponding to the two change IDs included in the output instruction; acquiring, by the computer system, the change ID of the manifest file of the object specified by the output instruction, the manifest file having a registration time included in a time period determined by the two specified registration times; a step of the computer system extracting, from the database, the operation history including either the change ID included in the output instruction or the change ID acquired from the version control system; A method for managing the operation history of an infrastructure, characterized in that the computer system extracts from the database the operation history relating to the object specified by the output instruction, where the time is included in the time zone and does not include the change ID, or includes the change ID included in the output instruction and a change ID that is different from the change ID obtained from the version control system.

13. A method for managing a board operation history according to claim 11, comprising: The operation history is data configured from fields for storing a time, an operation content, the object to be operated, and the change ID, the output instruction includes identification information of the object and a time period; The third step includes: the computer system accessing the version control system to obtain the change ID of the manifest file of the object specified by the output instruction, the manifest file having a registration time included in the time zone; The computer system extracts, from the database, the operation history including any of the change IDs obtained from the version control system; A method for managing the operation history of an infrastructure, comprising: a step in which the computer system extracts from the database the operation history, the time being included in the time zone and not including the change ID, or including the change ID that is different from the change ID obtained from the version control system.

14. A method for managing a board operation history according to claim 11, comprising: The second step includes: The computer system accesses the version control system to obtain the updated manifest file and the manifest files of other objects of the service that are configured from the object corresponding to the updated manifest file; a step of the computer system generating configuration information representing a configuration of the objects that configure the service using the acquired manifest files, and storing the generated configuration information in association with the change ID; The third step includes: a step of the computer system identifying the latest change ID from among a plurality of change IDs; A method for managing the operation history of an infrastructure, comprising: a step in which the computer system generates and outputs display information for displaying the configuration information associated with the identified change ID and the extracted operation history.

Images