Incident response support methods and incident response support systems

The incident response support system addresses the challenge of low accuracy and user burden in identifying system failures by using a language model to search and group past cases, providing efficient and accurate solutions for non-expert users.

JP2026097658APending Publication Date: 2026-06-16HITACHI LTD

Patent Information

Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
HITACHI LTD
Filing Date
2024-12-04
Publication Date
2026-06-16

Smart Images

  • Figure 2026097658000001_ABST
    Figure 2026097658000001_ABST
Patent Text Reader

Abstract

Even non-expert users can obtain appropriate solutions to system failures without incurring any burden. [Solution] The incident response support system uses a language model that generates output from natural language input to search for past case information based on the symptoms and system information of the target system as input, and retrieves past cases in which the symptoms and system information match or are similar. The incident response support system then uses the language model to group the retrieved past cases by the troubleshooting actions included in them, and outputs the grouped past cases along with the troubleshooting actions.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to an incident response support method and an incident response support system.

Background Art

[0002] Conventionally, experts in the operation of IT services have utilized their know-how based on their experience to identify the cause of a system failure, implement countermeasures, and restore the system when an IT service system fails. On the other hand, there has been a need to codify such expert knowledge so that even non-expert users can utilize the knowledge to identify the cause and take countermeasures and perform restoration when a system failure occurs.

[0003] Regarding identifying the cause by utilizing knowledge, for example, Patent Document 1 discloses the following prior art. That is, a query for searching a solution to a system failure is classified into the intention of the query based on its text expression, and the solution to a past system failure is mapped to each query based on the intention, thereby codifying the solution. Then, the symptoms of the input system failure are converted into a query, and the solution is searched using the converted query.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] However, with the conventional technology described above, when converting system failure symptoms into queries, if the necessary information for the search is not sufficiently captured, the queries will not be converted into appropriate queries, resulting in low accuracy in finding solutions and ultimately failing to obtain suitable solutions. However, inputting a large amount of information to cover all the necessary information for the search was a significant burden for the user.

[0006] This invention has been made in view of the above-mentioned problems, and aims to provide even non-expert users with an appropriate solution to system failures without requiring any burden. [Means for solving the problem]

[0007] To achieve the above objective, the present invention, in one aspect, is an incident response support method executed by an incident response support system that assists in identifying the cause of an incident occurring in a target system, wherein the incident response support system has access to: isolation action information which stores a combination of a verification procedure executed on the target system to identify the cause of the incident, the cause, and countermeasures against the incident as isolation actions; past case information which stores a combination of symptoms of an incident that occurred in a past system, system information indicating the configuration of the past system, and the isolation action including the verification procedure executed on the past system in which the incident occurred as a past case; and the processor of the incident response support system has the following processes: using a language model that generates output for natural language input, it searches for the past case information based on the symptoms and system information of the target system as input, obtains past cases in which the symptoms and system information match or are similar, uses the language model to group the past cases by the isolation actions included in the obtained past cases, and outputs the grouped past cases together with the isolation actions. [Effects of the Invention]

[0008] According to the present invention, even non-expert users can obtain appropriate solutions to system failures without incurring any burden. [Brief explanation of the drawing]

[0009] [Figure 1] A diagram illustrating the outline of the embodiment. [Figure 2] A diagram showing the configuration of the overall system, including the incident response support system according to the embodiment. [Figure 3] A diagram showing the configuration of the incident response support system according to the embodiment. [Figure 4] A diagram showing the configuration of the prompt information table according to the embodiment. [Figure 5] A diagram showing the structure of a search query according to the embodiment. [Figure 6] A diagram showing the configuration of the ticket management server according to the embodiment. [Figure 7] A diagram showing the configuration of the ticket information table according to the embodiment. [Figure 8] A diagram showing the configuration of the work memo table according to the embodiment. [Figure 9] A diagram showing the configuration of the knowledge database server according to the embodiment. [Figure 10] A diagram showing the structure of the FAQ according to the embodiment. [Figure 11] A diagram showing the configuration of the sorting action table according to the embodiment. [Figure 12] A diagram showing the configuration of a user terminal according to the embodiment. [Figure 13] A flowchart illustrating the FAQ creation and update process according to the embodiment. [Figure 14] A flowchart illustrating the FAQ search process according to the embodiment. [Figure 15] A diagram showing the configuration of the incident response support screen according to the embodiment. [Figure 16] A diagram illustrating the outline of the FAQ creation process according to the embodiment. [Figure 17] A diagram illustrating the overview of the FAQ search process according to the embodiment. [Figure 18] A diagram for explaining the outline of the FAQ update process according to an embodiment.

Mode for Carrying Out the Invention

[0010] In the following description, a "processor" may be one or more processor devices. At least one processor device may typically be a microprocessor device such as a CPU (Central Processing Unit), but may also be other types of processor devices such as a GPU (Graphics Processing Unit). At least one processor device may be single-core or multi-core. At least one processor device may be a processor core. At least one processor device may also be a hardware circuit (such as an FPGA (Field-Programmable Gate Array), CPLD (Complex Programmable Logic Device), or ASIC (Application Specific Integrated Circuit)) that performs part or all of the processing, which is a processor device in a broad sense.

[0011] Also, in the following description, when explaining a process with "XXX processing unit" as the subject, the XXX processing unit performs the defined process as appropriate while using a storage device and / or an interface device, etc., by executing a program by a processor. For this reason, the subject of the process may be a processor (or a device such as a controller having that processor). The program may be installed from a program source into a device such as a computer. Here, the program source may be, for example, a program distribution server or a computer-readable (e.g., non-temporary) recording medium. Also, in the following description, two or more programs may be realized as one program, or one program may be realized as two or more programs.

