Issue resolution utilizing feature mapping

A method for providing a resolution to an open issue is described. The method includes utilizing structured corresponding learning to determine pivots from a database having historical data records to determine data records having similar open issues and providing their resolution. The method further includes providing a recommended resolution for the open issue based on the historical data records.

BACKGROUND

The present invention relates in general to computer systems, and more specifically to systems, method and computer program products for resolving issues that arise in connection with computer systems.

Issues regarding the operation of computer systems are constantly developing. Such issues may be with respect to general queries that require an answer or tickets reflecting conditions that require attention by the system or system administrator in order to address the issue.

SUMMARY

In accordance with one or more embodiments, a computer-implemented method for providing a resolution includes providing, using a processing system, an original request having a criteria and requiring resolution. A database having a plurality of request records is accessed using the processing system. Each request record includes a request component and a resolution component. The processing system separates the database into a source domain and a target domain, the source domain comprising request records created prior to a predetermined time period, the target domain comprising request records created after the predetermined time period. The processing system analyzes the request records of the source domain and target domain to establish a combined request domain including data records having related requests and resolutions. The analysis includes utilizing structured correspondence learning to define pivots which are utilized to determine data records having related requests and resolutions. The processing system analyzes the original request and compares the original request to data records of the combined request domain to determine similar data records and related resolutions. A resolution is recommended for resolving the request of the original ticket.

In one or more embodiments of the invention, a system for providing a resolution for a computer system ticket includes a memory and a processing system communicatively coupled to the memory. The memory is configured to store a plurality of ticket records each having a symptom component and a resolution component. The processing system is configured to divide the ticket records into a source domain and a target domain, and wherein the processing system utilizes structural correspondence learning to identify pivots associated with the ticket records for determining related ticket records based on either the symptom or resolution component and associating the related tickets in a common ticket database. The processing system is also configured to analyze an original ticket record having a symptom and recommend a resolution based on a comparison with ticket records included in the common ticket database wherein a ticket record in the common ticket database has a symptom related to the symptom of the original ticket record and the recommended resolution is the resolution component of the ticket record in the common ticket database.

In accordance with one or more embodiments, a computer program product for providing a resolution for a ticket is provided. The computer program product comprises a computer readable storage medium having program instructions embodied therewith, wherein the computer readable storage medium is not a transitory signal per se, the program instructions readable by a processing circuit to cause the processing circuit to perform a method. The method includes providing, using a processing circuit, an original ticket having a symptom requiring resolution. A historical ticket database having a plurality of ticket each including a symptom component and a resolution component is accessed using a processing circuit. The processing circuit separates the database into a source domain and a target domain, the source domain comprising ticket records created prior to a predetermined time period, the target domain comprising ticket records created after the predetermined time period. The processing circuit analyzes the ticket records of the source domain and target domain to establish a combined request domain including ticket records having related symptoms and resolutions, the analysis including utilizing structured corresponding learning to define pivots which are utilized to determine ticket records having related requests and resolutions. The processing circuit analyzes the original ticket and compares the original ticket to ticket records of the combined request domain to determine similar ticket records and related resolutions; and a resolution recommendation is provided for resolving the request of the original ticket.

DETAILED DESCRIPTION

One or more embodiments of the present invention present an issue resolution system which utilizes historical data records for providing resolution of a newly created original issue. Embodiments of the invention allow for a system to utilize historical records which may not be semantically equivalent but relate to the same subject matter. Embodiments of the invention further allow the system to utilize corresponding historical resolutions to resolve more recent issues.

In particular, embodiments of the invention are directed to resolving outstanding tickets related to the operation of a computer system or program. IT service providers have rapidly introduced automation to their service delivery model. Reduction of cost and quality of service has required that outstanding tickets be resolved through automated service delivery. This is largely achieved through service providing facilities integrated with system management tools in combination with automation of routine maintenance procedures such as problem detection, determination and resolution for the service infrastructure. Automatic problem detection is typically realized by system monitoring software such as IBM Tivoli Monitoring Software. Monitoring continuously captures the events and generates incident tickets when alerts are raised. Deployment of monitoring solutions is a first step towards fully automated delivery of a service.

In an automated service infrastructure monitoring system event tickets are generated. The typical workflow of problem detection, determination, and resolution in services infrastructure management is prescribed by the Information Technology Infrastructure Library specification. Problem detection is usually provided by monitoring software, which computes metrics for hardware and software performance at regular intervals. The metrics are then matched against acceptable thresholds. A violation induces an alert. If the violation persists beyond a specified period, the monitor emits an event. Events from the entre service infrastructure are accumulated in an enterprise console that uses rule or knowledge based engines to analyze the monitoring events and decide whether to open an incident ticket in the ticketing system. The incident tickets created from the monitoring events are called monitoring tickets. Additional tickets are created upon customer request through a so-called “service management system.” The information accumulated in the ticket is used by technical support for problem determination and resolution. Embodiments of the invention are directed to tickets generated by the monitoring system. Additionally, embodiments of the invention may be utilized to resolve open issues of any type.

