JP5596663B2 - Incident management system - Google Patents

Description

  The present invention relates to an incident management operation system technique for performing an incident management operation operation of an information processing system. In particular, the present invention relates to a technique for shortening the failure recovery work time in incident management operation work.

  In the data center, there is an incident management operation business in which an information system (customer system) is entrusted by a customer (customer) and an operation service including failure handling is provided. The operation service provider must monitor incidents that occur in the customer system, and if an incident occurs, the service must be quickly restored and the impact on customer operations must be minimized.

  As a prior art example regarding a mechanism for quickly recovering a service from an incident that has occurred, a method of applying an incident management system described in Japanese Patent Application Laid-Open No. 2011-76161 (Patent Document 1) is conceivable. In Patent Document 1, a past case (approach and procedure for an incident that occurred in the past) that can be applied is retrieved and presented from a message or the like of the incident that has occurred, and appropriate and quick recovery work is enabled.

  With this mechanism, it is sufficient to apply past cases to all incidents and recover the service within the target time. However, in reality, the procedure is sparse and the recovery work at the service desk is difficult, or the system design department is asked to solve it. Recovery may be delayed.

  In order to reduce such incident resolution delay, it is indispensable to have a process in which the department causing the delay closely examines and improves the recovery work and shortens the recovery time.

  However, conventional technologies including the above-described technology do not have an incident solution time analysis and follow-up mechanism.

JP 2011-76161 A

  As described above, the problem with the prior art is that it does not have an incident resolution time analysis and follow-up mechanism. There are problems such as delay in resolution of incidents such as recovery work and lack of improvement.

  Therefore, the main object of the present invention is to solve the problem of shortening the incident resolution time using the prior art, for example, by shortening the recovery time by urging the department or user who caused the recovery delay to improve the recovery work content It is to provide a technology capable of realizing the above.

  In order to achieve the above object, a representative embodiment of the present invention is an information processing system (incident management operation system) for performing an incident management operation for an information processing system (customer system, data center, etc.). And it has the structure shown below, It is characterized by the above-mentioned.

  In this system, in particular, incident information that occurred, incident processing history, definition information of allowable service stoppage time, contact information for each follow target (by step, department), and definition information for contact content (follow content), etc. Use data information to automatically report improvement request information (follow-up information) for relevant departments and users for incidents and steps (work) that require a long time to resolve. Create and send a follow function (such as a corresponding restoration work improvement request automatic transmission method), and information on one or more steps (work) that are the targets for sending the above improvement request information (follow targets) List display function that creates and provides a screen that displays the list information in order of priority (the corresponding improvement target work action priority list display method ) Has the like. The follow target is determined, for example, as a step having the longest time required among a plurality of steps related to the resolution of one incident and a corresponding department in charge.

  The incident management and operation system includes a follow system having a follow function for automatically transmitting information on improvement requests relating to incident work steps to a department in charge or a user for follow-up. The step to be followed (candidate) is determined, for example, as an incident step whose resolution time exceeds an allowable time, or a step with the longest time required from the start to the end of the work. In addition, the follow system provides a screen for displaying a list of information on one or more steps to be followed (candidates) as a priority in the order of longer required time to a terminal such as a department in charge or a user. It has a function.

  According to a typical embodiment of the present invention, the problem of shortening the incident resolution time using the prior art is solved, and for example, the recovery time is promoted by encouraging the department or user that caused the recovery delay to improve the recovery work content. Can be realized.

It is a figure which shows the example of a system whole structure containing the system (incident management operation system) of one embodiment of this invention. It is a figure which shows the example of the workflow of incident management. It is a figure which shows the example of a table of incident information. It is a figure which shows the example of a table of incident process history information. It is a figure which shows the example of a table of generation | occurrence | production source information. It is a figure which shows the example of a table of service information. It is a figure which shows the example of a table of step charge information. It is a figure which shows the example of a table of request definition information. It is a figure which shows the flow of the work improvement request automatic transmission process by a follow function. It is a figure which shows the example of the improvement object step list screen by a list display function. As a supplement, it is a diagram showing the correspondence relationship between an origin, an incident, a workflow (step), a department in charge, a person in charge, and the like.

  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 system (incident management operation system) according to the present embodiment has a monitoring system 5 (incident management system 10, follow system 30, operation terminal 6, etc.) and fault monitoring on the data center 1 side in the overall system configuration as shown in FIG. The system includes the apparatus 3 and the like, and has a recovery work improvement request automatic transmission function (follow function) and a handling priority order work list display function (list display function) in incident management operation work (recovery work support and the like). As the follow function, the operation terminal 6 (contact information) of the corresponding user U (incident manager, person involved in recovery work, etc.) from the follow system 30 regarding the handling (recovery work, etc.) of the incident (for example, failure of the monitored device 2) Thus, the recovery work time is shortened by improving the recovery work of the user U by automatically transmitting a recovery work improvement request mail (information). At the same time, as the list display function, the list information of the recovery work is displayed in the priority order of handling on the display screen of the operation terminal 6 of the corresponding user U, so that the corresponding user U can check the recovery work time.

