System and method for generating incident action recommendations for incident diagnosis, mitigation, and resolution using generative artificial intelligence models

Abstract

A method, computer program product, and computing system for determining an incident request intent associated with an incident request by processing the incident request using a generative artificial intelligence (AI) model. A candidate structured troubleshooting guide node is obtained from a database of structured troubleshooting guide nodes by processing the incident request intent using the generative AI model. An incident action recommendation is generated by processing the candidate troubleshooting guide and the incident request intent using the generative AI model.

Description

System and Method for Generating Incident Action Recommendations for Incident Diagnosis, Mitigation, and Resolution Using Generative Artificial Intelligence ModelsBackground

[0001] Efficient incident mitigation is critical for maintaining service reliability in computing environments, yet the current landscape of Troubleshooting Guides (TSGs) presents significant challenges. Across various triage teams, TSGs exhibit inconsistencies in quality and format (e.g., generally low quality) , creating difficulties for Directly Responsible Individuals (DRIs) assigned with diagnosing a particular incident. The lack of standardized and high-quality TSGs often results in prolonged time-to-mitigation (TTM) for assigned incidents which reduces computing system performance and computing system availability.Brief Description of the Drawings

[0002] FIG. 1 is a flow chart of one implementation of an incident diagnosing process;

[0003] FIGS. 2-4 are diagrammatic views of an example incident diagnosing process; and

[0004] FIG. 5 is a diagrammatic view of an example computer system and an incident diagnosing process coupled to a distributed computing network.

[0005] Like reference symbols in the various drawings indicate like elements.Detailed Description

[0006] Implementations of the present disclosure provide a generative artificial intelligence (AI) -driven approach to reduce the time-to-mitigation (TTM) associated with computing system incident management. For example, to help the on-call engineers (e.g., DRIs) to speed up the incident diagnosis and mitigation process, thus reducing the overall TTM for computing environments, the present disclosure  describes a cloud incident auto diagnosis process. The backend of the process analyzes existing documents such as trouble shooting guide (TSG) , domain knowledge-related documents (i.e., documents concerning the operation of the cloud computing environment and / or components of the cloud computing environment) , past incidents, etc. to identify the diagnostic steps leading to the root cause of the incidents and recommendations to mitigate the incident. By offering assistance to users during incident mitigation, implementations of the present disclosure enhance efficiency, alleviate the burden on users, and contribute to a more seamless incident resolution process (e.g., reducing TTM) . Leveraging generative AI models, the present disclosure empowers users, regardless of their experience level, in navigating the complexities of incident mitigation with incident triage action recommendations.

[0007] Accordingly, implementations of the present disclosure describe determining an incident request intent associated with an incident request by processing the incident request using a generative artificial intelligence (AI) model. A candidate structured TSG node is obtained from a database of structured TSG nodes by processing the incident request intent using the generative AI model. An incident action recommendation is generated by processing the candidate TSG and the incident request intent using the generative AI model.

[0008] While existing approaches provide certain automation for triaging or diagnosing incidents, implementations of the present disclosure synthesize datasets from historical incidents, TSGs, and domain knowledge-related documents, and provides step-by-step guidance that leads to the most efficient mitigation actions (where the efficiency enhancement can be measured by a reduction in TTM) . This bridges the gap between disparate documents and triaging resources, and increases efficiency and consistency in incident response. Accordingly, implementations of the present disclosure reduce the overall incident TTM by reducing the amount of time required before a response is implemented to mitigate (i.e., when the incident no longer impacts users of the cloud computing environment) or resolve (i.e., when the  incident response is fixed such that the cloud computing environment is operating normally) an incident relative to conventional incident diagnosis processes.

[0009] The details of one or more implementations are set forth in the accompanying drawings and the description below. Other features and advantages will become apparent from the description, the drawings, and the claims.

[0010] The Incident Diagnosing Process:

[0011] Referring to FIGS. 1-4, incident diagnosing process 10 determines 100 an incident request intent associated with an incident request by processing the incident request using a generative artificial intelligence (AI) model. A candidate structured TSG node is obtained from a database of structured TSG nodes by processing the incident request intent using the generative AI model. An incident action recommendation is generated by processing the candidate TSG and the incident request intent using the generative AI model.

[0012] In some implementations, incident diagnosing process 10 determines 100 an incident request intent associated with an incident request by processing the incident request using a first generative artificial intelligence (AI) model. For example, during the operation of a cloud computing system, various computing services are provided to connected users or applications. In one example, cloud computing services include storage services, processing services, and application services provided over the Internet. Issues may occur within the cloud computing system that result in an “incident” (i.e., a detectable event that requires resolution or diagnosing by an incident management system) . Incident management in a cloud computing system (e.g., cloud computing system 200) involves detecting, responding to, and resolving incidents (e.g., incident 202) to ensure optimal performance and reliability. Referring also to FIG. 2, an incident management system (e.g., incident management system 204) follows a structured process including:

[0013] ● Detection: Automated tools monitor system health, performance, and security. Alerts are triggered if incidents are detected.

[0014] ● Alerting: The incident management system notifies relevant triage groups about the incident, providing details on the nature and severity of the problem.

[0015] ● Incident Triage: Triage groups prioritize incidents based on severity and potential impact, determining the appropriate response level.

[0016] ● Response: Triage groups initiate predefined response plans, which include automated actions, manual interventions, or a combination to diagnose, mitigate, and / or resolve the incident. As will be discussed in greater detail below, implementations of incident diagnosing process 10 provide responses to identified incidents by generating incident action recommendations using a generative AI model based, at least in part, upon a candidate TSG, and an incident request intent.

[0017] ● Mitigation and Resolution: Once the issue is addressed, triage groups work on restoring normal system functionality where mitigation restores impacts functionality to users resulting from the incident and resolution fixes the incident.

[0018] ● Post-Incident Analysis: Triage groups analyze the incident to understand its root cause and identify improvements to prevent similar issues in the future. This feedback loop contributes to ongoing system optimization.

