JP5469011B2 - Incident management system, failure impact range visualization method - Google Patents

Description

  The present invention relates to a technology such as an incident management system in IT service operation management, and more particularly, to a technology for grasping and visualizing a configuration of a target system and a failure status.

  ITIL (Information Technology Infrastructure Library) Version 3 is a standard related to incident management in IT service operation management. In the incident management system, incidents such as failures occurring in the information processing system (target system) to be managed are recorded and managed as incident information, and linked to incident countermeasures (responses) and escalations.

  In the target system, technologies such as virtual servers and parallel distributed processing are applied with the development of the cloud environment. In the target system, components (configuration items) such as servers and databases are designed and multiplexed in consideration of fault tolerance (fault tolerance, performance, etc.) and performance based on the service level. Has been implemented.

  Examples of prior art include Japanese Patent Application Laid-Open No. 2007-257244 (Patent Document 1) (failure influence range specifying system and the like), Japanese Patent Application Laid-Open No. 2009-181537 (Patent Document 2) (incident management system and the like), and the like.

JP 2007-257244 A JP 2009-181537 A

  In conventional incident management systems (and related systems such as configuration management systems), the issues are the scope of impact and the impact destination (higher services, etc.), and the urgency and impact level when a failure (incident) occurs in the target system. It is difficult for the person in charge (incident manager) to grasp such information immediately. Therefore, it is difficult to quickly escalate and implement countermeasures in accordance with the priority based on these grasps. In particular, when the configuration part of the target system adopts a multiplexed configuration or the like according to the fault tolerance or the like, the above-described problem is remarkable because the influence relationship between the configuration parts (configuration items) is complicated.

  For the above problems, a technique for visualizing the status and configuration (incident status and operational status) of the target system on the screen, etc., is considered effective. However, in the conventional technology, there is insufficient examination and realization of technology that makes it easy to understand the situation and configuration such as the failure impact range in the target system of the configuration designed and implemented considering the cloud environment and fault tolerance etc. on the screen It is.

  The main object of the present invention relates to the above incident management system, etc., such as the situation and configuration of the failure impact range, the priority of incidents and countermeasures, etc. in the target system configured in consideration of the cloud environment and fault tolerance By visualizing information on the screen, the person in charge can immediately grasp the above situation in an easy-to-understand manner, and provide a technology that can realize prompt escalation and implementation of countermeasures.

  In order to achieve the above object, a typical embodiment of the present invention is an incident management system or the like, and has the following configuration.

  The incident management system manages incidents including failures in the target system in the first database as incident information, and cooperates with the configuration management system that manages the configuration of the target system in the second database as configuration information. In cooperation with a service portal system that provides information screens to the terminals of the system, it cooperates with a fault monitoring system that monitors incidents including faults in the target system. The incident management system uses the configuration information and the incident information to create a screen for visualizing the incident status including the configuration of the target system, the failure influence range, and the failure affected service, and provides the screen to the person in charge And a second function for setting a configuration including a configuration part designed in consideration of fault tolerance in the target system in the configuration information as a configuration management model.

  In the configuration management model, each configuration part including a configuration part designed in consideration of the fault tolerance is set as a first configuration item, and the fault tolerance for the first configuration item is set to the second. And the dependency between the configuration items including the first and second configuration items is set as a link. The screen by the first function displays an incident status including a configuration management model, a failure influence range, and a failure influence destination service of the target system in a structure in which the configuration items are connected by links.

  According to a representative example of the present invention, the status and configuration of the failure impact range, etc., and the priority of incidents and countermeasures in the target system related to the incident management system and the like, taking into account the cloud environment and fault tolerance, etc. By visualizing such information on the screen, the person in charge can immediately grasp the above situation in an easy-to-understand manner, and can implement prompt escalation and implementation of countermeasures.

It is a figure which shows the example of an outline structure of the whole computer system containing the incident management system of one embodiment of this invention. It is a figure which shows the structural example of each part concerning the incident management system of this Embodiment. It is a figure which shows the example of a screen which visualizes the structure management model of the object system in this Embodiment, and the condition at the time of normal. It is a figure which shows the example of a screen which visualizes the structure management model of the target system in this Embodiment, and the condition at the time of a failure. (A)-(f) is a figure which shows the example of the fault tolerance information of the fault tolerance configuration item (FTCI) of the target system in this Embodiment. It is a figure which shows an example of the structure information (structure item information) etc. in this Embodiment. It is a figure which shows the example of the status determination method of the configuration item in this Embodiment. It is a figure which shows the example of the information of the dependency relation between the configuration items in this Embodiment. It is a figure which shows the example of the structure management model (part) in this Embodiment. It is a figure which shows the priority calculation method etc. in this Embodiment. It is a figure which shows the example of the incident information in this Embodiment. It is a figure which shows the example of the incident screen in this Embodiment. It is a figure which shows the example of a screen in a prior art example.

  Hereinafter, embodiments of the present invention (incident management system, failure effect range visualization method) 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.

[Summary]
The outline and features of the present embodiment are as follows (FIGS. 1, 3, 4, etc.). As main features, the incident management system 10 has a failure influence range visualization function 101, and the configuration management system 20 has a failure tolerance configuration item (FTCI) setting function 102 (FIG. 1). The failure influence range visualization function 101 is a function for visualizing the configuration and failure status (failure influence range, etc.) of the target system 1 on a screen. The FTCI setting function 102 is configured in the configuration information (configuration management model) of the target system 1 as “failure tolerance” (design / implementation configuration considering failure tolerance) of a configuration part (configuration item: CI) such as a server. Is set as a kind of configuration item (fault tolerance configuration item: FTCI).

  The configuration item (CI) is a configuration part such as a server configuring the target system 1 in the configuration management model (configuration information) and the screen (FIG. 3 and the like), and is an element to be displayed on the screen. The CI is displayed as a specific icon or the like according to the category or the like. Dependencies (links) between CIs are also visualized with lines. A configuration management model including a CI and a link is set.

  “Fault tolerance” is in accordance with a well-known term (fault tolerance, etc.) in this technical field, and is designed and implemented in consideration of fault tolerance, performance, service level, etc. in the target system 1. This corresponds to various known techniques such as a redundant configuration (physical / virtual multiplexing / clustering, etc.). “Fault tolerance” is one piece of design information of the target system 1 (CI), and can be set as FTCI by the person in charge 3 or the like using the FTCI setting function 102.

  On the screen (FIG. 3, FIG. 4, etc.), information in which an analysis result (failure status, etc.) in this system is mapped on a configuration management model including FTCI is visualized. As a result, the person in charge 3 can immediately and easily understand the fault influence range and the escalation destination.

