Failure recovery assistance device, failure recovery assistance method, and program

Abstract

This failure recovery assistance device assisting handling for recovering from a failure in a network includes a storage unit storing an event in the network and a failure handling pattern in association with each other, and a failure handling processing unit determining, by referencing the storage unit, a failure handling pattern corresponding to the event identified in the network.

Description

Disaster recovery support device, disaster recovery support method, and program

[0001] The present invention relates to a network maintenance technique.

[0002] Server virtualization and network virtualization technologies are becoming more prevalent in various network systems. When building a new network, various server and network virtualization technologies are combined to build the system. In particular, large-scale systems running multiple servers and systems related to social infrastructure tend to be complex.

[0003] When a failure occurs in a system like the ones described above, different procedures are required for each system to identify the cause of the failure and restore the system. In other words, since the propagation of the cause of the failure varies depending on the system configuration, the procedures for failure analysis and response differ for each system. For this reason, when a system failure occurs, failure analysis and response are carried out by failure analysts with advanced knowledge and skills who determine the procedures based on their experience and know-how.

[0004] When a network system failure occurs, a large number of error messages are generated due to a specific malfunction, making it difficult to identify the cause of the failure. It is particularly difficult for inexperienced failure analysts (with low analytical skills) to select appropriate points to check and determine the procedures to follow based on the large amount of error messages generated.

[0005] In light of this background, a fault analysis support technology has been proposed that helps a fault analyst efficiently identify potential fault locations when a fault occurs in a network system (Patent Document 1).

[0006] Patent No. 6754338

[0007] Although the technology disclosed in Patent Document 1 can support fault analysis, the fault analysis work is performed by an operator (which may also be called a maintenance technician.) Even if the cause and location of the fault are identified, the commands for checking the fault differ depending on the device manufacturer, operation system, etc., so a highly skilled person is required to handle the work.

[0008] Furthermore, when responding to identified faults, just as with fault analysis, fault analysts with advanced knowledge and skills determine procedures based on their experience and know-how. Even when it comes to troubleshooting, even something as simple as reconfiguring a device, the actual response varies depending on the equipment vendor and operating system. Furthermore, with multiple response methods available, it is difficult to select and implement the optimal response. It is particularly difficult for inexperienced (low-skilled) troubleshooting personnel (operators) to select the appropriate response points and determine the response procedures based on identified fault information.

[0009] The present invention has been made in view of the above points, and has an object to provide a technique for supporting measures to recover from a network failure.

[0010] According to the disclosed technology, there is provided a fault recovery support device that supports responses to recover from faults in a network, the fault recovery support device comprising: a storage unit that stores events in the network in association with fault response patterns; and a fault response processing unit that determines a fault response pattern corresponding to an event identified in the network by referring to the storage unit.

[0011] The disclosed technology provides a technology for supporting measures to recover from a network failure.

[0012] 1 is a diagram showing the overall configuration of a system. FIG. 2 is a diagram showing an example of the configuration of a failure recovery support device 100. FIG. 3 is a diagram showing an example of the configuration of a response policy processing unit 140. FIG. 4 is a diagram showing an example of the configuration of a failure confirmation processing unit 150. FIG. 5 is a diagram showing an example of the configuration of a failure response processing unit 160. FIG. 6 is a diagram showing the overall flow of processing executed by the failure recovery support device 100. A flowchart showing failure confirmation processing. A diagram showing an example of failure confirmation template information. A diagram showing an image of a failure confirmation command. A diagram showing an example of event identification information. A flowchart showing failure response processing. A diagram showing an example of failure response pattern information. A diagram for explaining a specific example of operation for determining a failure response pattern. A diagram for explaining a method of generating response policy determination information, etc. A diagram for explaining an example of generation and execution of a failure response command. A flowchart showing manual response learning processing. FIG. 7 is a diagram showing an example of the hardware configuration of the failure recovery support device 100.

[0013] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. The embodiment described below is merely an example, and the embodiment to which the present invention is applied is not limited to the following embodiment.