[0012] In the following description, information obtained as output for an input may be described in terms of "xxx table". However, such information may be data of any structure (e.g., structured data or unstructured data), or may be a learning model such as a neural network, a genetic algorithm, or a random forest that generates an output for an input. Therefore, "xxx table" can be referred to as "xxx information". Also, in the following description, the configuration of each table is an example, and one table may be divided into two or more tables, or all or part of two or more tables may be one table.

[0013] (Overview of Embodiment) FIG. 1 is a diagram for explaining the overview of an embodiment. The incident response support system 1 presents to a user, through an exchange such as a chat, a confirmation procedure, a cause, and a countermeasure for an incident that occurred in the execution environment of a target system that executes a service.

[0014] The incident response support system 1 executes an incident response support program 12p. The incident response support program 12p has an agent 12ag and a tool group 12t in addition to a processing functional unit that executes each process related to the incident response support process described later.

[0015] The agent 12ag interprets a chat input from a chat screen 502 displayed on an output device 500 (FIG. 12) connected to a user terminal 5 (FIG. 2) described later. The agent 12ag makes an inquiry to the language model 4 or requests necessary processing from the tool group 12t according to the interpretation of the chat. Also, the agent 12ag outputs, as a chat, an inquiry result returned from the language model 4 or a processing result of processing executed by the tool group 12t to the chat screen 502.

[0016] Language Model 4 is a model such as an LLM (Large Language Model) built by learning from a large amount of text data. For example, it is a generative AI (Artificial Intelligence) that generates and outputs the user's desired output in response to user input. The input and output here can be natural language text, images, audio, music, video, etc.

[0017] The 12t tool suite provides tools such as an API (Application Programming Interface) for accessing external devices like the ticket management server 2, and RAG (Retrieval-Augmented Generation), which provides the functionality to add search results from external information to queries to the language model 4. The 12t tool suite selects the appropriate tool in response to a request from agent 12ag and uses the selected tool to execute the desired process.

[0018] Specifically, the tool suite 12t executes an API to retrieve ticket information from the ticket management server 2 in response to a request from agent 12ag. Then, the tool suite 12t returns the retrieved ticket information to agent 12ag as the result of the execution.

[0019] Furthermore, the toolset 12t queries the RAG system 331r for information related to the query to language model 4 from agent 12ag, and retrieves the search results from the RAG system 331r for the FAQ (Frequently Asked Questions) 331 in the knowledge DB (Data Base) 3. Agent 12ag then queries language model 4, adding the search results from the FAQ table 331 obtained from the RAG system 331r.

[0020] For example, chat 5011 entered into chat screen 502 is a request from the user to retrieve information necessary for FAQ search from a ticket, specifying the ticket ID. Agent 12ag interprets chat 5011 and requests the toolset 12t to refer to the ticket management server 2, retrieve the ticket with the specified ticket ID, and obtain the information necessary for FAQ search. Chat 5012 output to chat screen 502 is the information retrieved by the toolset 12t in response to chat 5011.

[0021] Chat 5013, entered into chat screen 502, is a request for a similar FAQ to the FAQ shown in chat 5012. Agent 12ag interprets chat 5013 and requests the toolset 12t to search the FAQ table 331 of the knowledge DB server 3 via the RAG system 331r and retrieve the similar FAQ. When searching for a similar FAQ, the RAG system 331r adds additional information to the input based on the conversation history 132 (Figure 3) of the input and output of chat screen 502. The input and output history of chat screen 502 is recorded by the incident response support program 12p. This improves the accuracy of the similar FAQ search.

[0022] Chat 5014, displayed on chat screen 502, is a similar FAQ obtained by tool suite 12t in response to chat 5013.

[0023] Chat 5015, entered into chat screen 502, is a user inquiry regarding the "procedure for checking proxy settings" in relation to the information shown in chat 5014. Agent 12ag interprets chat 5015 and queries language model 4 for the "procedure for checking proxy settings," and obtains the query result.

[0024] Chat 5016, displayed on chat screen 502, is the "procedure for checking proxy settings" obtained by querying language model 4 in response to chat 5015.

[0025] Chat 5017, entered into chat screen 502, is the result of the user actually performing the "proxy settings verification procedure" shown in chat 5016 and entering the result (verification result). Agent 12ag interprets chat 5017 and obtains countermeasures corresponding to the verification result. Chat 5018, output to chat screen 502, is the countermeasure obtained in response to chat 5017.

[0026] (System configuration according to the embodiment) Figure 2 shows the configuration of the overall system S, including the incident response support system 1 according to the embodiment.

[0027] The overall system S consists of an incident response support system 1, a ticket management server 2, a knowledge database server 3, a language model 4, a user terminal 5, and a management terminal 6. The incident response support system 1, the ticket management server 2, the knowledge database server 3, and the language model 4 can communicate with other devices via network N.

[0028] The Incident Response Support System 1 is connected to a user terminal 5 and a management terminal 6. User terminal 5 is the terminal of the user receiving incident response support. The user receives incident response support from the Incident Response Support System 1 by inputting and outputting information via the Incident Response Support Screen 500D (Figure 15), which is displayed on the user terminal 5. Management terminal 6 is the terminal of the operations manager responsible for the operation and management of the Incident Response Support System 1.

[0029] (Configuration of the incident response support system 1 according to the embodiment) Figure 3 shows the configuration of the incident response support system 1 according to the embodiment. The incident response support system 1 is composed of a processor 11, memory 12, storage device 13, and communication interface 14.

