Prioritizing alerts in an information technology service management system

Abstract

A plurality of correlations is determined including by applying a machine learning model to a first plurality of features extracted from a plurality of information technology and operations management alerts and information technology service management reporting data. Each correlation of the plurality of correlations is between a corresponding one of the plurality of information technology and operations management alerts and at least one corresponding portion of the information technology service management reporting data. The information technology service management reporting data includes at least one urgency indicator. A prioritized list of information technology and operations management alerts is generated based at least in part on the determined plurality of correlations and the at least one urgency indicator. The prioritized list of information technology and operations management alerts is organized based at least in part on relative priorities of the alerts.

Description

BACKGROUND

[0001] Existing information technology service management (ITSM) systems utilize alerts generated by information technology and operations management (ITOM) monitoring systems when potential problems are detected. Due to the rapid growth in the volume of communications between network components, the number of ITOM alerts that can be generated during the course of normal operations can be impractical for proper resolution. In particular, a public organization can have tens of thousands of alerts generated daily, which number is practically impossible for human operators to resolve manually. To this end, solutions for automatically resolving alerts have been developed.

[0002] ITOM alerts are useful for determining that a problem has occurred, but each alert does not provide any information about the root cause of the problem (i.e., the event or misconfiguration that triggered the alert). Additionally, the same event can trigger multiple alerts. These alerts can be similar, such that each additional alert does not provide significant new information. Further, some alerts can be triggered by abnormal activity that does not otherwise indicate a root problem that needs to be fixed. As such, there can be an excessive number of low-information alerts. BRIEF DESCRIPTION OF DRAWINGS

[0003] Various embodiments of the application are disclosed in the following detailed description and in the drawings.

[0004] Figure 1 is a network diagram used to describe various disclosed embodiments.

[0005] Figure 2 is a flow diagram illustrating a method for prioritizing information technology and operations management (ITOM) alerts according to an embodiment.

[0006] Figure 3 is a flow diagram illustrating a method for data preparation according to an embodiment.

[0007] Figure 4A -B are example flow diagrams illustrating machine learning for correlating ITSM alerts with tickets and with resolution data, respectively.

[0008] Figure 5 is a schematic diagram of an alert prioritizer according to an embodiment.

[0009] Figure 6 is a flow diagram illustrating an embodiment for alert and ticket creation. DETAILED DESCRIPTION

[0010] The application can be implemented in numerous ways, including as a process; an apparatus; a system; a composition of matter; a computer program product, and / or a processor such as a processor configured to fetch and execute instructions, the instructions being stored on and / or provided by a memory coupled to the processor. In this specification, these implementations, or any other form that the application can take, can be referred to as techniques. In general, the order of the steps of disclosed processes can be altered, unless such alteration would contradict the spirit of the application. A component such as a processor or a memory described as being configured to perform a task can alternatively be implemented as an electrical circuit comprising general and / or special-purpose electronic hardware configured to perform the task. As used herein, the term 'processor' refers to one or more devices, circuits, and / or processing cores configured to process data, such as computer program instructions.

[0011] The application is herein described, by way of example only, with reference to the accompanying drawings, wherein: Figure 1 A detailed description of one or more embodiments of the application is provided below along with accompanying figures that illustrate the principles of the application. The application is described in connection with such embodiments, but the application is not limited to any embodiment. The scope of the application is limited only by the claims and the application encompasses numerous alternatives, modifications and equivalents. Numerous specific details are set forth in the following description in order to provide a thorough understanding of the application. These details are provided for the purpose of example and the application can be practiced according to the claims without some or all of these specific details. For the purpose of clarity, technical material that is known in the technical fields related to the application has not been described in detail so that the application is not unnecessarily obscured.

[0012] Some embodiments of the present disclosure generally relate to efficiently addressing alerts in an information technology service management (ITSM) system, and more particularly to prioritizing information technology and management (ITOM) alerts based on data from the ITSM system.