Each monitoring ticket is stored as a database record that consists of several related attributes with values describing the system status at the time when the monitoring event was generated. For example, a CPU-related ticket usually contains the CPU utilization and paging utilization information. A capacity related ticket usually contains the disk naiad the size of disk used/free pace. Typically, different types of monitoring events have different sets of related attributes. The resolution of every ticket is stored as a textual description of steps taken by the system administrator for resolution.

As system operations typically involve consistent operations, tickets generated with common resolutions frequently occur. A dilemma arises in service environments which utilize massive heterogeneous applications, as well as various monitoring software running on customers' servers to accomplish complex tasks and to monitor system health via different metrics, as over time correlated tickets are generated that have different symptom descriptions but similar resolutions. This arises as services are upgraded, environments change and different vocabularies are utilized in generating the tickets. Accordingly, the historical records may not be semantically equivalent to more current data records while being relevant in providing historical resolutions which may be relevant to the symptom of the current original ticket being issued.

Embodiments of the invention develop mappings between resolutions and initial tickets notwithstanding that the tickets may be created utilizing different vocabularies over time. The embodiments utilize structural correspondence learning (SCL). An example of utilizing SCL involves utilizing a dataset of historical tickets which is utilized for determining an appropriate resolution for an incoming event or ticket. While resolutions for the same root cause may slightly differ, due to system enhancements and such, descriptions of the symptoms which caused the creation of the ticket could vary significantly. For example, two tickets have the same resolution as “archive the logs and thus reduce the space utilization,” but their descriptions could be different when diverse vocabularies are used, such as “volume,” “capacity” or “harddiskvolume”. While “volume,” “capacity” and “harddiskvolume” are literally distinct, they have high correlation with “space” or “utilization” in the historical data set enabling construction of mapping between them and recommending similar resolutions for incoming events represented by different vocabulary.

The mapping is constructed utilizing various steps. Initially, the ticket database is divided into two or more distinct domains based on predetermined time windows. Source tickets are defined as the tickets from the first time window and target domain tickets are the tickets from the second time window. The structured corresponding learning first identifies a set of m pivot features that occur frequently in both domains. Next, the structured corresponding learning models the correlation between the pivot features and all other features by training pivot predictors t predict the occurrences of each pivot feature in all ticket datasets from both domains. The coefficients of the l-th pivot feature; positive coefficients indicate that a non-pivot feature is highly correlated with the corresponding pivot feature. The coefficients of each pivot predicator is considered as a column vector. All predictors are arranged into a matrix W=[wl]nl=1where wlis the lth column coefficient vector and n is the number of pivot features. θ∈Rhxdis set to be the top h left singular vectors of W, i.e.
[UDVT]=SVD(W),θ=UT[1:h,:]

These vectors are the principal predictors for the coefficient space and establishing pivots. Establishing pivots is essential for SCL to operate properly. The invention identifies pivot features which identify appropriate resolutions for the tickets. Identifying pivot features utilizes the calculation of term frequency-inverse document frequency (TD-IDF) scores for all words out of ticket symptom description in both time domains and choose a thousand words having the highest TF-IDF scores for each domain. After the TF-IDF scores are calculated, the m most frequently occurring words out of the two sets of a thousand words are chosen. This approach provides strong indicators of “symptoms” or “system issues requiring resolution”. The next step requires determining pivot features from ticket resolutions. An example of identifying pivot features is shown in the following table:

SymptomResolutionApp space job high restoreIncident close copy resolve server foundstatus error procedures failissue action team job clear close file

The pivot features chosen from the symptom strongly describes the ticket symptom observed on the server system. The pivot features chosen by resolution describe the ticket resolution, i.e., how to resolve issues on the server system. From each pivot feature a determination is made if a particular pivot feature occurs in the ticket requiring to be resolved utilizing m linear predicators. A linear regression model with l2regularization as the underlying classification model:
fl(x)=sgn(wl·x),l=1, . . . ,n

The following table summarizes the details the construction of predicators given by the prior equation:

Sign (.)Does pivot feature 1 occur in the resolution of this ticketPivot featureThe m most frequently occurring words shared in the twodomains of 100 words having the top T-IDF scores inticket resolutions in both domainsX1000 words having the highest TF-IDF scores fromsymptom descriptionTraining dataAll tickets attached with resolution from both domains

Pivot predicators are very important when utilizing Structured Corresponding Learning. The weight vectors wlencode the covariance of the no-pivot features with the pivot features. If the weight given to the z-th feature of the l-th pivot predicator is positive, then the feature z is positively correlated with pivot feature l. Since pivot features strongly indicate resolution, non-pivot features from both domains will also be correlated with them. If two non-pivot features are correlated in the same way with many of the same pivot features, then there is a high degree of correspondence.