[0014] (Configuration of System and Device) Fig. 1 shows an example of the overall configuration of a system according to this embodiment. As shown in Fig. 1, this system includes a failure recovery support device 100. A target network (NW) 200 to be monitored and a maintenance operator terminal 300, which is a terminal of a maintenance operator (operator), are connected to the failure recovery support device 100.

[0015] Fig. 2 shows an example of the configuration of the disaster recovery support device 100. As shown in Fig. 2, the disaster recovery support device 100 includes an input / output IF 110, a processing unit 120, and a storage unit 130. The storage unit 130 may also be called a database. The disaster recovery support device 100 may also be called a disaster recovery support system. The storage unit 130 (database) may also be provided outside the disaster recovery support device 100. The input / output IF 110 may also be called an input / output unit.

[0016] The processing unit 120 includes a monitoring unit 121 , a response policy processing unit 140 , a failure confirmation processing unit 150 , and a failure response processing unit 160 .

[0017] The storage unit 130 includes a design information storage unit 131, a response policy template information storage unit 132, a fault confirmation template information storage unit 133, an event identification information storage unit 134, a fault response template information storage unit 135, a response policy determination information storage unit 136, a fault confirmation information storage unit 137, a fault response information storage unit 138, and an additional investigation method information storage unit 139.

[0018] 3 shows an example of the configuration of the response policy processing unit 140. As shown in FIG. 3, the response policy processing unit 140 includes a response policy template registration / edit / deletion unit 141 and a response policy determination unit 142.

[0019] 4 shows an example of the configuration of the fault confirmation processor 150. As shown in FIG. 4, the fault confirmation processor 150 includes a fault confirmation procedure determiner 151 and a fault confirmer 152.

[0020] 5 shows an example of the configuration of the failure handling processing unit 160. As shown in FIG. 5, the failure handling processing unit 160 includes a failure handling determination unit 161 and a failure handling execution unit 162.

[0021] (Functional Overview of Each Unit) The functional overview of each unit described above will be explained below. The operational flow using each unit related to failure recovery will be explained after the functional overview.

[0022] <Input / Output IF 110> The input / output IF 110 inputs and outputs information to and from the outside.

[0023] <Storage Unit 130> The design information storage unit 131 stores information at the time of design (network topology, device information, IP information, etc.).

[0024] The response policy template information storage unit 132 stores response policy template information. A response policy template is a template of information (policy) used when selecting a failure response pattern (such as a script), and includes information related to policy attributes and selectable attribute values.

[0025] The response policy determination information storage unit 136 stores response policy determination information, which includes information (policies) for selecting a failure response pattern.

[0026] The fault confirmation template information storage unit 133 stores fault confirmation template information. The fault confirmation template information includes possible faults, assumed causes, scripts required to confirm the assumed causes, etc. The scripts do not store specific parameters and are used as templates for procedures to be used during fault confirmation processing.

[0027] The fault confirmation information storage unit 137 stores fault confirmation information, which includes a fault confirmation command generated by the fault confirmation procedure determination unit 151 using fault confirmation template information, design information, and the like.

[0028] The event identification information storage unit 134 stores event identification information, which includes information (such as a device log) obtained when the fault confirmation processing unit 150 identifies an event using a fault confirmation command or the like.

[0029] The failure response pattern information storage unit 135 stores failure response pattern information. Failure response pattern information may also be called failure response template information. The failure response pattern information includes procedure information for responding to a failure. The failure response pattern information is associated with failure identification information and response policy determination information.

[0030] The failure response information storage unit 138 stores failure response information, which includes failure response commands generated by the failure response determination unit 161 from failure response pattern information and design information, and results (e.g., logs) of the failure response commands executed by the failure response execution unit 162.

[0031] The additional investigation method information storage unit 139 stores the commands and judgment materials executed by the maintenance personnel for the additional investigation.

[0032] <Processing Unit 120-Monitoring Unit 121> The monitoring unit 121 monitors the target NW 200. Note that the monitoring unit 121 may be provided outside the failure recovery support device 100, and the failure recovery support device 100 may receive the monitoring results by the monitoring unit 121.

[0033] <Processing Unit 120 - Response Policy Processing Unit 140> The response policy template registering, editing, and deleting unit 141 registers, edits, and deletes response policy templates, and reflects the results in the response policy template information storage unit 132.