[0013] Figure 6is an example flowchart 600 illustrating the creation of alerts and tickets. A root cause 610 causes impacts 620-1 through 620-Q (where Q is an integer having a value of 1 or greater), any of which (or any combination thereof) causes symptoms 630-1 through 630-R (where R is an integer having a value of 1 or greater). The symptoms 630 manifest within one or more systems. A reaction to the symptoms 630 typically includes an alert 640 generated by an ITOM monitoring system. At the same time, the symptoms 630 impact the user experience, resulting in user experience and complaints 650. In response, affected users submit their complaints via an ITSM system, resulting in a ticket 660 being generated. Thus, the same root cause ultimately results in both the detection of a problem by a traditional monitoring system and the reporting of the problem within an ITSM system.

[0014] Alerts can be analyzed in order to suppress noise. This can add contextual information based on a situational awareness that provides an aggregated alert of the alerts. For example, when there is a growth in rate, the rate of web server error responses indicated in the alerts is tracked and reported. Additional and improved solutions for further prioritizing ITOM alerts and / or suppressing noise between ITSM alerts would be desirable. Thus, it would be advantageous to provide a solution that overcomes these challenges.

[0015] Certain embodiments disclosed herein include a method for prioritizing information technology and operations management (ITOM) alerts based on data from an information technology service management (ITSM) system. The method includes determining a plurality of correlations including by applying a machine learning model to a first plurality of features extracted from a plurality of ITOM alerts and ITSM report data, wherein each correlation of the plurality of correlations is between a corresponding one of the plurality of ITOM alerts and at least one corresponding portion of ITSM report data, wherein the ITSM report data includes at least one urgency indicator; and generating a prioritized list of the ITOM alerts based at least in part on the determined plurality of correlations and the at least one urgency indicator, wherein the prioritized list of the ITOM alerts is organized based at least in part on relative priorities of the ITOM alerts.

[0016] Certain embodiments disclosed herein also include a non-transitory computer- readable medium having stored thereon instructions to cause a processing circuit to perform a process comprising: determining a plurality of correlations including by applying a machine learning model to a first plurality of features extracted from a plurality of ITOM alerts and ITSM report data, wherein each correlation of the plurality of correlations is between a corresponding one of the plurality of ITOM alerts and at least one corresponding portion of ITSM report data, wherein the ITSM report data includes at least one urgency indicator; and generating a prioritized list of ITOM alerts based at least in part on the determined plurality of correlations and the at least one urgency indicator, wherein the prioritized list of ITOM alerts is organized based at least in part on relative priorities of the ITOM alerts.

[0017] Certain embodiments disclosed herein also include a system for prioritizing information technology and operations management (ITOM) alerts based on data from an information technology service management (ITSM) system. The system includes: one or more processors configured to: determine a plurality of correlations including by applying a machine learning model to a first plurality of features extracted from a plurality of ITOM alerts and ITSM report data, wherein each correlation of the plurality of correlations is between a corresponding one of the plurality of ITOM alerts and at least one corresponding portion of ITSM report data, wherein the ITSM report data includes at least one urgency indicator; and generate a prioritized list of ITOM alerts based at least in part on the determined plurality of correlations and the at least one urgency indicator, wherein the prioritized list of ITOM alerts is organized based at least in part on relative priorities of the ITOM alerts; and a memory coupled to at least one of the one or more processors and configured to provide the at least one of the one or more processors with instructions.

[0018] It is important to note that the embodiments disclosed herein are only examples of the many advantageous uses of the innovative teachings herein. In general, statements that

[0019] Various disclosed embodiments include methods and systems for prioritizing information technology and operations management (ITOM) alerts in an information technology service management (ITSM) system. The disclosed embodiments provide techniques for correlating ITSM activities with ITOM alerts and for prioritizing threats based on these correlations. Prioritization of threats can include removing redundant or otherwise low information ITOM alerts, thereby reducing noise and allowing for more efficient response to threats.

[0020] The disclosed embodiments also allow for enriching ITOM alerts with ITSM information that can be relevant to resolving the ITOM alerts. In particular, because the disclosed embodiments provide correlations between ITSM activities and ITOM alerts, information of the correlated ITSM activities can be used to enrich the ITOM alerts. The disclosed embodiments can be implemented into existing ITSM environments without impacting workflows within the environment.

