JP2015095105A - Recovery procedure update system, recovery procedure update method, and recovery support program - Google Patents

Abstract

An object of the present invention is to reduce the number of steps for correcting an automation flow.
A recovery procedure update system 1 having a work automation system 220 for handling a failure that occurs in a monitored device 120 by executing an automation flow 290, and a command for restoring the automation flow 290 A recovery support system 230 that generates an operation log file 270 that is an input history of the command, and the recovery support system 230 uses a command included in the operation log file 270 for a recovery script 280 that is a program for recovering the automation flow 290. Update based on
[Selection] Figure 1

Description

  The present invention relates to a recovery procedure update system, a recovery procedure update method, and a recovery support program.

  In the fault monitoring operation business, the service desk performs a primary response (hereinafter sometimes referred to as workaround) to a fault that occurs in the monitoring target device. In recent years, the number of workaround processes has increased with the increasing complexity of monitored devices. In order to automatically perform workaround, RBA (Run Book Automation) that automates system operation has been introduced. An RBA tool, which is a product for automating system operation, has an operation procedure for automating operation (hereinafter sometimes referred to as an automation flow).

  For example, there exists Unexamined-Japanese-Patent No. 2009-181441 (patent document 1). According to this publication, “each client is based on an incident data extraction unit that extracts incident information including its own identification information and time data when a defect occurs, and determination condition data indicating predetermined defect determination conditions. A check list processing unit that determines whether or not a failure has occurred, and a command that is associated in advance with determination condition data in order to eliminate the failure that has occurred, if a failure has occurred. The management command is transmitted to the repair command execution unit that executes the command, and the incident data and the information indicating the command execution result ”.

JP 2009-181441 A

  The technique described in Patent Literature 1 can automatically perform workaround for a failure that occurs in a specific monitoring target device.

  Here, when the operation by the automation flow fails, it is necessary to restore the automation flow. The command for restoring the automation flow differs depending on the software and hardware configuration of each monitored device. When the monitored device is a system of multiple customers, the software and hardware configurations of each monitored device are different, and a lot of man-hours are required to apply the corresponding command to each automation flow. It was.

  An object of the present invention is to provide a technique that makes it possible to reduce the number of steps for correcting an automation flow.

  Of the inventions disclosed in the present application, the outline of typical ones will be briefly described as follows.

  An embodiment of the present invention is a recovery procedure update system having a work automation system that performs a response to a failure that has occurred in a monitored device by executing an automation flow, and for restoring the automation flow It has a recovery support system that generates an operation log file that is a history of command input. The recovery support system updates a recovery script, which is a program for recovering the automation flow, based on the command included in the operation log file.

  In another embodiment, the present invention provides a recovery procedure update method using a recovery procedure update system having a work automation system for handling a failure that occurs in a monitored device by executing an automation flow. The support system includes an operation log file generation step of generating an operation log file that is a history of command input for restoring the automation flow. The recovery support system further includes a recovery script update step of updating a recovery script, which is a program for recovering the automation flow, based on the command included in the operation log file.

  In another embodiment, there is a recovery support program for causing a computer to function as a recovery support system included in a recovery procedure update system that performs a response to a failure that occurs in a monitored device by executing an automation flow. Then, the recovery support system causes the computer of the recovery support system to execute an operation log file generation step of generating an operation log file that is a history of command input for recovering the automation flow. Further, the recovery support system updates a recovery script, which is a program for recovering the automation flow, based on the command included in the operation log file, and executes a recovery script update step on the computer of the recovery support system Let

  Among the inventions disclosed in the present application, effects obtained by typical ones will be briefly described as follows.

  According to the representative embodiment of the present invention, the number of steps for correcting the automation flow can be reduced.

It is a figure which shows the outline | summary of the structural example of the recovery procedure update system in one embodiment of this invention. It is a figure which shows the structural example of the data which incident DB memorize | stores in one embodiment of this invention. It is a figure which shows the outline | summary of the whole process in one embodiment of this invention. It is a figure which shows the outline | summary of the process of the automation flow in one embodiment of this invention. It is a figure which shows the outline | summary of the structural example of the script for process 1 restoration before update in one embodiment of this invention. It is a figure which shows the outline | summary of the structural example of the script for the process 1 after an update in one embodiment of this invention. It is a figure which shows the outline | summary of the structural example of the necessity list screen of correspondence in one embodiment of this invention. It is a figure which shows the outline | summary of the structural example of the operation log file in one embodiment of this invention. It is a figure which shows the outline | summary of the structural example of the recovery procedure selection screen in one embodiment of this invention.

  Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. Note that components having the same function are denoted by the same reference symbols throughout the drawings for describing the embodiment, and the repetitive description thereof will be omitted.

  The recovery procedure update system according to an embodiment of the present invention includes a work automation system that performs a response to a failure that occurs in a monitored device by executing an automation flow. In addition, after an error occurs in the executed automation flow, a recovery script that is a program for restoring the automation flow is executed. If the automation flow does not recover even after executing the recovery script, the automation flow is recovered by accepting an operation from the service desk. Then, by updating the recovery script based on an operation log file that is an input history received from the service desk, the automated flow can be automatically recovered from the next time.