[0019] For example, incident management system 204 determines a triage group (e.g., triage groups 206, 208, 210) to assign to incident 202. In some implementations, incident management system 200 identifies a candidate triage group by processing the incident request using predetermined rule sets that identify a triage group to resolve an incident (e.g., incident 202) . A triage group (e.g., triage groups 206, 208, 210) is a group of resources (e.g., automated computing resources, trained machine learning models, dedicated engineers) that has access to domain knowledge in order to triage incidents. Examples of candidate triage groups include a storage triage group (e.g., a group for triaging storage issues) , a processing triage group (e.g., a group for triaging processing issues) , an application triage group (e.g., a group for triaging application  issues) , and a network triage group (e.g., a group for triaging network issues) . In some implementations, incident management system 204 leverages collaborative platforms, real-time communication channels, and documentation to facilitate efficient collaboration among distributed triage groups.

[0020] However, once assigned, the efficiency of a triage group is limited by the users’ ability to use their triage group domain knowledge (e.g., TSGs) . Accordingly, incident diagnosing process 10 uses generative AI models to auto-diagnose based on TSGs and assists triage groups to mitigate incidents. Referring also to FIG. 3, a user (e.g., a DRI) is assigned an incident (e.g., incident 202) . With incident diagnosing process 10, the user provides an incident request (e.g., incident request 300) to incident diagnosing process 10. In some implementations, incident request 300 is a prompt (e.g., a text prompt, an audio prompt) from the user asking for assistance with diagnosing incident 202 using incident diagnosing process 10. In some examples, incident request 300 is a request received from a user interface with information concerning incident 202. For example, incident management system 204 may include a user interface displaying identified incidents that a user can select and request assistance for using incident diagnosing process 10.

[0021] Incident diagnosing process 10 is represented in FIG. 3 as several systems (e.g., systems 302, 304, 306, 308, 310, 312) . As will be discussed in greater detail below, each system accesses a generative AI model (e.g., Large Language Model (LLM) and / or natural language processing (NLP) technology) that automatically (i.e., without human intervention) generates and outputs a respective output for communication with other systems in a multi-agent manner to generate incident action recommendations (i.e., suggested action (s) that should be taken to resolve the incident) . In one example, the systems access a common generative AI model (e.g., represented in FIG. 3 by generative AI model 314) to perform various functions. In some examples, the systems use multiple generative AI models (e.g., represented in FIG. 3 with first generative AI model 316, second generative AI model 318, third  generative AI model 320, fourth generative AI model 322, and fifth generative AI model 324) . For instance, each system (e.g., systems 302, 304, 306, 308, 310, 312) is shown as including or accessing separate generative AI models. Accordingly, any of systems 302, 304, 306, 308, 310, 312 may share with one or more other systems, or may use a single generative AI model or multiple generative AI models that use information from other generative AI models to perform their respective functions.

[0022] As shown in FIG. 3, intent understanding system 302 includes a first generative AI model (e.g., first generative AI model 316) that processes the incident request intent to identify an incident request; troubleshooting guide (TSG) retrieval system 304 includes a second generative AI model (e.g., second generative AI model 318) that processes the incident request from first generative AI model 316 to identify a candidate structured TSG node from a database of candidate structured TSG nodes; incident action recommendation system 306 includes a third generative AI model (e.g., third generative AI model 320) that generates incident action recommendations for the incident request using the candidate structured TSG node (s) ; post-processing system 308 includes a fourth generative AI model (e.g., fourth generative AI model 322) that performs a verification of the incident action recommendation for cloud computing system 200; TSG evaluator system 310 includes a fifth generative AI model 324) evaluates TSGs and provides the recommendations to a user (e.g., 326) ; and parsing and enhancing system 312 which includes fifth generative AI model 322 (or a separate generative AI model) for parsing and enhancing unstructured TSGs for a structured TSG database (e.g., by converting unstructured TSGs into structured TSGs for storage in the structured TSG database) .

[0023] In some implementations, when an incident is assigned to a user (e.g., a Directly Responsible Individual of a triage group) , the user can turn to incident diagnosing process 10 for guidance on mitigating the issue by providing relevant incident details. For example, and as will be described in greater detail below, incident diagnosing process 10 determines 100 an incident request intent associated  with an incident request by processing the incident request using a first generative artificial intelligence (AI) model, and if it is not clearly expressed, incident diagnosing process 10 uses the generative AI model to provide a request for clarification to refine the intent. Incident diagnosing process 10 obtains 102 or retrieves pertinent nodes from the database to diagnose and provide solutions for the current issue. Incident diagnosing process 10 generates 104 an incident action recommendation based upon the obtained nodes and the incident request. Incident diagnosing process 10 verifies 106 the incident action recommendation using a post-processor to confirm the validity of the recommended actions. In some implementations, once verified, the incident action recommendation may be performed 108 by a user (e.g., a DRI) or triggered automatically by incident diagnosing process 10. Incident diagnosing process 10 generates a summary and output of the incident action recommendation (e.g., results 328) to the user (e.g., the DRI) of a triage group (e.g., user 326) .

[0024] In some implementations, incident diagnosing process 10 determines 100 an incident request intent associated with an incident request by processing the incident request using a first generative artificial intelligence (AI) model. For example, a generative AI model (e.g., first generative AI model 316) receives and processes natural language prompts and / or example entries and / or contextual information concerning an incident to generate a response (e.g., queries to better understand the incident) . In some implementations, the first generative AI model includes a Large Language Model (LLM) . A LLM (e.g., GPT-4 from  OpenLLaMa, and Cerebras-GPT) is a language model comprising a neural network with many parameters (typically billions of weights or more) , trained on large quantities of unlabeled text using self-supervised learning or semi-supervised learning. Though trained on simple tasks along the lines of predicting the next word in a sentence, LLMs with sufficient training and parameter counts capture the syntax and semantics of human language. In some implementations, the first generative AI model includes a natural language processing (NLP) model. A NLP model (e.g.,  XLNet, Robustly Optimized Bidirectional Encoder Representations from Transformers Pretraining Approach (RoBERTa) , and Pathways Language Model (PaLM) ) is a model that concerns the understanding, analysis, and generation of natural language. NLP models analyze text and speech to extract meaning, as well as generating new text or speech in response.

[0025] In some implementations, general LLM and NLP models lack domain knowledge. Thus, it is more challenging for general LLM and NLP models to address domain-specific scenarios. For example, incident remediation, such as is described in TSGs, generally requires an actionable plan comprising several steps. To address this challenge and as will be described in greater detail below, incident diagnosing process 10 includes verifying 106 an incident action recommendation using a post-processor generative AI model acting as a domain expert to double-check the validity of the recommended actions.