[0021] In embodiments, ITSM activities are correlated with ITOM alerts (hereinafter, alerts) in order to prioritize the alerts. More specifically, portions of ITSM report data are correlated with the alerts, and a weighted causal relationship between each portion of the ITSM report data and the correlated alerts is determined. Based on the weighted causal relationships, the alerts are prioritized. The prioritization can result in, for example, an ordered list of the prioritized alerts (i.e., ordered from most likely to have a causal connection to least likely to have a causal connection). The prioritization can further include removing alerts having a weighted causal relationship below a threshold in order to suppress noise by removing irrelevant alerts.

[0022] In further embodiments, the weighted causal relationships are determined using a two-stage machine learning process, where each stage includes applying a machine learning model. Features are extracted from the results of the first stage and input to the machine learning model of the second stage. The first stage machine learning model uses input including alerts and ITSM activities in the form of tickets, resolution information, or both. The results of the first stage include pairs of alerts and corresponding correlated ITSM activities. The second stage machine learning model uses input including the correlated pairs and one or more features indicating a degree of correlation between the alerts and the ITSM activities.

[0023] Figure 1An example network diagram 100 is shown for describing various disclosed embodiments. In the example network diagram 100, user devices 120, alert generators 130-1 through 130-N (hereinafter referred to individually as an alert generator 130 and collectively as alert generators 130), information technology management system (ITSM) data sources 140-1 through 140-M (hereinafter referred to individually as an ITSM data source 140 and collectively as ITSM data sources 140), and an alert prioritizer 150 are communicatively connected via a network 110.

[0024] The network 110 can be, but is not limited to, a wireless, cellular, or wired network, a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), the Internet, the World Wide Web (WWW), similar networks, and any combination thereof.

[0025] The user devices (UDs) 120 can be, but are not limited to, personal computers, laptops, tablet computers, smart phones, wearable computing devices, or any other device capable of receiving and displaying prioritized alerts.

[0026] The alert generators 130 are configured to generate alerts indicative of ITOM problems. The alerts include data such as, but not limited to, a type of problem, a time of alert generation, a problem identifier (for known problems), an affected entity (e.g., a device or system exhibiting symptoms), a combination thereof, and the like. The alert generators 130 can include, but are not limited to, ITSM monitoring systems, systems deployed in an organization's network (i.e., systems monitored for ITSM systems, such as personal computers, servers, and the like), and the like. The alerts can be generated in response to events occurring within an environment monitored by the alert generators 130.

[0027] The ITSM data sources 140 include sources of ITSM activity data. The ITSM reporting data includes tickets, resolution data, or both. To this end, the ITSM data sources 140 can include, but are not limited to, ITSM systems (e.g., BMC Remedy, etc.), ticket repositories, or both.

[0028] Tickets can be created, for example, based on user submissions reporting problems (e.g., based on emails from users, phone calls with users, user inputs provided via web portals, and the like). Each ticket includes at least a textual description of a problem. The problem can be indicative of an event (e.g., an event that caused an alert to be generated by one of the alert generators 150).

[0029] ​Resolution data includes data related to resolution of the issue by an IT professional. Such resolution data can include, but is not limited to, identification of a root cause of the threat, a textual description of the issue, a textual description of the affected entity, a textual description of steps taken to resolve the issue (i.e., steps taken to fix the issue), a severity value indicative of a relative severity of the issue, and the like.

[0030] In some implementations, the tickets can be bundled and bound to resolution data by the alert prioritizer 150 as described herein. The bundled tickets and resolution data can be used as input to a machine learning model trained to identify correlations between ITSM activities and ITSM alerts.

[0031] The alert prioritizer 150 is configured to prioritize alerts as described herein. As noted above, it has been recognized that frequently, an alert is a result of the same root cause as a ticket or resolution data. Additionally, tickets and resolution data include additional information / indicators that can be relevant to identifying a root cause, determining how urgent a problem is, or both. More specifically, tickets and resolution data include information related to user impact that is not reflected in the alert. Thus, ITSM reporting data can be correlated with alerts, and can be used to prioritize alerts more accurately by an automated system than by prioritizing alerts based on the content of the alerts alone.