[System configuration]
FIG. 1 shows an example of the entire system configuration including the system (incident management operation system) of the present embodiment. This system is an information processing system related to incident management operations. In FIG. 1, the entire system has a configuration in which a data center 1 and a monitoring center 5 are connected by a communication line 4.

  The data center 1 is a monitoring target system, and includes a plurality of monitoring target devices 2 and a failure monitoring device 3 connected to them. The monitoring target device 2 is a server device that provides service processing. The failure monitoring device 3 monitors the state of the monitoring target device 2, detects a failure, and outputs failure information (monitoring information).

  The monitoring center 5 includes an operation terminal 6, an incident management system 10, a past case DB 12, an incident DB 20, a recovery work improvement follow system 30, and a follow information DB 40.

  The incident management system 10 includes a failure information input unit 11. The failure information input unit 11 inputs failure information (monitoring information) from the failure monitoring device 3 of the data center 1 via the communication line 4 and stores it in the past case DB 12 or stores incident information in the incident DB 20 (incident information 21). The process to store in. In addition, the incident management system 10 performs processing for providing information on the incident DB 20 on a screen to the user U (operation terminal 6) such as an incident manager.

  The past case DB 12 is a database in which past cases of failure information in the data center 1 (monitored device 2) are stored.

  The incident DB 20 includes information such as incident information 21 (example: FIG. 3), incident processing history information 22 (example: FIG. 4), source information 23 (example: FIG. 5), service information 24 (example: FIG. 6), etc. It is a database that stores and manages (tables).

  The follow system (recovery work improvement follow system) 30 uses the data information of the incident DB 20 and the follow information DB 40, and the department and the user U (contacts) to be followed in the steps of the recovery work related to the incident (the longest step described later) Processing for automatically transmitting the improvement request mail 50 (follow mail) to the previous) is performed. In addition, the follow system 30 performs a process of displaying (providing) a list screen (to be described later, FIG. 10) of steps such as restoration work to be improved for the user U (operation terminal 6).

  The follow information DB 40 stores and manages information (table) such as step charge information 41 (example: FIG. 7), request definition information 42 (example: FIG. 8), and the like.

  The fault monitoring device 3 of the data center 1 automatically collects faults that have occurred in the monitored device 2 and transmits them to the incident management system 10 via the communication line 4. The failure information is received from the failure information input unit 11 of the incident management system 10 and the failure information is collated with the past case DB 12 to determine an applicable past case. Then, the incident management system 10 (failure information input unit 11) stores the determined failure information as an incident in a table of incident information 21 in the incident DB 20.

  The user U is a person who uses the operation terminal 6 to perform incident management operation work, and is an incident manager, a person involved in recovery work, and the like, for example, a service desk operator or a designer. The user U refers to the incident (incident information managed by the incident management system 10) on the operation terminal 6. The user U performs work according to the steps in the workflow in accordance with the incident management workflow (eg, FIG. 2), resolves the incident, and restores the service (the service provided by the monitored device 2 in the data center 1). Let Information such as the start time and end time of each step on the workflow and the department in charge is recorded in the incident processing history information 22. Correspondences such as workflows (steps) are also shown in FIG.

  The follow system 30 executes a follow process (details will be described later, FIG. 9) once a month, for example. In this follow process, the previous month's incident is acquired from the incident information 21 table, incident process history information is acquired from the incident process history information 22 table, and the incident resolution time (Ta) is calculated for each incident. In this process, the source information 23 and the service information 24 are matched using the incident source as a key, and the service stop allowable time (Tb) is acquired. If the incident resolution time (Ta) exceeds the service stoppage allowable time (Tb), the longest step among a plurality of steps passed through the incident resolution process is acquired as the follow target (improvement target). . The contact address (mail address) and request definition ID to be followed are acquired from the table of the step charge information 41 in the follow information DB 40 using the responsible department and step name related to the follow target step as keys. The record indicated by the acquired request definition ID is acquired from the table of the request definition information 42, and the improvement request mail 50 created using the subject name and the text definition information described in the record is transmitted to the follow-up mail address. The follow system 30 records the steps to be improved for the incident that has been followed (reflected in 21, 22, etc.). Then, the follow system 30 (list display function) creates an improvement target step list screen (FIG. 10) to be provided to the user U (operation terminal 6) using the data information. List improvement target steps in descending order of processing time. The user U can refer to the screen on the operation terminal 6 to check the improvement target step and reflect the information according to the improvement.

  In the present embodiment, for example, the incident management system 10 and the follow system 30 are shown to be independent and separated. However, they may be integrated into one, and each function (processing unit) ) May be separated into each system.

  Each system / each processing unit such as the incident management system 10 and the follow system 30 is a software program processing such as a server device (configuration including a processor, a memory, a disk, an input device, an output device, a communication interface device, a bus, etc.) Can be implemented using For example, the operation terminal 6 includes software of a Web browser and a mail client, and can display a Web page screen provided by the incident management system 10 and the follow system 30 or receive and display a mail.

