Posted: Wed Apr 30, 2008 1:15 am Post subject: How to close a problem ticket that is used only to find RC

Hi,

How can a Problem ticket be closed if it was opened only to find the Root cause.Assume that the end result of the problem ticket is not any of the following -RFC Submitted/Completed/Denied.
For example- a CPU spikes drastically- and then a problem ticket is opened for the investigation.On analysis it was found that a sudden surge in the no of sessions creates this load.
In such a case how do i close the problem ticket.

ANother question
Can a problem ticket be closed if the error is known and accepted?.

What is your conclusion regarding the surge in sessions? Is it something that has to be catered for? Should you place limits? Should you increase capacity or have standby capacity? Should you schedule work patterns? Why did it happen? Will it become more frequent? Should you set up periodic reviews? Increased monitoring?

The answers to questions like these define the closure.

As for your second question: an error/bug/flaw/defect is not a problem if you decide it is not a problem. That means extrapolating the consequences, risks and impacts, and deciding they are not important. However, it is difficult to come to this decision if incidents are still being caused since incidents mean costs. It is also difficult to do if your customer(s) do not fully understand the situation and are not 110% in agreement._________________"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718

The CPU spikes.
An Incident ticket gets open
The incidentg ticket gets completed or resolved
The incident is recommended to the PM team for an Problem ticket
because it meets the criteria for a problem
The pM team has tro either accept or decline to make it a problem

Let us assume that PM team acknowledges this as a Probelm Ticket.
On Analysis- it was found that since it was quarter end- the load on the CPU spiked .
If this is the case- how should the problem ticket be closed.

Can an Problem ticket be closed without rectifying the Know Error.The aim of the PM is to resolve incidents from Reoccuring-i.e its goal is to resolve the know Error completley(i.e resolution with other than a workaround)

you close the problem because you have determined that the incident was not harmful. You document that that spike at quarter end is normal behaviour of the system and you don't raise an incident when it happens again.

Your problem never had a known error. No error existed unless you want to say that your threshold for reporting spikes was too low. But this is all a bit of a sledgehammer. What was done to "resolve" the incident? presumably it was simply noted that the spike had gone away. Why would you go into problem analysis for a single spike that did not break a service? Why not let Capacity Management worry about it (sorry, analyse it)?

A pro-active Problem Management can pick it up if it recurs because that might suggest that there is an underlying problem._________________"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718

In some organizations it would just be the day job for the infrastructure management team that looks after servers or for the Capacity Management function; it would only reach the service desk if things got a bit serious.

In other organizations all such work goes through the service desk; this allows tracking using the same tools as for incidents etc.

In either case there will be procedures in place for commissioning, tracking and reporting.

I don't see how to answer your question (which ticket) without knowing what tickets you have and how you use them. ITIL is not designed to answer that kind of question because it is specific to your organization._________________"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718

"The objective of Problem Management is to minimize the impact of problems on the organisation. Problem Management plays an important role in the detection and providing solutions to problems (work arounds & known errors) and prevents their reoccurrence."

"A 'Problem' is the unknown cause of one or more incidents, often identified as a result of multiple similar incidents."

"A 'Known error' is an identified root cause of a Problem."

Further reading of the ITIL guidelines would say something like this:
"Update Problem Records (solved problems records if the known error is resolved)"

"A Known Error is a problem for which the root cause is understood and there is a temporary workaround or a permanent fix has been identified. Note that the implementation of the permanent fix may be some time in the future."

My conclusion from the above definition is that a fix of the known error doesn't have to be technical bug-fix or such, but it also could be recommendations.

To your last question:
Unsolved known error?
C'mon, you IT people are smart people.
For the case of CPU spike, I assume a client/server configuration.
There are many ways to resolve the spike issue like recommendation of restructuring the configuration, f.e, by enhancing the tier (e.g from 2 to 3 tiers), using virtualization, using distributed config, etc.

But referring Diarmid's post, which I fully agree, CPU spikes is normal along with the number of sessions accessing it. If it doesn't affect the service or the CPU usage is still below threshold, why bother in relation with service support? Let Capacity Management Process take care of it.