JP2021135548A - Processor, processing method, and program - Google Patents

Abstract

To suppress overlooking of error while applying automatization for preventing operation error by manual work.SOLUTION: A processor comprises: a task executing part 12 for serving as a first processing part for executing a first task in a workflow including the first task and a second task, for changing a state of a first component of a server of a performance environment 50 as a first unit, from a first state to a second state; a result approval input part 14 for serving as a second processing part for acquiring first information from an operator after reporting information on an execution result of the first task to the operator; and a restoration processing part 16 for serving as a third processing part for executing predetermined processing, if the first information is second information indicating a denial.SELECTED DRAWING: Figure 1

Description

The present invention relates to processing equipment, processing methods and programs.

Maintenance may be performed on the operating system as an operation management task. It is considered desirable to automate this maintenance with as little human intervention as possible in order to prevent operational mistakes and the like. For example, set the setting information confirmed in the test environment on the command line, script it, and automatically execute it in the production environment. Here, each command line is called a task, and the work unit that is a set of them is called a workflow.

If there is a difference between the test environment and the production environment, the workflow executed in the test environment cannot be applied to the production environment as it is. Conventionally, a technique described in Patent Document 1 has been proposed as a method for solving the problem.

Japanese Unexamined Patent Publication No. 2012-146089

However, if it is automatically executed by the workflow system, the processing will be completed in an instant, so even if the setting information has been verified in the test environment, there is a possibility that an error may be overlooked. An error is, for example, a case where the task itself is not completed normally, or a case where the process is completed normally but the result is incorrect. In addition, there are cases where the customer is required to manually confirm the work result as an operation requirement, but there is a problem that the requirement cannot be satisfied only by automatically executing the workflow.

The present invention has been made in view of the above problems, and provides a processing device, a processing method, and a program capable of suppressing oversight of errors while applying automation for preventing operation mistakes due to manual work. It is a thing.

In order to solve the above problems, the processing apparatus according to the present invention changes the state of the first component of the first apparatus from the first state to the second state, so that the first task and the second task The first processing unit that executes the first task in the workflow including the above, and the second processing that acquires the first information from the operator after notifying the operator of the information of the execution result of the first task. It has a unit and a third processing unit that executes a predetermined process if the first information is the second information indicating denial, and the first processing unit is the first processing unit. If the information is the third information indicating approval, the second task in the workflow is executed in order to change the state of the second component of the first device from the third state to the fourth state. It is characterized by doing.

Further, the processing method according to the present invention is a processing method of a processing device that executes a workflow including a task, and the processing device changes the state of the first component of the first device from the first state to the second state. In order to change to the state of, the operator is notified of the information of the first processing step for executing the first task in the workflow including the first task and the second task and the execution result of the first task. After that, a second processing step of acquiring the first information from the operator, and a third processing step of executing a predetermined process if the first information is the second information indicating denial. And, in the first processing step, if the first information is the third information indicating approval, the state of the second component of the first apparatus is changed from the third state to the fourth. The second task in the workflow is executed in order to change to the state of.

In addition, the program according to the present invention changes the state of the first component of the first device from the first state to the second state of the computer that executes the workflow including the task, so that the computer is referred to as the first task. After notifying the operator of the information on the execution result of the first processing unit and the first task that executes the first task in the workflow including the second task, the first information is acquired from the operator. , The second processing unit, if the first information is the second information indicating denial, it functions as a third processing unit that executes a predetermined process, and the first processing unit is the first processing unit. If the information 1 is the third information indicating approval, the second task in the workflow is to change the state of the second component of the first device from the third state to the fourth state. It is characterized by executing.

According to the present invention, it is possible to prevent an error from being overlooked while applying automation for preventing an operation error due to manual work.

It is an overall block diagram of the workflow system which concerns on embodiment of this invention. This is an example of a workflow description file. This is an example of an execution history DB (Data Base). It is an example of the flowchart which shows the operation of the workflow system which concerns on embodiment of this invention. It shows the change in the contents of the execution history DB as the process progresses.

Hereinafter, embodiments for carrying out the present invention will be described in detail with reference to the drawings as appropriate.
Each figure is only schematically shown to the extent that the present invention can be fully understood. Therefore, the present invention is not limited to the illustrated examples. Further, in the present embodiment, description may be omitted for configurations that are not directly related to the present invention and well-known configurations. In each figure, common components and similar components are designated by the same reference numerals, and duplicate description thereof will be omitted.