<System configuration>
FIG. 1 is a diagram showing an outline of a configuration example of a recovery procedure update system 1 according to an embodiment of the present invention.

  A recovery procedure update system 1 according to an embodiment of the present invention includes a data center 100 and a monitoring center 200 connected to the data center 100 via a network.

  The data center 100 includes a failure monitoring apparatus 110 and a plurality of monitoring target devices 120.

  The monitoring center 200 includes an incident management system 210, a work automation system 220, a recovery support system 230, a service desk terminal 240, an operation SE terminal 250, and an incident DB 260.

  In addition, the failure monitoring apparatus 110, the monitoring target device 120, the incident management system 210, the work automation system 220, the recovery support system 230, the service desk terminal 240, and the operation SE terminal 250 have predetermined hardware and software. Implemented by. For example, the failure monitoring apparatus 110, the monitoring target device 120, the incident management system 210, the work automation system 220, the recovery support system 230, the service desk terminal 240, and the operation SE terminal 250 are each a processor, a memory, and the like. And the program on the memory executed by the processor includes the failure monitoring device 110, the monitoring target device 120, the incident management system 210, the work automation system 220, the recovery support system 230, and the service desk terminal 240. Then, each computer with the operational SE terminal 250 is caused to function.

  When a failure occurs in the monitoring target device 120, the monitoring target device 120 inputs a failure message (described later, FIG. 2) to the failure monitoring apparatus 110.

  The failure monitoring apparatus 110 transmits the input failure message to the monitoring center 200.

  The incident management system 210 of the monitoring center 200 receives the failure message transmitted from the failure monitoring device 110. Then, the incident management system 210 stores the received failure message in the incident DB 260. Further, the incident management system 210 instructs the work automation system 220 to execute an automation flow 290 (described later, FIG. 4).

  The work automation system 220 executes an automation flow 290. Further, when an error occurs during the processing of the automation flow 290 and the automation flow 290 is not restored thereafter, the work automation system 220 inputs restoration instruction information to the restoration support system 230.

  When the recovery instruction information is input, the recovery support system 230 displays a response necessity list screen (described later, FIG. 7) on a display unit (for example, a display) of the service desk terminal 240.

  An operation terminal (for example, a keyboard) of the service desk terminal 240 receives an input of a command for restoring the automation flow 290 from the service desk 20.

  The recovery support system 230 generates an operation log file 270 that is an input history received from the service desk 20.

  The recovery support system 230 updates the recovery script 280, which is a program for recovering the automation flow 290, based on the command included in the operation log file 270.

<Incident DB>
FIG. 2 is a diagram illustrating a configuration example of data stored in the incident DB 260 according to the embodiment of this invention. As shown in FIG. 2, the incident DB 260 stores [failure ID], [classification], and a failure message in association with each other.

  [Fault ID] indicates a code for identifying a fault. [Fault ID] is automatically assigned when a fault message is stored in the incident DB 260. [Category] indicates whether the recovery script needs to be updated. “No action required” indicates that it is not necessary to update the recovery script. “Action required” indicates that the recovery script needs to be updated. [Category] stores “no action required” as an initial value.

  The failure message has data items such as [occurrence date / time], [customer name], and [failure content]. [Occurrence date and time] indicates the date and time when the failure occurred. [Customer name] indicates the name of the customer who owns the monitoring target device 120 in which a failure has occurred. [Failure content] indicates the content of the failure.