[System configuration]
FIG. 1 shows a schematic configuration example of the entire computer system including the incident management system 10. The incident management system 10 is a system that cooperates with the configuration management system 20, the service portal system 30, the failure monitoring system 40, and the like. Cooperation between processes such as operation management / monitoring, incident management, and configuration management is systematized. The target system 1 is an information processing system (operation system) that is a target of incident management operation. The person in charge 3 is a user who uses the service portal system 30 or a terminal thereof. As shown in FIG. 1, the systems are connected to be communicable. Each system (10, 20, 30, 40, etc.) may be integrated, or may be appropriately divided.

  Target system 1: The target system 1 includes components such as network devices (switches, etc.), servers, storages, databases, middleware, applications, and the like, and realizes predetermined services (service processing). Each component holds or outputs log information or a failure message, for example.

  Incident management system 10: The incident management system 10 includes a server system and the like, and manages (registers / searches etc.) incident information including failure information in an incident management database (DB) 51 as a basic function. Incident information includes information such as failure information, operation information (initial diagnosis execution result information), analysis results (priority, etc.) (described later, such as FIG. 11). The incident information may include (or be associated with) countermeasure information, person-in-charge information, and the like. An incident screen G2 is configured based on the incident information (b2) in the DB 51.

  In addition, in the incident management system 10, the configuration (configuration management model) of the target system 1 managed by the configuration management system 20 is configured by initial diagnosis and analysis processing based on the fault monitoring of the target system 1 by the fault monitoring system 40. -Grasp the status of incidents such as operational status and faults (reflected in fault configuration information b3 and incident information b2).

  The person in charge 3 or the like can register or search for countermeasure information (measurement procedure, explanation, etc.) and related information regarding incidents such as failures in the target system 1 through the incident screen G2.

  FIG. 2 shows a detailed configuration example of each part of the incident management system 10. The incident management system 10 includes a failure information acquisition unit 11, a configuration information acquisition unit 12, an initial diagnosis unit 13, an analysis unit 14 {failure influence range CI extraction unit 15, FTCI situation grasping unit 16, priority calculation unit 17}, information registration It is the structure which has the part 18, etc. Each unit is realized by a software program or the like.

  The analysis unit 14 is a processing unit that systematizes a part of the incident analysis (analysis of the influence of the failure (incident) of the target system 1 including FTCI). The analysis unit 14 includes a function for grasping a failure influence range and the like for a detected failure (incident), a function for calculating priorities for prioritizing a plurality of failures (incidents), and the like. Details of each part will be described in a later-described flow.

  ○ Configuration management system 20: The configuration management system 20 is configured by a server system or the like, and is set by the configuration information acquired / collected from the target system 1, the fault monitoring system 40, etc., or the person in charge 3 as basic functions. Configuration information is managed (registered, searched, etc.) in the configuration management database (DB) 52. The configuration information includes CI information (including FTCI information) and the like. A configuration including the fault tolerance of the target system 1 and the like is modeled as a configuration management model using the configuration information. The configuration information may include (or be associated with) person-in-charge information. The configuration information screen G1 is configured based on the configuration information (b1) in the DB 52.

  The person in charge 3 and the like, through the configuration information screen G1, regarding the configuration of the target system 1 (configuration management model), the dependency between the configuration item (CI) and the CI (link), the relationship with the upper service, etc. It can be set as configuration information (configuration management model information). In particular, the person in charge 3 or the like can use the FTCI setting function 102 to set FTCI information (to be described later, FIG. 5) such as the relationship of the CI redundant configuration in the configuration management model.

  Further, for example, the configuration management system 20 can associate and manage a predetermined person in charge 3 (including an escalation destination) with respect to a configuration part (CI) of the target system 1 and its category. The person-in-charge information includes, for example, information such as a notification destination address, organization affiliation, name, and a constituent part (CI) in charge. Personnel information is associated with configuration information and incident information as necessary.

  The above configuration information is not limited to setting by manual operation by the person in charge 3 or the like, but registration by partially automatic processing is also possible. For example, the configuration management system 20 acquires and collects configuration information from the target system 1 and reflects it in the DB 52 (a2). Further, the configuration information may be obtained in the same manner in cooperation with the failure monitoring system 40 (a3 in FIG. 1). For example, it is possible to automatically collect configuration information by executing a known discovery command between components of the target system 1.

  Service Portal System 30: The service portal system 30 is configured by a server system or the like, has the screen providing unit 31 (for example, by a Web server or the like) in FIG. 2, and information (configuration information b1) of each system (10, 20). , Incident information b2, failure configuration information b3, etc.), various screens (G1, G2, etc.) for the person-in-charge 3 to view are composed of web pages and provided to the terminal of the person-in-charge 3. The information that constitutes the screen is provided from the incident management system 10 (information registration unit 18) side.

  In this embodiment, the screen includes a configuration information screen G1 and an incident screen G2. In particular, on the configuration information screen G1, not only can the conventional configuration information (no FTCI etc.) related to the target system 1 be displayed based on the configuration information b1 and the failure configuration information b3, but each CI including FTCI and Visualize the link configuration (configuration management model) and the failure status mapped on it (failure location, failure impact range, failure impact destination service, etc., and person-in-charge information) (see below, FIGS. 3 and 4) etc). On the incident screen G2, incident information including priority, target solution time, person-in-charge information, etc. is displayed based on the incident information b2 (described later, FIG. 11, FIG. 12, etc.). The failure configuration information b3 is information obtained by mapping a failure status (including failure influence range and the like) and related information based on the analysis result in the analysis unit 14 on the configuration management model (configuration information b1).

  The failure configuration information b3 is not limited to the form provided from the incident management system 10 to the service portal system 30, but may be provided from the configuration management system 20. In that case, the configuration management model including the failure configuration information b3 is managed in the configuration management system 20 (DB 52). In addition to the configuration information screen G1, a screen for failure configuration information b3 may be provided.

  As a way of providing a screen (GUI) for the terminal of the person in charge 3, the screen display content is updated and displayed in accordance with the change in the configuration and status of the target system 1. For example, the configuration and failure status of the target system 1 are always displayed in a predetermined Web page window (screen G1 or the like). Then, the display contents are updated in accordance with changes in configuration and failure status. Alternatively, the screen may be displayed only when necessary according to a user operation. Further, for example, the screen may be automatically displayed by an alert accompanying failure detection (S1). Further, the display may transition between the screen G1 and the screen G2, or the display contents may be integrated. Further, for example, the configuration / situation may be saved as a history (snap) for each time point, and information at a specified time point may be displayed.

  Fault monitoring system 40: The fault monitoring system 40 can be configured by various known technologies. For example, for the target system 1, server / storage monitoring and configuration information collection, network monitoring and configuration information collection, and It has processing functions such as failure log analysis based on monitoring. In addition, the processing function of the failure monitoring system 40 may be provided in another system (10, 20). The failure monitoring system 40 collects logs / failure messages (a1) from the components of the target system 1 and notifies the incident management system 10 of failure information (for example, failure detection / failure location information by failure log analysis). (S1). Further, the failure monitoring system 40 may collect configuration information of the components of the target system 1 and provide the configuration information to the configuration management system 20 (a3).

  ○ Person in charge 3: Person in charge 3 shows a person in charge who uses the service portal system 30 and its terminal. The person in charge 3 includes an escalation destination. The person in charge 3 can access the service portal system 30 from a terminal provided with a Web browser and browse various screens (Web pages and the like) including the configuration information screen G1 and the incident screen G2. The terminal of the person in charge 3 acquires and displays the screen in response to a request to the screen providing unit 31, or automatically acquires display update content data of the screen and updates the display content.

  As the person in charge 3, U is the person in charge of initial diagnosis. A, B, and C are persons in charge of various escalation destinations. A indicates a functional escalation destination, which is a developer / maintenance operator or the like associated with a component of the target system 1. B and C indicate hierarchical escalation destinations, and hierarchical parties such as the supervisor and subordinates of the organization. Various escalation destinations may be managed. For example, the first type (B) of the hierarchical escalation destination is the person in charge on the management (this system) side, the second type (C) is the person in charge on the customer (target system 1) side, and the like. E1 indicates escalation (notification, etc.) from U to A. E2 indicates an escalation (notification or the like) from U to B or C.