[0026] In some implementations, determining 100 the incident request intent associated with the incident request includes providing 110 a request for clarification in response to the incident request using the first generative AI model. For example, incident diagnosing process 10 interprets the user’s intention and determines whether the current request necessitates the generation of an incident action recommendation for addressing an incident. In this manner, incident diagnosing process 10 provides 110 a request for clarification in response to the incident request.

[0027] In an example, incident diagnosing process 10 guides and provides requests for clarification. For instance, when users pose vague questions or use incorrect terminology, incident diagnosing process 10 intervenes to seek clarification. An example dialogue between an interface or assistant of incident diagnosing process 10 and a user is shown below where first generative AI model 316 queries the user’s use of the term “deletion pending” by confirming if the user intended to inquire about “isolation pending” :

[0028] User: How to investigate container deletion pending?

[0029] Incident Diagnosing Assistant: I cannot confidently confirm, but are you asking about ‘How to Investigate Container Isolation Pending Check if container isolation is occurring’ ?

[0030] User: Yes

[0031] Incident Diagnosing Assistant: To investigate container isolation pending follow these steps:

[0032] …

[0033] If an exception is thrown indicating that the container is not found, the container is either already isolated or does not exist.

[0034] In some implementations, incident diagnosing process 10 determines 100 the incident request intent associated with the incident request within the context of a multi-round conversation (e.g., incident diagnosing process 10 processes iterative dialogue rather than one-round question-answer tasks) . For example, there are two common scenarios where the user inputs information related to incidents. First and as will be discussed in greater detail below, if the user successfully takes an action previously recommended by incident diagnosing process 10 and provides feedback, incident diagnosing process 10 matches the user’s input against a “CONDITION” in a previously obtained TSG node. If a match is found, the current TSG node is likely completed, and incident diagnosing process 10 returns the “SHOULD_DO” context, prompting retrieval of the next TSG node (e.g., from a database of TSG nodes) . If no match occurs, incident diagnosing process 10 reviews the user’s input and confirms the incident action recommendation.

[0035] The second scenario involves the user posing a new question unrelated to the current incident. In this case, incident diagnosing process 10 may seek confirmation for the closure of the ongoing incident mitigation. If the user wishes to address a new incident, incident diagnosing process 10 initiates a new conversation, cleans memory for the new interaction, and determines 100 the incident request intent for the new incident request. Accordingly and for both scenarios, intent understanding system 302 provides the incident request intent (e.g., incident request intent 330) to TSG node retrieval system 304) .

[0036] When diagnosing incidents, the primary data source for obtaining information concerning how to diagnose and resolve an incident within an incident management system includes unstructured TSGs (i.e., descriptions of incidents and descriptions of actions to diagnose, mitigate, and / or resolve the incident that lack consistent structure) . Generating an effective TSG for incidents in a cloud computing environment is challenging due to various complexities and factors specific to cloud environments. For example, cloud services are updated frequently, which can result in changes to features and interfaces. With these changes, it is difficult to keep the TSG up-to-date. Additionally, different cloud service incident triaging groups have different approaches to naming conventions, configurations, and application programming interfaces (APIs) , making it challenging to create a standardized TSG.

[0037] As will be discussed in greater detail below, incident diagnosing process 10 is able to convert unstructured TSGs (i.e., TSGs without a particular schema or structure) into structured TSGs by reformulating the information from the unstructured TSG into a generic format. However, even after TSG reformulation, it is still challenging for generative AI models (e.g., LLMs) to directly take such content to generate inferences and decisions. Additionally, generative AI models generally cannot directly query these documents via traditional data retrieval methods without first parsing and processing the structures. For example, to successfully query a reformulated TSG (e.g., a structured TSG) , the generative AI model would be trained using the particular structured TSG and such training may limit the generative AI model to a particular TSG (i.e., limitations from overfitting to the structured TSG itself) . As will be discussed in greater detail below, incident diagnosing process 10 processes the unstructured TSGs into connected nodes. A troubleshooting guide (TSG) node is a structured representation of information (e.g., terminology information, background information, frequently asked questions, steps  / actions to perform, and / or appendix information) used to diagnose, mitigate, and / or resolve an incident.

[0038] TSG nodes define particular “chunks” of TSGs that can be provided to a  generative AI model as context for diagnosing, mitigating, or resolving an incident. For example, an incident request that a user provides concerns an incident that is described in a TSG. However, generative AI models may be trained using various sources of information that lack domain-knowledge concerning diagnosing, mitigating, and / or resolving particular incidents. Accordingly, Retrieval Augmented Generation (RAG) is used to provide the domain-knowledge from particular TSGs to the generative AI model to “search” for in when generating an incident action recommendation.

[0039] One challenge with this approach is that the size of the prompt to the generative AI model is limited. TSGs that can be searched using generative AI models are often orders of magnitude larger than any prompt size limit. For example, the size of a single example unstructured TSG may range between tens megabytes to hundreds of megabytes or even gigabytes. Accordingly, Retrieval Augmented Generation (RAG) generally is used to break input documents into chunks that are small enough to fit the prompt size limitations. It then uses existing indexing and retrieval techniques to match incident requests to the most relevant content chunks, and then combines the user query and context (one or more chunks) as a prompt to the generative AI model and presents the incident action recommendation (s) to the user. However, existing approaches may generate equal-sized chunks that do not account for the particular content of a TSG. For example, generating equally-sized chunks of a particular TSG may split a single step into multiple chunks reducing the contextual clarity for the generative AI model. In another example, a chunk may include each and every step in a large series of steps for resolving large incidents.

[0040] To address this prompt size limitation, incident diagnosing process 10 uses TSG nodes generated for particular portions of the TSG to provide as context with the incident request for processing by the generative AI model. As described below, with candidate TSG nodes that are identified as relevant to a given incident request, the generative AI model can generate incident action recommendations from specific  TSGs to diagnose, mitigate, and / or resolve the incident.