[0030] Memory 12 stores and executes the incident response support program 12p loaded from the storage device 13, etc., by the processor 11. The incident response support program 12p includes an FAQ creation processing unit 121 and an FAQ search processing unit 122. The processing of the FAQ creation processing unit 121 and the FAQ search processing unit 122 will be described later.

[0031] The storage device 13 is a non-volatile storage unit that stores the prompt information table 131 and the conversation history 132. Details of the prompt information table 131 will be described later. The conversation history 132 is the chat history between the user and agent 12ag via the chat screen 502.

[0032] The communication interface 14 is a communication device that allows the incident response support system 1 to communicate with external devices via the network N.

[0033] (Configuration of the prompt information table 131 according to the embodiment) Figure 4 shows the configuration of the prompt information table 131 according to the embodiment. The prompt information table 131 is information that lists the required items of the prompt 502b used for searching the FAQ table 331 of the knowledge DB server 3. The prompt information table 131 has items for environment 131a, component 131b, operating status 131c, and connection status 131d.

[0034] Environment 131a is defined as "Execution Environment" and represents the execution environment of the service where the incident occurred. Component 131b is defined as "Service Name, Instance Name, IP Address, Application Name" and lists the components of the execution environment of the service where the incident occurred. Operational Status 131c is defined as "Service, Instance, Application" and indicates the operational status of each component of the execution environment of the service where the incident occurred. Connection Status 131d is defined as "Inter-Service, Inter-Instance, Inter-Application" and indicates the connection status between each component of the execution environment of the service where the incident occurred.

[0035] (Configuration of search query 123 according to the embodiment) Figure 5 shows the configuration of a search query 133 according to the embodiment. Search query 133 is a query used to search the FAQ table 331 of the knowledge DB server 3. Search query 133 has the items Environment 133a, Symptom 133b, and Component 133c. Environment 133a has the content "xxx environment" and represents the specific name of the execution environment of the service in which the incident occurred. Symptom 133b has the content "monitoring tool failed to connect with application" and "error message is..." and specifically describes the symptoms when the incident occurred. Component 133c has the content "EC2-01, 192.168.1.1, application" and "error message is..." and specifically lists the components (service, instance, IP address, application) of the execution environment of the service in which the incident occurred.

[0036] (Configuration of ticket management server 2 according to the embodiment) Figure 6 shows the configuration of the ticket management server 2 according to the embodiment. The ticket management server 2 includes a processor 21, memory 22, storage device 23, and communication interface 24.

[0037] Memory 22 stores and executes the ticket management program 22p loaded from the storage device 23 or the like by the processor 21. The ticket management program 22p includes a ticket information acquisition processing unit 221 and a work memo acquisition processing unit 222. The processing of the ticket information acquisition processing unit 221 and the work memo acquisition processing unit 222 will be described later.

[0038] The storage device 23 is a non-volatile storage unit that stores the ticket information table 231 and the work memo table 232. Details of the ticket information table 231 and the work memo table 232 will be described later.

[0039] The communication interface 24 is a communication device that allows the ticket management server 2 to communicate with external devices via the network N.

[0040] (Configuration of the ticket information table 231 according to the embodiment) Figure 7 shows the configuration of the ticket information table 231 according to the embodiment. The ticket information table 231 manages information for incidents that occur in the system on which the target service managed by the ticket management server 2 is executed. The ticket information table 231 manages information extracted from the work memo table 232. The ticket information table 231 has the following items: ticket ID 231a, creation date and time 231b, creator 231c, title 231d, description 231e, and conclusion 231f.

[0041] Ticket ID 231a is the identification information for the ticket. Creation date 231b is the creation date and time of the ticket. Creator 231c indicates the creator of the ticket. Title 231d is the title of the ticket and represents a summary of the incident. Description 231e is the content of the ticket (content according to the items shown in prompt information table 131, etc.). Conclusion 231f indicates the cause of the incident indicated by the ticket, the countermeasures taken, and whether or not it was ultimately resolved.

[0042] When an incident occurs, the ticket ID (231a), creation date (231b), creator (231c), title (231d), and description (231e) are entered. Then, when the incident is resolved, the conclusion (231f) is entered.

[0043] (Configuration of the work memo table 232 according to the embodiment) Figure 8 shows the configuration of the work memo table 232 according to the embodiment. The work memo table 232 is an example of a work record, and it contains the response and response results recorded by the worker when responding to an incident. The work memo table 232 has the following items: ticket ID 232a, work ID 232b, creator 232c, creation date and time 232d, and content 232e.

[0044] Ticket ID 232a is the identification information of the ticket from which the relevant work memo was extracted. Work ID 232b is the identification information of the work in which the relevant work memo was recorded. Creator 232c indicates the creator of the relevant work memo. Creation date and time 232d indicates the creation date and time of the relevant work memo. Content 232e is the actual content of the relevant work memo.

[0045] (Configuration of Knowledge DB Server 3 according to the embodiment) Figure 9 shows the configuration of the knowledge DB server 3 according to the embodiment. The knowledge DB server 3 is composed of a processor 31, memory 32, storage device 33, and communication interface 34.

[0046] Memory 32 stores and executes the knowledge DB program 32p loaded from the storage device 33, etc., by the processor 31. The knowledge DB program 32p includes a troubleshooting action search processing unit 321, a troubleshooting action registration processing unit 322, an FAQ search processing unit 323, an FAQ registration processing unit 324, and an FAQ filtering processing unit 325. The processing of the troubleshooting action search processing unit 321, the troubleshooting action registration processing unit 322, the FAQ search processing unit 323, the FAQ registration processing unit 324, and the FAQ filtering processing unit 325 will be described later.

