Processing device, processing method, and program

Abstract

To enable incidents to be efficiently managed.SOLUTION: A processing device comprises: a first processing unit which, when it is identified that input information indicating the first alarm content received from a monitoring device is not registered as information of an incident that must be responded to in a storage unit, identifies first information that indicates the first degree of influence of the incident upon a prescribed service; a second processing unit which, when identified that the first information affects a service, identifies second information that represents the second degree of influence of the incident upon a service; and a third processing unit which, when identified that the second information affects a service, identifies third information that is received from an operator device after a prescribed processing procedure is executed in order to restore a service, and that indicates the third degree of influence of the incident upon a service.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present disclosure relates to a processing device, a processing method, and a program. [Background technology]

[0002] When dealing with many systems and services, such as data centers and cloud services, many alerts are generated when a failure occurs or an abnormality is detected, which can lead to congestion in responding to incidents and delays in restoring services.

[0003] For example, a mechanism for efficiently handling incidents by aggregating alarm messages when an incident occurs has been disclosed (see Patent Document 1). In addition, the accuracy of aggregation is improved by using machine learning to determine whether or not to aggregate. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Patent 6515048 Summary of the Invention [Problem to be solved by the invention]

[0005] However, there are cases where multiple types of alarms occur simultaneously or the service status changes during a failure, so there was a problem in that simply aggregating alarm messages was not enough to respond to incidents appropriately.

[0006] The present disclosure provides a processing device, a processing method, and a program capable of efficiently managing incidents. [Means for solving the problem]

[0007] The processing device of the present disclosure includes a first processing unit that identifies first information indicating a first impact of the incident on a specified service when it is determined that input information indicating a first alarm content received from a monitoring device is not registered in a memory unit as information on an incident that requires addressing; a second processing unit that identifies second information, which is information received from an operator device and is information indicating a second impact of the incident on the service when it is determined that the first information has an impact on the service; and a third processing unit that identifies third information, which is information received from the operator device and is information indicating a third impact of the incident on the service when it is determined that the second information has an impact on the service after a specified processing procedure for restoring the service is executed. Effect of the Invention

[0008] According to the processing device of the present disclosure, it is possible to obtain an effect of efficiently managing incidents. [Brief description of the drawings]

[0009] [Figure 1] FIG. 1 is a block diagram showing an example of the configuration of a monitoring system according to the present embodiment. [Diagram 2] FIG. 2 is a diagram illustrating a functional configuration of the incident management device. [Diagram 3] FIG. 3 is a flowchart of a processing routine executed by the incident management device when an alarm occurs. [Figure 4] Referring to FIG. 4, this is a flow when the incident management device closes an incident. [Diagram 5] Figure 5 shows an example of an open incident list screen. [Figure 6] Figure 6 shows an example of the incident details screen that appears when the Details button is clicked. [Figure 7] FIG. 7 shows an example of an incident list screen. [Figure 8]Figure 8 shows an example of the incident details screen that appears when the Details button is clicked. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] An embodiment of the present invention will be described in detail below. Note that an information processing device according to the present embodiment relates to an incident management system, a problem management system, or the like that can efficiently manage incidents in an environment where many incidents occur.

[0011] (Monitoring system configuration) 1 is a block diagram showing an example of the configuration of a monitoring system according to the present embodiment. The configurations of the devices and DBs included in the monitoring system will be described below.

[0012] The monitored devices 1011 to 101n are devices monitored by this system, including network devices, physical servers, and virtual servers.

[0013] The monitoring device 110 monitors each of the monitored devices 1011 to 101n, and when an abnormality occurs, transmits the contents of an alarm to the incident management device 112. Examples of monitoring methods include alive monitoring for checking ping responses, process monitoring for checking whether processes in the virtual server are running, log monitoring for checking abnormal logs in the server (system logs and logs of each application), resource monitoring for checking the usage status of the CPU, memory, and disk, and trap monitoring for receiving and notifying traps from each monitored device.

