JP2011076161A - Incident management system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a technique allowing efficient handling in response to a characteristic, a situation of an objective system or the like, in an operation management system (incident management system). <P>SOLUTION: The incident management system 10 obtains information of an incident (including information of the characteristic and the situation of an objective system 1) generated in the objective system 1. A handling information obtaining part 30 determines whether information of the incident corresponds to known incident information or not, by retrieving information stored in a DB 50, and obtains and outputs handling information including a handling procedure about the known incident, when corresponding to the known incident. The handling information obtaining part 30 also draws out a proper handling procedure, based on the characteristic and the situation of the objective system 1, a service level and the like, on the basis of a retrieval result. The system displays or notifies the handling information and the like in/to terminals of handling persons (U1, U2). <P>COPYRIGHT: (C)2011,JPO&INPIT

Description

  The present invention relates to a technology such as an operation management system for an information processing system, and more particularly to a technology for incident management performed by a responder and a computer.

  In the operation management system of the conventional technology example (incident management system that is a component thereof), when an incident (error, failure, inquiry of a problem, etc.) occurs in the target system, responders such as the service desk (the operator) Whether or not the incident is a known incident is determined by performing a search process from a database (stores information on known incidents) based on a manual operation. The known incident is an incident that has occurred in the past or an incident that has not occurred in the past. If there is a corresponding incident (information) in the search results, the responder refers to the information on the response procedure (for example, the procedure for system recovery from the failure state) related to the relevant incident, and responds accordingly ( Incident response (for example, system recovery) is executed or instructed.

  For example, in a securities system as a target system, as characteristics and status of a system including business (for example, stock information providing service), for example, characteristics and status related to date and time (business days, service hours, place, etc.), components (servers, etc.) Its importance, status of operation, etc. (number of users, etc.), predetermined service level (for example, availability), etc., vary in real time.

  Therefore, depending on the characteristics and status of the target system, the required response procedure, the urgency, importance, and impact of the response when an incident occurs greatly differ. For example, in a situation where there are many users in a securities system and there is a failure in a system (server) that provides a brand search service, the urgency and importance of handling (such as recovery) is high.

  As a prior art example related to the incident management system, there is JP-A-2008-129773 (Patent Document 1). In this technical example, the importance of incidents is taken into account in the management of incident processing (business process) for service desk operators, system developers, operations personnel, etc., who respond to system incidents, specifically impact. It is described that (an index for determining the priority of incident processing) is calculated.

  The conventional technology as described above is not a technology for automatically determining a response in consideration of past (known) incident information by a computer.

JP 2008-129973 A

  As described above, in the operation management system (incident management system) of the prior art example, the responder manually searches for information to determine and respond to the incident in the target system, and the efficiency of the response, etc. Is insufficient.

  In addition, as described above, conditions such as response procedures required to respond to incidents may differ depending on the characteristics and status of the target system. It is not a system that takes into account, and the efficiency of handling in such a case is insufficient.

  In view of the above, a main object of the present invention is to provide a technique that is related to an operation management system (incident management system) and that can realize an efficient response according to the characteristics and status of the target system.

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

  The system of the present invention (incident management system), when incidents of target systems (securities systems, etc.) occur and are detected, appropriate incident response information according to real-time fluctuations such as characteristics and status of the target system, It is automatically acquired and output according to the reference / search of information on known incidents (incidents that have occurred in the past or assumed even if they have not occurred) stored in the database.

  The form of this system is, for example, an incident management system that is a component of a system that manages and manages the target system, and that uses a computer to manage incidents in the target system. Based on the information stored in the database (incident and response management information) automatically, it is determined whether the incident that occurred corresponds to a known incident (match or similar), and applicable Information including procedures for handling known incidents is acquired, the acquired information is output as information to be applied to the incident that has occurred, and processing such as displaying or notifying the responder's terminal is performed.

  The effects obtained by typical ones of the inventions disclosed in the present application will be briefly described as follows. According to the present invention, it is related to an operation management system (incident management system), and an efficient response can be realized according to the characteristics and status of the target system.

1 is a diagram illustrating an overall configuration of a system (an information processing system including an incident management system) according to an embodiment of the present invention. It is a figure which shows the outline | summary of the information data handled by this system. It is a figure which shows the example (the 1) of the management information table (incident information, response information) of the database in this system. It is a figure which shows the example (the 2) of the management information table (incident information, response information) of the database in this system. It is a figure which shows the example of the management information table ((a) service level, (b) field) of the database in this system. It is a figure which shows the example of a correspondence information acquisition process flow in this system. It is a figure which shows the relationship in the example of an incident in this system. It is a figure which shows the example (the 1) of the display information (incident information, response information) in this system. It is a figure which shows the example (the 2) of the display information (incident information, response information) in this system. It is a figure which shows the example (the 3) of the display information (incident information, response information) in this system.

  Hereinafter, a system (incident management system and an operation management system including the system) according to an embodiment of the present invention will be described in detail with reference to the drawings (FIGS. 1 to 10). The characteristic configuration of this system is, in particular, the correspondence information acquisition unit 30 and DB 50 of FIG. Correspondence information acquisition unit 30 includes the incident information in the target system 1 and the corresponding incident information 51 (including the response procedure and the target time) adapted to the characteristics and situation at that time, and the known incident information 51 ( And the correspondence information) are automatically referred to / searched to obtain / acquire them and output them to the responders (U1, U2).

<System>
FIG. 1 shows the overall configuration of the present system. The whole has a target system 1 and an operation management system 2. The operation management system 2 includes an incident management system 10 and a responder and response system 3. Each system is connected for communication. A1 and the like indicate communication access, operation, and information data flow.

  The target system 1 is an information processing system that is a target of operation management by the operation management system 2 and incident management by the incident management system 10, and is used and operated by a user U0 (customer or the like). The target system 1 is, for example, a securities system and includes a stock information providing site. The target system 1 includes a group of servers 203 that constitute one or more systems (services) 202. The system (service) 202 is, for example, a brand search system (service). The server 203 includes a program for performing processing for providing the service.

  The operation / history information of the system (service) 202 is recorded in a log 201 (log file). By referring to the log 201, it is also possible to acquire or determine an incident and various types of information (FIG. 2) such as the characteristics and status of the target system 1 related to the incident and the service level. The target system 1 is set with a predetermined service level (described later, FIG. 5). The service level is defined in accordance with characteristics such as a part (component) of the target system 1 and a date and time. In the present system, the service level of the target system 1 is also taken into account when calculating the correspondence information. Incidents include those caused by various malfunctions, errors, failures, performance degradation, their possibility, inquiries, etc. in the target system 1. The incident inhibits provision of a service that satisfies a predetermined service level in the target system 1.

  The responder and the response system 3 are responders (U1, U2) who perform the response (A13) to the incident of the target system 1, and an information processing system used by the responder. For example, a computer terminal (including a Web browser) such as a PC or a mobile phone, and a communication LAN for connecting them.

  The first responder U1 is, for example, a service desk operator who responds immediately when an incident occurs or is detected or when an inquiry (A11) is received from the user U0 (target system 1) by telephone or the like (A11). Inquiries, responses, cooperation, etc.) (primary responders). For example, U1 is always ready for viewing by viewing the screen of the terminal (such as a Web screen (Web page) provided by the screen display unit 20) during business (A3a). If the inquiry or the like (A11) cannot be dealt with (resolved) at the level of U1, cooperation (escalation) corresponding to U2 is performed (A12).

  The second responder U2 is, for example, a developer or an operator of the target system 1 and normally performs a predetermined job, and receives a notification (A9b, A12) from the system or U1 when necessary. Thus, the person who responds (secondary responder). The developer is a developer of the components of the target system 1 (system 202, server 203, its program, etc.). The operator is a person in charge of maintenance / operation work of the components of the target system 1. For example, U2 does not browse the display of the terminal screen in real time (A3a) like U1, and recognizes the incident and the necessity of response by the notification.

  The incident management system 10 includes a detection unit (incident acquisition unit) 11, a correspondence information acquisition unit 30 (search unit (incident search unit) 12, a derivation unit (corresponding information derivation unit) 13), a screen display unit 20 (incident information display unit). 21, correspondence information display unit 22), correspondence information notification unit 23, registration unit 40, DB (database) 50, and the like. Each processing unit is configured by a device such as a server, a program, or the like, and communicates information data between the processing units.

  In the DB 50, necessary management information including incident information 51 and correspondence information is integrated and managed (a table 60 in FIG. 2, which will be described later). The incident information 51 is information on known incidents, and includes information on incidents that have occurred and acquired in the past (IA), information on incidents that have not occurred in the past (IB), and the like. The IA is information that is automatically acquired and stored by a computer through the system (detecting unit 11). The IB is information that is manually registered and edited by a responder (U2 or the like) through the registration unit 40. Any information (IA, IB) is a target of search or the like. Correspondence information (incident response information) is associated with the incident information 51 and managed. In this embodiment, the incident information 51 is managed by including the correspondence information in (attribute), but may be managed separately.

  The detection unit 11 detects the occurrence of an incident from the target system 1 by regular monitoring of the log 201 or the like (A1), and acquires incident information about the generated incident (A2). The information acquired here includes information (log message, date and time of occurrence, occurrence location, etc.) indicating the characteristics and status of the target system 1 at that time. The incident information is managed by including (attributes) information such as its characteristics and status. The detection unit 11 passes the acquired incident information to the incident information display unit 21 of the screen display unit 20 (A3). The detection unit 11 stores the acquired incident information in the DB 50 (A4, IA).

  Moreover, the detection part 11 may acquire incident information similarly via the responder and the response system 3 besides acquiring the said incident information directly from the target system 1 (A14). For example, you may notify the detection part 11 of the incident by the inquiry etc. (A11) from the user U0 to the responder U1.

  The screen display unit 20 provides information for displaying incident information 51, response information, and the like in the form of a Web screen (Web page) or the like to the terminal of the responder U1 (described later, FIGS. 8 to 10). Based on the information (A3) from the detection unit 11, the incident information display unit 21 creates and displays an incident information screen (for example, incident information (1) in FIG. 8) regarding the current incident. The responders (U1, U2) can recognize the current incident by browsing the screen (A3a, A3b). Together with the screen display and the like, cooperation is performed to the correspondence information acquisition unit 30 (A5).

  The response information acquisition unit 30 automatically refers to and searches information in the DB 50 for the current incident, and derives and acquires response information suitable for the situation of the real-time target system 1 related to the incident. Is performed (described later, FIG. 6).

  The search unit 12 performs a search process of the incident information 51 in the DB 50 based on the information (A5) of the incident that has occurred from the detection unit 11 (A6). The search unit 12 searches and collates the known incident information 51 (including IA and IB) (matching destination) in the DB 50 using the information on the incident incident as a search key (matching source). Thereby, it is determined whether or not the incident incident corresponds to a known incident (match or similar). When it corresponds, the search part 12 cooperates with the derivation | leading-out part 13, and passes the search and determination result information containing the information of applicable incident (candidate) to the derivation | leading-out part 13 (A7).

  The deriving unit 13 is based on the information (A7) from the search unit 12, that is, the incident (including information on the characteristics and status of the target system 1 at that time) and the information on the corresponding incident, and the characteristics of the target system 1 at that time. A process for deriving or selecting an appropriate response procedure or the like according to the situation or service level is performed. The deriving unit 13 obtains correspondence information including the corresponding procedure by performing calculation using the information (A7) and the information of the DB 50 (A8). The deriving unit 13 outputs correspondence information regarding the incident incident to the correspondence information display unit 22 and the correspondence information notification unit 23 of the screen display unit 20 (A9).

  The deriving unit 13 derives at least information on the handling procedure and information on the target time and impact in addition to the information on the corresponding procedure. Information such as the target time is output in association with the response procedure. Alternatively, when the response procedure is determined, information such as the target time is reflected. The deriving unit 13 determines whether or not the response procedure for the corresponding incident (candidate) is appropriate as the response procedure applied to the incident incident. That is, the deriving unit 13 confirms information such as the characteristics, status, and service level of the target system 1 related to the incident incident, derives a target time and the like regarding the corresponding procedure, and determines the appropriateness by comparing them. Determine the corresponding procedure to be applied.

  Based on the information (A9) from the derivation unit 13, the response information display unit 22 displays a screen of response information related to the incident (for example, incident response procedure (1) in FIG. 8) (A9a). A responder (such as U1) can recognize the response procedure for the incident that has occurred by browsing the screen.

  The correspondence information notification unit 23 notifies the incident information, the correspondence information, and the like regarding the incident incident to the terminal of the cooperating counterpart U2 such as the developer by means such as e-mail or telephone (A9b). The notification information may be the same as the Web screen information on the screen display unit 20 (21, 22), for example, or instruction information for browsing the display information. The responder (U2 or the like) can recognize the incident and the response procedure to be executed by the notification. In addition, about the display and notification of the said incident information and response information, you may carry out to both of 2 types of responders (U1, U2).

  The registration unit 40 (incident and response information registration unit) performs a process of registering the incident information 51 and the response information as its attribute in the DB 50 (IB) based on the manual input operation of the responders (U1, U2) ( A15). For example, the registration unit 40 provides a user interface screen for the registration. In this registration, the responder U2 such as a developer can freely register and edit information such as a response procedure (for example, a system recovery procedure) performed for an incident (for example, a failure) that has actually occurred. Can do. Moreover, even if it does not occur, information such as an assumed incident and a response procedure can be registered and edited in advance. For example, an error that can be predicted by a developer from the program of the server 203 and a script corresponding to the error are assumed.

  Also, from the registration unit 40, key information (described later) such as a case key for designating (determining) incidents as the same case can be registered and edited as an attribute of the incident information 51 by the responder. If the key information is registered on the basis of the incident response results, a matching incident (same case) is determined at a high speed by making a determination using the key information in the search processing by the search unit 12 from the next time. Can be acquired.