Incident management workflow
FIG. 2 shows an example of an incident management workflow (s1 and the like are processing steps). Regarding a failure incident, after starting recovery, (s1) as a first step on the workflow, there is a step of performing a primary solution with the department in charge as a service desk. (S2) If the incident is resolved (Y), the process ends. (S3) As a second step on the workflow, there is a cause investigation step by the design department (designer). (S4) As a third step on the workflow, there is a step of countermeasures by the design department (designer). As shown in this workflow, when it matches the above-mentioned past case and can be solved only by the service desk, the incident can be solved only by the primary solution step (s1). However, if the solution cannot be solved by the service desk alone (s2-N), in the design department (designer) that developed the corresponding service (service provided by the monitored device 2 in the fault state) After performing s3), the step (s4) of the countermeasure for the incident is performed.

[Supplement]
FIG. 11 shows, as a supplement, the correspondence relationship between the source (host, service, etc.), incident, workflow (step), department in charge, person in charge (user U), and the like. Incident sources, hosts, services, and the like are related to the data center 1, the monitoring target device 2, and the like. Incidents are associated with workflows. A workflow is associated with one or more steps (eg, # 1- # N). The steps include, for example, the primary solution, cause investigation, countermeasures, etc. described above (FIG. 2). Each step is related to a department in charge or a person in charge (user U). The department includes a service desk and each design department, and the person in charge includes the above-described service desk operator and the designer of the monitored device 2 (its software, etc.), and each has contact information (e-mail address, etc.). . Each step has a required time (from start time to end time). For example, the step requiring the longest time is the improvement target step.

Incident information
FIG. 3 shows a table example of incident information 21 existing in the incident DB 20 of FIG. This table includes items such as incident ID, generation source, generation time, message, status, matching case, presence / absence of follow-up, improvement task ID, and improvement implementation. The incident ID is information for uniquely identifying an incident. The generation source is host identification information or the like. The message is a failure information message or the like. The status is status information indicating the status of incident resolution, and includes values such as completed and being taken countermeasures. The matched case indicates a matched case by referring to the past case DB 12 described above. The presence / absence of follow indicates the presence / absence of follow-up (recovery work improvement request) by the follow system 30. The improvement task ID is identification information of the improvement task (corresponding to 22 task IDs). Improvement implementation is the status of the implementation of the improvement, and there are values such as completed / uncompleted.

[Incident processing history information]
FIG. 4 shows a table example of incident processing history information 22 existing in the incident DB 20 of FIG. This table has items such as task ID, incident ID, step name, department in charge, start time, end time, and the like. The task ID is information for uniquely identifying a task (incident processing history). The step name is the name of the step that performed the task processing. The department in charge is the responsible department signature (service desk, design A, B, C, etc.) of the task (step, etc.). The start time and end time are the start time and end time of the task (step or the like).

[Origin information]
FIG. 5 shows a table example of the source information 23 existing in the incident DB 20 of FIG. This table includes items such as a source ID, a source name, and a service ID. The source ID is information for uniquely identifying the source (the host or the like). The source name is the name of the host or the like. The service ID is service identification information provided by the originating host.

[Service Information]
FIG. 6 shows a table example of the service information 24 existing in the incident DB 20 of FIG. This table has items such as a service ID and a service stop allowable time. The service ID is the same as the service ID of 23. The service stop allowable time indicates an allowable time of a stop state (failure state or the like) in the service.

  For example, the incident management system 10 defines incident source information 23 and service information 24 provided by the source (host, etc.), and stores the incident information 21 in the incident DB 20 each time an incident occurs. . The user U (related person, etc.) confirms the contents of the incident from the operation terminal 6 on the screen provided by the incident management system 10, and follows the steps (work, etc.) until the incident is resolved according to the workflow provided by the incident management system 10. Is processed (implemented).

[Step charge information]
FIG. 7 shows a table example of the step charge information 41 existing in the follow information DB 40 of FIG. This table has items such as a step name, a department in charge, an e-mail address, and a request definition ID. The step name is a name of a step to be followed (candidate). The department in charge indicates the department in charge of the step. The email address is email address information to be followed. That is, it is an email address used as the destination of the follow email 50 to be sent to the person in charge (user U) in the department in charge of the step. The request definition ID is identification information of request definition information including a subject and a text described in the follow mail 50 (corresponding to 42).

[Request definition information]
FIG. 8 shows a table example of the request definition information 42 existing in the follow information DB 40 of FIG. This table includes items such as a request definition ID, presence / absence of a matching case, subject, and text. The request definition ID is information for uniquely identifying a record of request definition information. The presence / absence of a matching case indicates the presence / absence of a matching case of the incident to be followed (corresponding to 21). The subject and the text are information on the subject and text to be included in the follow mail 50. As shown in the figure, for example, there are “primary solution work review request”, “countermeasure procedure inappropriate review request”, “measure establishment request”, etc., depending on the difference in the presence or absence of steps and matching cases.

  The step charge information 41 and the request definition information 42 include follow content information defined for each step and each department. The follow system 30 (its manager, etc.) defines the contact information (email address) of each department in charge of the step in the step charge information 41, and defines the request and the definition information of the subject and text of the follow mail (50). It is defined as information 42.

[Recovery work improvement request automatic transmission process]
The flow of FIG. 9 shows a specific example of recovery work improvement request automatic transmission processing executed by the follow system 30 (follow function). S101 and the like indicate processing steps.

  (S101) The follow system 30 acquires (reads) information on incidents that occurred in the previous month from the incident information 21 (FIG. 3) in the incident DB 20 at a timing such as once a month.

  (S102) 30 repeats the process between S102 to S115 for each incident, as many as the number of acquired incidents.

  (S103) 30 determines whether the incident is a completed status (FIG. 3). If not completed (S103-N), the next incident is processed.

  (S104) 30 acquires (reads) the incident processing history information 22 (FIG. 4) using the incident ID (FIG. 3) as a key.

  (S105) 30 calculates (acquires) the incident resolution time (Ta). That is, the sum of the required time ([end time] − [start time]) in each processing history (record) acquired in S104 is calculated as Ta.

  (S106) 30 refers to the source information 23 (FIG. 5) and the service information 24 (FIG. 6), and acquires the service stop allowable time (Tb) of the service provided by the incident source. That is, the service ID is acquired by searching the service source information 23 using the source of the incident as a key, and the service stop time (Tb) is acquired by searching the service information 24 using the service ID.

  (S107) 30 determines whether the incident resolution time (Ta) exceeds the allowable service stop time (Tb) (Ta> Tb). If not exceeded (N), the process proceeds to the next incident.

  (S108) 30 repeats the process of S109 in S108 to S110 for each incident process history by the number of the acquired incident process histories.

  (S109) 30 acquires the step (FIG. 11) with the longest working time and sets it as the follow target step. That is, the step having the longest required time ([end time]-[start time]) is acquired.

  (S111) 30 searches the step responsible information 41 (FIG. 7) based on the step name of the follow target step and the information of the department in charge (FIG. 4), and follows the follow target (work improvement request target). Information on the mail address and request definition ID for the mail 50 is acquired.

  (S112) 30 acquires a record (request definition information) from the request definition information 42 based on the request definition ID acquired in S111.

  (S113) 30 creates and sends a follow-up mail (work improvement request mail) 50 based on the mail address acquired in S111 and the subject and text information in the request definition information acquired in S112.

  (S114) 30 records and updates the information (there is a task ID) in the items of the presence / absence of follow-up and the improvement task ID in the incident information 21 table (FIG. 3) for the incident that has been followed. In the improvement task ID, the task ID of the record of the incident processing history (22) that has become the follow target step is recorded.

  (S115) When the above process is repeated for the number of incidents acquired in S101, the process ends.

[screen]
FIG. 10 is an example of the improvement target step list screen provided to the user U (operation terminal 6) by the list display function of the present system (follow system 30). On this screen, based on the above-described processing and each data information, list information regarding the steps that the follow system 30 followed as an improvement target is displayed. In particular, the processing priority (order of countermeasure priority) is displayed in descending order from the longest processing time required in a plurality of steps (corresponding incidents and tasks). As described above (FIG. 9), information corresponding to the longest step among the workflow steps of the incident whose resolution time (Ta) exceeds the allowable time (Tb) is displayed at the top of this list. become. Using the follow content information (41, 42), a plurality of target steps are displayed in a list in order of priority for handling.

  The table in FIG. 10 displays items such as incident ID, step name, department in charge, start time, end time, required processing time, and improvement implementation based on the data information described above. It also has information on the month to be counted and a “change to implemented” button.

  With respect to the step in which improvement is performed by the user U following the follow by the follow function, the status is changed from “not yet” to “completed” (improved) by, for example, a “change to performed” button. For example, the user U such as an incident manager checks the top of the list on this screen in order from the highest priority. For example, if the status is “not yet”, the improvement review department (the user U such as the designer) ) Can confirm the work status. Similarly, a user U such as a designer can confirm a step (work or the like) to be improved on this screen. It is also possible to make a transition from this screen to a display screen for each data information such as incident information 21 for confirmation.