[0032] As a non-limiting example of a prioritization benefit of correlating alerts with ITSM reporting data, a root cause can be a failure that disrupts communication between a network server and its database. As a result, at least some users attempting to log into the network server fail to do so. These users failing to log in report the problem to an IT professional, and a ticket is created for the reported problem. Meanwhile, symptoms on another network server (e.g., a drop in speed of communication) trigger an alert. The IT professional resolves the problem or otherwise sees that the problem is resolved, and can create resolution data indicative of the information. By identifying a relationship between the alert and the ticket, future alerts can be prioritized more accurately from the ticket.

[0033] The alert prioritizer 150 is configured to receive or retrieve alerts and ITSM reporting data from the alert generator 130 and the ITSM data source 140, respectively, and determine correlations between the alerts and the set of ITSM reporting data. The alert prioritizer 150 can be further configured to enrich the alerts using the ITSM reporting data. The alert prioritizer 150 can also be configured to generate and send notifications related to alert priorities to, for example, the user device 120.

[0034] It should be noted that, Figure 1The alert generator 130 is illustrated for example purposes only, and other alert sources (e.g., a database storing alerts) can be utilized in addition to or instead of the alert generator 130 without departing from the scope of the disclosed embodiments.

[0035] It should also be noted that, Figure 1 The deployment of the alert prioritizer 150 illustrated in FIG. 1 is an example only, and other deployments are possible. For example, the alert prioritizer 150 can be a physical system or a virtual machine, and can be deployed in an organization's cloud or on-premises.

[0036] Figure 2 is an example flowchart 200 illustrating a method for prioritizing ITOM alerts according to an embodiment. In an embodiment, the method is performed by the alert prioritizer 150.

[0037] At S210, alerts and ITSM report data are obtained. In an example implementation, the alerts are received from an alert generator (e.g., the alert generator 130, Figure 1 ), and the ITSM report data includes tickets, resolution data, or both retrieved from an ITSM data source (e.g., the ITSM data source 140, Figure 1 ). The ITSM report data includes textual descriptions of problems experienced by users, resolutions to such problems, or a combination thereof.

[0038] At optional S220, the data obtained at S210 is prepared. In an embodiment, S220 includes cleaning text in the obtained data, bundling tickets, tethering tickets to resolution data, or a combination thereof.

[0039] Figure 3 is an example flowchart S220 illustrating a method for data preparation according to an embodiment.

[0040] At S310, text in the data is cleaned. Cleaning can include, but is not limited to, stemming, removing extra spaces, correcting misspellings, stopword removal, converting synonyms (e.g., converting "X minutes," "ever," or "long time" to just "time"). Cleaning can be based on a predetermined thesaurus, a synonym thesaurus, or both. Cleaning can result in textual descriptions of problems that include only information about the problem from a larger set of information that is likely to be used to uniquely identify the problem. To this end, cleaning removes words that are commonly used in sentence construction or otherwise do not provide information about the problem.

[0041] At S320, semantic similarity scores are determined for the tickets. Each semantic similarity score indicates a degree of similarity between two of the tickets, and can thus be used to bundle tickets based on similarity. In embodiments, S310 includes deriving a semantic similarity score for each pair of tickets using a machine learning model trained based on features derived from a historical collection of tickets.

[0042] More specifically, in embodiments, S320 includes applying a machine learning model to features extracted from the tickets. The extracted features include textual portions describing the problems, and can include but are not limited to names or other identifiers of affected entities, adjectives describing the impact of symptoms (e.g., impact on system performance such as "slow"), verbs describing activities that can be affected (e.g., "load"), combinations thereof, and the like. The machine learning model is trained using features extracted from historical tickets.

[0043] As a non-limiting example, the following textual descriptions of symptoms can represent the same symptom, and can be identified by a common feature including the name of the affected system, the use of the same adjective related to the impact on system performance, and a conceptual relationship between the adjective and a verb representing a system activity. The following problem descriptions represent the same symptom:

[0044] 1) "System is loading very slow and you can't buy anything"

[0045] 2) "System A is very slow for all team members"

[0046] 3) "Loading takes system A between 5-10 minutes"

[0047] 4) "System A loads forever".