<< Configuration of workflow system according to the embodiment >>
The workflow system 100 according to the embodiment will be described with reference to FIG. FIG. 1 is an overall configuration diagram of the workflow system 100 according to the embodiment. The workflow system 100 includes a workflow execution device 10, a workflow DB 20, an execution history DB 30, a test environment 40, and a production environment 50.

The test environment 40 is a system composed of a group of servers including a plurality of servers. On each server, middleware and applications are running on the OS (Operating System). Further, the production environment 50 is a system composed of a group of servers including a plurality of servers. In each server, middleware and applications are running on the OS.

The test environment 40 is a system for testing the operation in the production environment 50. The system configurations of the test environment 40 and the production environment 50 are registered in a CMDB (Configuration Management Database) (not shown). The CMDB automatically derives and manages the dependencies between servers and between configuration items such as applications running on the servers.

In this embodiment, it is assumed that maintenance is performed on a server (sometimes referred to as a “target host”) operating in the production environment 50. Server maintenance includes, for example, changing control parameters, changing configuration files, and replacing programs (including version upgrades and bug fixes). For example, the setting information confirmed in the test environment 40 is set on the command line, scripted, and automatically executed in the production environment 50. As mentioned above, each command line is called a "task", and the work unit that is a set of them is called a "workflow".

The workflow execution device 10 is an example of a “processing device”, and an example of the “processing device” is not limited to the workflow execution device 10.
Further, the server in the production environment 50 is an example of the "first device", and the example of the "first device" is not limited to the server in the production environment 50.

The workflow DB 20 stores a workflow (sometimes called a workflow file) executed in the production environment 50. The workflow stored in the workflow DB 20 is created by using, for example, the workflow execution device 10, and is confirmed in the test environment 40.

FIG. 2 is an example of a workflow description file. FIG. 2 shows a workflow for changing control parameters. In this example, each task (1) to (5) is described in sentences, but it is actually a command line that realizes the described contents.
-In the task (1), the "parameter (i)" of the "program A" of the "server 1" is changed to the "value X".
-In the task (2), the "parameter (ii)" of the "program A" of the "server 1" is changed to the "value Y".
-In the task (3), the "parameter (iii)" of the "program B" of the "server 2" is changed to the "value Z".
-In task (4), restart "Server 1".
-In task (5), "Server 2" is restarted.

The execution history DB 30 stores various information related to the execution of the workflow. The execution history DB 30 stores, for example, execution history information for each task. One of the execution history information is, for example, the execution result of a task.

FIG. 3 is an example of the execution history DB 30. The execution history DB 30 shown in FIG. 3 includes a "task number" column 31, a "target host" column 32, a "task execution result" column 33, a "result approval" column 34, an "approver" column 35, and an "execution history log". A “file” column 36 is provided. A new record is added to the execution history DB 30 every time a task is executed.

Information for identifying the task is stored in the "task number" column 31. In this embodiment, each command line is called a task, and a work unit that is a set thereof is called a workflow.

In the "target host" column 32, information on the device (target host) for which the task is executed is stored. For example, when executing a workflow in the production environment 50, the server in the production environment 50 corresponds to the target host.

In the "task execution result" column 33, the status due to the execution of the task is stored. For example, if the task can be executed normally, "OK" is stored, and if the task cannot be executed normally, "NG" is stored.

In the "result approval" column 34, information indicating the operator's judgment (approval / rejection of task completion) regarding the execution of the task is stored. For example, if the operator confirms that the task can be executed normally, "OK" indicating "approval" is stored, and if the operator cannot confirm that the task can be executed normally, "denial" is stored. "NG" indicating "" is stored.

In the "Approver" column 35, the nomination of the operator who has determined whether or not the task can be executed normally is stored.

Information related to the task execution history (for example, log file) is stored in the "execution history log file" column 36. The information stored in the "execution history log file" column 36 may be the log file itself (may be a part) or information (path) indicating the location where the log file is stored. The log file may be, for example, a system log, a middleware log, or an application log.