<Incident-Response procedure>
The following shows an example of the case where the response information acquisition unit 30 outputs response information such as a response procedure adapted to the characteristics, status, etc. of the target system 1 for the incident that has occurred. This is an example in which the response procedure differs depending on the location of the incident, the date and time of occurrence, the status of operation and failure, and the like.

  (Example 1) When a hardware failure has occurred as an incident in a redundant part (for example, the server 203 of the system 202) in the target system 1. In this case, when the occurrence date and time of the incident falls under [on-site] which is a predetermined date and time characteristic, as the response procedure a, the system 202 is continuously operated without replacing the hardware at the relevant location, and the priority is given. Continue to monitor the area. Further, in the case of “other than in the field”, the system 202 is stopped as a response procedure b, and the hardware at the corresponding location is replaced.

  (Example 2) When a bug (error) of an application at a predetermined location in the target system 1 is found as an incident. In this case, if the occurrence date / time of the incident corresponds to [on-site] which is a predetermined date / time characteristic, the system 202 cannot be stopped as the response procedure c, so that the corresponding processing (corresponding to the bug (error)) When the processing that is caused occurs, the corresponding person manually rewrites the data. Further, in the case of “Other than in the field”, as the handling procedure d, the error part is corrected, and the service of the application is restarted.

  In this system, as in the above example, the processing of the response information acquisition unit 30 and the DB 50 so that the response information (for example, response procedures a to d) corresponding to the characteristics and situation of the target system 1 regarding the incident incident can be selected. Information is configured. For example, incidents and response information according to the above example can be registered in the DB 50 (IB) by the responder, and are automatically selected by the response information acquisition unit 30 according to the above situation and the like.