[0048] These problem descriptions can be cleaned up as discussed above with respect to S310, resulting in the following textual descriptions from which features are extracted:

[0049] 1) "System loading slow can't buy"

[0050] 2) "System A slow team members"

[0051] 3) "System A to load time"

[0052] 4) "System A load time".

[0053] These tickets can be determined to be semantically similar via the machine learning model on the basis of the shared textual portions "System A", "slow", and ["load" + time term].

[0054] At S330, the semantic similarity scores can be weighted based on one or more other characteristics of the tickets, such as but not limited to characteristics indicated in the ticket metadata. Such characteristics can include, for example, time (i.e., tickets created close in time are more likely to be similar), impacted system(s), impacted user(s), and so on. To this end, in embodiments S330 includes determining a weight for each semantic similarity score using predetermined rules about ticket characteristics. The ticket metadata can be used to improve the accuracy of the semantic similarity determination by providing contextual information that further indicates whether the similar text does indeed represent the same issue. As a non-limiting example, identical portions of text appearing in tickets created a year apart can be weighted very low.

[0055] At S340, a final similarity score is determined based on the semantic similarity scores and the weights.

[0056] At S350, similar tickets are bundled based on the final similarity scores. In embodiments, each ticket is bundled with every other ticket that has a shared final similarity score above a threshold (i.e., if a pair of tickets has a similarity score above a threshold, the tickets of the pair are bundled together).

[0057] It has been recognized that an alert can indicate more than one possible root cause, and thus can be related to more than one type of issue that will impact a user and be reported by a user. Therefore, bundling tickets that can represent different issues or variations of the same issue allows for more accurate prioritization of alerts than tying each alert to a single ticket.

[0058] At S360, the bundled tickets are tied to the resolution data. In embodiments, a machine learning model trained like the machine learning model described with respect to S320 can be used to tie the tickets to the resolution data based on the text descriptions therein (i.e., using at least some of the same features extracted from the text descriptions). That is, common text features such as names of impacted entities, adjectives describing the impact of symptoms, and verbs describing impacted activities can be used to tie the tickets to the resolution data based on the similarity scores.

[0059] It should be noted that, Figure 3 described with respect to bundling tickets and tying bundled tickets to resolution data, some embodiments can prepare data without bundling tickets or tying tickets to resolution data.

[0060] Returning to Figure 2 At S230, features to be used for correlation are extracted. The features include, for example, ticket-related features, resolution-related features, or both. The following is described with respect to ticket-related features, but some embodiments can use resolution-related features or both.Figure 4A -B to describe example ticket correlation and resolution correlation features. In embodiments, at least some of the extracted features can be determined based on the alerts and ITSM report data. For example, the number of co-occurrences can be determined as the number of times an alert was created within a threshold time period of an ITSM report data.

[0061] At S240, a correlation is determined between the alerts and the ITSM report data. In embodiments, S240 includes using the extracted features as input to a machine learning model trained to determine a correlation between the alerts and the ITSM report data based on historical alerts and ITSM activities. The machine learning model is trained to output a degree of causality indicating a degree to which each alert is caused by each correlated portion of the ITSM report data, which in turn represents a likelihood that the alert and the correlated portion of the ITSM report data are related. The correlation can be between an alert and a ticket, between an alert and multiple tickets (e.g., a bundle of tickets), between an alert and one or more tickets bound to resolution data, or between an alert and resolution data.

[0062] Figure 4A -B are example flowcharts illustrating training of a machine learning model to determine correlations between tickets and alerts and between resolution data and alerts, respectively.

[0063] Figure 4A Training of a correlation model based on ticket correlation features is shown. In Figure 4A In the example of FIG. 4A, ticket correlation features 410 are input to a machine learning algorithm 420A in order to train a correlation model 430A. A time proximity feature 411 indicates an amount of time between generation of an alert and creation of a ticket. A no-ticket-alert probability feature 412 indicates a probability of an alert occurring without a corresponding ticket following (e.g., within a predetermined time period). A degree of inter-attribute similarity feature 413 indicates a degree of similarity between alert attributes (i.e., measurements included in the alert) and ticket attributes (e.g., a user reporting a problem for which the ticket was created, an affected entity mentioned in a problem description (such as a bug), keywords in a text description, etc.), a number of tickets, or both. A bound-to-alert unique ticket number feature 414 indicates a number of related tickets bound to an alert. Feature 414 can be determined based on, for example, a number of unique tickets in a bundle of tickets related to the alert.