[0047] The storage device 33 is a non-volatile storage unit that stores the FAQ table 331 and the troubleshooting action table 332. Details of the FAQ table 331 and the troubleshooting action table 332 will be described later.

[0048] The communication interface 34 is a communication device that allows the knowledge DB server 3 to communicate with external devices via the network N.

[0049] (Configuration of FAQ Table 331 according to the embodiment) Figure 10 shows the configuration of the FAQ table 331 according to the embodiment. The FAQ table 331 is information that shows the correspondence between symptoms and troubleshooting actions corresponding to FAQs in the system that performs the target service. The FAQ table 331 has the following items: FAQ name 331a, symptoms 331b, environment 331c, configuration 331d, and troubleshooting action group 331e. The FAQ associated with FAQ name 331a, symptoms 331b, environment 331c, configuration 331d, and troubleshooting action group 331e is an example of past cases. The FAQ table 331 is also an example of past case information.

[0050] FAQ name 331a is the name or identification information of the relevant FAQ. Symptom 331b indicates the symptom corresponding to the relevant FAQ. Environment 331c indicates the environment in which the relevant symptom occurred. Configuration 331d indicates the system components in which the relevant symptom occurred. Troubleshooting action group 331e indicates a group of one or more troubleshooting actions that apply to the relevant FAQ. Troubleshooting actions include checking configuration information, command execution results, checking logs and traces, and checking the GUI (Graphical User Interface).

[0051] (Configuration of the decomposition action table 332 according to the embodiment) Figure 11 shows the configuration of the troubleshooting action table 332 according to the embodiment. The troubleshooting action table 332 is information that indicates troubleshooting action groups, which are shown by the correspondence between the verification procedure, cause, and countermeasure for grouping FAQs in the system that performs the target service. The troubleshooting action table 332 has the items Action name 332a, verification procedure 332b, ease of execution 332c, cause 332d, and countermeasure 332e. The troubleshooting action table 332 is an example of troubleshooting action information.

[0052] Action name 332a is the name and identification information of the relevant troubleshooting action group. Verification procedure 332b indicates how to verify whether the incident under investigation was caused by the cause 332d of the relevant troubleshooting action group. Execution ease 332c is an indicator of how easy it is to execute the relevant verification procedure 332b. Cause 332d indicates the cause of the incident that is grouped into the relevant action group. Countermeasure 332e indicates the countermeasure to be implemented for the incident grouped into the relevant action group to restore the system.

[0053] The troubleshooting action table 332 may, in addition to or instead of ease of execution 332c, include a ranking of the symptoms 331b associated with the FAQ table 331 in descending order of frequency. In step S35 of the FAQ search process described later (Figure 14), the input of the troubleshooting action result with the most associated symptoms 331b is received.

[0054] (Configuration of user terminal 5 according to this embodiment) Figure 12 shows the configuration of a user terminal 5 according to an embodiment. The user terminal 5 includes a processor 51, memory 52, storage device 53, and communication interface 54. An output device 500 such as a display and an input device (not shown) such as a keyboard are connected to the user terminal 5 via a predetermined interface.

[0055] Memory 52 stores and executes the chat program 52p loaded from the storage device 53 or the like by the processor 51. The chat program 52p includes a prompt input processing unit 521 and a response output processing unit 522. The processing of the prompt input processing unit 521 and the response output processing unit 522 will be described later.

[0056] The storage device 53 is a non-volatile storage unit. The communication interface 54 is a communication device that allows the user terminal 5 to communicate with external devices via the network N.

[0057] (FAQ creation and update process as described above) Figure 13 is a flowchart illustrating the FAQ creation and update process according to an embodiment. The FAQ creation and update process is executed by the FAQ creation processing unit 121 of the incident response support system 1, triggered by the input of a prompt 502b by a user operating the user terminal 5.

[0058] First, in step S11, the FAQ creation processing unit 121 of the incident response support system 1 creates an FAQ. In other words, the prompt input processing unit 521 of the chat program 52p sends the prompt 502b requesting FAQ creation, which was entered by the user via the chat screen 502, to the incident response support system 1. Agent 12ag of the incident response support system 1 interprets the prompt 502b received from the chat program 52p and requests the toolset 12t to retrieve the specified ticket. The tool group 12t requests the ticket management program 22p to retrieve the specified ticket. The ticket information retrieval processing unit 221 and the work memo retrieval processing unit 222 of the ticket management program 22p retrieve the ticket stored in the ticket information table 231 in response to the request from the tool group 12t. The ticket information retrieval processing unit 221 and the work memo retrieval processing unit 222 also retrieve the work memo associated with the retrieved ticket from the work memo table 232. The ticket information retrieval processing unit 221 and the work memo retrieval processing unit 222 then send the retrieved ticket and work memo to the tool group 12t. The tool group 12t sends the ticket and work memo table 232 received from the ticket management program 22p to agent 12ag. Agent 12ag uses the language model 4 to create an FAQ from the received ticket and work memo. This FAQ includes items for symptoms, system information, verification procedures, and cause and countermeasures.

[0059] Next, in step S12, the FAQ creation processing unit 121 uses the language model 4 to extract troubleshooting actions (confirmation procedures and combinations of causes and countermeasures) for identifying the cause from the FAQ created in step S11. The troubleshooting actions are extracted using the language model 4, eliminating duplicates due to matching or similarity between the confirmation procedures and causes and countermeasures of the FAQ obtained in step S11.

[0060] Next, in step S13, the FAQ creation processing unit 121 uses the language model 4 to classify the verification procedures and causes and countermeasures of the FAQ created in step S11 into separate actions based on their similarity or match. Next, in step S14, the FAQ creation processing unit 121 uses the language model 4 to parameterize the constants included in the verification procedures classified in step S13 and determine the ease of execution. Ease of execution may be evaluated based on the amount of user effort required for execution; for example, those that can be easily executed using tools, etc., are classified as "easy," and others as "difficult."