Embodiments of the invention utilizing structural correspondence learning and pivots were tested on various ticket domains and respective resolutions. A project matrix θ was established identifying respective words which could be pivots. The following table illustrates the first row of θ. The features on each row appear only in the corresponding domain. The features indicate event tickets caused by the same or similar root cause and thus share similar resolution.

From the table, certain correspondence feature groups appear. Notation “s” corresponds to features coming from the source domain, and “t” corresponds to features coming from the target domain. The + and − symbols indicate positive and negative features in correspondences. Certain correspondence groups were identifiable. For example sdump, page, harddiskvolume, paging, traps” indicate system issues in or similar to paging due to low capacity. Sdump is an executable command that tries to dump virtual storage and thus makes space for paging. Without feature mapping, tickets will be considered having low or no similarity if they contain discriminant features. With feature mapping, discriminant features can be projected to shared feature space by applying them to θx. The features will ensure that their corresponding even tickets have higher similarity. Applying structural correspondence language to both the source and target labeled tickets enables resolution recommendations to be applied.

Referring toFIG. 1, computer system100includes processors112which may include servers. The processors or servers operate to perform various operational processes or functions. From the operation if certain performance issues develop a manual ticket114may be generated. Additionally, the system may include an autonomous operational monitoring system116which monitors the various operational functions of the system and generate tickets if certain performance issues develop. Additionally, monitoring system may be utilized to monitor incoming activities such as a query and generate a corresponding action request to solve the query. In the illustration as shown, an incoming ticket118is generated in response to operation of the processor or servers112which requires resolution. To provide a resolution, system100includes a historical ticket database120. Historical ticket database includes a plurality of pre-existing ticket records which include an original symptom component and a resolution component. The ticket records are evaluated and some may be removed for various reasons such as being an erroneous ticket or the like. The remaining ticket records are stored in a refined ticket database122. A recommendation engine124is utilized for applying the structural correspondence learning processing with the tickets and developing the corresponding pivots for ascertaining the relevant tickets and corresponding resolutions. From the recommendation engine, the appropriate resolution is recommended to a user utilizing a web user interface126, or the system automatically performs the required resolution.

Referring toFIG. 2, a method for recommending a ticket resolution is disclosed. At block200, the respective historical tickets and their corresponding resolutions are identified. At block210, an incoming ticket without a resolution is produced. At block220, a common domain utilizing structural correspondence learning and pivots is established. At block230, the symptom of the incoming ticket is compared to the historical tickets created at block220. From the comparison step at block230, those historical tickets which appear the most closely related to the incoming ticket are identified and at block260the corresponding resolutions are identified. The most relevant resolutions are recommended at block280either automatically by the system or to a system operator.

Referring toFIG. 3, the development of the combined domain of historical tickets and resolutions is illustrated. Initially at step300, the historical ticket database is accessed. The historical ticket database includes prior ticket records which include their symptom or issue and related resolution. With the advent of system upgrades and other changes, the various semantic of the symptoms or resolution may evolve. To identify tickets and resolutions which are equivalent but semantically changed due to the passage of time the historical ticket database is split into separate domains. The first domain is the source domain and the second domain is the target domain. The bifurcation is conducted utilizing respective timeframes. Of course the domains may be split into multiple domains providing different reference points. For each source domain structural correspondence learning is utilized to develop pivots for both the respective symptoms or issues and resolutions. By utilizing pivots for both components, a larger universe of related tickets is identified as the resolutions may apply to different unrelated symptoms. Concurrently with the development of pivots in the source domains, pivots are developed in the target domain for both the symptoms and resolutions. The target domain consists of the most current tickets and resolution which should correspond closer to the newly created original ticket. To extend the historical coverage of tickets of the target domain, the pivots of the source domain with respect to both the symptoms and resolutions are compared with the pivots of the target domain. From this comparison older tickets which correspond to the newer tickets are combined to create the combined domain. In essence, the target domain is utilized as a bridge to establish the relevancy of older tickets and their corresponding resolutions to the newer nomenclature utilized in the newly created ticket by utilizing the presumed newer nomenclature of the target domain as a Rosetta stone for establishing the relevancy of the older tickets in possibly providing solutions to the newly generated ticket. With the establishment of the combined domain, the symptom of the new ticket is compared to the symptoms of the historical tickets in steps230and240ofFIG. 2.

Thus, as configured inFIG. 4, the computer system100includes processing capability in the form of processors101, storage capability including the system memory114and mass storage104, input means such as keyboard109and mouse110, and output capability including speaker111and display115. In one or more embodiments, a portion of system memory114and mass storage104collectively store an operating system to coordinate the functions of the various components shown inFIG. 4.