[Management operation flow]
The outline of the incident management operation flow in the incident management system 10 and the failure influence range visualization method of the present embodiment is as follows. This management operation flow conforms to ITIL Version 3.

(0) Configuration management model setting including FTCI (Others, acquisition of configuration information (b1), etc.)
(1-1) Fault (incident) detection (Incident identification / recording, etc.)
(1-2) Initial diagnosis (Others, failure log analysis, etc.)
(2-1) Understanding failure status through analysis: Understanding failure impact range, impact destination, FTCI status, etc. (2-2) Incident prioritization through analysis (decision of countermeasure policy): Priority, target solution time, Determination of escalation destination, etc. (3-1) Creation / registration of information reflecting the above analysis results: Mapping failure status on the configuration management model (failure configuration information b3) and corresponding incident information (b2)
(3-2) Screen provision: The screen (configuration information screen G1, incident screen G2) for visualizing the above information (b3, b2) is configured and provided to the person in charge 3 (4-1) Primary response: Person in charge 3 (Early diagnosis staff U, etc.) grasp the configuration, failure status, countermeasures, etc. on the above screen (G1, G2) and execute various escalations (E1, E2) as necessary (4-2) Secondary Response: The person in charge 3 (A, B, C) of the escalation destination grasps the configuration, failure status, countermeasure policy, etc. on the above screen (G1, G2), and implements countermeasures as necessary.

  In the above (4-2), for example, the person in charge of functional escalation (A) checks the failure message on the screen G2, investigates the failure influence range on the screen G1, etc. Implement countermeasures such as program correction. Thereby, in the case of recovery of the failure (problem solving), the incident is closed. Incident information (b2) is registered (updated) at any time, and the incident status is updated at any time.