[0061] Next, in step S15, the FAQ creation processing unit 121 determines whether a troubleshooting action that matches or is similar to the troubleshooting action extracted in step S12 is registered in the troubleshooting action table 332 of the knowledge DB server 3. In other words, the FAQ creation processing unit 121 requests the troubleshooting action search processing unit 321 of the knowledge DB program 32p to search for troubleshooting actions that match or are similar to the troubleshooting actions extracted in step S12. The troubleshooting action search processing unit 321 searches the troubleshooting action table 332 of the knowledge DB server 3 and retrieves any troubleshooting actions that match or are similar to the troubleshooting action extracted in step S12. The FAQ creation processing unit 121 uses the language model 4 to determine whether the troubleshooting action extracted in step S12 matches or is similar to the troubleshooting action table 332. The FAQ creation processing unit 121 moves to step S16 if a troubleshooting action table 332 that matches or is similar to the troubleshooting action extracted in step S12 is registered (step S15 YES). On the other hand, the FAQ creation processing unit 121 moves to step S17 if a troubleshooting action table 332 that matches or is similar to the troubleshooting action extracted in step S12 is not registered (step S15 NO).

[0062] In step S16, the FAQ creation processing unit 121 obtains the Action names of matching or similar troubleshooting action tables 332 registered in the troubleshooting action table 332 via the troubleshooting action search processing unit 321. Meanwhile, in step S17, the FAQ creation processing unit 121 registers the troubleshooting action obtained in step S12 in the troubleshooting action table 332 of the knowledge DB server 3 via the troubleshooting action registration processing unit 322 and obtains the Action name. Once step S16 or S17 is completed, the process moves to step S18.

[0063] In step S18, the FAQ creation processing unit 121 uses the language model 4 to extract basic system information and symptoms from the tickets extracted in step S12.

[0064] Next, in step S19, the FAQ creation processing unit 121 searches the FAQ table 331 to determine whether there is a similar FAQ (registered) that has basic system information and symptoms similar to or matching the basic system information and symptoms obtained in step S18. In other words, the FAQ creation processing unit 121 requests the FAQ search processing unit 323 of the knowledge database program 32p to search for similar FAQs. The FAQ search processing unit 323 searches the FAQ table 331 of the knowledge DB server 3 and retrieves any similar FAQs that exist. The FAQ creation processing unit 121 uses the language model 4 to determine the consistency between the basic system information and symptoms extracted in step S18 and the basic system information and symptoms in the FAQ table 331. The FAQ creation processing unit 121 proceeds to step S20 if a similar FAQ exists (step S19 YES). On the other hand, the FAQ creation processing unit 121 proceeds to step S21 if a similar FAQ does not exist (step S19 NO).

[0065] In step S20, the FAQ creation processing unit 121 updates the FAQ table 331 by adding the said troubleshooting action to the similar FAQ troubleshooting action group 331e via the FAQ registration processing unit 324 of the knowledge DB program 32p.

[0066] Meanwhile, in step S21, the FAQ creation processing unit 121 creates a new FAQ in the FAQ table 331 via the FAQ registration processing unit 324 of the knowledge DB program 32p. The FAQ creation processing unit 121 then updates the FAQ table 331 by adding the troubleshooting action to the troubleshooting action group 331e.

[0067] The response output processing unit 522 of the chat program 52p receives the processing results from steps S20 and S21 from the FAQ creation processing unit 121, and outputs the received processing results as a response 502c to the end user via the chat screen 502.

[0068] (FAQ search processing according to this embodiment) Figure 14 is a flowchart illustrating the FAQ search process according to an embodiment. The FAQ search process is executed by the FAQ search processing unit 122 of the incident response support system 1 in response to input of a prompt 521p by an end user operating the user terminal 5.

[0069] First, in step S31, the FAQ search processing unit 122 of the incident response support system 1 obtains, for example, acquired symptoms and basic system information as search information necessary for similar FAQ searches, via the ticket information acquisition processing unit 221 and the work memo acquisition processing unit 222. The acquired symptoms and basic system information are obtained from the ticket and work memo of the incident for which the cause and countermeasures are to be identified. The user's specification of the incident is entered into prompt 502b via the prompt input processing unit 521 of the chat program 52p.

[0070] Next, in step S32, the FAQ search processing unit 122 refers to the FAQ table 331 via the FAQ search processing unit 323 and searches for similar FAQs that have symptoms and basic system information similar to or matching the symptoms and basic system information obtained in step S31. The FAQ search processing unit 122 uses the language model 4 to determine whether the symptoms and basic system information obtained in step S31 match or are similar to the symptoms and basic system information in the FAQ table 331.

[0071] Next, in step S33, the FAQ search processing unit 122 uses the language model 4 to extract troubleshooting actions from similar FAQs obtained by the search in step S33. Next, in step S34, the FAQ search processing unit 122 uses the language model 4 to group FAQs obtained by the search in step S32 that match or are similar to the troubleshooting actions obtained in step S33, and the grouping result is set as answer 502c. Grouping can be done by grouping identical commands with different parameters or identical environment variables together, for example. The FAQ search processing unit 122 outputs the grouping result as answer 502c via the answer output processing unit 522 of the chat program 52p. As a result of the grouping, combinations of troubleshooting actions and FAQs are displayed in an order that is easy to execute. The user performs the verification procedure in an order that is easy to execute the troubleshooting actions.