[0034] The response policy determination unit 142 creates a maintenance policy (safety-oriented, cost-oriented, etc.) based on the response policy template stored in the response policy template information storage unit 132 and stores it in the response policy determination information storage unit 136.

[0035] <Processing unit 120-Fault confirmation processing unit 150> The fault confirmation procedure determination unit 151 compares the alarm information, etc. notified or collected via the input / output IF 110 with the possible faults and their assumed causes stored in the fault confirmation template information storage unit 133, and determines the template to be used for fault confirmation.

[0036] Furthermore, the fault confirmation procedure determination unit 151 extracts information (such as IP addresses) necessary for a fault confirmation template (script) from the design information, sets the information in the fault confirmation template, and generates fault confirmation information including the script used for fault confirmation, etc. The generated fault confirmation information is stored in the fault confirmation information storage unit 137.

[0037] The fault confirmation unit 152 retrieves the fault confirmation information generated by the fault confirmation procedure determination unit 151 from the fault confirmation information storage unit 137 and performs fault confirmation processing. The executed fault confirmation information and the obtained log are stored in the event identification information storage unit 134.

[0038] <Processing Unit 120-Failure Response Processing Unit 160> When the failure confirmation unit 152 completes the failure confirmation process, the failure response determination unit 161 determines a failure response pattern. The failure response pattern is selected based on the event identification information and the response policy determination information. The failure response determination unit 161 extracts parameters (such as an IP address) necessary to implement the failure response from the log information or design information included in the event identification information as parameters to be set in the selected failure response pattern (script), and sets these parameters in the script included in the failure response pattern to generate a failure response command. The generated failure response command is stored in the failure response information storage unit 138.

[0039] The failure response execution unit 162 reads out a failure response command from the failure response information storage unit 138 and executes it to handle the failure.

[0040] The operation of the disaster recovery support device 100 will now be described in detail.

[0041] 6, the overall flow of the processing executed by the disaster recovery support device 100 will be described. The monitoring unit 121 of the disaster recovery support device 100 performs failure monitoring in S1 (step 1), and if a failure is detected (Yes in S2), the process proceeds to S3.

[0042] In S3, the fault confirmation processing unit 150 performs fault confirmation processing, and in S4, the fault response processing unit 160 performs fault response processing.

[0043] In this embodiment, failure response patterns are determined in advance for each failure and stored in the failure recovery support device 100. The failure recovery support device 100 can support the failure response work of the maintenance person (which may also be called an operator) by presenting the failure response pattern corresponding to the identified failure to the maintenance person.

[0044] Depending on the type of failure, there are cases where a failure response pattern is predetermined and cases where it is not.

[0045] In the case where a failure response pattern is determined in advance, the failure response pattern may be notified to the maintenance person terminal 300 from the input / output IF 110, or the failure recovery support device 100 may automatically deal with the failure.

[0046] If the failure that has occurred is an unknown failure for which no failure response pattern has been defined, maintenance processing is carried out manually (by a maintenance person), and the processing procedures and methods used at that time are reflected in the failure response pattern information storage unit 135, etc., so that from the next time onwards, it can be handled as a known failure pattern.

[0047] The fault confirmation process, the fault response process, and the manual response learning process will each be described in detail below.

[0048] (Fault Confirmation Processing) Fig. 7 is a flowchart showing the fault confirmation processing. The fault confirmation processing will be described according to the procedure shown in Fig. 7 .

[0049] <S301> In S301, the fault confirmation procedure determination unit 151 identifies the assumed cause notified via the input / output IF 110 and identifies the instance type that is a candidate for the fault location from the design information stored in the design information storage unit 130. Note that an "instance" corresponds to an individual device, and an "instance type" corresponds to the model number of the device. Once the "instance type" is determined, the command system is determined, and once the assumed cause is identified, a fault confirmation template (script) is determined.

[0050] <S302> In S302, the fault confirmation procedure determination unit 151 refers to the fault confirmation template information stored in the fault confirmation template information storage unit 133, and searches for a fault confirmation template (script) linked to the combination of the assumed cause and the instance type identified in S301.