The workflow execution device 10 is a device that executes a workflow in the production environment 50 and the test environment 40. Since the present embodiment focuses on the execution of the workflow in the production environment 50, it is intended to be executed in the production environment 50 unless otherwise specified. In the execution of the workflow by the workflow execution device 10, the execution result approval step is provided, and the execution of the next task is not started unless the execution result is approved by the operator. The details will be described below.

The workflow execution device 10 shown in FIG. 1 includes a workflow generation unit 11, a task execution unit 12, an execution history collection unit 13, a result approval input unit 14, an execution history recording unit 15, and a restoration processing unit 16. ..

The workflow generation unit 11 has a function for generating a workflow. For example, as a function of the workflow generation unit 11, a function of manually inputting using a text editor can be considered. Further, depending on the setting information, a function of automatically scripting an operation manually executed in the test environment 40 and incorporating it into the workflow as it is can be considered. For example, the operation performed by using the mouse in the test environment 40 is recorded, and the operation is saved in a file (the operation is scripted). Then, in the production environment 50, the file in which the operation is scripted is executed. It is also possible to script multiple commands. In that case, multiple commands are executed by executing the scripted file. The generated workflow is stored in the workflow DB 20.

The task execution unit 12 executes the tasks described as workflows one by one in the production environment 50. When the task execution result is returned from the production environment 50, the task execution unit 12 acquires the task execution result (execution result value). The execution result of the task is, for example, the status due to the execution of the task. The task execution unit 12 enables the operator to confirm, for example, the acquired execution result. The task execution unit 12 may positively notify the terminal operated by the operator of the execution result. In that case, the display method is not particularly limited, and for example, a pop-up display may be used.

The execution history collection unit 13 acquires the execution history (for example, log file (including system log, middleware log, application log)) of the target host (here, the server in the production environment 50) and writes it in the log file. Allow the operator to confirm any messages that have been sent. The execution history collection unit 13 may positively notify the terminal operated by the operator of the message written in the log file (the log file itself may be used). In that case, the display method is not particularly limited, and for example, a pop-up display may be used.

The result approval input unit 14 is a function for realizing the operator's approval for the execution of the task. The result approval input unit 14 inputs information related to the operator's judgment based on the operator's input operation shown below (that is, acquires information related to the operator's judgment).
Here, the operator confirms the message of the task execution result (for example, status) and execution history (for example, log file) for each task execution, and makes the operator's judgment (approval or denial of task completion) in the result approval input unit. Enter for 14. The content to be confirmed by the operator may be one or both of the task execution result (for example, status) and the execution history (for example, log file) message. When checking both the task execution result and the execution history, the order of checking is not particularly limited. Depending on the specification method in the workflow, the operator may check the execution result and execution history after executing a plurality of tasks at once.

Further, the result approval input unit 14 notifies the terminal operated by the operator of information (judgment standard information) as a reference for determining the suitability of the task status and the message of the log file (that is, the approval or disapproval of the completion of the task). May be good. The judgment criterion information may be, for example, a checklist.

The execution history recording unit 15 records the information acquired by the task execution unit 12, the execution history collection unit 13, and the result approval input unit 14 in the execution history DB 30. For example, the execution history recording unit 15 acquires the task number, the target host information, and the task execution result from the task execution unit 12, and has the "task number" column 31 and the "target host" column of the execution history DB 30 shown in FIG. 32, Register in the "task execution result" column 33. Further, the execution history recording unit 15 acquires a message (may be the log file itself) written in the log file from the execution history collecting unit 13, and puts it in the “execution history log file” column 36 of the execution history DB 30 shown in FIG. to register. Further, the execution history recording unit 15 acquires the task completion approval / disapproval information and the operator information input by the operator from the result approval input unit 14, and the “result approval” column 34 of the execution history DB 30 shown in FIG. Register in the "Approver" column 35.

The execution history recording unit 15 may have a function of notifying the operator of the information stored in the execution history DB 30 instead of the other functions.

When the operator denies the completion of the task, the restoration processing unit 16 executes a predetermined process. The processing executed by the restoration processing unit 16 is, for example, as follows.
(A) Perform a process to return to the state before the task whose completion was denied is executed (first response process).
(B) Performs a process of returning to the state before the workflow including the task whose completion is denied is executed (second response process).
(C) Performs a process of terminating the workflow including the task whose completion is denied in the middle (third response process).
(D) Perform the process of executing the workflow including the task whose completion is denied to the end (fourth response process). In this case, it is preferable to notify the operator of the information of the task whose completion is denied.