[0072] Next, in step S35, the FAQ search processing unit 122 receives input of the result of the troubleshooting action. That is, the result of the user performing the verification procedure for the troubleshooting action that is easiest to execute among the troubleshooting actions presented to the user in step S34 is input to prompt 502b via the prompt input processing unit 521 of the chat program 52p. Step S35 is executed repeatedly, so that the troubleshooting actions are executed sequentially in the order of ease of execution.

[0073] Next, in step S36, the FAQ search processing unit 122 uses the language model 4 to identify the cause of the incident from the execution results of the troubleshooting action entered in step S35. That is, the FAQ search processing unit 122 uses the language model 4 to determine whether the execution results of the verification procedure included in the troubleshooting action performed by the user correspond to the cause in the troubleshooting action table 332, and if so, it is determined that the cause has been identified.

[0074] Next, in step S37, the FAQ search processing unit 122 determines whether the cause has been identified. If the cause has been identified (step S37 YES), the FAQ search processing unit 122 outputs the cause 332d and countermeasure 332e of the troubleshooting action performed as an answer 502c via the answer output processing unit 522p of the chat program 52p.

[0075] Meanwhile, if the cause cannot be identified (step S37NO), the FAQ search processing unit 122 moves to step S38. In step S38, the FAQ search processing unit 122 filters the FAQs grouped in step S34 by the troubleshooting actions for verification procedures that the user has not yet performed and for which the execution result of step S35 has not been entered. The FAQ search processing unit 122 then outputs the filtered FAQs again via the chat program 52p's answer output processing unit 522p in an order of ease of execution. In other words, if the cause cannot be identified, the FAQs related to troubleshooting actions for which the user has already performed the verification procedure are deleted, and only the FAQs related to troubleshooting actions for which the user has not yet performed the verification procedure are output again. When step S38 is completed, the FAQ search processing unit 122 moves to step S35 and accepts input of the execution result of the troubleshooting action that is easiest to execute.

[0076] (Incident response support screen according to this embodiment) Figure 15 shows the configuration of the incident response support screen 500D according to the embodiment.

[0077] The incident response support screen 500D is displayed on the user terminal 5's display screen. The incident response support screen 500D includes a ticket management screen 501, a chat screen 502, and a search results display screen 503.

[0078] The ticket management screen 501 has a ticket list display area 501a and a ticket information display area 501b.

[0079] The ticket list display area 501a includes a filter condition setting area 5011a and a filter result display area 5011b. The ticket information display area 501b includes an ID display area 5012a, a title display area 5012b, a description display area 5012c, a conclusion display area 5012d, and a work memo display area 5012e.

[0080] The filter condition setting area 5011a is where the filter conditions selected by the user are entered. The filter conditions specify each item in the ticket information table 231, such as the ticket ID 231a, creation date and time 231b, and creator 231c, or keywords contained in each item. The filter result display area 5011b displays the ID and other information of the ticket information read from the ticket information table 231 stored in the ticket management server 2 that matches the filter conditions.

[0081] The ID display area 5012a displays the ID of the ticket information selected by the user from the filter result display area 5011b. The title display area 5012b displays the title of the ticket information corresponding to the ID displayed in the ID display area 5012a. The description display area 5012c displays the description of the ticket information corresponding to the ID displayed in the ID display area 5012a. The conclusion display area 5012d displays the conclusion of the ticket information corresponding to the ID displayed in the ID display area 5012a.

[0082] The chat screen 502 has a model selection area 502a, and display areas for a prompt 502b and an answer 502c. The model selection area 502a accepts the selection of a language model 4 that generates answers to questions entered via chat. The prompt 502b is an input format that accepts the content of the question from the user and requests the language model 4 to generate an answer. The answer 502c is the answer to the prompt 502b generated by the language model 4.

[0083] The search results display screen 503 has an FAQ search results display area 5031 and a troubleshooting action display area 5032. The FAQ search results display area 5031 displays the results of searching the FAQ table 331 of the knowledge DB server 3 in response to the prompt 502b of the chat screen 502. The FAQ search results display area 5031 has a selection check input area 503a, an FAQ name display area 503b, a symptom display area 503c, a basic system information display area 503d, and a troubleshooting action group display area 503e. A check mark is entered in the selection check input area 503a for the FAQ selected from the FAQ search results. The FAQ name display area 503b displays the FAQ name 331a (Figure 10) of the relevant FAQ. The basic system information display area 503d displays the environment 331c and configuration 331d (Figure 10) of the relevant FAQ. The troubleshooting action group display area 503e shows the troubleshooting action group 331e (Figure 10) for the relevant FAQ.

[0084] The troubleshooting action display area 5032 displays a list of troubleshooting actions included in the troubleshooting action group display area 503e, which is included in the search results of the FAQ table 331 corresponding to the prompt 502b of the chat screen 502. The troubleshooting action display area 5032 has an Action name display area 503f, a verification procedure display area 503g, an ease of execution display area 503h, and a cause / solution display area 503i. The Action name display area 503f displays the Action name 332a (Figure 11) of the relevant troubleshooting action. The verification procedure display area 503g displays the verification procedure 332b (Figure 11) of the relevant troubleshooting action. The ease of execution display area 503h displays the ease of execution 332c (Figure 11) of the relevant troubleshooting action. The cause / solution display area 503i displays the cause 332d and solution 332e (Figure 11) of the relevant troubleshooting action.

[0085] (FAQ creation process according to the embodiment) Figure 16 is a diagram illustrating the overview of the FAQ creation process according to the embodiment.