<Overall processing>
FIG. 3 is a diagram showing an overview of the overall processing in the embodiment of the present invention.

  First, in S301, each monitoring target device 120 of the data center 100 determines whether a failure has occurred. When it is determined that no failure occurs in any monitored device 120 (S301-No), the process proceeds to S301. On the other hand, when any one of the monitoring target devices 120 determines that a failure has occurred (S301-Yes), the process proceeds to S302.

  Next, in S <b> 302, the monitoring target device 120 inputs a failure message (described above, FIG. 2) to the failure monitoring apparatus 110.

  Next, in S303, the failure monitoring apparatus 110 transmits a failure message to the monitoring center 200.

  In step S <b> 304, the incident management system 210 of the monitoring center 200 receives the failure message transmitted from the failure monitoring apparatus 110. Then, the incident management system 210 stores the received failure message in the incident DB 260. Further, the incident management system 210 instructs the work automation system 220 to execute the automation flow 290.

  Next, in S305, the work automation system 220 executes an automation flow 290 (described later, FIG. 4). Hereinafter, the automation flow 290 will be described with reference to FIG.

  FIG. 4 is a diagram showing an outline of the processing of the automation flow 290 according to the embodiment of the present invention.

  The automation flow 290 includes processing 1 and processing 2 that are workarounds, processing 1 recovery processing that is a program for recovering processing 1, and processing 2 recovery processing that is processing for recovering processing 2.

  The process 1 recovery process, which is an error trap of process 1, is executed when an error occurs during the process 1. In the process 1 recovery process, a process 1 recovery script that is a process for recovering process 1 is executed.

  The process 2 recovery process, which is an error trap of process 2, is executed when an error occurs during the process 2. In the process 2 recovery process, a process 2 recovery script, which is a program for recovering process 2, is executed. Hereinafter, a configuration example of the processing 1 recovery script will be described with reference to FIGS. 5 and 6.

  FIG. 5 is a diagram showing an outline of a configuration example of the script for the process 1 restoration before update in the embodiment of the present invention. As shown in FIG. 5, the script for processing 1 before update does not include a command for restoring processing 1, but a command for instructing the restoration support system 230 to restore (hereinafter referred to as restoration instruction information). In some cases). In addition, the recovery instruction information consists of a character string such as “[IncidentID: 90] [XXXXXX automated flow process 1] [Processing 1 recovery script]. Please respond at the service desk.” ID (“90” corresponds in FIG. 5) and an automation flow process name (“XXXX automation flow process 1” in FIG. 5).

  FIG. 6 is a diagram showing an outline of a configuration example of the process 1 recovery script after the update according to the embodiment of the present invention. As shown in FIG. 6, each command for restoring the first process is added to the updated script for process 1 restoration. In addition, a process for determining whether or not the process has been executed normally is added each time a command for restoring the first process is executed. If the process is not executed normally, a recovery instruction process is executed. When the recovery instruction process is executed, the work automation system 220 inputs the recovery instruction information to the recovery support system 230. The configuration of the processing 2 recovery script is the same as the configuration of the processing 1 recovery script. Further, the processing 1 recovery script and the processing 2 recovery script are appropriately updated when the operation SE terminal 250 receives an input from the operation SE 10 in a state where a recovery procedure selection screen (described later, FIG. 9) is displayed.

  Refer to FIG. 3 again. In step S <b> 306, the recovery support system 230 determines whether recovery instruction information has been input from the work automation system 220. When the recovery support system 230 determines that the recovery instruction information is not input (S306-No), the entire process is terminated. On the other hand, when the recovery support system 230 determines in S306 that the recovery instruction information has been input (S306-Yes), the process proceeds to S307.

  Next, in S307, the recovery support system 230 extracts the incident ID included in the recovery instruction information. Then, the recovery support system 230 searches the incident DB 260 using the extracted incident ID as a key, and updates the [classification] of the record corresponding to the key to “response required”.

  Next, in S308, the recovery support system 230 acquires all the data stored in the incident DB 260, and on the display unit (for example, display) of the service desk terminal 240 based on the acquired data, the correspondence necessity list screen ( FIG. 7) to be described later is displayed. Hereinafter, the correspondence necessity list screen will be described with reference to FIG.

  FIG. 7 is a diagram showing an outline of a configuration example of a correspondence necessity list screen according to the embodiment of the present invention. As shown in FIG. 7, the response necessity list screen includes [Fault ID], [Occurrence Date / Time], [Customer Name], [Failure Content] included in the record whose [Category] is “Correspondence Required”. Corresponding list of necessary trouble IDs 701, and [failure ID], [occurrence date / time], [customer name], and [failure contents] included in the record whose [category] is "no action required" A display of an unnecessary response ID list 702 to be displayed is displayed. By displaying the response necessity list screen, the service desk 20 can confirm an outline of a failure that needs to be addressed.

  Refer to FIG. 3 again. Next, in S <b> 309, the operation terminal of the service desk terminal 240 receives an input from the service desk 20 for restoring the automation flow 290.

  Next, in S <b> 310, the recovery support system 230 generates an operation log file 270 that is an input history received from the service desk 20. Hereinafter, the operation log file 270 will be described with reference to FIG.

  FIG. 8 is a diagram showing an outline of a configuration example of the operation log file 270 according to the embodiment of the present invention. As shown in FIG. 8, the operation log file 270 includes information such as an incident ID, an executed command, and a processing result. The command corresponds to “Ping A-Server”, “net stop”, “net start”, “http-Get www.xxxx.com”, and the like.

  Refer to FIG. 3 again. Next, in S311, the recovery support system 230 searches the operation log file 270 input using the incident ID extracted in S307 as a key, and acquires all corresponding commands. For example, when the operation log file 270 shown in FIG. 8 is searched using the incident ID “90” as a key, the recovery support system 230 reads “Ping A-Server”, “net stop”, and “net start” corresponding commands. "And" http-Get www.xxxx.com ". Note that the recovery support system 230 determines whether or not the operation log file 270 generated between the time when the failure occurs and the current time exists, and if not, the entire process is terminated. Anyway.

  Next, in S <b> 312, the recovery support system 230 displays a recovery procedure selection screen on the display unit of the operational SE terminal 250. In the recovery procedure selection screen, an input for selecting a command included in the recovery script 280 is accepted. Hereinafter, the recovery procedure selection screen will be described with reference to FIG.

  FIG. 9 is a diagram showing an outline of a configuration example of the recovery procedure selection screen according to the embodiment of the present invention. As shown in FIG. 9, the recovery procedure selection screen displays an incident ID 901, an application column 902, a command 903, a reflection destination 904, a script name 905, and an OK button 906.

  In the incident ID 901, the incident ID 901 extracted in S307 is displayed. In the command 903, each command 903 acquired in S311 is displayed. In the application column 902, “●” or “◯” is displayed for the corresponding command 903 according to the input received from the operation SE10. In the reflection destination 904, the automation flow process name included in the recovery instruction information input in S305 is displayed. As the script name 905, the script name 905 that has received an input from the operation SE10 is displayed. When the operational SE terminal 250 receives an input selected by the OK button 906 from the operational SE 10, the process proceeds to S313.

  Refer to FIG. 3 again. Next, in S313, the recovery support system 230 adds all the commands 903 for which “●” is displayed in the application column 902 shown in FIG. 9 to the updated recovery script 280. Furthermore, the recovery support system 230 adds a determination process for determining whether the added command 903 has been executed normally to the updated recovery script 280. Then, the recovery support system 230 updates the recovery script 280 before update (described above, FIG. 5) to the updated recovery script 280 (described above, FIG. 6).

  Here, S310 corresponds to an operation log file generation step. S313 corresponds to a recovery script update step.