[0041] In some implementations, generative AI models are leveraged to build a knowledge base where fields in a TSG node define the node’s type, intent, action, and / or linking to other nodes. As will be discussed in greater detail below, the TSG node definition generated from the respective fields allows generative AI models to retrieve the most relevant TSG node to the user’s query and to generate an incident action recommendation by linking TSG nodes. The node knowledge base can be used by generative AI model (s) to identify or generate new connections between TSGs (e.g., where a particular incident is referenced in multiple TSGs from the same incident triaging group or from different incident triaging groups) by processing TSGs in multiple nodes representative of different fields of the TSG (e.g., background information in background nodes, frequently asked question information in frequently asked question nodes, steps to diagnose, mitigate, and / or resolve in step nodes, and appendix information in appendix nodes) . This is especially relevant for cross-incident diagnostic teams (e.g., a combination of an incident diagnostic group for triaging storage issues, an incident diagnostic group for triaging processing issues, an incident diagnostic group for triaging application issues, and / or an incident diagnostic group for triaging network issues) with troubleshooting flows that do not exist in TSGs. For example, by processing TSG nodes, incident diagnosing process 10 generates incident action recommendations formed by linking the steps described in various TSG nodes to resolve the incident.

[0042] In some implementations, incident diagnosing process 10 organizes unstructured TSGs into five types of TSG nodes: terminology; background; frequently asked questions; steps; and appendix. However, it will be appreciated that other types of TSG nodes are usable within the scope of the present disclosure. In one example, a step node includes particular fields: a title field, an intent field, an action field, an output field, and a default parameter field concerning a particular step from a TSG, where each step of a TSG defines a respective node. As step nodes describe the flow  of distinct actions to diagnose, mitigate, and / or resolve an incident, these fields are processed by the generative AI model to link particular steps together to generate an incident action recommendation for the incident. In this example, the title field describes what the step is doing, and the intent field describes the intention of this step. In some examples, if there is no further detailed intention description, it is left blank, and / or it will be filled by the title field. The action field describes the process for troubleshooting the incident and / or provides an explanation of the intent field. In some implementations, the action field contains code blocks in markdown format, and placeholders for parameters. In some implementations, the output field is defined in the following format: if a condition is met (e.g., “condition” ) , then the described action (i.e., the action described in the action field) is performed (e.g., “should_do” ) .

[0043] In some implementations, the default parameter field describes default value (s) for parameters defined in the action field. In an example, the default parameters are generated by a generative AI model generating the TSG nodes for a particular TSG based on the action field, by extracting parameters mentioned within the action field. The inclusion of placeholders within the action field enables a seamless substitution of these placeholders with user-provided parameters, should they be provided. In cases where users do not provide specific parameter values, the default parameters generated by the generative AI model persist in the action field.

[0044] In some implementations, incident diagnosing process 10 obtains 102 a candidate structured TSG node from a database of structured TSG nodes by processing the incident request intent using a second generative AI model. In one example, obtaining 102 the candidate structured TSG node includes two stages: 1) retrieving the top- “k” (where k is a predefined value) most relevant TSG nodes with traditional data-retrieval methods by matching the similarity between incident request and the candidate TSG node’s intent and 2) using the second generative AI model to select the most relevant node (s) from the top-k retrieved candidates. Referring again to FIG. 3, TSG node retrieval system 304 includes a second generative AI model (e.g.,  second generative AI model 318) that retrieves pertinent TSG nodes from a structured TSG node database (e.g., structured TSG node database 332) based on the incident request (e.g., incident request 300) and / or the incident request intent (e.g., incident request intent 330) . In some implementations, structured TSG node database 332 is a database or other data structure (e.g., a log, a hash table, a graph data structure, a tree data structure, a queue) that maintains a plurality of TSG nodes. In some implementations, obtaining 102 the TSG node is similar to traditional data retrieval methods, where similarities between the incident request intent and the “intent” of each of the TSG nodes are compared. In one example, similar intent is determined by comparing keywords from the incident request to keywords from TSG node database 332 using rule-based matching where rules are defined for matching keywords relative to predefined thresholds. In another example, similar intent is determined by using a machine learning model trained on examples of keywords in the incident request that have a known intent. In this example, a confidence level is generated by the machine learning model and when the confidence level exceeds a predefined threshold, a matching intent between the incident request and a TSG node is identified. To bolster fault tolerance, incident diagnosing process 10 obtains 102 multiple TSG nodes, leveraging generative AI models to select the most closely related TSG nodes to establish the knowledge context (i.e., a plurality of TSG nodes with similar intent (based on a threshold similarity) that provide context for diagnosing, mitigating, and / or resolving the incident) for diagnosing the incident for the incident request. In some implementations, retrieving multiple TSG nodes, rather than just a single TSG node, avoids potential mismatches in similarity mapping. For example, while certain keywords may match between user intent and TSG node intent, semantic differences can persist. In these cases, having information from multiple TSG nodes serves to refine and enrich the knowledge context for subsequent actions.

[0045] In one example, incident diagnosing process 10 determines that incident request intent 330 is associated with a networking incident (e.g., incident 202) within  a cloud computing system. In this example, incident diagnosing process 10 uses first generative AI model 316 to determine incident request intent 330 that indicates that the user is requesting assistance for diagnosing a networking incident within a cloud computing system (e.g., the incident request states “what are the steps to resolve a networking issue associated with accessing large datasets in a cloud computing system? ” ) . With incident request intent 330, incident diagnosing process 10 obtains 102 a candidate structured TSG node by processing incident request intent 330 and comparing that intent against the intent of each structured TSG node using second generative AI model 318 and a database of structured TSG nodes (e.g., structured TSG node database 332) . As shown in FIG. 3, structured TSG node database 332 includes a plurality of structured TSG nodes (e.g., structured TSG nodes 334, 336, 338) . In this example, structured TSG node 334 concerns diagnosing a network incident within a cloud computing environment. Accordingly, incident diagnosing process 10 obtains structured TSG node 334 (e.g., a structured TSG node that describes the steps to resolve a networking issue) using incident request intent 330. In some implementations, incident diagnosing process 10 obtains a threshold number of candidate structured TSG nodes, where the threshold number is pre-defined, user-defined, or automatically defined by incident diagnosing process 10. In this example, the threshold number of candidate structured TSG nodes allows the third generative AI model of the incident action recommendation system to have information from multiple TSG nodes in order to refine and enrich the knowledge context for subsequent incident action recommendations.