<Target time, impact, etc.>
Examples of target time, impact, etc. will be described. When the response information acquisition unit 30 determines the response procedure and the like (response information) based on the incident and the characteristics and status of the target system 1 related thereto, the difference in impact (impact) due to the incident and the characteristics and status Can be determined in consideration of and reflected in the information (which is automatically realized by the processing of the DB 50 information and the correspondence information acquisition unit 30).

  As described above, depending on the characteristics and status of the target system 1, the required response procedure, the urgency, importance, and impact of the response when an incident occurs greatly differ. On the other hand, in the present system, it is possible to determine the corresponding information (for example, the response procedure and the target time) in consideration of and reflecting that the impact of the incident varies depending on, for example, the occurrence date and time (date characteristics) of the incident. Such an example is as follows.

  (Example 1) A failure (IA) occurs in the system 202 or the like of the target system 1 (securities system). At that time (occurrence date and time), an application (such as a program of the server 203) affected by the failure (IA) is If it is not running. For example, the occurrence date / time corresponds to [other than on-site]. In this case, it can be determined that there is no or little influence (small impact) due to this failure (IA). Therefore, a procedure for dealing with the contents in consideration of this and the target time (the urgency is small) are derived. For example, the target time can be delayed according to the time margin until the next [on-the-fly] (time during which the application operates).

  (Example 2) A failure (IA) occurs in the system 202 or the like of the target system 1 (securities system), and the time (occurrence date and time) is a peak time zone, and the application (server 203) affected by this failure (IA) The program is running. For example, the date and time of occurrence corresponds to [on the spot], or the number of users corresponds to a predetermined value or more. In this case, it can be determined that the influence (IA) is large (impact is large). Therefore, a procedure for dealing with the contents in consideration of this and the target time (the urgency is large) are derived. For example, rather than responding to other incidents (when there are multiple incidents that need to be handled) (target time, etc.), the target time etc. Derived. For example, the target time can be advanced according to the priority. Further, for example, target times and responders in a plurality of pieces of correspondence information regarding a plurality of incidents may be scheduled in consideration of the priority. For example, the technique of Patent Document 1 may be used.

  Further, in the present system, the response information can be determined in consideration of the time (date / time characteristics) that is the target of executing the response to the incident incident (response procedure). For example, the contents of the corresponding procedure as an application candidate, the target part and the required time, the date characteristic of the time as an application candidate, the service level, and the like are considered. Such an example is as follows.

  (Example 1) A failure (IA) occurs in the system 202 or the like of the target system 1 (securities system). As a countermeasure (corresponding procedure) for this failure, for example, it is desired to execute a restoration procedure of the system, which requires a reboot of the system. Therefore, when the occurrence date is “on the spot”, it is inappropriate to immediately execute the corresponding procedure. Accordingly, a target time or the like is derived in order to execute the corresponding procedure by estimating the time when the time is “outside the field”.

  (Example 2) The occurrence date and time of the failure (IA) is, for example, 8:30, and 30 minutes before the next time (9 o'clock) when it becomes [in-place]. Further, the time required for the procedure for dealing with this failure (recovery procedure, etc.) is estimated to be 10 minutes, for example. In this case, a target time or the like is derived so as to execute the corresponding procedure before the next [in-place].

  (Example 3) The occurrence date and time of the failure (IA) is, for example, 8:55, and 5 minutes before the next time (9 o'clock) when it becomes [in-place]. Further, the time required for the procedure for dealing with this failure (recovery procedure, etc.) is estimated to be 10 minutes, for example. In this case, it is determined that it is inappropriate to execute and complete the corresponding procedure before the next [in-place]. For example, the corresponding procedure is performed at a time avoiding the peak time zone after [in-place]. The target time or the like is derived in order to execute

<Information data>
FIG. 2 shows main information data handled by this system. The target system 1 has information such as system characteristics, status, and service level related to the incident in the form of a log 201 and other management information. The detection part 11 grasps | ascertains and acquires those various information. These various types of information may be managed by the incident management system 10 side, the detection unit 11 or the like. A record including incident information 51 and correspondence information 52 is recorded in the table 60 of the DB 50. The incident information 51 and the correspondence information 52 are associated with information such as the characteristics and status of the target system 1 and the service level.

  As system characteristic information, for example, information on component elements (parts), such as system type (for example, type of system 202), server name (for example, name of server 203), their importance, etc. There is information that defines information such as business days, service hours, and venues. As system status information, for example, information such as date and time of occurrence, occurrence site (eg, system 202, server 203, etc.), log message, number of users (eg, number of users of system 202, server 203, etc.), number of transactions, etc. is there. In addition, there is information defining service levels related to them.

  The incident information 51 includes, as attributes, an incident ID, whether an incident has occurred (classification), an occurrence date and time, an occurrence site (system classification, server name, etc.), status such as operation or failure (log message, number of users, etc.), There are information such as relationships with other incidents (parent-child ID, etc.), key information (same case key, auxiliary same case key), and the like. The parent-child ID is information indicating the relationship of the same case. The key information is registration information for determining the same case.

  The correspondence information 52 includes information such as a correspondence procedure (procedure, cause, comment, etc.), a target time for correspondence (plan, limit, etc.), impact, responder (display destination, notification destination, etc.), and the like. The target time is information related to the urgency of the response. The impact is information related to the impact level of incidents and responses.

  3 to 4 show a detailed example of the table 60 as an example of the data structure of the incident information 51 (including the correspondence information 52) of the DB 50. A record of incident information is created for each incident and response. The table 60 stores both a record for an incident (IA) that actually occurs / detected and a record for an incident (IB) registered by the responder (U2).

  Information of A (a, b) is basic management information. a is an incident ID (identification information). The “occurrence / non-occurrence” of b is a value for discriminating whether or not an actual incident has occurred as an incident type, and is set automatically by the present system. For example, Y (present) indicates information (IA) that the system has detected an incident that has actually occurred and is automatically stored in the DB 50. N (none) indicates information (IB) manually registered by the responder (U2) from the registration unit 40 with respect to an incident that has not occurred. In this example, a record with ID = 1 (incident I1) is a record for an incident (IA) such as a failure that actually occurred in [on-site], and a record with ID = 2 (incident I2) Based on the occurrence, the developer (U2) manually registers the correspondence information in [other than on-site] as an assumed incident (IB).

  The information of B (c to g) is information indicating the characteristics and status of the target system 1 and stores values automatically acquired from the target system 1 by the present system (detection unit 11). The “log message” of c is information of the log 201 and includes, for example, an error code, a failure content, a pattern, and the like. d is the occurrence date (date, day, day, time, etc.) of the incident. The value of d is stored when the presence / absence of occurrence is Y (IA), and is not stored when N (IB) (NULL value). In the figure, “-” indicates a NULL value.

  The “system type” of e is information such as the type and name of the target system 1 and the system 202 constituting it. For example, a system 202 that provides a brand search service is shown. The “server name” of f is information such as the type and name of the server 203 constituting the target system 1 or system 202. The information of e and f is information related to an incident occurrence site, a response target site, and the like, and also indicates the importance level of the element. For example, it has a predetermined importance according to the brand search service. Further, the importance level information may be stored separately in association with the correspondence information acquisition process.

  The “number of users” of g is the number of users who are using or accessing the target system 1 (occurrence site) at the time of occurrence of the incident. In addition, the number of transactions, the load amount, and the like may be managed and considered in the correspondence information acquisition process.

  C (h, i) information sets incident parent-child relationship (same relationship) based on automatic judgment processing by computer (search unit 12 etc.) and manual operation and judgment by responder (U2 etc.) , To manage. For example, when the search unit 12 determines that the generated incident corresponds to a known incident (match or similar) as a result of the search process, the search unit 12 sets the incidents in a parent-child relationship. That is, a known incident is a parent incident, and an incident incident is a child incident. Specifically, the system (search unit 12) automatically assigns and stores the value of the parent-child ID (h, i) to the record of the incident. The “parent ID” of h indicates the ID of the parent incident for the record of the incident (child incident). The “child ID” of i indicates the ID of the child incident for the record of the incident (parent incident).

  Also, the developer (U2) manually registers the relationship from the registration unit 40 when the next incident or later occurs with respect to a known incident and the incidents are determined to be the same incident. can do. In accordance with the registration operation, the system (registration unit 12) automatically assigns and stores the value of the parent-child ID (h, i) to the record of the incident in the same manner as described above.

  The information of D (j˜l) is the same case key. Information of E (mo) is an auxiliary coincidence key. As an example, three types (# 1 to # 3) of key information are set (# 1 etc. are identification numbers). The key information stores values manually registered by the developer (U2) from the registration unit 40. Such key information can be held as an attribute of the parent incident. The key information is information used when the search unit 12 searches for and determines the incident of the same case, and in order to determine that an incident that occurs after that with respect to a known incident is the same as that of itself. Information. The same case key is an indispensable setting value in order to obtain and display correspondence information through high-speed search / determination. The auxiliary case key is used as an auxiliary to the case key (described later). It should be noted that even if no hit is found in the search processing using these key information, or even if the key information is not set, it is known (match or similar) by performing a full-text search or the like on the incident information in the DB 50 / Unknown determination is possible.

  As the key information, various types of information regarding the characteristics and status of the target system 1 can be set. The same key # 1 of j is when the log message (error code or the like) is set. The same key # 2 for k is when the system type (for example, “brand search”) is set. The same case key # 3 of l is a case where the server name (for example, “Server01”) is set. The m auxiliary joint key # 1 is set when [business day] (for example, Y is [business day] and N is [non-business day]), which is one of the date and time characteristics. The case key # 2 of n is a case where [in-place] (for example, Y is [in-place] and N is [in-place]), which is one of the date and time characteristics, is set. The same case key # 3 of o is the case where the number of users (for example, “100 people or more”, “50 people or less”) is set.

  As information of F (pt), a value registered by the developer (U2) from the registration unit 40 is stored. The “corresponding procedure” of p is information describing the handling procedure. For example, an instruction and a comment for executing predetermined scripts A and B in order as in the procedure corresponding to the record of I1 (procedure 1). The “required time” of q is a standard time taken from the start to the end of the “corresponding procedure” of p. The “downtime actual value” of r is an actual value of downtime (time during which services cannot be normally provided) due to an incident such as a failure that has actually occurred. The “person in charge” (corresponding person) of s is the name and ID of the person who executes the “corresponding procedure” of p. The cause of t is information on the cause of the incident (such as what the responder has determined to be the cause).

  Further, in FIG. 5, as an example of the management information table of the target system 1, FIG. 5A shows a service level table 61, and FIG. 5B shows a place table 62. Such information is managed, for example, in the DB 50 of this system.

  The service level is preliminarily concluded when contracting with the customer (U0) of the target system 1 or the like. Based on this, the value of the table 61 is set. The service level is defined by availability (operating rate) for each unit such as characteristics of the target system 1, for example, system type (part) and date / time characteristics. The availability is expressed as an operation rate [%]. For example, higher availability is required for the system 202 or the time zone with higher importance.

  In the place table 62, the start time and end time of [In-place] of the place (for example, the TSE pre-stage and the TSE post-stage) in the securities system are defined. [In-place] is within stock trading hours, and the number of users is high. In addition, [business days] and [service hours] are managed in the same manner. The urgency (target time) of the response changes depending on the difference (variation) in the characteristics, status, service level, etc. of the target system 1 as described above.

<Correspondence information acquisition processing>
FIG. 6 shows a processing flow example in the correspondence information acquisition unit 30 (S represents a processing step).

  (S1) With respect to the incident incident (IA) from the detection unit 11, the search unit 12 searches for information in the DB 50 (table 60) and determines a known / unknown incident. In the search process, for example, incidents (and corresponding information) having the highest degree of matching / similarity are sequentially obtained as candidates (candidates for selecting and determining corresponding information to be applied). The search range of the DB 50 is such that the parent incident column (parent ID) in the record group of the incident information 51 is NULL (that is, other than the child incident). Since the record in which the parent ID is set is a child incident and is related to the parent, it is not necessary to include it in the search range.

  In the search process, when key information (FIG. 3, D, E) such as the same key is set in the record in the search range, the key is referred to and the search process using the key information is performed. The incident of the same case is determined according to the hit by the key information. When key information is used, a full-text search or the like is unnecessary, so that a result can be obtained at high speed. If the key information (D, E) is not set, for example, a full-text search targeting information (FIG. 3, B) indicating the characteristics and status of the target system 1 such as the system type and log message. (Fuzzy search) or the like is applied, and the incidents of the same case are determined by checking the degree of matching / similarity between the incidents by collation.

  When a known incident is hit in the search result, the derivation unit 13 is linked. When no hit is found (ie, when it is determined as unknown), for example, the information is displayed or notified to the terminal of the responder in cooperation with the screen display unit 20 or the notification unit 23.

  (S1-1) First, as a first-stage search, the search unit 12 uses the same key information (D) to search for a record group of the incident information 51 under conditions such as complete matching. As a result, for example, when all the same case keys are hit, the record is determined to be the same incident.

  (S1-2) In addition, as a second-stage search, the search unit 12 uses the auxiliary coincidence key information (E) to search for a record group of the incident information 51 based on conditions such as partial matching. . As a result, the hit record (group) is ranked according to the degree of matching / similarity, and is obtained as a candidate from the top. As the candidate incident, for example, a plurality of candidates may be output as a list in order from the top.

  Based on the search processing result, incident response information (response procedure) to be applied to the incident incident is temporarily determined as one candidate (for example, procedure X).

  (S2) The deriving unit 13 extracts information such as the occurrence date / time characteristic, occurrence site, status of operation, service level, and the like regarding the incident (refer from the detection unit 11 or the DB 50). For the service level, the value of availability (operating rate) corresponding to the part, date, etc. is extracted from the table 61 of FIG.

  (S3) The deriving unit 13 derives a correspondence completion date limit (T1) that is one of the target time information regarding the procedure X. At this time, the time information is derived in consideration of information such as the occurrence date and time of the incident extracted in S2. For example, the deriving unit 13 derives the occurrence date and time and the downtime allowable time at the occurrence site based on the date characteristic and the service level, thereby deriving the correspondence completion date limit (T1).

  (S4) The deriving unit 13 derives a correspondence completion date / time schedule (T2) that is one of the target time information regarding the procedure X. For example, the deriving unit 13 refers to the required time (q) of the procedure X, confirms whether it is in time for the limit (T1), and derives the response completion date / time schedule (T2).

  (S5) Based on the target time information (T1, T2) regarding the procedure X, the deriving unit 13 confirms the status (change) of the service level and the like in the time until the schedule (T2) is reached. For example, as shown in the table 61 of FIG. 5, there is a transition of the service level specified value according to the date and time. If there is no change, it is OK. If there is a change, it is NG if the limit (T1) is not met.

  (S6) The deriving unit 13 confirms and determines the appropriateness and validity of the procedure X and the target time information (T1, T2). For example, in the case of NG in S5, the process returns after S1, selects a candidate again from the result of S1, and repeats the processes of S2 to S6.

  (S7) As a result of S6, information such as the response procedure (procedure X) and target time information (T1, T2) determined to be OK is determined and output as response information to be applied to the incident that has occurred.

<Processing case (1)>
Based on the above processing flow, table 60, and the like, a processing example in each incident case will be described below with reference to FIG. 7 and FIGS. FIG. 7 simply shows a time series relationship of incidents (I1 to I5) in each case. Incidents I1 (IA) and I2 (IB) are the same as those in the above-described table 60 (I1 is an example of occurrence of [in the field] and I2 is an example of registration for responding to [other than in the field]). 8 to 10 show examples of Web screen display information (incident information 51, incident response procedure (response information 52)) by the screen display unit 20 (21, 22). The underlined portions indicate different information portions in FIGS. 8 to 10 for easy understanding.

  The first case is a case where an incident I3 such as the following failure occurs in [business days], [within service hours], and [in-place] of the target system 1 (securities system). I3 is also an example of occurrence [in the field] (type is IA). The display information is incident information (1) and incident response procedure information (1) in FIG. As shown in the incident information (1) in FIG. 8, the incident ID is 3, the occurrence date and time is August 12, 2009 (Wednesday) at 10:00, the system type is “brand search” as the occurrence site, the server name Is the server 203 of “Server01”. Other situations include the log message and the number of users.

  First, the result of the first case is shown. As shown in FIG. 7, the occurrence incident I3 (IA) matches I1 from the values such as the occurrence date and time, the occurrence site, and the log message by the search process (same case). And the corresponding procedure of I1 (procedure 1) is a candidate to be applied to I3. Next, target time information (limit (T1), schedule (T2), etc.) regarding the procedure 1 is derived in consideration of the characteristics and status of the target system 1 at that time, the service level, and the like. If the appropriateness of the result is confirmed as OK, the procedure 1 of I1 and the target time information are determined. As a relationship in this case, I1 is a parent, I3 is a child (child 1), and the procedure 1 of I1 is applied to I3. Detailed processing contents are as follows.

  (S1) The search unit 12 searches the DB 50 (table 60) to determine whether or not the incident I3 corresponds to a known incident. The same case key (D) (# 1 to # 3) is used as the search in the first stage (S1-1). As a result, for example, the records I1 and I2 in FIGS. As a search in the second stage (S1-2), the auxiliary same key (E) (# 1 to # 3) was used for the result (I1, I2) hit in the first stage (S1-1). Perform matching. Thereby, for example, the record of I1 hits with the highest degree of coincidence (I3 is closer to the content of I1 than I2 because I3 is an example of [In-place]). As described above, I1 and its corresponding procedure (procedure 1) are once selected as candidates.

  (S2) In order to derive target time information (limit (T1), schedule (T2), etc.) in consideration of the characteristics and status of the target system 1 related to I3, the deriving unit 13 relates to the procedure 1 of I1. Information on occurrence date, occurrence location, service level, etc. is extracted. The deriving unit 13 is based on the date and time of occurrence of I3 (Wednesday, August 12 at 10:00) and the location (system 202 or the like whose system type is “brand search”), the service level table 61 and the place table 62 or the like. The value of availability (operation rate) corresponding to the date and part is extracted. Since the date / time and part correspond to [business day] [service time] [in-service], the value is 95% as shown in [in-service availability in service time] (c).

  (S3) The deriving unit 13 calculates a limit (T1) related to the procedure 1 based on S2. First, the deriving unit 13 calculates a daily downtime allowable time (T3). The total time for the day is 4.5 hours (270 minutes) from the place table 62. [In-place] operating rate is 95% (5% in terms of allowable downtime). That is, T3 = [total time of day field] × [1−operation rate] = 270 minutes × (1−0.95) = 13.5 minutes.

  The deriving unit 13 calculates the limit (T1) based on the allowable time (T3). That is, T1 = [I3 occurrence date / time] + [T3] = [10:00] + [13.5 minutes] = 10: 13: 30.

  (S4) The deriving unit 13 calculates a schedule (T2) related to the procedure 1 based on S3. When the required time (q) in the procedure 1 is confirmed, it is “3 minutes”. The completion time when step 1 is executed immediately is [I3 occurrence date and time] + [required time] = [10:00] + [3 minutes] = [10:03]. In time for (T1) (in other words, the required time is within the limit). Therefore, the deriving unit 13 sets the schedule (T2) of the procedure 1 to [10:03].

  (S5) The deriving unit 13 confirms the status (change) of the service level in the time until the schedule (T2) is reached. For example, from the table 61, there is no change in service level until T2 = [10:03] (same 95%).

  (S6, S7) Based on the above, the deriving unit 13 determines that the procedure 1 of I1 is appropriate (OK) as the corresponding procedure applied to I3. Accordingly, the correspondence information output from the correspondence information acquisition unit 30 and displayed on the screen is, for example, as shown in the incident response procedure (1) in FIG. As a relationship of the same case, the ID value of I3 is stored in the child ID of the record of I1, and the ID value of I1 is stored in the parent ID of the record of I3.

<Processing case (2)>
As a second case, in the [business days] and [within service hours] of the target system 1, the incident I4 such as the following trouble is 15 minutes before “in-place”, that is, “out of place”. This is the case. I4 is an example of occurrence of [other than on-site] (type is IA). The display information is incident information (2) and incident response procedure information (2) in FIG. The different incident information includes an incident ID of 4, an occurrence date and time of August 14 (Friday) of 8:45, the number of users is 30, and so on.

  First, the result of the second case is shown. As shown in FIG. 7, it is determined that I4 (IA) corresponds to I1 and I2 by searching, and the corresponding procedure (procedure 1 and procedure 2) of I1 and I2 is a candidate. It becomes. The target time information (T1, T2, etc.) is also derived in the same manner as described above. Based on the determination of the appropriateness of the result, it is determined that I2 is NG and I1 is OK. Therefore, it is determined as the procedure 1 of I1 and the target time information. That is, I1 is a parent and I4 is a child (child 2), and the procedure 1 of I1 is applied to I4. Detailed processing contents are as follows.

  (S1) The search unit 12 performs a search process for I4 as described above. In the first stage (S1-1), for example, records I1 and I2 are hit by using the same case key (D). In the second stage (S1-2), for example, unlike the first case, the record of I2 matches / matches the result (I1, I2) using the auxiliary coincidence key (E). Hit with the highest degree of similarity (I4 is an example of the occurrence of [except in the field], so it is closer to the content of I2 than I1). By the above, I2 and its corresponding procedure (procedure 2) are once selected as candidates.

  (S2) The deriving unit 13 extracts the value of availability (operating rate) from the service level table 62 based on the information of I4. That is, it is [except in the field], and is 80% from [availability other than in the service time] (d).

  (S3) The deriving unit 13 calculates a limit (T1) related to the procedure 2 based on S2. As described above, the allowable downtime (T3) in days is calculated. The “total time of the place within the service time” is 450 minutes. The utilization rate of [except in-place] is 80%. That is, T3 = [total time of place within service time] × [1−operation rate] = 450 minutes × (1−0.8) = 90 minutes. The deriving unit 13 calculates the limit (T1) based on the allowable time (T3). That is, T1 = [I4 occurrence date and time] + [T3] = [08:45] + [90 minutes] = [10:15].

  (S4) The deriving unit 13 calculates a schedule (T2) related to the procedure 2 based on S3. When the required time (q) in the procedure 2 is confirmed, it is “45 minutes”. The completion time when step 2 is executed immediately is [I4 occurrence date and time] + [required time] = [08:45] + [45 minutes] = [09:30], and this time is the above limit. In time for (T1). Therefore, the schedule (T2) of the procedure 2 is set to [09:30].

  (S5) The deriving unit 13 confirms the status (change) of the service level in the time until the schedule (T2) is reached. There is a change in the prescribed value of the service level from the table 61 to T2 = [09:30]. That is, it switches from [Non-play] (80%) to [In-place] (95%) after 9:00. As discussed in the first case, this is not in time because the downtime allowable time (T3) of [In-place] is 13.5 minutes.

  (S6, S7) Based on the above, the deriving unit 13 determines that the procedure 2 of I2 is inappropriate (NG) as the corresponding procedure applied to I4. When the service level after the change is higher in the change in the service level, the value after the change is set as the value of the service level used for calculation / judgment.

  Returning to the selection of the candidate, this time, the procedure 1 of I1 that was the second closest result in S1 is selected as a candidate, and the processing after S2 is performed (similar to the case of the first case). For example, the limit (T1) is obtained as [08:48] and the schedule (T2) is obtained as [08:58]. As a result, the deriving unit 13 determines that the procedure 1 of I1 is appropriate (OK) as the corresponding procedure applied to I4. Accordingly, the correspondence information output from the correspondence information acquisition unit 30 and displayed on the screen is, for example, as shown in the incident response procedure (2) in FIG.

<Processing case (3)>
The third case is a case where an incident I5 such as the following failure occurs at the [non-business day] (holiday) of the target system 1. I5 is an example of occurrence of [non-business day] [outside service hours] (type is IA). The display information is incident information (3) and incident response procedure information (3) in FIG. The different incident information includes an incident ID of 5, an occurrence date and time of August 16 (Sunday) of 10:00, the number of users is 2, and so on.

  When the result of the third case is shown first, as shown in FIG. 7, I5 (IA) is determined to be I2 by the search, and the corresponding procedure (procedure 2) of I2 is a candidate. Target time information (T1, T2, etc.) is also derived in the same manner as described above. Based on the determination of the appropriateness of the above result, I2 is determined to be OK. Therefore, it is determined as the procedure 2 of I2 and the target time information. That is, I2 is a parent and I5 is a child (child 1), and the procedure 2 of I2 is applied to I5. Detailed processing contents are as follows.

  (S1) The search unit 12 performs a search process for I5 as described above. In the first stage (S1-1), for example, records I1 and I2 are hit by using the same case key (D). In the second stage (S1-2), for example, the matching rate (number) is 0 for I1 and 2 for I2 by matching using the auxiliary coincidence key (E) with respect to the result (I1, I2). I2 hits as having a higher degree of coincidence / similarity (I5 is an example of the occurrence of [non-business day], so it is closer to the content of I2 than I1). By the above, I2 and its corresponding procedure (procedure 2) are once selected as candidates.

  (S2) The deriving unit 13 extracts the value of availability (operating rate) from the service level table 62 based on the information of I5. That is, [Non-business day], which is 0% from [Service availability] (e).

  (S3) Based on S2, the deriving unit 13 determines the date and time when the service level is changed and the availability becomes other than 0% as the limit (T1) related to the procedure 2 when the availability is 0%. That is, from the table 61, T1 = August 17 (Monday) 8:00.

  (S4) The deriving unit 13 calculates a schedule (T2) related to the procedure 2 based on S3. When the required time (q) in the procedure 2 is confirmed, it is “45 minutes”. The completion time when step 2 is executed immediately is [I5 occurrence date and time] + [required time] = [10:00] + [45 minutes] = [10:45]. In time for (T1).

  (S5) The deriving unit 13 confirms the status (change) of the service level. Since it is a [non-business day], there is no change in service level for a while. As described above, when the availability is 0%, it is not necessary to display the schedule (T2), and information on the time required for the procedure 2 (“45 minutes”) is displayed.

  (S6, S7) Based on the above, the deriving unit 13 determines that the procedure 2 of I2 is appropriate (OK) as the corresponding procedure applied to I5. Accordingly, the correspondence information output from the correspondence information acquisition unit 30 and displayed on the screen is, for example, as shown in the incident response procedure (3) in FIG.

<Effects of the embodiment>
According to the present embodiment, when an incident occurs, unlike manual search / judgment work by a responder as in the conventional example, information in the DB 50 can be automatically searched / judged and the corresponding information can be output. An efficient response can be realized. Manual operation by the responders can be reduced and time can be reduced, and responders with less skills can easily handle the tasks. In addition, in order to be more effective than the conventional example, derivation calculation processing of information of DB 50, incident and correspondence information is configured. That is, for the same incident (for example, failure), different appropriate response information (response procedure, target time information, etc.) is obtained depending on the calculation considering the characteristics, status, service level, etc. of the target system 1 in real time. can get.

<Modification>
The following is mentioned about the modification of the said embodiment. For example, the processing method of the correspondence information acquisition unit 30 is not limited to one by determining similar incident information, but may determine a plurality of incidents and correspondence information and output display information (list) thereof. . For example, the responder can compare the correspondence information in the list and apply them in order from the higher correspondence information. In addition, when a parent incident indicating the same relationship is hit, if there is a child incident related to the hit, it may be automatically listed and the plurality of incidents and corresponding information may be output.

  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 an operation management system, an information security management system, and the like.

  DESCRIPTION OF SYMBOLS 1 ... Target system, 2 ... Operation management system, 3 ... Responder and response system, 10 ... Incident management system, 11 ... Detection part (incident acquisition part), 12 ... Search part (incident search part), 13 ... Derivation part ( (Corresponding information deriving unit), 20 ... screen display unit, 21 ... incident information display unit, 22 ... corresponding information display unit, 23 ... corresponding information notifying unit, 30 ... corresponding information acquiring unit, 40 ... registration unit, 50 ... DB, 51 ... incident information, 52 ... corresponding information, 60, 61, 62 ... table, 201 ... log, 202 ... system, 203 ... server, I, IA, IB ... incident (or incident information), U0 ... user, U1, U2 ... Corresponding person.

Claims (5)

An incident management system that is a component of a system that manages and manages a target system, and that performs processing for managing incidents of the target system using a computer,
Based on information on incidents that occurred in the target system, information on known incidents stored in the database is automatically searched to determine whether the incidents that occurred are known incidents. An incident management system characterized in that information including a procedure for handling a known incident is acquired and output as information for application to the incident that has occurred. The incident management system according to claim 1,
The first incident that occurred in the target system is detected, information on the first incident including information on the characteristics or status of the target system is obtained, stored in the database as information on known incidents, the first A first processing unit for displaying or notifying information on one incident on a terminal of a responder;
Based on the information on the first incident, the information on the incident stored in the database is automatically searched to determine whether the first incident matches or resembles a known incident. The correspondence information including the corresponding procedure of the second incident that matches or is similar is derived or selected according to the characteristic or status information of the target system of the first incident, and is applied to the first incident. A second processing unit that outputs as information for
A third processing unit for displaying or notifying information to be applied to the first incident on the terminal of the responder;
Based on the operation of the responder, including information on incidents that occurred in the target system and corresponding information including corresponding procedures, and information on incidents that are assumed even if they have not occurred, and corresponding procedures related to them An incident management system comprising: a fourth processing unit that registers correspondence information as information on the known incident in the database. In the incident management system according to claim 2,
The second processing unit is configured to respond to the second incident response procedure and target time information related to execution and completion of the response procedure according to information including an occurrence date and time and an occurrence site related to the first incident. , Is derived or selected, and is output as the correspondence information. In the incident management system according to claim 2,
In the target system, service level information according to the date and part is specified,
The second processing unit derives a response procedure for the second incident and target time information related to the execution and completion of the response procedure according to the service level information related to the first incident. Or an incident management system, wherein the information is selected and output as the correspondence information. In the incident management system according to claim 2,
The fourth processing unit, when registering the incident information and the response information in the database based on the operation of the responder, registers key information for determining the relationship of the incident in the relationship of the incident,
The second processing unit obtains information on the second incident that is determined to be the same as the first incident by searching with reference to the key information. Management system.

Images