[0051] 8 shows an example of fault confirmation template information stored in the fault confirmation template information storage unit 133. As shown in Fig. 8, the fault confirmation template information is information in which a design pattern, a possible fault, a hypothetical cause, and a fault confirmation template are linked together.

[0052] The fault confirmation template information is a common component that does not depend on an individual environment, and environment-dependent parameters such as IP address and subnet information are generated from design information and set in the fault confirmation template script.

[0053] <S303> If a fault confirmation template can be acquired (YES in S303), the process proceeds to S304, and if not (NO in S303), the process proceeds to S306. In S306, learning is performed manually, the details of which will be described later.

[0054] <S304 to S307> In S304, the fault confirmation procedure determination unit 151 generates a fault confirmation command (fault confirmation information) by setting the parameters generated from the design information in the fault confirmation template acquired in S302, and stores the generated fault confirmation information in the fault information storage unit 137.

[0055] An image of the fault confirmation command is shown in Fig. 9. As shown in Fig. 9, the fault confirmation command is created by setting environment-dependent parameters such as IP addresses and subnet information generated from design information in the required locations of the fault confirmation template.

[0056] Next, the fault confirmation unit 152 reads the fault confirmation command generated by the fault confirmation procedure determination unit 151 from the fault confirmation information storage unit 137 and executes the fault confirmation command, thereby performing fault confirmation processing. The fault confirmation unit 152 stores the executed fault confirmation command and the obtained log in the event identification information storage unit 134 as event identification information.

[0057] If the failure can be identified by executing the failure confirmation information (YES in S305), the process proceeds to S307, and if the failure cannot be identified (NO in S305), the process proceeds to S306.

[0058] In S307, the fault confirmation unit 152 stores the fault confirmation result in the event identification information storage unit 134.

[0059] An example of the event identification information stored in the event identification information storage unit 134 is shown in Fig. 10. As shown in Fig. 10, the event identification information is information that links together the executed fault confirmation command, the log, the execution result, and the assumed cause. Fig. 10 shows an example in which a fault confirmation command (a script with parameters) is executed and a problem (a setting error) is identified in the VLAN settings.

[0060] <S308 to S309> When all the confirmation processes are completed (Yes in S308), in S309, the fault confirmation unit 152 outputs the determination result (confirmation result) of the isolation result. The output information is notified to the maintenance person terminal 300, for example.

[0061] (Failure Handling Process) Fig. 11 is a flowchart showing the failure handling process. The failure handling process will be described in accordance with the procedure shown in Fig. 11 .

[0062] <S401 to S402, S405> In S401, the failure handling determination unit 161 searches for a failure handling pattern linked to a set of event identification information (specific event) and response policy determination information.

[0063] Specifically, the failure response determination unit 161 reads the event (specific event) identified by the failure confirmation unit 152 from the event identification information storage unit 134, reads response policy determination information (policy) for a service related to the current failure from the response policy determination information storage unit 136, and searches for (selects) a failure response pattern corresponding to the specific event and the response policy determination information from the failure response pattern information stored in the failure response pattern information storage unit 135. Note that a failure response pattern may also be called a failure response template, a failure response script, or the like.

[0064] 12 shows an example of failure response pattern information stored in the failure response pattern information storage unit 135. As shown in Fig. 12, the failure response pattern information includes information about a specific event, a failure response pattern (specifically, a script required to handle the failure of the event), and response policy determination information (attribute value information of a maintenance policy).

[0065] The fault response pattern information is a common component that is independent of individual environments. Environment-dependent parameters such as IP addresses and subnet information are generated from design information, and a fault response command is generated by setting these in the fault response pattern (script).

[0066] A specific example of an operation for determining a failure response pattern will be described with reference to Fig. 13. Here, it is assumed that the target service is service A, and the response policy determination information storage unit 136 stores the information shown in Fig. 13(a) as response policy determination information for service A, the event identification information storage unit 134 stores the event identification information shown in Fig. 13(b), and the failure response pattern information storage unit 135 stores the failure response pattern information shown in Fig. 13(c).