[0046] In some implementations, obtaining 102 the candidate structured TSG node includes: obtaining 112 a first candidate structured TSG node from a first incident triaging group; and obtaining 114 a second candidate structured TSG node from a second incident triaging group. As described above, a triage group (e.g., triage groups 206, 208, 210) is a group of resources (e.g., automated computing resources, trained machine learning models, dedicated engineers) that has access to domain  knowledge in order to triage incidents. For example, structured TSG node database 332 includes structured TSG node 334 from a first incident triaging group (e.g., a networking issue triaging group) and structured TSG node 336 from a second incident triaging group (e.g., a storage issue triaging group) . Continuing with the above example, incident diagnosing process 10 processes incident request 300 (e.g., “what are the steps to resolve a networking issue associated with accessing large datasets in a cloud computing system? ” ) and determines that the incident request intent (e.g., incident request incident 202) concerns networking issues and storage issues. Accordingly, incident diagnosing process 10 obtains 112 a first candidate structured TSG node (e.g., structured TSG node 334) from a networking issue triaging group and obtains 114 a second candidate structured TSG node (e.g., structured TSG node 336) . In this example, incident diagnosing process 10 obtains 102 candidate structured TSG nodes from multiple incident triaging groups. In this manner, incident diagnosing process 10 allows unique combinations of steps from multiple TSGs across different incident triaging groups.

[0047] In some implementations, incident diagnosing process 10 generates 104 an incident action recommendation by processing the candidate TSG node and the incident request intent using a third generative AI model. An incident action recommendation (e.g., incident action recommendation 340) is a recommendation of an action or actions to diagnose, mitigate, and / or resolve a particular incident described in the incident request. Referring again to FIG. 3, incident action recommendation system 306 includes a third generative AI model (e.g., third generative AI model 320) . As discussed above and in some implementations, incident diagnosing process 10 provides the candidate TSG node and the incident request as a prompt to third generative AI model 320 for processing using Retrieval Augmented Generation (RAG) . In some implementations, multiple candidate TSG nodes are provided as context and used to generate a prompt to third generative AI model 320.

[0048] In some implementations, incident diagnosing process 10 generates steps  based on the level of difficulty of the incident diagnosis, mitigation, and / or resolution and the availability of software tools, such as plugins (i.e., a software add-on that allows for connections between incident diagnosing process 10 and other resources of incident management system 204 for automated triaging) . In some implementations, for straightforward incidents, incident diagnosing process 10 generates 104 incident action recommendation 340 as a series of sequential steps that can be performed automatically using plugins without requiring user input.

[0049] Referring also to FIG. 4, incident action recommendation system 306 operates in an automated fashion (i.e., performing incident action recommendations automatically for incident action recommendations with available external plugins) or in a semi-automated fashion (i.e., requesting instructions from a user before performing any portion of the incident action recommendation) . For example, after clarifying the user’s intent and retrieving related structured TSG nodes from the TSG node retrieval system, incident action recommendation system 306 utilizes the intent, available external plugins (e.g., from plugin gallery 400) , and memory (e.g., memory 402) as in-context to generate an incident action recommendation. In one example, incident action recommendation 340 includes detailed operational instructions. Subsequently, incident action recommendation system 306 determines whether the incident action recommendation can be automated with available external plugins by comparing the incident action recommendation with actions associated with the available external plugins that can be executed automatically. As will be discussed in greater detail below, if automation is possible, the results (e.g., result 328) of an execution engine (e.g., execution engine 404) are fed back into incident action recommendation system 306 to generate the next action or sub-action. In one example, each step is provided iteratively. In another example, a series of steps are fed to execution engine 404 at once for execution. However, if manual intervention is required, incident diagnosing process 10 provides incident action recommendation 340 to the user (e.g., user 326) and awaits feedback or action results from user 326.

[0050] In some implementations, memory 402 includes various components, including retrieved structured TSG nodes, conversation history, dynamic demonstrations, and incident parameters. A conversation history serves as a repository of past intentions, actions, and observations. Leveraging this history is integral to incident diagnosing process 10’s ability to swiftly pinpoint the current step in incident mitigation. By referencing the conversation history, incident diagnosing process 10 avoids redundancies, ensuring it does not repeat recommendations when users get stuck in specific steps. This capability facilitates the delivery of more detailed and actionable actions, contributing to a smoother and more efficient incident resolution process. Incident parameters, such as tenant names and monitor identifiers, are unique to each incident instance. These parameters tailor the recommendations and actions provided by incident diagnosing process 10 as the parameters are dynamically filled into placeholders in the code, ensuring that the generated actions are contextually relevant to the specific incident of the incident request (i.e., by using parameters provided by the user to replace placeholders or default parameters in the placeholders) .

[0051] In some implementations, generating 104 the incident action recommendation includes linking 116 the first candidate structured TSG node and the second candidate structured TSG node. For example, empirical studies indicate that cross-triage team / group incidents exhibit significantly higher TTMs compared to inner-triage team incidents. In other words, incidents traversing multiple teams inherently consume additional TTM. Moreover, mitigating such cross-triage team incidents is often challenging due to the intricacies involved in diagnosing root causes. Incident diagnosing process 10 addresses this challenge through structured TSG node database 332, specifically designed to expedite the resolution of cross-team / group incidents. In some implementations, incident diagnosing process 10 transforms TSGs from various triage teams and groups into structured TSG nodes. This transformation facilitates the identification of mitigation flow (s) not present in existing TSGs. For  instance, if a first triage group’s TSG (e.g., structured TSG node 334) suggests that the incident may be related to networking issues and advises consulting a second triage group, incident diagnosing process 10 automatically retrieves and links 116 relevant structured TSG nodes from the second triage group (e.g., structured TSG node 336) if it determines that first triage group’s TSG nodes are insufficient to resolve the incident. In another example, incident diagnosing process 10 automatically retrieves and links 116 relevant structured TSG nodes from the second triage group (e.g., structured TSG node 336) that were previously linked to the first triage group’s TSG nodes. This dynamic retrieval and linking of information streamlines the troubleshooting process and contributes to a more efficient resolution of cross-team / group incidents.