[Effects]
As described above, in the system according to the present embodiment, information such as the incident information (21), incident processing history (22), and service stop allowable time definition (24) generated by the follow system 30 or the like is used. For example, the follow function that automatically sends the improvement request information (50) to the department in charge / step of the step (user U) who spent the most time for each incident, and priority to deal with the improvement target step (work) A function is provided in which a list is displayed in order and the user U can confirm and operate. In this system, contact information and contact details are defined for each follow target (23, 24), a processing history until the resolution of the incident that occurred is stored (22), and the resolution time (Ta ) Is determined as a follow-up step that spends the most time of incidents exceeding the service stop allowable time (Tb), and the improvement request information (50) is automatically transmitted to the department in charge of the step (user U). Perform processing.

  As a result, for example, it is possible to shorten the service recovery time by urging the department / person (user U) who caused the delay in the service recovery to improve the recovery work content and follow it. In order to reduce the delay of incident resolution, the department causing the delay has a process of scrutinizing and improving the recovery work to shorten the recovery time. The function of this system (incident resolution time analysis and follow-up mechanism) can act on the process and make the process more efficient.

  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.

  The present invention can be used for a monitoring center for a data center or the like, an incident management operation system in an outsourcing service, a failure handling business support system, and the like.

  DESCRIPTION OF SYMBOLS 1 ... Data center, 2 ... Monitoring object apparatus, 3 ... Fault monitoring apparatus, 4 ... Communication line, 5 ... Monitoring center, 6 ... Operation terminal, 10 ... Incident management system, 11 ... Fault information input part, 12 ... Past example DB , 20 ... incident DB, 21 ... incident information, 22 ... incident processing history information, 23 ... source information, 24 ... service information, 30 ... recovery work improvement follow system, 40 ... follow information DB, 41 ... step charge information, 42 ... request definition information, 50 ... improvement request email.