<Effects of the present embodiment>
According to the recovery procedure update system 1 in the present embodiment described above, the man-hour for correcting the automation flow 290 can be reduced by updating the recovery script 280 based on the command included in the operation log file 270. Become. Furthermore, by updating the recovery script 280 separated from the processing of the automation flow 290, the automation flow 290 can be recovered without changing the processing of the automation flow 290. Furthermore, when the same failure occurs next time, the automated flow 290 can be automatically restored.

  As mentioned above, the invention made by the present inventor has been specifically described based on the embodiment. However, the present invention is not limited to the embodiment, and various modifications can be made without departing from the scope of the invention. Needless to say.

DESCRIPTION OF SYMBOLS 10 ... Operation SE, 20 ... Service desk, 100 ... Data center, 110 ... Fault monitoring apparatus, 120 ... Monitored device, 200 ... Monitoring center, 210 ... Incident management system, 220 ... Work automation system, 230 ... Recovery support system, 240 ... Service desk terminal, 250 ... Operational SE terminal, 260 ... Incident DB, 270 ... Operation log file, 280 ... Recovery script, 290 ... Automation flow, 701 ... Corresponding fault ID list, 702 ... Corresponding fault ID list, 901 ... Incident ID, 902 ... Application column, 903 ... Command, 904 ... Reflection destination, 905 ... Script name

Claims (3)

It is a recovery procedure update system having a work automation system that responds to failures that occur in monitored devices by executing an automation flow,
A recovery support system that generates an operation log file that is a history of command input for recovering the automation flow;
The recovery support system is a recovery procedure update system in which a recovery script, which is a program for recovering the automation flow, is updated based on the command included in the operation log file. It is a recovery procedure update method using a recovery procedure update system having a work automation system that responds to failures that occur in monitored devices by executing an automation flow,
An operation log file generation step in which the recovery support system generates an operation log file that is a history of command input for recovering the automation flow;
A recovery script update step in which the recovery support system updates a recovery script, which is a program for recovering the automation flow, based on the command included in the operation log file;
A recovery procedure update method. A recovery support program for causing a computer to function as a recovery support system possessed by a recovery procedure update system that responds to a failure that occurred in a monitored device by executing an automation flow,
An operation log file generating step for generating an operation log file that is a history of command input for the recovery support system to recover the automation flow;
A recovery script update step in which the recovery support system updates a recovery script, which is a program for recovering the automation flow, based on the command included in the operation log file;
A recovery support program for causing a computer of the recovery support system to execute