[0052] In some implementations, incident diagnosing process 10 verifies 106 the incident action recommendation using a fourth generative AI model. For example, the post-processing verification system (e.g., post-processing verification system 308) is a post-processor system, specifically designed to infuse domain knowledge relevant to the cloud computing system. In one example, fourth generative AI model 322 is a pre-trained LLaMA2 7B model which is supervised finetuned (SFT) on domain-knowledge of the cloud computing system. For example, supervised finetuning of fourth generative AI model 322 includes adapting a pre-trained Language Model (LLM) to the specific downstream task of verifying whether incident action recommendation 340 is consistent with domain-knowledge using labeled data for previous incidents. During supervised fine-tuning, the finetuning data is collected from responses validated for previous incidents. Referring again to FIG. 3, post-processing verification system 308 receives incident action recommendation 340 and verifies 106 incident action recommendation 340 using fourth generative AI model 322 to determine whether incident action recommendation 340 is consistent with domain-knowledge of the cloud computing system. As shown in FIG. 3, post-processing verification system 308 provides a verification response (e.g., “verified” or  “not verified” ) associated with incident action recommendation 340.

[0053] In some implementations, incident diagnosing process 10 automatically performs 108 the incident action recommendation by dividing the incident action recommendation into a plurality of sub-actions, and iteratively executing the plurality of sub-actions. Referring again to FIG. 4, incident diagnosing process 10 determines whether incident action recommendation 340 is automatically performable. For example, incident diagnosing process 10 determines whether plugin gallery 400 includes a plugin for executing incident action recommendation 340. In one example, suppose incident diagnosing process 10 determines that incident action recommendation 340 describes the steps to reboot a networking component within cloud computing system 200 to resolve incident 202. In this example, suppose that the complete process to reboot the networking component requires other configurations. Accordingly, incident diagnosing process 10 divides incident action recommendation 340 into a plurality of sub-actions using execution engine 404. As each sub-action is processed, the result (e.g., result 328) is processed by execution engine 404 to iteratively execute the plurality of sub-actions until each of the sub-actions of incident action recommendation 340 are executed.

[0054] Evaluating and Structuring Troubleshooting Guides

[0055] In some implementations, incident diagnosing process 10 converts 118 an unstructured TSG into the structured TSG node. The primary data source for incident diagnosing process 10 is an unstructured TSG which includes descriptions of incidents and descriptions of actions to diagnose, mitigate, and / or resolve the incident that lack consistent structure. In some implementations, incident diagnosing process 10 converts 118 the unstructured TSGs into a structured TSG node through a generative AI model (e.g., fifth generative AI model 324) . For example, incident diagnosing process 10 leverages generative AI models (e.g., fifth generative AI model 324) to build a knowledge base where each field is a structured TSG node defining its  type, intent, action, linking. This node definition allows generative AI models to retrieve the most relevant node to the incident request and to generate incident action recommendations. As discussed above, linking nodes using generative AI models forms new connections between TSGs, especially cross-team mitigation flows that do not exist in current TSGs.

[0056] In some implementations, incident diagnosing process 10 converts 118 or reformulates an unstructured TSG by incorporating a Human-in-the-Loop (HITL) approach. For example, this iterative process engages users (e.g., triage group 206) in collaboration with a TSG evaluator system (e.g., TSG evaluator system 310) . Through a series of iterations, triage group 206 and TSG evaluator system 310 work collaboratively to enhance the structure of TSGs. For example and as described below, TSG evaluator system 310 generates recommendations and provides the recommendations to triage group 206 and triage group 206 provides revisions to the TSG to TSG evaluator system 310. In some implementations, converting 118 the unstructured TSG provides more accurate parsing by incident diagnosing process 10 (e.g., using parsing and enhancer system 312) and improves the overall quality and consistency of TSGs.

[0057] In some implementations, incident diagnosing process 10 evaluates 120 an unstructured TSG using a fifth generative AI model. For example, TSG evaluator system 310 processes the text of a TSG for correct grammar, punctuation, and formatting by comparing the TSG to a training set of structured TSGs to determine whether the TSG includes particular content associated with TSG nodes of a structured TSG as described above (e.g., terminology explanation, the background of the incident, the frequently asked questions, the steps, and an appendix for extra information) . TSG evaluator system 310 assesses how difficult the TSG is for the users to understand and follow without any difficulties using various NLP approaches within fifth generative AI model 324 by comparing each portion of the TSG with multiple examples of training TSGs indicating examples of TSGs with clear portions  and TSGs with unclear portions. In this example, fifth generative AI model 324 flags unclear portions based on its TSG training data. As described below, the TSG training data includes previous human-generated labels concerning various aspects of a sample TSG or multiple TSGs.

[0058] In some implementations, fifth generative AI model 324 checks if each step in the TSG is clearly defined and follows a logical order which leads to the resolution of the incident by comparing each step in the TSG with steps from steps from several TSGs in a training set of TSGs that are pre-labeled as being appropriately defined and sequences of steps that are pre-labeled as following a logical order using fifth generative AI model 324. In some implementations, TSG evaluator system 310 uses fifth generative AI model 324 to assess the transitions between consecutive steps by comparing each transition between consecutive steps of the TSG with examples of TSGs with effective transitions and TSGs with ineffective transitions. In this example, fifth generative AI model 324 flags ineffective transitions between steps based on its TSG training data and provides an example of an effective transition using its TSG training data.

[0059] In some implementations, TSG evaluator system 310 uses fifth generative AI model 324 to determine whether the result from one step is directly linked to the following steps including specific “if-else” branching conditions to guide users through progressions without abrupt changes or gaps. For example, TSG evaluator system 310 uses fifth generative AI model 324 to assess linking between steps by comparing the steps of the TSG with examples of TSGs with linked results between steps and TSGs without linked results between steps. In this example, fifth generative AI model 324 flags steps with results that are not linked to following steps on its TSG training data and provides an example of linked steps using its TSG training data.

[0060] In some implementations, TSG evaluator system 310 uses fifth generative AI model 324 to process each TSG to determine whether each step maintains a predefined level of generality to ensure that an individual step can be independently  applied to solve specific sub-problems by avoiding content that is too specific to a TSG’s overly specific case. For example, TSG evaluator system 310 compares each step of the TSG with examples of TSGs with a consistent level of generality and TSGs without consistent levels of generality. In this example, fifth generative AI model 324 flags steps that do not maintain the predefined level of generality based on its TSG training data and provides an example of steps with a consistent level of generality using its TSG training data. This allows for better adaptability across various troubleshooting scenarios and incidents.