Claims (2)

An incident management and operation system for performing incident management and operation work for an information processing system,
The incident management operation business includes a workflow for solving and handling an incident including a failure that occurs in the information processing system. The workflow is composed of one or more steps, and the work of each step is performed by the department in charge. Done by the user,
Has a follow-system having a follow function to achieve follow and automatically send information improvement request on the work step of the workflow of the incident to the department or user,
The steps to follow are the steps of incidents where the resolution time exceeds the allowable time, and the steps with the longest time required from the start to the end of the work .
The follow function of the follow system includes incident information, incident processing history information including information on a time required for the step, incident source information, service information including information on the allowable time, the step, a department in charge , And step responsible information including contact information, and request definition information including definition information for creating the improvement request information defined for each step and department in charge, the follow target step An incident management and operation system characterized by determining information and creating information on the improvement request . In the incident management operation system according to claim 1,
The follow system has a list display function for providing a screen for displaying a list of information about one or more steps to be followed as a priority in order of longest required time to the department in charge or the user terminal. And
The list display function of the follow system includes the incident information, incident processing history information including information on the time required for the step, service information including information on the origin of the incident, and information on the allowable time, and the step Step definition information including information on the department in charge and contact information, and request definition information including definition information for creating the improvement request information defined for each step and department in charge, An incident management and operation system characterized by determining a follow target step and creating a screen for displaying the list .

Images