[Processing flow]
A main processing flow (indicated by steps S0 to S9) when a failure occurs in the target system 1 in the processing flow of the present system based on the management operation flow will be described with reference to FIGS.

  (S0: Configuration Setting) As one of preparation and premise, the configuration (configuration management model) of the target system 1 is set in the configuration management system 20 (DB 52). For example, the person in charge 3 or the like uses the configuration information screen G1 to set each component as a CI, sets a dependency (link) between CIs, and uses the FTCI setting function 102 to set the component ( By setting the fault tolerance of CI) as FTCI, the configuration management model is set as configuration information.

  (S1: Failure Detection) The incident management system 10 (failure information acquisition unit 11) detects a failure of the target system 1 using the failure monitoring system 40. The process after S2 is executed with the failure detection as a trigger. For example, failure information (failure message or the like) is output from the target system 1 to the failure monitoring system 40 (a1 in FIG. 2). Fault information (such as a fault message) is output from the fault monitoring system 40 to the fault information acquisition unit 11. The failure information acquisition unit 11 may register the received (acquired) failure information in the DB 51 as incident information. The failure information acquisition unit 11 may extract the CI of the failure location from the failure message by, for example, failure log analysis.

  (S2: Configuration Information Acquisition) The incident management system 10 (configuration information acquisition unit 12) receives configuration information (configuration management model information) of the target system 1 from the configuration management system 20 (DB52) at a predetermined timing such as daily. To get. Alternatively, the configuration information may be acquired at a timing when the configuration is changed. The acquired configuration information is used in the following processing.

  (S3: Execution of initial diagnosis) Based on S1, the incident management system 10 (initial diagnosis unit 13) sets the target system 1 (for example, the entire or part of the target system 1 to be diagnosed, including the failure detection location of S1). ) To execute an initial diagnosis (initial diagnosis script). The initial diagnosis script is a script program corresponding to each category (server, database, etc.) of the part to be diagnosed.

  (S4: Initial diagnosis result acquisition) The incident management system 10 (initial diagnosis unit 13) acquires the execution result (operation information) of the initial diagnosis script of S3 from the target system 1. As a result, the operating status of the target system 1 is grasped (including the grasp of the failure location (CI)). The result information of S4 may be reflected in the corresponding incident information in the DB 51.

  Next, based on the information up to S4, the analysis unit 14 performs analysis processing on the failure (incident) in the following S5 to S7. As a result, the CI of the fault influence range is grasped in S5, the situation (status) of the FTCI is grasped in S6, and the priority (P) and the target solution time (T) are determined in S7.

  (S5: Failure Influence Range CI Extraction) The failure influence range CI extraction unit 15 extracts the failure influence range CI (including FTCI) related to the failure location using the information in S4 and S2 (described later, FIG. 4 etc.).

  (S6: FTCI situation grasping) The FTCI situation grasping unit 16 determines the FTCI situation (failure allowable situation) as the status using the information of S4, S5, S2, etc. (described later, FIG. 4, FIG. 7, etc.).

  Also, based on the processing of S5 and S6, the analysis unit 14 grasps the status and number (N) of the higher-level service (service CI) that is the failure-affected destination according to the status of the lower-level FTCI.

  (S7: Priority calculation) The priority calculation unit 17 uses the information of S4 to S6, S2, and the like, the status of each CI including the current service level of the target system 1 and the FTCI (for example, the CI status: “Normal” ”,“ Degeneration ”,“ decrease ”,“ stop ”, etc.) are comprehensively considered, and the urgency level (α) and impact level (β) are calculated. Then, using these pieces of information (α, β), the priority (P) of the countermeasure against the failure (incident) is calculated. Furthermore, the target solution time (T) according to the priority (P), the presence / absence of escalation, and the like are determined (described later, such as FIG. 10).

  (S8: Information registration) The incident management system 10 (information registration unit 18) obtains various types of information (failure location, fault impact range, CI and link status, number of fault impact destination services (N) obtained through the processing up to S7. The failure configuration information b3 and the incident information b2 are created or updated using the priority (P), the target solution time (T), etc., and registered in the DB 51, DB 52, and the like. The analysis results (failure status, etc.) of S5 to S7 are mapped onto the configuration management model (configuration information b1) of S2 and become failure configuration information b3.

  The service portal system 30 side requests and acquires the above information (b3, b2) from the incident management system 10 (information registration unit 18) or the like as necessary. Alternatively, in the case of creating the failure configuration information b3 on the service portal system 30 side, the information registration unit 18 may transmit and register the above information (b3, b2) to the service portal system 30. . As a result, the screens (G1, G2) can be configured and provided.

  (S9: Screen Provision) The service portal system 30 (screen provision unit 31) uses the above-described failure configuration information b3 to construct a configuration information screen G1 for visualizing the configuration / failure status and the like to the person in charge 3 provide. Further, by using the incident information b2, an incident screen G2 is constructed and provided to the person in charge 3. The person in charge 3 such as the initial diagnosis person in charge U can grasp the configuration, the failure status (including the failure influence range), related information (including the person in charge information, etc.) of the target system 1 by referring to the configuration information screen G1. Detailed incident information can be grasped by referring to the incident screen G2.

[Processing example (a)]
Detailed processing examples relating to the initial diagnosis (S3, S4) to FTCI status grasping (S6) are as follows. This is a processing example in which the status of each CI and link is updated according to the status of the target system 1, and data information (described later) shown in FIGS.

  (1) Initial diagnosis script execution: In S3, the initial diagnosis unit 13 executes a script associated with each CI category for each component (CI) to be diagnosed based on failure detection (S1). The initial diagnosis script parameter of FIG. 6 is executed as an argument. In S4, the execution result (operation information) of S3 is stored in the configuration information of FIG.

  (2) Registration of CI status: The failure influence range CI extraction unit 15 applies to each CI (here, CI excluding FTCI) related to the failure location, based on the result information of the above (1), FIG. The status determined according to the status determination method of FIG. 7 is registered as the status of the CI.

  (3) Dependency Status Registration: The failure influence range CI extraction unit 15 has a larger CI layer number (FIG. 6) for the dependency relationship (link) between the CIs related to the failure location ( That is, the status of the lower CI is registered as the status of the dependency (link) (“dependency status”) (FIGS. 8 and 9).

  (4) FTCI status registration: The FTCI status grasping unit 16 sets the status determined according to the status determination method of FIGS. 6 and 7 to the status of the FTCI for each FTCI related to the fault location / failure influence range. sign up.

[Processing example (b)]
Detailed processing examples from the information registration (S8) to the screen provision (S9) are as follows. Data information (described later) shown in FIGS. The incident management system 10 (information registration unit 18 or the like) can provide the screens (G1, G2, etc.) to the DB 51, DB 52, etc. at any time (for example, timing according to changes in configuration / situation), and update the contents. Processing to create, register, and provide information (b1 to b3, etc.) is performed. Hereinafter, for example, processing by the information registration unit 18 is performed.

  (1) The display state of the CI icon (including the FTCI icon) on the screen G1 (failure configuration information b3) is changed according to the change in the status of the CI (FTCI) (FIG. 6). For example, in response to the status of the corresponding CI changing from “normal” to “abnormal” / “stop”, a process of changing the display color of the corresponding CI icon from blue to red is performed.

  (2) The display state of the dependency relationship (link) between CIs on the screen G1 (failure configuration information b3) is changed in accordance with the change in the dependency relationship (link) status (FIG. 8). The change in (2) is performed in conjunction with the change in (1) above. For example, a process of determining / changing the status of the corresponding dependency relationship according to the status of the lower CI is performed.

  (3) Create or update failure configuration information b3 for screen G1, incident information b2 for screen G2, etc. using information on the changes in (1) and (2) above, and for DB 51, DB 52, etc. sign up. Thereby, the service portal system 30 (screen providing unit 31) can provide the screen G1 and the like as in the examples of FIGS. 3 and 4 using the above information.

  In addition to the above information, various types of information displayed on the screen (for example, information for displaying the icon of the person in charge in FIG. 3, information for displaying the CI status, fault location, fault impact) Create, register, and provide information for display such as scope and failure-affected service.

[Screen (1)]
3 and 4 show examples of display screens, and a configuration example of the target system 1 is also shown. FIG. 3 shows a first example (when the target system 1 is normal) of a screen (configuration information screen G1) for visualizing the failure configuration information b3. This screen displays a structure in which a plurality of CIs (CI icons) are connected by links (lines) indicating dependency relationships based on the failure configuration information b3 and the like.

  An upper CI ("Service", "Cluster", etc.) with a lower layer number is shown in the upper part of the screen, and a lower CI ("Physical Server", "L2Switch", etc.) with a higher layer number is shown in the lower part of the screen. . A logical unit / virtual unit (service, virtual server, application, etc.) has a higher layer, and a physical unit (server device, network device, etc.) has a lower layer. In FIG. 3, for example, “Terminal” (terminal), “L3Switch”, “L2Switch”, “Physical Server” (physical server), “Hypervisor” (server virtualization software), “DB Server” (virtualization) Server), “DataBase”, “Cluster” (failure tolerance), etc. A cloud icon indicates a higher-level service (service CI) provided by the target system 1.

  Each CI and link is displayed with different expressions such as color, icon, character information, size, etc., according to the name, category, status, etc. For example, in FIG. 3, CIs and links whose status is “normal” are displayed in solid lines or blue.

  The FTCI is displayed with a specific icon (an octagonal icon in the example of FIG. 3) so that it can be distinguished from a normal CI (non-FTCI). 401-414 etc. show FTCI. Otherwise, normal CI (non-FTCI) is indicated. The fault tolerance information associated with FTCI will be described later (FIG. 5).

  The method of displaying each CI and link can be input and set in the system.

  In addition, for each CI icon, related information associated with the CI is appropriately displayed. For example, when the person in charge 3 performs a mouse operation (such as mouse over or clicking on a CI icon), the relevant information of the CI is displayed in a pop-up form. For example, incident information associated with the CI is displayed or linked to the incident screen G2. Also, for example, fault tolerance information associated with the FTCI is displayed.

  Further, for example, information on the person in charge 3 associated with the CI is displayed. In the example of FIG. 3, the person-in-charge icon is displayed on the upper right (A: for example, orange) or upper left (B, C: for example, green) of the CI icon, and information on the person in charge 3 is displayed by operating the person-in-charge icon. To do. For each FTCI icon or service CI icon, the icon of the person in charge 3 of the existing type is displayed.

[Screen (2)]
FIG. 4 shows a second example (when a failure occurs in the target system 1) of a screen (configuration information screen G1) for visualizing the failure configuration information b3 on the same premise as FIG. The content reflects the failure status (failure impact range, etc.) on the configuration management model of FIG. CI names are omitted. In the example of FIG. 4, each link line is displayed with a line type corresponding to the status (“normal” is a solid line, “degenerate” is a broken line, “decline” is a one-dot chain line, and “stop” is a dotted line).

  The fault location, fault impact range, fault impact destination service, and the like are displayed using specific icons or boxes. For example, the expression is made more conspicuous as the degree of failure is serious (corresponding to a large status value).

  Reference numerals 501 to 505 and the like indicate failure locations (CI, links) based on the S1 and the like. In addition, for the failure influence range CI (S5), for example, each corresponding CI is displayed in a box. The type and color of the enclosure will depend on the status. In the example of FIG. 4, the CIs in the failure influence range whose status is “stopped” are displayed so as to be highlighted with a solid line box. Similarly, ranges of “decrease” and “degeneration” may be displayed respectively. For example, when the status of the CI and the link is “normal”, it is displayed in blue, “degenerate” is purple, “decreased” is yellow, “stop” is red, and the like. Information such as the status of each CI may be displayed in a pop-up or the like.

  500 is an example (only a part) of the failure influence range, and shows the range from the failure location (physical server) 501 to the FTCIs 401 and 402 due to the failure influence to the upper level. Thus, a range including a plurality of CIs and links may be displayed. In addition, the services higher in the FTCI (two in this example, 601 and 602) are also affected by the failure. In the example of FIG. 4, each service (601, 602) whose status is “stopped” is displayed in a box as a failure affected service. Also, service status information such as the number of failure-affected services (N) may be displayed in a pop-up or the like.

  In the example of FIG. 4, the status of the FTCI 401, 402, etc. is “stop (3)”. The FTCI 403 is “degeneration (1)”. FTCI 404 is “Decrease (2)”. The FTCIs 405 to 408 are “normal (0)”. The FTCI 409 is “degenerate (1)”. The FTCIs 411, 412, 413, and 414 are “normal (0)”. The upper two services 601 and 602 have a status of “stop (3)”. The number (N) of fault-affected services (“stop”) is 2.

  The person in charge 3 can grasp the fault influence range and the like in an easy-to-understand manner by looking at the difference in color, surroundings, specific icons, and display information on the screen G1. Since various types of information can be referred to in a form associated with the component part (CI), the situation grasp by the person in charge 3 can be facilitated and speeded up. For example, when a person in charge of initial diagnosis U touches a CI icon corresponding to a failure influence range or the person in charge thereof, the person in charge of corresponding incident information or various escalation destinations (A, B, C) exists. The information of the person 3 can be viewed, and the corresponding escalation operation (notification) can be linked.

[Screen (3)]
FIG. 13 shows an example of a screen for visualizing a target system configuration in a general prior art example. In the prior art example, since the dependency relationship (link) between the CIs is not displayed, the influence destination of the failure part cannot be grasped. In addition, since there is no FTCI in the prior art example, it is impossible to grasp the degree of influence on the upper layer when a redundant configuration location becomes a failure. On the other hand, in the present embodiment, since there are dependency relationships (links) between CIs and FTCIs, it is possible to grasp the influence destination of a failure location and the degree of influence on higher layers such as services. Note that even prior art examples such as Patent Documents 1 and 2 do not have a function of displaying FTCI or the like.

[FTCI information]
FIG. 5 shows an example of fault tolerance information of each FTCI corresponding to the configuration of FIG. In FTCI, design information related to fault tolerance (“failure tolerance information”) is input and set as attribute information. The fault tolerance information is design information that differs depending on the configuration of the target system 1, and can be set by the person in charge 3 or the like (FTCI setting function 102). Further, the relationship with related CIs (upper and lower) is also set in the form of dependency (link). If there is a person in charge 3 (A, B, C, etc.) related to FTCI, the person in charge information is associated.

  In the FTCI (icon display name: “Cluster”) such as 401 and 402 shown in FIG. 5A, a duplex configuration (clustering configuration) for load distribution and the like regarding DB access (access from the service to the DB) is used. is there. In this duplex configuration, if only one system is in a failed state (single system failure), "Degenerate" (service allowed), if both systems are in a failed state (both system failures), "stopped" (service stopped), Such information is set.

  FTCI (“Cluster”) such as 403 and 404 shown in FIG. 5B is a triple configuration (clustering configuration) for load distribution with respect to Middleware (MW) access (access from Service to Middleware). is there. In this triple configuration, information such as “degenerate” (service allowance) for a single failure, “decrease” (service degradation) for a double failure, and “stop” (service stop) for a triple failure is set. Is done.

  In FTCI ("Cluster") such as 405 to 409 shown in FIG. 5C, the L2Switch-Physical Server (PS) has a duplex configuration. In this duplex configuration, information such as “degenerate” in the case of a one-system failure and “depends on higher-level FTCI” in the case of both-system failure (such status is determined according to the status of the higher-level FTCI) is set. Is done.

  In FTCI (“Cluster”) such as 411 and 412 shown in FIG. 5D, the L2Switch-Storage configuration is a duplex configuration. In this duplex configuration, information such as “degenerate” in the case of a single system failure and “stop” (service stop (all)) in the case of both system failures is set.

  In FTCI (“Cluster”) 413 shown in FIG. 5E, the L2Switch has a duplex configuration. In this duplex configuration, information such as “degenerate” in the case of a single system failure and “stop” (service stop (all)) in the case of both system failures is set.

  In FTCI (“Cluster”) 414 shown in FIG. 5F, L3Switch has a duplex configuration. In this duplex configuration, information such as “degenerate” in the case of a single system failure and “stop” (service stop (all)) in the case of both system failures is set.

[CI information]
FIG. 6 shows a data structure example (table) of configuration information (CI information). Items include CI_ID, category name, layer number, initial diagnostic script parameter, functional escalation (A), hierarchical escalation # 1 (B), hierarchical escalation # 2 (C), status determination method, status, initial diagnostic script Execution results, etc.

  CI_ID is an identifier of the CI. The category name indicates the category (type) of the CI, and has “failure tolerance” (FTCI) in addition to the DB server, DB, middleware, service, and the like. The FTCI may be managed by providing a FTCI type or the like (for example, each FTCI as shown in FIG. 5).

  The layer number indicates the layer to which the CI belongs, and is information regarding the relationship between the CIs such as upper and lower levels. The smaller the numerical value of the layer is, the higher the lower one. A configuration management model is created and displayed according to the layer. The CI status and the like are determined in consideration of the layers. In this example, layer 1: service, layer 1.5: FTCI, layer 2: DB, middleware, etc., layer 3: DB server, Web server, etc. are defined.

  The initial diagnosis script parameter indicates parameter information used as an argument in the initial diagnosis process (S3). For example, information such as IP and user password. The initial diagnosis script execution result indicates information on the result (S4) of the initial diagnosis process. These are also stored in incident information.

  Functional escalation (A) indicates information of the person 3 in charge of functional escalation associated with the CI (component). A1 to A3 indicate individual persons in charge. Hierarchical escalation (B) indicates information of a person in charge (for example, a supervisor) on the management (this system) side as the first type of hierarchical escalation destination. B1 to B3 indicate individual persons in charge. Hierarchical escalation (C) indicates information of a person in charge (for example, a supervisor) on the customer (target system 1) side as a second type of hierarchical escalation destination. C1 indicates an individual person in charge.

  The status determination method indicates a method for determining a status value as the next item (see FIG. 7 in detail). For example, in a CI whose category is DB server, DB, middleware or the like, the method (a) is applied, and in the FTCI (401) whose ID is “0126”, the method (b) is applied and the ID is “0130”. Different settings can be made for each CI and category, such as applying the method (c) in the FTCI (403) and applying the method (d) in the service CI. The status indicates the status of the CI, and includes, for example, “normal (0)”, “degenerate (1)”, “degraded (2)”, “stop (3)”, “abnormal (1)”, and the like. In particular, in the case of FTCI, the status indicates a fault tolerance situation. The value in the parenthesis of status indicates a number for identifying the status for each category or method. The status value (status number) is defined so as to increase as the degree of failure or the like increases.

  FIG. 7 shows an example of a status determination method.

  In the method (a), in the initial diagnostic script execution result of the target CI, the status is set to “normal (0)” in the case of normal termination, and the status is set to “abnormal (1)” in the case of abnormal termination. This is an example of a simple binary definition, but it may be defined in multiple values according to the CI or method.

  In the method (b), in the normal operation rate (r) of the lower CI, “normal (0)” when 100%, “degenerate (1)” when 50% or more and less than 100%, 0 In the case of%, “stop (3)” is assumed. r can be calculated from the status value of each CI.

  In the method of (c), in the normal operation rate (r) of the lower CI, “normal (0)” when 100%, “degenerate (1)” when 65% or more and less than 100%, 1% or more If it is less than 65%, “decrease (2)”, and if it is 0%, “stop (3)”.

  In the method (d), the status with the highest status number of the lower CI (the one with the highest failure degree or the like) is inherited. For example, in the case of the service CI (601) on the left side of FIG. 4, one lower CI (401) is “stop (3)”, and the other lower CI (403) is “degenerate (1)”. “Stop (3)” is inherited and set to the status of the service CI.

[Dependency]
FIG. 8 shows a data structure example (table) of dependency relationships (links) between CIs. The values in FIG. 8 correspond to the example (part) of the configuration management model in FIG. In FIG. 9, the numerical values next to the CI and the link (line) indicate the ID. A line between each CI indicates a dependency (link). Dependency relationships (links) are also included in a type of CI (referred to as dependency relationship CI).

  In FIG. 8, items include dependency (link) _ID, first CI (lower CI) _ID, second CI (upper CI) _ID, and dependency status (= lower CI status).

  In the example of FIG. 9, there are two FTCIs, “Cluster” (0126) and “Cluster” (0130), below a certain service (0131). FTCI “Cluster” (0126) has a duplex configuration, and there are two DBs (0124, 0125) at the lower level. A DB server (0123) is subordinate to the DB (0124). The FTCI “Cluster” (0130) has a triple configuration, and there are three middlewares (0127, 0128, 0129) at the lower level. Each CI / link is shown in an expression corresponding to the status. A balloon indicates the status. In particular, a CI whose status is “abnormal” is indicated by a dotted line.

  As shown in FIG. 9, for example, the dependency (link) of the ID “1233” is the first CI (subordinate CI) that is the DB server of ID “0123” and the second DB that is the DB of ID “0124”. The dependency relationship (link) with the CI (upper CI) is shown, and the dependency relationship (link) status is “abnormal” (for example, red) as the status of the lower CI.

  As an example of the status, in the “Cluster” (0126), one side DB server (0123) and its DB (0124) are “abnormal” (eg, red), and the other side DB (0125) is “normal” ( Example: Blue). Since “Cluster” (0126) is a one-system failure, it is “degenerate” (example: purple). In the “Cluster” (0130), the first middleware (0127) is “normal” (example: blue), and the second and third middleware (0128, 0129) are “abnormal” (example: red). is there. “Cluster” (0130) is “decreased” (eg, yellow) because it is a double failure. The service (0131) is “decreased” (eg, yellow) due to the inheritance of the status of “Cluster” (0130).

[Calculation of priority, etc.]
FIG. 10 shows a calculation method of the priority (P) and the like in the priority calculation unit 17 (S7). FIG. 10A shows a method (one example) of calculating the degree of urgency (α). The urgency level (α) is determined in accordance with the FTCI status and the fault tolerance information in the fault influence range (S5). As a condition, α = 1 is set when there is “normal (0)” or “degenerate (1)” in the status of FTCI. If there is no “stop (3)” and “decrease (2)”, α = 2. If there is “stop (3)”, α = 3.

  FIG. 10B shows a method for calculating the impact level (β) (an example). It depends on the status determination method (FIG. 7). Using the status of FTCI, fault tolerance information, and the like, the impact level (β) is calculated according to the situation such as the number of FTCI of each status and the number of fault-affected services. For example, in the case of the method of (c) in FIG. 7 (status values are four values of normal (0), degeneration (1), decrease (2), and stop (3)), as a condition (expression), in the FTCI status, [Degenerate (1) FTCI number (n1)] × Coefficient a1 (Example: 1) + [Decrease (2) FTCI number (n2)] × Coefficient a2 (Example: 5) + [Stop (3) FTCI number (N3)] × coefficient a3 (example: 10). The numerical value according to this formula is the impact level (β). The value of each weighting coefficient (a1 to a3) is an example.

  Similarly, for example, in the case of the method (b) (status values are three values of normal (0), degeneration (1), and stop (3)), the above equation is expressed by β = [number of FTCIs of degeneration (1) (n1) ] × coefficient a1 + [number of FTCIs for stop (3) (n3)] × coefficient a3.

  FIG. 10C shows a calculation method (one example) such as the priority (P). The values of α and β are used. As a condition, when α × β ≦ 9, priority (P) = “low”. When 10 ≦ α × β ≦ 29, the priority (P) = “medium”. When 30 ≦ α × β, the priority (P) = “high”.

  In addition, corresponding to the priority (P), a target solution time (T) in the countermeasure for the failure (incident) is obtained. In this example, the correspondence is 12 hours when P = “low”, 6 hours when P = “medium”, and 2 hours when P = “high”.

  Also, the presence or absence of the above-described various escalations (A to C) is obtained in correspondence with the priority (P). For example, when P = “low”, there is no hierarchical escalation # 1 (B) and hierarchical escalation # 2 (C). In the case of P = “medium”, # 1 (B) (contact to the management side, etc.) is set to “present”. Further, when P = “high”, # 2 (C) (contact to the customer side, etc.) is also set.

  In addition, the number (N) of failure affected services is calculated based on the failure affected range CI extracted in S5 and the FTCI status determined in S6. For example, the status of the service CI is determined according to the status of the FTCI subordinate to the service CI. Then, the number (N) of failure-affected services is counted for each service CI status (“degenerate”, “decreased”, “stopped”, etc.).

  The information registration unit 18 or the like registers the incident information b2 described including the information obtained above in the DB 51 or the like.

Incident information
FIG. 11 shows a data structure example (table) of the incident information (b2). FIG. 12 shows an example (format) of the incident screen G2 corresponding to FIG. In incident information, items include incident ID, urgency level (α), impact level (β), number of failure-affected services (N), priority (P), target solution time (T), hierarchical escalation # 1 (B ), # 2 (C), and the like. Each item stores information obtained by the processing described above. The same items as the incident ID and other conventional incident information (status, title, category, component (CI), date, description information, etc.) are also stored and managed. For the number of failure-affected services (N), a value for each status is stored. In the incident screen G2 of FIG. 12, information is displayed based on the incident information of FIG. The person in charge 3 can refer to incident information or input a value on the screen G2. In addition, for example, information on the person in charge 3 associated with the CI (such as information on the person in charge 3 of the functional escalation (A) or countermeasure information by the person in charge 3 (A)) may be managed and displayed.

[Concrete example]
A specific example along the flow (S0 to S9) described above is shown below.

  (S0) A configuration management model as shown in FIG. 3 is set.

  (S1) Assume that the failure location CI is, for example, 501 (physical server) in FIG. 4 by failure detection (failure information). The same concept applies when there is another fault location (502 etc.).

  (S2) Acquire related CI information (all or a part) including the failure location (501). Information on CIs and links connected at least in the upper and lower levels is acquired.

  (S3), (S4) An initial diagnosis execution result is obtained for the object including the failure location (501).

  (S5) From the above result, the CI in the fault influence range including the fault location (501) is extracted. For example, the CI in the failure influence range 500 of FIG. 4 is extracted. The influence of the failure propagates from the lower CI such as the failure location to the higher CI connected by the dependency (link). As an example of processing, the status of the upper CI is determined according to the above calculation using the status values of all the lower CIs connected by the link. The failure influence range 500 is a case including up to upper FTCI (eg, 401, 402).

  (S6) For the FTCI (eg, 401, 402) related to the failure influence range, the failure allowable status is grasped. For example, for 401, the status is determined using the method (b) of FIGS. First, considering only the influence of a failure at one failure location (501) below 401, the status of 401 is "degenerate (1)" because it is a one-system failure. Further, when the influence of the failure of the other failure portion (502) below 401 is added, the status of 401 is “stop (3)” because of the failure of both systems. Similarly, the FTCI 402 is “stop (3)”.

  Further, the higher-level services (601, 602) in the failure-affected range 500 also have the status ("stopped") as the failure-affected destination (failure-affected service) based on the status of the lower-level FTCI (401, 402). ) And its number (N = 2).

  (S7) The priority (P) is obtained for the incident related to the failure influence range 500 including the failure location (501) and the FTCI (401, 402) based on the failure location (501). First, the urgency level (α) is α = 3 when the statuses of 401 and 402 are both “stop (3)”.

  Next, the impact level (β) in the incident related to the failure influence range 500 is, for example, β = 2 × 1 + 1 × 5 + 2 × 10 = 27 from a predetermined condition (formula) according to the method (b).

  Next, since the priority (P) in the incident relating to the failure influence range 500 is α × β = 3 × 27 = 81, 30 ≦ α × β, P = “high”. In addition, T = 2 hours, hierarchical escalation # 1 (B): Yes, hierarchical escalation # 2 (C): Yes.

  (S8) The results up to S7 are reflected / registered in the incident information b2, and the failure configuration information b3 (information mapping the situation including the failure influence range 500 on the configuration management model in FIG. 3) is stored. Configure and register in DB51 etc.

  (S9) As described above, the service portal system 30 provides the person in charge 3 with the screen G1 having the contents as shown in FIG.