When the operator approves the completion of the task, the task execution unit 12 executes the next task, and similarly receives the approval of the task completion from the operator.

The task execution unit 12 is an example of the “first processing unit”, and the example of the “first processing unit” is not limited to the task execution unit 12.
Further, the execution history collection unit 13 and the result approval input unit 14 are examples of the "second processing unit", and an example of the "second processing unit" is limited to the execution history collection unit 13 and the result approval input unit 14. is not it.
Further, the restoration processing unit 16 is an example of the “third processing unit”, and the example of the “third processing unit” is not limited to the restoration processing unit 16.

The message included in the task execution result (for example, status) and execution history (for example, log file) is an example of "execution result information", and an example of "execution result information" is an example of task execution result (for example, status). ) And the message included in the execution history (for example, log file).
Further, the task completion approval / disapproval information input by the operator is an example of the "first information", and the example of the "first information" is not limited to the task completion approval / disapproval information.

<< Operation of workflow system according to the embodiment >>
The operation of the workflow system 100 according to the embodiment will be described with reference to FIGS. 4 and 5 (see FIGS. 1 to 3 as appropriate).

First, the workflow generation unit 11 is a workflow (a work unit that is a set of command lines) based on an operator's input operation (command line editing by the operator, command line operation / storage, etc.) related to each command line. Is created (step S101).
A simple method is to manually edit and create a command line that is a task with a text editor. Alternatively, it is conceivable to use a tool that memorizes the operation once manually performed for automatic execution. Such a tool can perform the same operation many times by giving a predetermined instruction. The workflow generation method is not specified here. The created workflow is stored in the workflow DB 20.

Next, the workflow system 100 inputs a predetermined workflow execution instruction by the operator, and the task execution unit 12 sequentially executes the tasks of the workflow in which the execution instruction is instructed (step S102).
As shown in FIG. 2, a workflow is basically a collection of tasks to be executed sequentially. The task execution unit 12 reads the task described in the workflow description file, analyzes the description content, and executes the specified command to the target host (here, the server in the production environment 50).

Next, if the command line (task) status exists, the execution history recording unit 15 acquires the status as the task execution result from the task execution unit 12 and records it in the execution history DB 30 (step S103). ..
FIG. 5A shows the state of the execution history DB 30 in step S103 when the “task 1” is executed.

After the execution of the task is completed, the execution history collection unit 13 confirms whether or not error information is output from the OS, middleware, and application to the system log, middleware log, and application log. The execution history collecting unit 13 acquires the latest output information from the target log file and displays the output information on the screen of the terminal operated by the operator so that the operator can immediately notice it (step S104).
The execution history collection unit 13 acquires not only the log file but also a capture of a predetermined confirmation screen (for example, a screen for displaying the information set in the task), and displays the screen on the screen of the terminal operated by the operator. You may let me. Further, although the execution history information related to each task may differ, the execution history collection unit 13 has a function of designating the collection contents of the execution history for each task in advance, so that a wide variety of executions can be performed. You can collect history. The execution history recording unit 15 records the collected execution history (for example, a log file) in the execution history DB 30 (step S104). FIG. 5B shows the state of the execution history DB 30 in step S104 when "task 1" is executed.

Next, the operator refers to the execution result and execution history of the task on a task-by-task basis, and determines whether or not the task can be executed normally. The result approval input unit 14 waits for input until the operator inputs the task approval result (step S105).
If the operator confirms that the execution was successful, enter the approval. Generally, the method of pressing the approval button can be considered. On the other hand, if the result is different from the expected result and the approval cannot be obtained, for example, the method of pressing the denial button is adopted. The execution history recording unit 15 records the input approval / disapproval information and the information of the operator who performed the approval / disapproval in the execution history DB 30. FIG. 5C shows the state of the execution history DB 30 after recording the approval / disapproval information when the “task 1” is executed.

If the operator approves (“OK” in step S106), the result approval input unit 14 determines whether all the tasks have been completed (step S107), and if not, returns to step S102, and the task execution unit 12 returns to step S102. , Move on to the execution of the next task.
The state of the execution history DB 30 after executing the “task 2” is shown in FIG. 5 (d). If all tasks have been completed, the workflow execution ends. FIG. 5 (e) shows the state of the execution history DB 30 after executing all the tasks “tasks 1 to 5”.

