For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone
Note: ® ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.
The Itil Community Forum: Forums
ITIL :: View topic - How to close a problem ticket that is used only to find RC
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?.
Joined: Mar 04, 2008 Posts: 1883 Location: Newcastle-under-Lyme
Posted: Wed Apr 30, 2008 3:43 am Post subject:
Hi prasadabr,
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)
Joined: Mar 04, 2008 Posts: 1883 Location: Newcastle-under-Lyme
Posted: Thu May 01, 2008 12:50 am Post subject:
prasadabr,
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
If there is a request for an analysis/Investigation - what type of ticket should be raised.
Assume that this reuqest doesnt qualify for a problem ticket( the PM is aware that this request is just for some analysis and also are sure that this is a one-off issue)
An incident ticket ccannot be open for investigation since it is tied up with SLA.
It doesnt qualify for a service Request Ticket either.
How can the service desk keep track of the this request.
Someone answer this question
Can a problem ticket be closed without solving/rectifying the know error.
Joined: Mar 04, 2008 Posts: 1883 Location: Newcastle-under-Lyme
Posted: Thu May 01, 2008 3:08 am Post subject:
prasadabr wrote:
Someone answer this question
Can a problem ticket be closed without solving/rectifying the know error.
I thought I had answered that question earlier. In brief, yes so long as you have identified the consequences and there is no longer term need (or practicality) to do anything else.
prasadabr wrote:
If there is a request for an analysis/Investigation - what type of ticket should be raised.
Assume that this reuqest doesnt qualify for a problem ticket( the PM is aware that this request is just for some analysis and also are sure that this is a one-off issue)
An incident ticket ccannot be open for investigation since it is tied up with SLA.
It doesnt qualify for a service Request Ticket either.
How can the service desk keep track of the this request.
.
Request from whom? To whom?
I need to understand your management organization structure to answer this.
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
Joined: Oct 07, 2007 Posts: 441 Location: Jakarta, INA
Posted: Thu May 01, 2008 10:13 am Post subject:
Hi prasadabr,
I quote the following definitions from ITIL Open Guide
"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.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