[0064] Figure 4B Training of a correlation model based on ticket correlation features is shown. In Figure 4BIn particular, the resolved data correlation features 440 are inputs to the machine learning algorithm 420B in order to train the correlation model 430B. The co-occurrence feature 441 indicates the number of times the resolution and the alert occurred together (e.g., within a threshold time period). The independent occurrence rate feature 442 indicates the number of times the resolution and the alert occurred separately (e.g., within a threshold time period, one occurred and the other did not). The text similarity feature 443 indicates the degree to which the text description in the resolution matches the text description in the alert. The alert correlation number feature 444 indicates the number of resolutions that have been correlated with the alert. The concurrent active alert number feature 445 indicates the number of other alerts that were active at any time during which the alert in question was active. The problem impact feature 446 indicates the severity of the problem (e.g., indicated in the text description of the resolution) to which the resolution relates. The problem impact feature 446 can be, for example, a numerical representation of the severity (i.e., a problem with high severity can be represented as a 9 on a scale from 1 to 10).

[0065] It should be noted that, Figure 4A - separate training of machine learning models is shown for ticket and resolution data, respectively, but the machine learning models can be trained to determine correlations between alerts and combinations of ticket and resolution data without departing from the scope of the present disclosure. To this end, in example implementations, inputs from both Figure 4A and 4B may be provided to the same machine learning algorithm during training. Such an implementation can be used, for example, when tickets are tied to resolution data or otherwise used in order to improve the accuracy of the machine learning model by using features related to both tickets and resolution data.

[0066] At optional S250, the alert is enriched with data related to the respective correlated ticket of the alert. The enrichment data can include, but is not limited to, one or more portions of ITSM report data or pointers thereto, text data from one or more tickets (e.g., from a representative ticket selected from among a bundle of tickets), a severity of the correlated ITSM report data, statistical data related to the relationship between the alert and the correlated ticket, and the like. As a non-limiting example, the enrichment data for the alert can include text data indicating: “85% of the time that this alert occurred, it was followed by 10 or more tickets with a severity indicating a critical impact. Here are examples of recent tickets: LinkToTicketl, LinkToTicket2”.

[0067] At S260, a prioritized list of alerts is generated based on the determined correlations. The prioritized list of alerts includes alerts organized from highest priority to lowest priority, and can include all alerts or a subset (e.g., top 10 highest priority alerts). In embodiments, the alerts can be organized based on relative urgency indicated by the correlated portions of ITSM report data. Urgency can be based on, for example, severity of the issue represented by the ITSM report data, degree of impact on users, both, etc.

[0068] At S270, a notification is generated based on the prioritized list of alerts. The notification can include, but is not limited to, the prioritized list of alerts or a portion thereof (e.g., a predetermined number of top alerts in priority).

[0069] Figure 5 is an example schematic diagram of an alert prioritizer 130 according to embodiments. The alert prioritizer 130 includes processing circuitry 510 coupled to memory 520, storage 530, and network interface 540. In embodiments, the components of the alert prioritizer 130 can be communicatively connected via bus 550.

[0070] The processing circuitry 510 can be implemented as one or more hardware logic components and circuits. For example, and without limitation, illustrative types of hardware logic components that can be used include field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip systems (SOCs), graphics processing units (GPUs), tensor processing units (TPUs), general purpose microprocessors, microcontrollers, digital signal processors (DSPs), and the like, or any other hardware logic components that can perform calculations or other manipulations of information.

[0071] The memory 520 can be volatile (such as RAM), non-volatile (such as ROM, flash memory, etc.), or a combination of both.

[0072] In one configuration, software for implementing one or more embodiments disclosed herein can be stored in storage 530. In another configuration, the memory 520 is configured to store such software. Software shall be construed broadly to mean any type of instructions, whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise. Instructions can include code (e.g., in source code format, binary code format, executable code format, or any other suitable format of code). The instructions, when executed by the processing circuitry 510, cause the processing circuitry 510 to perform the various processes described herein.