[Effects]
As described above, according to the present embodiment, the situation and configuration of the failure impact range, etc., and the priority of incidents and countermeasures are related to the incident management system 10 and the like in the target system 1 configured in consideration of the cloud environment and fault tolerance. By visualizing information such as the degree on the screen (G1, G2), the person in charge 3 can immediately grasp the above situation in an easy-to-understand manner, and can realize quick escalation (information transmission) and implementation of countermeasures.

  When the person in charge 3 detects the failure (S1), the person in charge 3 sees the screen (G1) in FIG. By viewing incident information (G2) together, it is possible to facilitate and speed up the response such as primary isolation and escalation based on information such as the scope of impact and priority (P). .

  In the present embodiment, in particular, due to the mechanism provided with FTCI, in addition to the CI in the fault influence range of the virtual server, etc. in consideration of the continuity of the service provided by the target system 1 (service level, etc.) The status of the service (such as the service CI higher in FTCI) affected by the failure can be grasped by visualizing the status of each service and the number (N) of the failure affected services.

[Other embodiments]
(1) Although the fault tolerance of the component part of the target system 1 is modeled as CI (FTCI), in addition to the fault tolerance, other non-functional items (design information) such as the performance of the component part (performance index) May be modeled as CI.

  (2) In the initial diagnosis (S3, S4) based on the failure information (S1), the diagnosis is executed on all CIs of the target system 1, and the failure location CI is found and specified from the result. The diagnosis may be performed on some specific CIs. For example, a part of specific CIs for which a fault or the like is estimated is specified (narrowed down) from the fault information (S1), and the specific CI is set as a diagnosis target.

  (3) Based on the failure information (S1), etc., the existing incident information (history) in the DB 51 is automatically searched, the failure pattern analysis is performed, and the countermeasure procedure related to or included in the incident information, etc. May be obtained and presented on the screen (G1, G2).

  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 integrated operation management system, an incident management system, a configuration management system, a service portal system, a failure monitoring system, and the like.

  DESCRIPTION OF SYMBOLS 1 ... Target system (operation system), 3 ... Person in charge, 10 ... Incident management system, 11 ... Fault information acquisition part, 12 ... Configuration information acquisition part, 13 ... Initial diagnosis part, 15 ... Fault influence range CI extraction part, 16 FTCI situation grasping unit 17 Priority calculating unit 18 Information registering unit 20 Configuration management system 30 Service portal system 31 Screen providing unit 40 Fault monitoring system 51 Incident management database (DB) ), 52 ... Configuration management database (DB), 101 ... Failure influence range visualization function, 102 ... FTCI setting function.