[0014] The monitoring information DB 111 stores information indicating what equipment is monitoring what.

[0015] The incident management device 112 records the state of a currently occurring incident and incidents that have occurred in the past, and prompts an operator to take action by notifying the alarm device 121 as necessary. The incident management device 112 is an example of a processing device of the present disclosure.

[0016] Fig. 2 is a diagram showing a functional configuration of the incident management device 112. As shown in Fig. 2, the incident management device 112 is configured to include a first processing unit 112A, a second processing unit 112B, and a third processing unit 112C. The hardware configuration of the incident management device 112 is realized by a computer including a CPU (Central Processing Unit), a ROM (Read Only Memory) that stores programs for implementing each processing routine, a RAM (Random Access Memory) that temporarily stores data, a memory as a storage means, a network interface, and the like.

[0017] The incident information DB 113 records incidents that have occurred in the past. It also includes currently occurring open incidents. The incident information DB 113 records when and what kind of alarm occurred and what kind of measures were taken, and based on the records, the problem management staff investigates the cause and develops measures to prevent recurrence.

[0018] The configuration management device 114 is a device capable of managing, referring to, and notifying information indicating which service is affected by each monitoring target and what kind of operation check or temporary measure should be implemented.

[0019] The configuration management DB 115 records information about each monitored device, which service it belongs to, how to check operation, and how to take provisional measures.

[0020] The notification device 116 can send emails or make phone calls to those involved in each service.

[0021] The notification information DB 117 records contact information for the relevant parties of each service.

[0022] The operation terminal 120 is a device for an operator to carry out operations such as checking the monitoring status and logging in to each monitored device.

[0023] The alarm device 121 is a device that notifies an operator of an abnormality when an abnormality occurs in a service by using sound, light, etc. The alarm device 121 is set to sound when the incident management device 112 detects an abnormality. The terminals 131a and 131b are terminals through which the relevant parties can be contacted by email, telephone, etc. Devices such as PCs, mobile phones, and smartphones can be used.

[0024] (Processing flow) Next, a description will be given of the flow of processing in the monitoring system 10. Fig. 3 is a flowchart of a processing routine executed by the incident management device 112 when an alarm occurs. Fig. 4 is a flowchart of a processing routine executed by the incident management device 112 when closing an incident.

[0025] In step S201, when an alarm occurs, the monitoring device 110 transmits to the incident response device the date and time the alarm occurred, the target device ID, a message regarding the alarm content, and the like.

[0026] In step S202, the incident management device 112 identifies the service corresponding to the device in which the alarm occurred, and refers to the configuration management DB 115 for the service of the device.

[0027] In step S203, the incident management device 112 identifies the open state of the target incident. The open state is determined by referring to the incident information DB 113. "Open" refers to a state in which the incident has already occurred. In other words, an incident that is not open is an incident that has not been registered as needing action.

[0028] In step S204, the incident management device 112 determines whether the incident is already open. If the incident is already open, the process proceeds to S205, and if the incident is not open, the process proceeds to S207.

[0029] In step S 205 , the incident management device 112 acquires the incident number from the incident information DB 113 .

[0030] In step S206, the incident management device 112 stores the incident in the incident information DB 113 as an open incident.

[0031] In step S207, the incident management device 112 adds the generated alarm message information to the incident of the target service in the incident information DB 113.

[0032] In step S208, the incident management device 112 judges whether an alarm having the same content as the currently occurring alarm has already been registered as an incident. For example, if the same CPU utilization rate excess alarm has already been registered, it is judged to be the same alarm. If it is not the same alarm, the process proceeds to S209. If it is the same alarm, the process ends.