[0067] In the example shown in Figure 13, the failure (specific event) is an error in the VLAN information setting of the SW related to service A, and the maintenance policy for service A is "low security" and "priority on cost," so the failure response determination unit 161 selects script #1001 as the failure response pattern corresponding to these.

[0068] An example of a method for generating the response policy determination information used as described above will now be described with reference to FIG.

[0069] As described above, a failure response pattern (failure response procedure, etc.) is determined according to response policy determination information (herein referred to as a policy) assigned to the service, device, etc. in which the event occurred.

[0070] The policy is determined using a response policy template stored in the response policy template information storage unit 132. FIG. 14(a) shows an example of a response policy template. As shown in FIG. 14(a), the response policy template is composed of a policy attribute and a corresponding policy attribute value list. The policy attribute value list is a list or range of policy attribute values ​​that the policy attribute can take. The policy attribute value list also has "no specification" as a default policy attribute value.

[0071] A policy (corresponding policy determination information) is determined by specifying a policy attribute and a policy attribute value to be used as the policy from a policy attribute value list. In Fig. 14, (b) shows the policy for service A, and (c) shows the policy for service B.

[0072] 11, if a failure response pattern can be acquired (YES in S402), the process proceeds to S403, and if no failure response pattern is available (NO in S402), the process proceeds to S405. In S405, manual processing is learned.

[0073] <S403 to S407> In S403, first, the failure handling determination unit 161 generates a failure handling command in which parameters generated from the design information, etc. are set as a failure handling pattern, and stores the command in the failure handling information storage unit 138. Next, the failure handling execution unit 162 reads the failure handling command from the failure handling information storage unit 138 and executes it to execute the failure handling. Note that the failure handling determination unit 161 may notify the maintenance person terminal 300 of the failure handling pattern or the failure handling command, thereby causing the maintenance person to execute the failure handling.

[0074] If the failure can be recovered (YES in S404), the process proceeds to S406, and if the failure cannot be recovered (NO in S404), the process proceeds to S405.

[0075] In S406, the failure handling execution unit 162 stores the handling log in the failure handling information storage unit 138. When all the failure handling processes have been completed, the process ends (YES in S407).

[0076] An example of generating and executing a failure response command will be described with reference to Fig. 15. In the example of Fig. 15, it is assumed that the event identification information storage unit 134 stores the event identification information shown in Fig. 15(a), and the failure response pattern information storage unit 135 stores the failure response pattern information shown in Fig. 15(b).

[0077] As described above, the failure handling determination unit 161 generates commands (failure handling commands) for actually handling a failure by setting parameters required for a failure handling pattern.

[0078] The parameters to be set in the failure response pattern (script) may be information obtained during failure confirmation (e.g., the IP address of the switch in which a configuration error was detected), or may be generated from the design information. Specifically, for example, the IP address of the misconfigured switch is extracted from the log generated during failure confirmation, and the IP address required for confirming continuity after reconfiguration is extracted from the design information.

[0079] 15, because the cause of the failure was a VLAN information setting error, the failure handling determination unit 161 selects script #1001, which is a failure handling pattern for setting VLAN information, generates command #1001 by setting necessary parameters in script #1001, and the failure handling execution unit 162 handles the failure by executing command #1001. Furthermore, as shown in FIG. 15(c), log information about when the failure was handled may be stored in the failure handling information storage unit 138 together with the failure handling command as failure handling information.

[0080] <Summary of Failure Response Processing> As described above, in cases where a failure response pattern corresponding to a combination of an assumed cause and a specific event (confirmation result) is determined in advance, the failure recovery support device 100 can automatically perform failure response.

[0081] If the failure is unknown and no failure response pattern has been defined in advance, manual handling is performed, and the processing procedure and method used at that time are reflected in the failure response pattern information storage unit 135, so that from next time onwards it can be handled as a known failure response pattern. In addition, logs obtained as a result of handling the failure may be recorded as a response log.

[0082] (Manual Response Learning Process) Fig. 16 is a flowchart showing the manual response learning process. The manual response learning process will be described in accordance with the procedure shown in Fig. 16 .