Claims (8)

An incident management system that manages an incident including a failure of a target system as incident information in a first database,
In cooperation with a configuration management system that manages the configuration of the target system as configuration information in a second database,
In cooperation with the service portal system that provides information screens to the terminal of the person in charge,
In cooperation with a fault monitoring system that monitors incidents including faults in the target system,
This incident management system
A first function for creating a screen for visualizing an incident situation including a configuration of the target system, a failure influence range, and a failure influence destination service using the configuration information and the incident information, and providing the screen to the terminal of the person in charge; ,
A second function for setting a configuration including a configuration part designed in consideration of fault tolerance in the target system based on an operation of the person in charge as the configuration management model in the configuration information;
In the configuration management model, each configuration part including a configuration part designed in consideration of the fault tolerance is set as a first configuration item, and fault tolerance for the first configuration item is set as a second configuration item. Set as an item, set the dependency between configuration items including the first and second configuration items as a link,
The screen by the first function displays a configuration management model of the target system, a configuration item in a fault impact range including a fault location, and an incident status including a fault target service in a structure in which the configuration items are connected by a link. Incident management system characterized by that. The incident management system according to claim 1,
(S1) a processing unit that detects a failure in the target system and acquires failure information;
(S2) a processing unit for acquiring configuration information of the target system;
(S3) a processing unit that performs an initial diagnosis on a constituent part including a faulty part of the target system;
(S4) a processing unit for acquiring information of an execution result of the initial diagnosis;
(S5) Using the information of (S4) above, a processing unit that extracts the first configuration item and the second configuration item included in the failure influence range due to the failure,
(S6) Using the information of (S4) above, a processing unit that grasps the status of the second configuration item included in the fault influence range due to the fault according to the fault tolerance design information,
(S7) Using the information of (S6) above, a processing unit that calculates the priority regarding the countermeasure against the failure, the target solution time, and further the presence or absence of escalation,
(S8) A processing unit that reflects the results up to (S7) in the incident information and configuration information, and creates information in which the failure status including the failure affected range and the failure affected service is mapped on the configuration management model,
(S9) An incident management system comprising: a processing unit that provides a screen for visualizing a failure status in the target system to the person in charge using the information created in (S8). In the incident management system according to claim 2,
In connection with the processing of (S5) and (S6), the status determination method is set as the fault tolerance design information for the second configuration item,
The status has a plurality of status values including normal, degeneracy, decline, and stop according to the degree of fault tolerance,
The link between the configuration items connects the upper configuration item and the lower configuration item,
The status of the link is determined according to the status of the subordinate configuration item,
Each of the configuration items belongs to a layer, and the status of the configuration item above the layer is determined according to the status of the configuration item below the layer,
An incident management system characterized in that statuses of upper configuration items are determined by calculation using status values of all lower configuration items connected by the link. The incident management system according to claim 1,
An incident management system characterized in that, on the screen, each icon indicating the configuration item and each line indicating the link are displayed in a color corresponding to a status. The incident management system according to claim 1,
The incident management system characterized in that, on the screen, information of a person in charge associated with the configuration item is displayed for each icon indicating the configuration item. The incident management system according to claim 1,
The screen includes a first screen that displays the configuration information, and a second screen that displays the incident information.
An incident management system, characterized in that an incident status including a configuration management model and a failure influence range of the target system is displayed on the first screen. The incident management system according to claim 1,
An analysis unit including a processing unit for calculating a priority regarding countermeasures against the failure, a target solution time, and further, the presence or absence of escalation;
In the processing of the analysis unit,
Using the status of the second configuration item, calculate the urgency (α) of countermeasures for the incident,
Using the status of the second configuration item, the impact level (β) of the countermeasure for the incident is calculated,
The priority is calculated using the urgency level (α) and the impact level (β),
In association with the priority, a target solution time is determined,
Corresponding to the priority, determine the presence or absence of escalation,
An incident management system, comprising: calculating information including a status and number of a higher-level service that is a failure affected destination according to the failure affected range. A method for visualizing a fault influence range in an incident management system for managing an incident including a fault in a target system as incident information in a first database,
The incident management system includes a configuration management system that manages the configuration of the target system as configuration information in a second database, a service portal system that provides an information screen to a terminal of a person in charge, and a failure of the target system In conjunction with a fault monitoring system that monitors incidents, including
The incident management system has a function of setting a configuration including a configuration part designed in consideration of fault tolerance in the target system based on an operation of the person in charge as the configuration management model in the configuration information, and the target A screen for visualizing an incident situation including a system configuration, a failure influence range and a failure influence destination service is created using the configuration information and the incident information, and has a function to provide the terminal of the person in charge.
In the configuration management model, each configuration part including a configuration part designed in consideration of the fault tolerance is set as a first configuration item, and fault tolerance for the first configuration item is set as a second configuration item. Set as an item, set the dependency between configuration items including the first and second configuration items as a link,
In the screen, in the structure in which the configuration items are connected by a link, the configuration management model of the target system, the configuration item of the fault impact range including the fault location and the incident status including the fault impact destination service are displayed,
The incident management system includes:
(S1) processing for detecting a failure in the target system and acquiring failure information;
(S2) processing for acquiring configuration information of the target system;
(S3) a process for executing an initial diagnosis on a constituent part including a faulty part of the target system;
(S4) a process for acquiring information on the execution result of the initial diagnosis;
(S5) Using the information of (S4) above, a process of extracting the first configuration item and the second configuration item that are included in the fault influence range due to the fault,
(S6) Using the information of (S4) above, a process of grasping the status of the second configuration item included in the fault influence range due to the fault according to the fault tolerance design information;
(S7) Using the information of (S6) above, a process for calculating the priority regarding the countermeasure against the failure, the target solution time, and further the presence / absence of escalation,
(S8) processing for reflecting the results up to (S7) above in the incident information and configuration information, and creating information in which the failure status including the failure impact range and the fault affected service is mapped on the configuration management model;
(S9) Using the information created in (S8) above, the service portal system performs a process of providing a screen for visualizing the failure status in the target system to the person in charge. How to visualize the range of failure impact.