[0061] In some implementations, TSG evaluator system 310 uses fifth generative AI model 324 to process the TSG and to prioritize the issues found in the above evaluation that are most critical based on the impact on incident diagnosing, mitigation, and / or resolution steps. For example, TSG evaluator system 310 processes the identified or flagged issues described above with examples of TSGs with labeled priorities for each issue. In this example, fifth generative AI model 324 generates a ranking of issues (e.g., from most critical to least critical) based on its TSG training data..

[0062] In some implementations and after TSG reformulation, a TSG is structured in a markdown format and includes the below sections with each section defined in a header:

[0063] ● Background that describes the background of the TSG.

[0064] ● Terminology that includes the important terms used in the TSG.

[0065] ● Frequently Asked Questions (FAQ) that define the most asked questions about the incident.

[0066] ● Steps that describe diagnosing, mitigating, and / or resolving an incident.

[0067] ● Appendix that provides additional information or clarification for a particular incident.

[0068] In some implementations, the “steps” section includes the steps of incident mitigation, where each step follows the below format:

[0069] ● Title filed that describes what the step is doing.

[0070] ● Intent field that describes the intention of this step. If there is no further detailed intention description, it is left blank, and it will be filled by the title field.

[0071] ● Action field that describes the content to troubleshoot the incident or provides an explanation of the intent field. In some implementations, the action field contains code blocks in markdown format, and placeholders for parameters.

[0072] ● Output field that is defined in the following format: if a condition is met (e.g., “condition” ) , then the described action is performed (e.g., “should_do” ) .

[0073] In some implementations, incident diagnosing process 10 (using parsing and enhancing system 312) obtains a reformulated TSG as an input and extracts candidate structured TSG nodes from the TSG (i.e., by converting each section into a corresponding node (e.g., generating a background TSG node from a background section, generating a step TSG node from a step section for a particular step) ) .

[0074] In addition to TSGs, historical incidents serve as a robust data source for the parsing and enhancing system 312 by enriching the content of structured TSG node database 332. For example, parsing and enhancing system 312 provides relevant historical incidents from TSG node database 332 when obtaining 102 a candidate TSG node as supplemental context to the candidate TSG node (s) for generating incident action recommendations. In this manner, incident diagnosing process 10 leverages insights from historical incidents to enhances the overall comprehensiveness of the knowledge base when generating incident action recommendations using a generative AI model as described above.

[0075] System Overview:

[0076] Referring to FIG. 5, an incident diagnosing process 10 is shown to reside on and is executed by storage system 500, which is connected to network 502 (e.g., the Internet or a local area network) . Examples of storage system 500 include: a  Network Attached Storage (NAS) system, a Storage Area Network (SAN) , a personal computer with a memory system, a server computer with a memory system, and a cloud-based device with a memory system. A SAN includes one or more of a personal computer, a server computer, a series of server computers, a minicomputer, a mainframe computer, a RAID device, and a NAS system.

[0077] The various components of storage system 500 execute one or more operating systems, examples of which include:  Red  Mobile, Chrome OS, Blackberry OS, Fire OS, or a custom operating system (Microsoft and Windows are registered trademarks of Microsoft Corporation in the United States, other countries or both; Mac and OS X are registered trademarks of Apple Inc. in the United States, other countries or both; Red Hat is a registered trademark of Red Hat Corporation in the United States, other countries or both; and Linux is a registered trademark of Linus Torvalds in the United States, other countries or both) .

[0078] The instruction sets and subroutines of incident diagnosing process 10, which are stored on storage device 504 included within storage system 500, are executed by one or more processors (not shown) and one or more memory architectures (not shown) included within storage system 500. Storage device 504 may include: a hard disk drive; an optical drive; a RAID device; a random-access memory (RAM) ; a read-only memory (ROM) ; and all forms of flash memory storage devices. Additionally or alternatively, some portions of the instruction sets and subroutines of incident diagnosing process 10 are stored on storage devices (and / or executed by processors and memory architectures) that are external to storage system 500.

[0079] In some implementations, network 502 is connected to one or more secondary networks (e.g., network 506) , examples of which include: a local area network; a wide area network; or an intranet.

[0080] Various input  / output (IO) requests (e.g., IO request 508) are sent from  client applications 510, 512, 514, 516 to storage system 500. Examples of IO request 508 include data write requests (e.g., a request that content be written to storage system 500) and data read requests (e.g., a request that content be read from storage system 500) .

[0081] The instruction sets and subroutines of client applications 510, 512, 514, 516, which may be stored on storage devices 518, 520, 522, 524 (respectively) coupled to client electronic devices 526, 528, 530, 532 (respectively) , may be executed by one or more processors (not shown) and one or more memory architectures (not shown) incorporated into client electronic devices 526, 528, 530, 532 (respectively) . Storage devices 518, 520, 522, 524 may include: hard disk drives; tape drives; optical drives; RAID devices; random access memories (RAM) ; read-only memories (ROM) , and all forms of flash memory storage devices. Examples of client electronic devices 526, 528, 530, 532 include personal computer 526, laptop computer 528, smartphone 530, laptop computer 532, a server (not shown) , a data-enabled, and a dedicated network device (not shown) . Client electronic devices 526, 528, 530, 532 each execute an operating system.

[0082] Users 534, 536, 538, 540 may access storage system 500 directly through network 502 or through secondary network 506. Further, storage system 500 may be connected to network 502 through secondary network 506, as illustrated with link line 542.

[0083] The various client electronic devices may be directly or indirectly coupled to network 502 (or network 506) . For example, personal computer 526 is shown directly coupled to network 502 via a hardwired network connection. Further, laptop computer 532 is shown directly coupled to network 506 via a hardwired network connection. Laptop computer 528 is shown wirelessly coupled to network 502 via wireless communication channel 544 established between laptop computer 528 and wireless access point (e.g., WAP) 546, which is shown directly coupled to network 502. WAP 546 may be, for example, an IEEE 802.11a, 802.11b, 802.11g, 802.11n,  and / or device that is capable of establishing a wireless communication channel 544 between laptop computer 528 and WAP 546. Smartphone 530 is shown wirelessly coupled to network 502 via wireless communication channel 548 established between smartphone 530 and cellular network  / bridge 550, which is shown directly coupled to network 502.