[0086] Step S41 shown in Figure 16 corresponds to step S11 (Figure 13) of the FAQ creation / update process. Step S42 corresponds to step S12 of the FAQ creation / update process. Step S43 corresponds to step S15 of the FAQ creation / update process. Step S44 corresponds to steps S16 and S17 of the FAQ creation / update process. Steps S45 and S46 correspond to step S21 of the FAQ creation / update process.

[0087] Step S41 is executed in response to the FAQ creation instruction 5021 entered from the chat screen 502. As a result of the execution of steps S42 to S44, data for a new troubleshooting action is registered in the troubleshooting action display area 5032. As a result of the execution of step S45, a new FAQ, FAQ1, is registered in the FAQ search results display area 5031. As a result of the execution of step S46, Action2 is registered in the troubleshooting action group display area 503e for the new FAQ, FAQ1, in the FAQ search results display area 5031. In Figure 16, the final response 5022 is output to the chat screen 502, notifying that FAQ1 has been created and Action2 has been added.

[0088] (Overview of FAQ search processing according to the embodiment) Figure 17 is a diagram illustrating the overview of the FAQ search process according to the embodiment.

[0089] Step S51 shown in Figure 17 corresponds to step S31 (Figure 14) of the FAQ search process. Step S52 corresponds to step S32 of the FAQ search process. Step S53 corresponds to step S33 of the FAQ search process. Steps S54 and S55 correspond to step S34 of the FAQ search process. Step S57 corresponds to step S38 of the FAQ creation / update process.

[0090] In response to the instruction 5023 to obtain necessary information for the FAQ search entered from the chat screen 502, step S51 is executed and the answer 5024 is output to the chat screen 502. Also, in response to the instruction 5025 to perform a similar FAQ search entered from the chat screen 502, step S52 is executed and the answer 5026 is output to the chat screen 502.

[0091] Furthermore, steps S56 and S57 are executed in response to the input 5027 of the execution result of Action 1 from the chat screen 502. In Figure 16, the chat screen 502 displays a final response 5028 indicating that the cause of step S57 could not be identified, and that similar FAQs displayed in the FAQ search results display area 5031 were filtered using unexecuted troubleshooting actions. This filtering removes information related to the executed Action 1 from the troubleshooting action group display area 503e.

[0092] (Overview of the FAQ update process according to the embodiment) Figure 18 is a diagram illustrating the overview of the FAQ update process according to the embodiment.

[0093] As shown in Figure 18, in the chat screen 502, the FAQ update instruction 5029 is input following the output of response 5028. Steps S41 to S44 are then executed, and as a result, the troubleshooting action Action 3 is registered in the troubleshooting action display area 5032. Step S46A is then executed, and as a result, the troubleshooting action Action 3 is registered in FAQ1 in the FAQ search results display area 5031. In Figure 18, as the final response 5020, the chat screen 502 shows the registration of Action 3 in the troubleshooting action display area 5032 and a notification of the addition of Action 3 to the selected symptom in the FAQ search results display area 5031.

[0094] (Effects of the embodiment) In the above embodiment, a language model is used to search past case information (e.g., FAQ table 331) based on the symptoms and system information of the target system as input, and past cases (e.g., FAQs) with matching or similar symptoms and system information are obtained. Then, using the language model, past cases are grouped by the troubleshooting actions included in the obtained past cases, and the grouped past cases are output along with the troubleshooting actions. Therefore, according to this embodiment, FAQs can be searched using broad conditions such as symptoms and system information, many search results can be obtained, and these search results can be used to easily and clearly narrow down the cause and countermeasures of an incident through interactive and guided chat. In other words, by grouping the searched past case information based on the matching or similarity of the troubleshooting actions, it becomes easier to see what actions to take and how the cause of the incident will be isolated. By grouping, even if the same command or the same environment variable has different parameters, for example, the same verification procedure is used, so it is possible to judge the ease of execution and perform execution and verification all at once. In addition, even if the symptoms that can be confirmed by the user do not provide all the information necessary to identify the cause, effective cause narrowing can be performed, and the time to identify the cause can be shortened.

[0095] Furthermore, in the above-described embodiment, the execution result of the verification procedure included in the troubleshooting action by the user is received, and a language model is used to determine whether the execution result of the verification procedure corresponds to the cause in the troubleshooting action information. The cause determined to be the same and the countermeasure corresponding to the cause in the troubleshooting action information are then output. Thus, according to this embodiment, efficient incident response can be achieved by having the user execute the verification procedure of the troubleshooting action that has been guided through the chat dialogue and outputting the cause and countermeasure.

[0096] Furthermore, in the above-described embodiment, if the cause cannot be identified, past cases related to troubleshooting actions for which the user has already performed the verification procedure are deleted, and only past cases related to troubleshooting actions for which the user has not yet performed the verification procedure are re-output. Therefore, according to this embodiment, by filtering, executed troubleshooting actions for which the cause could not be identified are excluded from the output display, allowing for a clearer view of the continuation of incident response.

[0097] Furthermore, in the above embodiment, a language model is used to extract symptoms, system information, verification procedures, causes, and countermeasures from work records related to past cases, and the extracted verification procedures are classified based on similarity or matching using the language model. Then, a troubleshooting action combining the classified verification procedure and the corresponding cause and countermeasure is registered in the troubleshooting action information. In addition, past cases combining the extracted symptoms, system information, verification procedures, and troubleshooting actions registered in the troubleshooting action information are newly registered in the past case information. That is, troubleshooting actions are extracted from the verification procedures among the symptoms, system information, verification procedures, causes, and countermeasures extracted from resolved tickets + work memos, with similar and duplicated actions removed, and past case information is prepared by associating troubleshooting actions with past cases. Therefore, according to the embodiment, the verification procedure of the troubleshooting action that isolates the cause of an incident can be efficiently selected and executed based on the similarity or matching of the troubleshooting actions.