[0073] The storage 530 can be a magnetic storage, an optical storage, and the like, and can be implemented as, for example, a flash memory or other memory technology, a CD-ROM, a Digital Versatile Disk (DVD), or any other medium that can be used to store the desired information.

[0074] The network interface 540 allows the alert prioritizer 130 to communicate with the ITSM data source 140 and the alert generator 150 for purposes such as obtaining alert and ITSM report data. Further, the network interface 540 allows the alert prioritizer 130 to communicate with the user device 120 for purposes such as sending a prioritized list of alerts, notifications, and the like.

[0075] It should be understood that the embodiments described herein are not limited to the specific architecture illustrated in FIG. 6, and that other architectures can be equally used without departing from the scope of the disclosed embodiments. Figure 5 It should be understood that the embodiments described herein are not limited to the specific architecture illustrated in FIG. 6, and that other architectures can be equally used without departing from the scope of the disclosed embodiments.

[0076] The various embodiments disclosed herein can be implemented as hardware, firmware, software, or any combination thereof. Furthermore, the software is preferably implemented as an application program tangibly embodied on a program storage

[0077] All examples and conditional language recited herein are intended to be construed to cover all processes possible that can come within the scope of the embodiments as claimed and all equivalents thereof. Additionally, it is intended that the scope of the embodiments disclosed herein include all alternatives, modifications and equivalents of the concepts disclosed herein. Furthermore, it is intended that the scope of the embodiments disclosed herein include all products made using any of the processes disclosed or suggested herein. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed by the application unless otherwise indicated herein or otherwise clearly contradicted by context.

[0078] It should be understood that any reference to an element in the singular has no limitation on the number or type of elements in the implementation. For example, a reference to an element can include one or more of the same or similar elements. Unless otherwise stated, a set of elements includes one or more elements.

[0079] As used herein, the phrase "at least one of" followed by a listing of items means that any individual item in the list can be utilized, or that any combination of two or more of the listed items can be utilized. For example, if a system is described as including "at least one of A, B, and C," the system can include A alone; B alone; C alone; 2A's; 2B's; 2C's; A and B in combination; B and C in combination; A and C in combination; A, B, and C in combination; 2A's and C in combination; A, 3B's, and 2C's in combination; and the like.

[0080] Although the above embodiments have been described in some detail for purposes of clarity, the application is not limited to the details provided. There are many alternative ways of implementing the application. The disclosed embodiments are illustrative and not restrictive.

Claims

1. A method comprising: Determining multiple correlations includes applying a machine learning model to a first plurality of features extracted from multiple information technology and operations management alerts and information technology service management report data, wherein each of the plurality of correlations lies between a corresponding one of the plurality of information technology and operations management alerts and at least one corresponding portion of the information technology service management report data, wherein the information technology service management report data includes at least one urgency indicator; as well as A priority list of information technology and operations management alarms is generated, at least in part based on a plurality of identified correlations and the at least one urgency indicator, wherein the priority list of information technology and operations management alarms is organized at least in part based on the relative priority of the information technology and operations management alarms.

2. The method of claim 1, wherein the priority list of information technology and operations management alerts is organized such that: an alert in the information technology and operations management alerts that is related to the higher urgency portion of the information technology service management report data is assigned a higher priority than another alert in the information technology and operations management alerts that is related to the lower urgency portion of the information technology service management report data.

3. The method of claim 2, wherein the at least one urgency indicator is based on at least one of the following: the severity of the corresponding IT service management problem experienced by the user; and the degree of impact of the corresponding IT service management problem on the user.

4. The method of claim 1, wherein the information technology service management report data includes multiple tickets, wherein each ticket includes a text description of the corresponding information technology service management problem experienced by the user.

5. The method of claim 4, further comprising: Bundling the plurality of tickets into at least one bundle, wherein bundling the plurality of tickets further includes determining a semantic similarity score for every two tickets among the plurality of tickets, wherein the semantic similarity score is determined by applying a machine learning model to a third plurality of features extracted from the textual descriptions of the plurality of tickets.