[0033] In step S209, the incident management device 112 determines whether the impact level of the incident on the current target service is "1, 2" or "0, 3, 4." Here, the impact level is defined, for example, as follows: If the impact level is "0, 3, 4 (service impacted)," the process proceeds to S210, and if the impact level is "1, 2," the process ends. Impact level 0: Impact level not determined Impact level 1: Operation is normal and no action is required Impact level 2: Operating normally, but cause investigation and action required Impact level 3: Some service functions are affected Impact level 4: All functionality of the service is affected In this way, it is possible to set a classification of the degree of impact from 0 to 4 based on the impact on the operating state and the function of the service. The classification can be used in the following determinations in the same manner. The degree of impact determined here is an example of the first degree of impact (first information) of the present disclosure.

[0034] In step S210, the incident management device 112 notifies the alert generation process. The alarm device 121 is notified, and the alarm device 121 sounds to prompt the operator to deal with the incident. At the same time, alarm information is sent to the notification device 116, which notifies the relevant parties of the alarm by email or the like. The relevant parties may be associated with the notification information DB 117.

[0035] In step S211, the incident management device 112 receives the results of the operation check of the target service performed by the operator from the operation terminal 120. The operator inputs the impact of the operation check result from the operation terminal 120. The input information, time, etc. are recorded in the incident management device 112 and used as historical information. The incident management device 112 notifies the relevant parties of the impact of the service by sending the impact information to the notification device 116. The operator performs the task of checking the information of the relevant device in the monitoring information DB 111 from the operation terminal 120. The impact input by the operator here is an example of the second impact (second information) of the present disclosure.

[0036] In step S212, the incident management device 112 determines whether the impact of the current incident on the target service is "1, 2" or "3, 4." If the impact is "1, 2," the flow ends. If the impact is "3, 4," the flow proceeds to S212.

[0037] In step S213, the operator implements a predetermined procedure for a temporary measure to restore the service, and notifies the incident management device 112 of the implementation result from the operation terminal 120. For example, a process restart or a server restart may be implemented.

[0038] In step S214, the operator checks the operation of the service to confirm whether the service has been restored after the implementation of the temporary measure, and notifies the incident management device 112 of the implementation result from the operation terminal 120. The impact degree of the incident is updated appropriately by the operation check. Note that the impact degree updated by the operator here is an example of the third impact degree (third information) of the present disclosure.

[0039] In step S215, the incident management device 112 determines whether the impact level of the current incident on the target service is "1, 2" or "3, 4." If the impact level is "1, 2," the process proceeds to S217. If the impact level is "3, 4," the process proceeds to S216.

[0040] In step S216, the incident management device 112 notifies the operation terminal 120 of the escalation to the operator, and the operator contacts the person in charge in the specialized department and takes over the response.

[0041] In step S217, since the service has been restored, the operator inputs the degree of impact from the operation terminal 120 to the incident management device 112, and the incident management device 112 closes the incident. At the same time, incident recovery information is sent to the notification device 116, so that the recovery is notified to the relevant parties by e-mail or the like.

[0042] The processes of the above steps correspond to the processes of the first processing unit 112A, the second processing unit 112B, and the third processing unit 112C. When the first processing unit 112A identifies that the input information (S202, S203) indicating the first alarm content received from the monitoring device is not registered as information on an incident that requires action in the storage unit (incident information DB 113) (S204 to S208), it identifies first information indicating a first impact of the incident on a predetermined service (S209). The first information is the impact determined in step S209. When it is identified that the first information has an impact on the service, the second processing unit 112B identifies second information, which is information received from the operator device (operation terminal 120) and is information indicating a second impact of the incident on the service (S210 to S212). When the second information is identified as having an impact on the service, the third processing unit 112C identifies third information, which is information received from the operator device (operation terminal 120) after a predetermined processing procedure for restoring the service is executed and indicates a third impact degree of the incident on the service (S213 to S217).

[0043] Next, a flow when the incident management device 112 closes an incident will be described with reference to Fig. 4. Note that this flow is executed, for example, every five minutes.

[0044] In step S302, the incident management device 112 determines whether or not there are any open incidents. If there are any open incidents, the incident management device 112 selects one of the incidents and proceeds to step S303. If there are no open incidents, the flow ends.