[0084] General:

[0085] As will be appreciated by one skilled in the art, the present disclosure may be embodied as a method, a system, or a computer program product. Accordingly, the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc. ) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit, ” “module” or “system. ” Furthermore, the present disclosure may take the form of a computer program product on a computer-usable storage medium having computer-usable program code embodied in the medium.

[0086] Any suitable computer usable or computer readable medium may be used. The computer-usable or computer-readable medium may be, for example an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium. More specific examples (a non-exhaustive list) of the computer-readable medium may include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM) , a read-only memory (ROM) , an erasable programmable read-only memory (EPROM or Flash memory) , an optical fiber, a portable compact disc read-only memory (CD-ROM) , an optical storage device, a transmission media such as those supporting the Internet or an intranet, or a magnetic storage device. The computer-usable or computer-readable medium may also be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, via, for instance, optical scanning of the paper or other medium, then compiled, interpreted, or otherwise processed in a suitable manner, if  necessary, and then stored in a computer memory. In the context of this document, a computer-usable or computer-readable medium may be any medium that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The computer-usable medium may include a propagated data signal with the computer-usable program code embodied therewith, either in baseband or as part of a carrier wave. The computer usable program code may be transmitted using any appropriate medium, including the Internet, wireline, optical fiber cable, RF, etc.

[0087] Computer program code for carrying out operations of the present disclosure may be written in an object-oriented programming language. However, the computer program code for carrying out operations of the present disclosure may also be written in conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user’s computer, partly on the user’s computer, as a stand-alone software package, partly on the user’s computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user’s computer through a local area network  / a wide area network  / the Internet.

[0088] The present disclosure is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, may be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general-purpose computer  / special purpose computer  / other programmable data processing apparatus, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart  and / or block diagram block or blocks.

[0089] These computer program instructions may also be stored in a computer-readable memory that may direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function / act specified in the flowchart and / or block diagram block or blocks.

[0090] The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0091] The flowcharts and block diagrams in the figures may illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function (s) . It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, not at all, or in any combination with any other flowcharts depending upon the functionality involved. It will also be noted that each block of the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, may be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

[0092] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. As used herein, the singular forms “a” , “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and / or “comprising, ” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0093] The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the present disclosure has been presented for purposes of illustration and description but is not intended to be exhaustive or limited to the disclosure in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the disclosure. The embodiment was chosen and described in order to best explain the principles of the disclosure and the practical application, and to enable others of ordinary skill in the art to understand the disclosure for various embodiments with various modifications as are suited to the particular use contemplated.

[0094] A number of implementations have been described. Having thus described the disclosure of the present application in detail and by reference to embodiments thereof, it will be apparent that modifications and variations are possible without departing from the scope of the disclosure defined in the appended claims.

Claims

1.A computer-implemented method, executed on a computing device, comprising:determining an incident request intent associated with an incident request by processing the incident request using a generative artificial intelligence (AI) model;obtaining a candidate structured troubleshooting guide node from a database of structured troubleshooting guide nodes by processing the incident request intent using the generative AI model; andgenerating an incident action recommendation by processing the candidate troubleshooting guide and the incident request intent using the generative AI model.2.The computer-implemented method of claim 1, further comprising:verifying the incident action recommendation using the generative AI model.3.The computer-implemented method of claim 2, further comprising:performing the incident action recommendation by:dividing the incident action recommendation into a plurality of sub-actions, anditeratively executing the plurality of discrete sub-actions.4.The computer-implemented method of claim 1, further comprising:converting an unstructured troubleshooting guide into the structured troubleshooting guide node.5.The computer-implemented method of claim 1, further comprising:evaluating an unstructured troubleshooting guide using the generative AI model.6.The computer-implemented method of claim 1, wherein obtaining the candidate structured troubleshooting guide node includes:obtaining a first candidate structured troubleshooting guide node from a first incident triaging group; andobtaining a second candidate structured troubleshooting guide node from a second incident triaging group.7.The computer-implemented method of claim 6, wherein generating the incident action recommendation includes linking the first candidate structured troubleshooting guide node and the second candidate structured troubleshooting guide node.8.A computing system comprising:a processor; anda memory storing computer-readable instructions, which, when executed, cause the system to perform operations comprising:determine an incident request intent associated with an incident request by processing the incident request using a first generative artificial intelligence (AI) model,obtain a candidate structured troubleshooting guide node from a database of structured troubleshooting guide nodes by processing the incident request intent using a second generative AI model,generate an incident action recommendation by processing the candidate troubleshooting guide and the incident request intent using a third generative AI model,verify the incident action recommendation using a fourth generative AI model, andautomatically perform the incident action recommendation.9.The computing system of claim 8, wherein the operations further comprise:convert an unstructured troubleshooting guide into the structured troubleshooting guide node.10.The computing system of claim 9, wherein the operations further comprise:evaluate an unstructured troubleshooting guide using a fifth generative AI model.11.The computing system of claim 8, wherein determining the incident request intent associated with the incident request includes providing a request for clarification in response to the incident request using the first generative AI model.12.The computing system of claim 8, wherein obtaining the candidate structured troubleshooting guide node includes:obtaining a first candidate structured troubleshooting guide node from a first incident triaging group; andobtaining a second candidate structured troubleshooting guide node from a second incident triaging group.13.The computing system of claim 12, wherein generating the incident action recommendation includes linking the first candidate structured troubleshooting guide node and the second candidate structured troubleshooting guide node.14.The computing system of claim 8, wherein automatically performing the incident action recommendation includes:dividing the incident action recommendation into a plurality of sub-actions, anditeratively executing the plurality of sub-actions.15.A computer program product residing on a computer readable medium having a plurality of instructions stored thereon which, when executed by a processor, cause the processor to perform operations comprising:converting an unstructured troubleshooting guide into the structured troubleshooting guide node;determining an incident request intent associated with an incident request by processing the incident request using a generative artificial intelligence (AI) model;obtaining a candidate structured troubleshooting guide node from a database of structured troubleshooting guide nodes by processing the incident request intent using the generative AI model;generating an incident action recommendation by processing the candidate troubleshooting guide and the incident request intent using the generative AI model;verifying the incident action recommendation using the generative AI model; andautomatically performing the incident action recommendation.

Images