Trouble Ticket Automation
Publication Date: 2010-Dec-13
The IP.com Prior Art Database
The ability to open trouble tickets to the right support group and quickly change this configuration with no need of programming or system restart can be essential for who receives a lot of monitoring events and can avoid Service Level Agreement (SLA) loss. This article describes the algorithm used to map monitoring events to trouble ticket queue, severity and classification using generic rules that allow this reconfiguration and the mechanism to monitor thetrouble ticket flow, analysing which queue closed that kind of monitoring event in order to have the ability to reconfigure it automatically.
Page 01 of 7
Trouble Ticket Automation
Disclosed is a process for generating generic rules to direct all events for a specific class to one queue, except for some servers that are directed to different queues. The disclosed process further provides an ability to open a ticket in different tools using event mapping in a Perl script calling a shell script to open the trouble ticket for each customer, independent of which trouble ticketing tool the customer has, enabling the event mapping to be done the same way for all customers.
The disclosed process further provides an analysis algorithm for monitoring log data generated by the automated system operation, to determine which types of tickets are taking more steps to reach the right queue, or cycling between queues before getting resolved. The analysis algorithm of the disclosed process identifies situations and associates the situations with specific types of
roblems. For each type of problem and severity, there are patterns of "useless" queue cycles or bounces, that can be avoided once operators are alerted to a problem they have must be resolved by them or, in some cases, the system can open the ticket and place the ticket in the correct queue directly, skipping several analysis steps (first level, for example) and saving time, since the system is learning in which queue a problem is actually resolved.
In one example a commercially available customer event management centralized environment using Tivoli Enterprise Console®1 (TEC) as a concentrator for all events associated with trouble tickets open for customers was overloaded with too many trouble tickets for different customers affecting the performance of TEC server and delaying the trouble ticket opening. This overload may cause a loss of Service Level Agreement (SLA). In addition there was a problem associated with determining the opening of the trouble tickets automatically to the correct queue. Too many manual interventions from operators consulting procedures and some operator mistakes also caused trouble tickets to flow to wrong queues consuming time from support groups in rerouting the trouble tickets to the correct queues.
In the example prior to the implementation of the disclosed process system issues included human error sending tickets to wrong queues, trouble tickets bouncing from one queue to another, back and forth, opening of a trouble ticket was dependent on operators acknowledging a TEC event and loss of SLA due to time lost in wrong queues or in operators actions.
The disclosed process automates the process of trouble tickets opening by mapping the events, servers and specific monitoring information to the correct trouble ticket tool, queue and severity. Automatic trouble ticket creation is implemented for selected tools.
The disclosed process also enables event analysis to map the major incidents by customer, server and category reducing the number of trouble tickets and tuning the monitoring process.
Page 02 of 7...