[0045] In step S303, the incident management device 112 determines whether a certain period of time has passed since the occurrence of an alarm. If a certain period of time (e.g., one hour) has passed since the last alarm, the process proceeds to S304. If not, the process proceeds to S306. This makes it possible to identify when the last alarm of the selected incident occurred.

[0046] In step S304, the incident management device 112 determines the impact level of the incident. If the impact level of the incident is "1, 2", the process proceeds to S305. If the impact level is "0, 3, 4", the process proceeds to S306.

[0047] In step S305, the incident management device 112 closes the target incident. In step S306, the incident management device 112 determines whether there are any unconfirmed open incidents. If there are any unconfirmed incidents, the flow proceeds to S302. If there are no unconfirmed incidents, the flow ends. As described above, when a certain period of time has passed since the alarm generation for an incident and the impact level satisfies the conditions, the incident is closed.

[0048] An example of an incident list screen in an open state is shown in Fig. 5. Reference numeral 401 denotes a screen (incident list screen) for displaying multiple open incidents. The list screen is generated by the incident management device 112 and is displayed on the operator's operation terminal.

[0049] Each box in 402 indicates one incident, and various information (404 to 407) for the incident is displayed. 403 displays the service name of the incident, and is a display section for identifying which service the incident is for. 404 is a display section for indicating whether or not the incident needs to be dealt with. 405 is a display section for indicating what kind of action is required (action content). It is possible to display the action content and a link to a procedure manual. In addition, it is possible to update the impact of the service after confirming operation, etc., by inputting or selecting from the input interface. 406 is a display section for indicating the impact of the service. The impact in the display section in 406 can be updated by inputting or selecting the impact from 405. 407 is a button for displaying details of the incident, and clicking the button pops up a screen that displays alarm information, impact, and response history information. In addition, the incident list screen (401) can display multiple incidents that are currently open. The display order can be changed by the degree of impact, the order of need for action, etc. As described above, the incident management device 112 controls so that, by clicking or otherwise operating the details button on the screen listing the incidents that have occurred, alarm information, the degree of impact, and response history information for the incidents are displayed.

[0050] Figure 6 is an example of the incident details screen that appears when the Details button (407) in Figure 5 is clicked. Reference numeral 501 denotes a screen that pops up and is displayed on the operation terminal. Reference numeral 502 denotes a screen that displays detailed information about the incident, and displays the service name, the alarm that occurred, the current impact, the response history, and so on. Reference numeral 503 denotes a button for closing the pop-up screen.

[0051] Figure 7 shows an example of an incident list screen. 601 is a screen for displaying incidents that have occurred, including incidents that have already been closed. 602 indicates one incident. 603 is the incident number assigned to each incident. 604 is the date and time when the incident occurred. 605 indicates the name of the service for which the incident occurred. 606 indicates the status of the incident. An incident that is still open and being dealt with is closed as "temporarily being dealt with," and if measures to prevent recurrence are being considered, "permanent measures being considered" is displayed. 607 is a button for viewing detailed information about the incident. The incident list screens in Figures 5 and 7 are interfaces that can be switched as appropriate.

[0052] Figure 8 is an example of the incident details screen that appears when the Details button in Figure 7 is clicked. Reference numeral 701 is a screen that pops up and is displayed on the operation terminal. Reference numeral 702 is a screen (incident details screen) on which detailed information about the incident is recorded, and displays the service name, incident status, information about the alarm that has occurred, maximum impact, and response history. Reference numeral 703 is a text box for investigating and inputting the cause of the incident in the problem management phase. Reference numeral 704 is a text box for considering and inputting measures to prevent the recurrence of the incident. Reference numeral 705 is a button for closing the pop-up screen. It is assumed that problem management will often be performed by a different person from the operator who responds to the incident.