On the other hand, if the result approval input unit 14 is not approved by the operator (“NG” in step S106), for example, the task execution result must be returned before execution, so that the restoration processing unit 16 returns a predetermined change. (Step S108).

As described above, according to the workflow execution device 10 and the workflow system 100 according to the present embodiment, by providing the execution result approval step for each task, the operator can obtain the execution result and the execution history of each automatically executed task. You can check. Therefore, since the operator judges the execution result while applying automation to prevent operation mistakes due to manual work, it is possible to prevent overlooking an error.
In addition, the approval result and the execution history that is the basis are recorded and saved. Therefore, it is possible to confirm that there is no omission of the check after the fact, and if there is a mistake, it is easy to investigate the cause.
Further, the workflow execution device 10 and the workflow system 100 according to the present embodiment are only for the worker for the work (re-examination) in a two-person system of the worker and the confirmer (the person who confirms the work content of the worker). It can be replaced with the work of one person (here, the work of two people (re-examination) is the case where the customer is required to manually confirm the work result as an operational requirement, and the workflow. This is an example of the work to be done in case the operation requirements cannot be satisfied only by the automatic execution in.).

Although the embodiments of the present invention have been described above, the present invention is not limited to this, and can be carried out within a range that does not change the gist of the claims.

10 Workflow execution device 11 Workflow generation unit 12 Task execution unit 13 Execution history collection unit 14 Result approval input unit 15 Execution history recording unit 16 Restoration processing unit 20 Workflow DB
30 Execution history DB
40 Test environment 50 Production environment 100 Workflow system

Claims (7)

A first task of executing the first task in a workflow including a first task and a second task in order to change the state of the first component of the first device from the first state to the second state. Processing unit and
A second processing unit that acquires the first information from the operator after notifying the operator of the information on the execution result of the first task.
If the first information is the second information indicating denial, it has a third processing unit that executes a predetermined process.
The first processing unit
If the first information is the third information indicating approval, the second component in the workflow changes the state of the second component of the first device from the third state to the fourth state. To perform the task of
A processing device characterized by the fact that. If the first information is the second information indicating denial, the third processing unit may use the third processing unit.
A first response process, which returns the state of the first component of the first device from the second state to the first state.
A second response process, which returns the state of all the components of the first device changed by the workflow.
A third response process, which terminates the execution of the workflow in the middle.
Fourth response processing, which executes the execution of the workflow to the end,
The processing apparatus according to claim 1, wherein any of the above is executed. The information on the execution result is
One or both of the status due to the execution of the first task and the message contained in the log file relating to the execution of the first task.
The processing apparatus according to claim 1 or 2, wherein the processing apparatus is characterized in that. The second processing unit
Pop-up display of the execution result information on the terminal operated by the operator.
The processing apparatus according to any one of claims 1 to 3, wherein the processing apparatus is characterized in that. The second processing unit
Further notify the operator of the judgment standard information which is the standard for judging the suitability of the execution result information.
The processing apparatus according to any one of claims 1 to 4, wherein the processing apparatus is characterized in that. A processing method of a processing device that executes a workflow including a task.
The processing device is
A first task of executing the first task in a workflow including a first task and a second task in order to change the state of the first component of the first device from the first state to the second state. Processing steps and
A second processing step in which the operator is notified of the information on the execution result of the first task and then the first information is acquired from the operator.
If the first information is the second information indicating denial, it has a third process step of executing a predetermined process.
In the first processing step,
If the first information is the third information indicating approval, the second component in the workflow changes the state of the second component of the first device from the third state to the fourth state. To perform the task of
A processing method characterized by that. A computer that performs a workflow that includes tasks
A first task of executing the first task in a workflow including a first task and a second task in order to change the state of the first component of the first device from the first state to the second state. Processing unit,
The second processing unit, which acquires the first information from the operator after notifying the operator of the information on the execution result of the first task.
If the first information is the second information indicating denial, it is made to function as a third processing unit that executes a predetermined process.
The first processing unit
If the first information is the third information indicating approval, the second component in the workflow changes the state of the second component of the first device from the third state to the fourth state. To perform the task of
A program characterized by that.

Images