6. The method of claim 5, wherein the semantic similarity score is weighted based on the metadata of the plurality of tickets, and wherein the plurality of tickets are bound based on the weighted similarity score.

7. The method of claim 1, wherein the information technology service management report data includes parsing data associated with multiple parsings of a problem experienced by a user, wherein at least a portion of the parsing data associated with one of the parsings includes a text description of the one parsing.

8. The method of claim 1, further comprising: At least one first information technology and operations management alert among the plurality of information technology and operations management alerts is enriched based on the plurality of correlations, wherein the at least one first information technology and operations management alert is enriched using data from at least one correlated portion of the information technology service management report data.

9. The method of claim 1, wherein the machine learning model is trained based on a second plurality of features extracted from historical information technology and operations management alarms and historical information technology service management report data.

10. The method of claim 1, wherein each of the at least one urgency indicator is a corresponding information technology service management problem experienced by the user.

11. A system comprising: One or more processors are configured to: Determining multiple correlations includes applying a machine learning model to a first plurality of features extracted from multiple information technology and operations management alerts and information technology service management report data, wherein each of the plurality of correlations lies between a corresponding one of the plurality of information technology and operations management alerts and at least one corresponding portion of the information technology service management report data, wherein the information technology service management report data includes at least one urgency indicator; as well as A priority list of information technology and operations management alarms is generated based at least in part on a plurality of identified correlations and the at least one urgency indicator, wherein the priority list of information technology and operations management alarms is organized at least in part based on the relative priority of the information technology and operations management alarms; as well as A memory coupled to at least one of the one or more processors and configured to provide instructions to at least one of the one or more processors.

12. The system of claim 11, wherein the priority list of information technology and operations management alerts is organized such that: an alert in the information technology and operations management alerts that is related to the higher urgency portion of the information technology service management report data is assigned a higher priority than another alert in the information technology and operations management alerts that is related to the lower urgency portion of the information technology service management report data.

13. The system of claim 12, wherein the at least one urgency indicator is based on at least one of the following: the severity of the corresponding IT service management problem experienced by the user; and the degree of impact of the corresponding IT service management problem on the user.

14. The system of claim 11, wherein the information technology service management report data includes multiple tickets, wherein each ticket includes a text description of a corresponding information technology service management problem experienced by the user.

15. The system of claim 14, wherein the one or more processors are further configured to: Bundling the plurality of tickets into at least one bundle, wherein bundling the plurality of tickets further includes determining a semantic similarity score for every two tickets among the plurality of tickets, wherein the semantic similarity score is determined by applying a machine learning model to a third plurality of features extracted from the textual descriptions of the plurality of tickets.

16. The system of claim 15, wherein the semantic similarity score is weighted based on the metadata of the plurality of tickets, and wherein the plurality of tickets are bound based on the weighted similarity score.

17. The system of claim 11, wherein the information technology service management report data includes parsing data associated with multiple parsings of a problem experienced by a user, wherein at least a portion of the parsing data associated with one of the parsings includes a text description of the one parsing.

18. The system of claim 11, wherein the one or more processors are further configured to: At least one first information technology and operations management alert among the plurality of information technology and operations management alerts is enriched based on the plurality of correlations, wherein the at least one first information technology and operations management alert is enriched using data from at least one correlated portion of the information technology service management report data.

19. The system of claim 11, wherein the machine learning model has been trained based on a second plurality of features extracted from historical information technology and operations management alerts and historical information technology service management report data.

20. A computer program product embodied in a non-transient computer-readable medium and comprising computer instructions for performing the following operations: Determining multiple correlations includes applying a machine learning model to a first plurality of features extracted from multiple IT and operations management alerts and IT service management report data, wherein each of the plurality of correlations lies between a corresponding portion of one of the plurality of IT and operations management alerts and at least one corresponding portion of the IT service management report data, wherein the IT service management report data includes at least one urgency indicator; and A priority list of information technology and operations management alarms is generated, at least in part based on a plurality of identified correlations and the at least one urgency indicator, wherein the priority list of information technology and operations management alarms is organized at least in part based on the relative priority of the information technology and operations management alarms.

Images