[0098] Furthermore, in the above embodiment, if the extracted symptom and system information combination is already registered in the past case information, the troubleshooting action corresponding to the symptom and system information is added to the troubleshooting action of the registered past case information to update the past case information. Thus, according to this embodiment, by grouping past cases of various symptoms with troubleshooting actions, it is possible to prevent the increase of similar past cases (similar FAQs) and the resulting decrease in search accuracy.

[0099] Furthermore, in the above-described embodiment, the ease of execution of the classified verification procedure is determined using a language model, and the classified verification procedure, the corresponding cause and countermeasure, and the determined ease of execution of the verification procedure are combined and registered as a troubleshooting action in the troubleshooting action information. Therefore, according to this embodiment, verification procedures for troubleshooting actions with higher ease of execution can be executed preferentially, so that the search for cause and countermeasure can be advanced efficiently.

[0100] Furthermore, in the above-described embodiment, the history of inputs and outputs is recorded, and when searching for past case information, additional information based on the history is added to the input. Therefore, according to this embodiment, the accuracy of searching for similar past cases can be improved.

[0101] Although several embodiments have been described above, these are merely illustrative examples for explaining the present invention and are not intended to limit the scope of the present invention to these embodiments only. The present invention can also be implemented in various other forms, such as forms in which some of the components of the above embodiments are omitted, forms in which at least some of the components are replaced, forms in which components are added, or forms in which some or all of the embodiments are combined. [Explanation of Symbols]

[0102] S: Overall system, 1: Incident response support system, 2: Ticket management server, 3: Knowledge DB server, 4: Language model, 5: User terminal, 11: Processor, 12: Memory, 132: Conversation history, 500: Output device, 500D: Incident response support screen

Claims

1. An incident response support method performed by an incident response support system that assists in identifying the cause of an incident that occurred in the target system, The aforementioned incident response support system is: Troubleshooting action information that stores a combination of a verification procedure performed on the target system to identify the cause of the incident, the cause, and countermeasures for the incident as troubleshooting action, It is possible to access past case information, which stores as past cases a combination of the symptoms of an incident that occurred in a past system, system information indicating the configuration of the past system, and the troubleshooting actions, including the verification procedure, that were performed on the past system in which the incident occurred. The processor of the aforementioned incident response support system Using a language model that generates output for natural language input, the system searches for past case information based on the symptoms and system information of the target system as input, and obtains past cases in which the symptoms and system information match or are similar. Using the language model, the past cases are grouped by the segmentation action included in the acquired past cases. The grouped past cases are output along with the aforementioned troubleshooting actions. An incident response support method characterized by having each of the following processes.

2. The incident response support method according to claim 1, The aforementioned processor, The user receives the result of executing the verification procedure included in the troubleshooting action, Using the language model, determine whether the result of executing the verification procedure corresponds to the cause corresponding to the verification procedure in the troubleshooting action information. The cause determined to be applicable and the countermeasure corresponding to that cause are output in the troubleshooting action information. An incident response support method characterized by further comprising each of the following processes.

3. The incident response support method according to claim 2, The aforementioned processor, If the cause cannot be identified, the past cases related to the troubleshooting action for which the user has already performed the verification procedure are deleted, and only the past cases related to the troubleshooting action for which the user has not yet performed the verification procedure are re-output. An incident response support method characterized by having a processing function.

4. The incident response support method according to claim 1, The aforementioned processor, Using the aforementioned language model, the symptoms, system information, verification procedure, cause, and countermeasures are extracted from the work records related to the past cases. Using the aforementioned language model, the extracted verification procedures are classified based on their similarity or match. The troubleshooting action, which combines the classified verification procedure, the corresponding cause, and the countermeasure, is registered in the troubleshooting action information. The extracted symptoms, the system information, the verification procedure, and the troubleshooting action registered in the troubleshooting action information are combined to create a new past case which is then registered in the past case information. An incident response support method characterized by having each of the following processes.

5. The incident response support method according to claim 4, The aforementioned processor, If the extracted combination of symptoms and system information is already registered in the past case information, the troubleshooting action corresponding to the symptoms and system information is added to the registered troubleshooting action in the past case information and the past case information is updated. An incident response support method characterized by having a processing function.

6. The incident response support method according to claim 4, The aforementioned processor, Using the aforementioned language model, the ease of execution of the classified verification procedure is determined. The classified verification procedure, the corresponding cause and countermeasure, and the determined ease of execution of the verification procedure are combined and registered as the troubleshooting action in the troubleshooting action information. An incident response support method characterized by having each of the following processes.

7. The incident response support method according to claim 1, The aforementioned processor, The history of the aforementioned inputs and outputs is recorded. When searching for the aforementioned past case information, additional information based on the history is added to the input. An incident response support method characterized by the following features.

8. An incident response support system that assists in identifying the cause of an incident that occurred in the target system, Troubleshooting action information that stores a combination of a verification procedure performed on the target system to identify the cause of the incident, the cause, and countermeasures for the incident as troubleshooting action, It is possible to access past case information, which stores as past cases a combination of the symptoms of an incident that occurred in a past system, system information indicating the configuration of the past system, and the troubleshooting actions, including the verification procedure, that were performed on the past system in which the incident occurred. The processor of the aforementioned incident response support system is Using a language model that generates output for natural language input, the system searches for past case information based on the symptoms and system information of the target system as input, and obtains past cases in which the symptoms and system information match or are similar. Using the language model, the past cases are grouped by the segmentation action included in the acquired past cases. The grouped past cases are output along with the aforementioned troubleshooting actions. An incident response support system characterized by the following features.