[0053] In the embodiment, the operation check and the temporary measures are performed manually by the operator, but some operation checks can be performed automatically, so they may be performed automatically. Examples of operations that can be performed automatically include accessing a web page to check whether login is possible, and automatically rebooting the system. Automatic and manual checks may be mixed. In that case, an automatic operation check device, an automatic temporary action device, etc. may be added to the configuration.

[0054] In addition, in the embodiment, the flow is such that the incident is closed after a certain period of time has passed, but if it is clear that the incident has been resolved, the incident may be closed manually. Filtering is also possible on the incident list screen by adding search buttons, sort buttons, etc.

[0055] As described above, according to this embodiment, incidents can be managed efficiently.

[0056] In addition, by managing the status of incidents as described above, incidents are not registered as new incidents every time an alarm occurs, allowing for efficient incident response. This allows smooth communication with the various parties involved in the service. In addition, incident management can be efficiently implemented in the problem management phase, where measures to prevent the recurrence of the incident are considered.

[0057] The present invention is not limited to the above-described embodiment, and various modifications and applications are possible without departing from the spirit and scope of the present invention.

[0058] Furthermore, although the present specification has been described as an embodiment in which the program is pre-installed, the program may also be provided by being stored on a computer-readable recording medium. [Explanation of symbols]

[0059] 10. Surveillance System 110 Monitoring equipment 112 Incident Management Device 114 Configuration management device 116 Notification device 120 Operation terminal 121 Alarm device

Claims

1. a first processing unit that identifies first information indicating a first impact degree of the incident on a predetermined service when it is determined that input information indicating a first alarm content received from the monitoring device is not registered in the storage unit as information on an incident that requires a response; a second processing unit that identifies, when the first information is identified as having an impact on the service, second information that is received from an operator device and indicates a second impact degree of the incident on the service; a third processing unit that identifies third information, which is information received from the operator device and indicates a third impact degree of the incident on the service, after a predetermined processing procedure for recovering the service is executed when the second information is identified as having an impact on the service; and A processing device comprising:

2. The processing device according to claim 1 , wherein the first impact level, the second impact level, and the third impact level are classified based on an impact on an operating state and a service function.

3. The processing device according to claim 1 , wherein the incident is closed when a certain period of time has passed since an alarm was generated for the incident and the degree of impact of the incident satisfies a condition.

4. 2. The processing device according to claim 1, further comprising: a list screen displayed on the operator device, the list screen displaying the list of incidents that have occurred, the list screen displaying alarm information, impact level, and response history information as details of each incident.

5. The processing device according to claim 4 , wherein the degree of influence can be updated on the list screen through an input interface.

6. The processing device according to claim 1 , wherein, when the third information indicates that the service has been restored, incident recovery information is sent to a notification device to notify relevant parties of the recovery.

7. A processing method executed by a processing device, comprising: identifying first information indicating a first impact degree of the incident on a predetermined service when it is determined that input information indicating a first alarm content received from the monitoring device is not registered in the storage unit as information on an incident that requires a response; identifying second information, when the first information is identified as having an impact on the service, the second information being information received from an operator device and indicating a second impact level of the incident on the service; when the second information is identified as having an impact on the service, after a predetermined processing procedure for recovering the service is executed, identifying third information, which is information received from the operator device and indicates a third impact degree of the incident on the service; A processing method comprising the steps of:

8. A program that causes a computer to function as each unit in a processing device, a first processing unit that identifies first information indicating a first impact degree of the incident on a predetermined service when it is determined that input information indicating a first alarm content received from the monitoring device is not registered in the storage unit as information on an incident that requires a response; a second processing unit that identifies, when the first information is identified as having an impact on the service, second information that is received from an operator device and indicates a second impact degree of the incident on the service; a third processing unit that identifies third information, which is information received from the operator device and indicates a third impact degree of the incident on the service, after a predetermined processing procedure for recovering the service is executed when the second information is identified as having an impact on the service; and A program to function as a

Images