[0083] In S501, the failure recovery support device 100 sends a manual processing request from the input / output IF 110 to the maintenance person terminal 300. At this time, either or both of failure confirmation template information and failure response pattern information (failure response template information) may be presented to the maintenance person terminal 300.

[0084] When a maintenance technician receives a manual processing request, they store specific parameters in the presented fault confirmation template information or fault response pattern information and perform the processing, or they perform the processing from scratch without relying on the template information.

[0085] If the manual processing is successful (YES in S502), in S503, the maintenance person uses the maintenance person terminal 300 to reflect the manual processing content in the storage unit of the failure recovery support device 100 via the input / output IF 110. Specifically, this is as follows.

[0086] The maintenance person stores log information and the like that are the basis for taking action in the event identification information storage unit 134. Furthermore, if an additional investigation is performed, the maintenance person stores the commands performed for the additional investigation and the materials for judgment in the additional investigation method information storage unit 139.

[0087] The maintainer uses the maintainer terminal 300 to store information about the policy used when responding to a failure in the response policy determination information storage unit 136, and also stores failure response pattern information corresponding to the work content when responding to a failure in the failure response pattern information storage unit 135. In addition, the maintainer may use the maintainer terminal 300 to store failure response commands and logs in the failure response information storage unit 138.

[0088] (Hardware Configuration Example) The disaster recovery support device 100 described in this embodiment can be realized, for example, by causing a computer to execute a program. This computer may be a physical computer or a virtual machine on a cloud.

[0089] That is, the device can be realized by executing a program corresponding to the processing performed by the device using hardware resources such as a CPU and memory built into a computer. The program can be recorded on a computer-readable recording medium (such as a portable memory) and stored or distributed. The program can also be provided via a network such as the Internet or email.

[0090] Fig. 17 is a diagram showing an example of the hardware configuration of the computer. The computer in Fig. 17 includes a drive device 1000, an auxiliary storage device 1002, a memory device 1003, a CPU 1004, an interface device 1005, a display device 1006, an input device 1007, an output device 1008, and the like, all of which are interconnected by a bus BS. The computer may further include a GPU.

[0091] The program that realizes the processing on the computer is provided by a recording medium 1001, such as a CD-ROM or a memory card. When the recording medium 1001 storing the program is set in the drive device 1000, the program is installed from the recording medium 1001 to the auxiliary storage device 1002 via the drive device 1000. However, the program does not necessarily have to be installed from the recording medium 1001, but may be downloaded from another computer via a network. The auxiliary storage device 1002 stores the installed program as well as necessary files, data, etc.

[0092] The memory device 1003 reads and stores the program from the auxiliary storage device 1002 when an instruction to start the program is received. The CPU 1004 realizes functions related to the disaster recovery support device 100 in accordance with the program stored in the memory device 1003. The interface device 1005 is used as an interface for connecting to a network, etc. The display device 1006 displays a GUI (Graphical User Interface) or the like according to the program. The input device 1007 is composed of a keyboard, mouse, buttons, a touch panel, etc., and is used to input various operation instructions. The output device 1008 outputs the results of calculations.

[0093] (Summary, Effects, etc. of the Embodiments) As described above, with the technology described in the present embodiment, for known events, it is possible to select a predetermined failure response pattern that corresponds to an event identified through a response policy and confirmation tests, etc., and to perform a failure response. Therefore, for known events, it is possible to perform a failure response without causing a difference in the experience of operators.

[0094] Furthermore, unknown events can be gradually turned into known events through manual learning processes, which reduces the number of events that result in experience differences.

[0095] The following additional notes are provided regarding the above-described embodiments.

[0096] <Additional Notes> (Additional Item 1) A failure recovery support device that supports a response to recover from a failure in a network, comprising: a memory that stores events in the network and failure response patterns in association with each other; and at least one processor connected to the memory, wherein the processor determines a failure response pattern corresponding to an event identified in the network by referring to the storage unit. (Additional Item 2) The failure recovery support device according to Additional Item 1, wherein the processor notifies an operator of the failure response pattern, or executes processing on the network to recover from the failure based on the failure response pattern. (Additional Item 3) The failure recovery support device according to Additional Item 1 or 2, wherein, when a failure response pattern corresponding to an event identified in the network is not stored in the memory, the processor requests an operator to respond to the failure, receives a failure response pattern related to the failure response from the operator, and stores the received failure response pattern in the memory. (Supplementary Item 4) The failure recovery support device according to any one of Supplementary Items 1 to 3, wherein the processor determines the failure response pattern based on an event identified in the network and a policy related to the event. (Supplementary Item 5) The failure recovery support device according to any one of Supplementary Items 1 to 4, wherein the processor executes processing to recover from a failure using the failure response pattern and parameters obtained from information obtained during failure confirmation or from design information. (Supplementary Item 6) The failure recovery support device according to any one of Supplementary Items 1 to 5, wherein the processor generates a failure confirmation command based on a presumed cause of the failure and design information of the network, and identifies the event in the network by executing the failure confirmation command.(Supplementary Item 7) A failure recovery support method executed by a failure recovery support device that supports measures to recover from a failure in a network, wherein the failure recovery support device has a storage unit that stores events in the network and failure response patterns in association with each other, and the failure recovery support method comprises a failure response processing step of determining a failure response pattern corresponding to an event identified in the network by referring to the storage unit. (Supplementary Item 8) A non-transitory storage medium that stores a program for causing a computer to execute processing in the failure recovery support device according to any one of Supplementary Item 1 to 6.

[0097] Although the present embodiment has been described above, the present invention is not limited to such a specific embodiment, and various modifications and changes are possible within the scope of the gist of the present invention described in the claims.

[0098] REFERENCE SIGNS LIST 100 Failure recovery support device 200 Target network 300 Maintenance person terminal 110 Input / output IF 120 Processing unit 130 Storage unit 121 Monitoring unit 140 Response policy processing unit 150 Failure confirmation processing unit 160 Failure response processing unit 131 Design information storage unit 132 Response policy template information storage unit 133 Failure confirmation template information storage unit 134 Event identification information storage unit 135 Failure response template information storage unit 136 Response policy decision information storage unit 137 Failure confirmation information storage unit 138 Failure response information storage unit 139 Additional investigation method information storage unit 141 Response policy template registration / edit / deletion unit 142 Response policy decision unit 151 Failure confirmation procedure decision unit 152 Failure confirmation unit 161 Failure response decision unit 162 Failure response execution unit 1000 Drive device 1001 Recording medium 1002 auxiliary storage device 1003 memory device 1004 CPU 1005 interface device 1006 display device 1007 input device 1008 output device

Claims

1. A fault recovery support device that supports responses to recover from faults in a network, comprising: a memory unit that stores events in the network in association with fault response patterns; and a fault response processing unit that determines a fault response pattern corresponding to an event identified in the network by referring to the memory unit.

2. The failure recovery support device according to claim 1, wherein said failure response processing section notifies an operator of said failure response pattern, or executes processing for recovering from a failure on said network based on said failure response pattern.

3. A fault recovery support device as described in claim 1, further comprising an input / output unit which, when a fault response pattern corresponding to an event identified in the network is not stored in the memory unit, requests an operator to handle the fault, receives a fault response pattern related to the fault response from the operator, and stores the received fault response pattern in the memory unit.

4. The failure recovery support device according to claim 1, wherein the failure response processing section determines the failure response pattern based on an event identified in the network and a policy relating to the event.

5. The fault recovery support device according to claim 1, wherein the fault response processing unit executes processing for recovering from a fault using the fault response pattern and information obtained at the time of fault confirmation or parameters obtained from design information.

6. A fault recovery support device as described in claim 1, further comprising a fault confirmation processing unit that generates a fault confirmation command based on the assumed cause of the fault and design information of the network, and identifies an event in the network by executing the fault confirmation command.

7. A fault recovery support method executed by a fault recovery support device that supports responses to recover from faults in a network, the fault recovery support device having a memory unit that stores events in the network in association with fault response patterns, and the fault recovery support method comprising a fault response processing step of determining a fault response pattern corresponding to an event identified in the network by referring to the memory unit.

8. A program for causing a computer to function as each unit in a disaster recovery support device according to any one of claims 1 to 6.

Images