Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: ABurchfie
New Today: 0
New Yesterday: 169
Overall: 130733

People Online:
Visitors: 129
Members: 3
Total: 132 .

Languages
Select Interface Language:


Major ITIL Portals
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

Related Resources
Service related resources
Service Level Agreement
Outsourcing

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 - Handling Incidents in performance tuning
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Handling Incidents in performance tuning

 
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion
View previous topic :: View next topic  
Author Message
ITSMCurious
Newbie
Newbie


Joined: Feb 10, 2011
Posts: 5

PostPosted: Wed Feb 16, 2011 5:31 pm    Post subject: Handling Incidents in performance tuning Reply with quote

How to apply incident management when a desktop user complains about system being slow?

While the incident engineer tries to match the incident in known error database and doesn't find a resolution, he will investigate the issue. The typically approach that is following in restoring service in such scenario by system administrators is trial and error. They will try to increase the virtual memory or swap or tune kernel parameters to resolve the issue. What is the recommended steps to be carried out in ITIL way?

- Should this go through a problem management team to find the root cause and then apply the resolution instead of trying the trial and error method of manipulating virtual memory/swap or tuning the kernel?

- Since this involves changing the CIs of the service, when do we raise the change request to accommodate this change?

- What if the performance issue specific to a user due to opening of more applications? Should it still apply to change the CIs in the desktop service, as it is specific to the user?

- If trial and error investigation should not be carried out by system administrator and problem management team should be involved, doesn't this make the process ineffective and delay. While the previous method of adhoc tuning has helped in restoring the service faster, the problem management is going to cause the delay. Also the technical skill of incident management staff is going to be wasted.

- Is it not a overhead on the way system administration staff work? They should be more knowledgeable enough to understand when to investigate in detail and when to leave it to problem management staff etc, which can bring lots of conflicts.

- While it can be easily said that the same person can be part of both incident and problem management team, the boundaries are not clearly defined and the process doesn't help in anyway to improve the situation.

Any comments and suggestions on how you have handled such situations while implementing ITIL will be more beneficial.
Back to top
View user's profile
ashuahmed
Newbie
Newbie


Joined: Feb 17, 2011
Posts: 1

PostPosted: Thu Feb 17, 2011 10:29 pm    Post subject: Reply with quote

Hi,

ITIL recommends to handle incidents in the following manner:

The service desk needs to:

1. Log the incident
2. Classify them
3. Prioritize them
4. Diagnosis
5. Resolution
6. Close

If the service desk team couldn't resolve the issue, the ticket needs to be escalated to the technical team. If the technical team also fail to resolve, it has to be raised as a problem ticket, where the root cause analysis of the issue is done. The KEDB is then updated.

Hope this makes sense.

Thanks
Ahmed
Back to top
View user's profile
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3251
Location: London, UK

PostPosted: Fri Feb 18, 2011 12:01 am    Post subject: Reply with quote

Wrong.wrong

The SD manages the incident. It may not be involved in any analysis of the incident. The SD may merely assign the incident to a resolver group to have service restored. The emphasis on service restored.

The resolving team work to restore service by solving the incident.

Once the incident is solved or service is restored,which ever comes first, then the incident is then resolved as the service impacting incident has been concluded.

The solution to the service impact may not have been found or even looked into. The IM team job is to restore service. End of story. They do what ever they need to do to restore service

Problem mgmt only comes into play if the incident record not only meets the criteria for problem but that the PM team accept it as one that they can work on to solve.

If they dont, then the reason for the incident is left open

THIS ALLSO DEPENDS ON THE SPECIFIC PROCESSES USED AND HOW THEY ARE WRITTEN AND INTEGRATED

Your post - ashuahmed - did not answer ITSM Curious' question

There is no real answer to the question beyond the following

Raise the incident
Conduct FTA (fault tree analysis) t0 break down what can be wrong
Try to eliminate things

So if a user says .. I am using 'app name' and it is slow. Ticket is raised and then you do the analysis

1 - His system characteristics - memory, CPU, O/S & patch version,
2 - his system services - what process, programs are running - background services and what applications / programs the user has activtates. Also, what programs are running in the background as part of the company build
3 - his system architecture - How is he connected to the ' network' - VPN, Wireless, Office LAN.
4 - Network Architecture - how busy is the corp net, the LAN he is on, the # of LANs and hops to the application
5 - Repeat 1 thru 4 for the application that he is using
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Sat Feb 19, 2011 3:51 am    Post subject: Reply with quote

Just to add to John's comments "wrong wrong".

Incident management is the management of everything you do to resolve an incident and therefore you never hand over an incident to problem management which is everything you do to resolve a problem.

The difference is that when an incident needs resolved, one or more people are waiting for the resolution in order to carry on with some part of their work in an effective manner and when a problem needs resolving someone is waiting an hoping that certain incidents will not recur too often before the problem is resolved and people may be performing a workaround of some inconvenience in the meantime.

Thus, in the extreme case, any of the techniques and activities normally associated with problem management may be put to work in the resolution of a stubborn incident, but that does not make it problem management.
_________________
"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
Back to top
View user's profile Send e-mail
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Sat Feb 19, 2011 4:23 am    Post subject: Reply with quote

ITSMCurious,

my comment above is also part of the answer to part of your question.

If a single desktop is "going slow" that is an incident and remains so until resolved even if the user keeps working and the investigation takes some time. The nature of the investigation is performance analysis using the kind of techniques that John outlined. This remains true if it happens to other machines as well, but the waters become murky.

It is almost certain that their would need to be a problem opened as well. In this case also the main activity is performance analysis. The difference is that the objective of the performance analysis for the incident(s) is to [immediately] improve the performance and the objective for the problem is to find the initiating or underlying cause so that steps can be taken to prevent performance declining in the future.

Don't forget that the problem resolution could be something as simple as ensuring that users changed their behaviour with their desktops or as painful as as replacing all the desktops.

It seems to me that it is only in very large organizations that it makes sense to have a full technical team separate each for the use of incident management and problem management. In smaller organizations it seems reasonable that at least some of the technical staff are at the call of incident management and problem management as needed. This should not be an issue since their role is to perform technical activities rather than to manage anything. After all, in even smaller organizations, there may be only one or two people performing all the incident and problem management and performing all the technical activities.
_________________
"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
Back to top
View user's profile Send e-mail
DaveInSeoul
Newbie
Newbie


Joined: Feb 25, 2011
Posts: 14
Location: Seoul, South Korea

PostPosted: Sat Feb 26, 2011 9:42 pm    Post subject: Reply with quote

One of the things that is missing from this discussion is any discussion of escalation procedures - which are fundamental to proper Incident Management.

To many IT service organizations I have been involved with will allow the technician to 'fiddle' with the computer far to long - no matter what the cause.

"The computer running too slow" can be caused by a lot of things, not to and including the network. If the problem is isolated to only one machine, and after xx number for minutes or hours (depending on the escalation priority), our organization will ask the user to log out. We have a script that will automatically save all of the user data to a server when he/she does that, so the user data is all stored remotely. Once the user is logged out, our technicians will re-image the disk to pristine condition. The user will log back in, and when they do that, they get all there data back. Not there is the odd chance that this does not solve the problem, but I have yet to see this process fail.

Incident management is all about restoring service to a steady state as soon as possible. The end-user should NOT be made to wait while the field tech tries to solve the problem forever. And yes, the service desk manages and monitors this process from end to end.

Dave Martin
ITIL v3 Expert
Back to top
View user's profile Send e-mail
LizGallacher
Senior Itiler


Joined: Aug 31, 2005
Posts: 550
Location: UK

PostPosted: Sun Feb 27, 2011 4:37 am    Post subject: Reply with quote

David, I think you should be careful of what you describe as a problem, and what you describe as an incident.
John DID address functional escalation when he said "The SD may merely assign the incident to a resolver group to have service restored."
Yes, I agree that there needs to be target times for how long each support level works on something before admitting it is beyond them, and passing it to the next level - however the issue you describe as "technician fiddling" is the result of the technician losing sight of the purpose of Incident management - restoring service asap. Problem investigation comes later.
"odd chance that this does not solve the problem" - again, I think you mean Incident. The Problem was the cause, which has not been addressed by the fix
"The service desk manages and monitors this process from end to end. " - This is true for the Incident process - the Service Desk does NOT monitor the Problem process
_________________
Liz Gallacher,
ITIL EXPERT
Accredited ITIL and ISO/IEC20000 Trainer and Consultant - Freelance
Back to top
View user's profile Send e-mail Visit poster's website
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Sun Feb 27, 2011 7:46 pm    Post subject: Reply with quote

Dave,

rebuilding the system is a workaround, and is a legitimate response to an incident if it is likely to recover service quicker than other approaches. However, it can have the effect of destroying the evidence needed to discover why the system was going slow and thus make problem resolution much more difficult. I'm sure there is a good chance that the system will perform better immediately after this rebuild, but how long will it be until it starts to slow down again?

At some point it becomes worthwhile to stop tolerating these incidents and do something to prevent them, i.e. investigate and resolve the underlying problem. This is likely to mean that you need to preserve an offending system (perhaps replacing it for the user), or that you have to compromise on an incident resolution on some occasions(s) to allow further investigation. Of course this latter approach will only be done with the full agreement of the customer and in circumstances of their choosing.
_________________
"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
Back to top
View user's profile Send e-mail
DaveInSeoul
Newbie
Newbie


Joined: Feb 25, 2011
Posts: 14
Location: Seoul, South Korea

PostPosted: Sun Feb 27, 2011 8:23 pm    Post subject: Reply with quote

Diarmid,

In theory I agree with you. But this assumes that you have good problem management processes in place AND the qualified staff to do proper root cause analysis.

The easiest part is to develop the problem management processes. Finding field techs that are qualified enough to learn how to do good root cause analysis. This assumes a certain level of skill qualification and salaries that go along with good problem management. When either one of those conditions is lacking, then the best you can do to keep the customer reasonablly happy is too develop good incident management procedures to get them up and running as soon as possible.
_________________
Dave Martin
ITIL v3 Expert
Ph.D (C), Information Technology
Back to top
View user's profile Send e-mail
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Sun Feb 27, 2011 8:57 pm    Post subject: Reply with quote

Dave,

good problem management is a vital part of ensuring good service delivery and is a management capability, not a technical one. Not all problems require deep technical skills and, in any event, no assumption is required about the existence of "qualified staff" since when you need a certain expertise you obtain it whether by recruiting or training, short term contract, or use of an external support organization. The model you follow depends on both cost and flexibility criteria and the scale of your organization and on the frequency with which you require that particular expertise.

If you want me to be theoretical, then I would suggest that a total dependence on reactive defence (incident management without problem management) is very dangerous and probably doomed in the long run.
_________________
"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
Back to top
View user's profile Send e-mail
BorisBear
Senior Itiler


Joined: Mar 10, 2008
Posts: 402
Location: Sunderland

PostPosted: Mon Mar 07, 2011 11:45 pm    Post subject: Reply with quote

If the 'trends' suggest that your technical staff spend too long fannying around with incidents then that's a 'problem' in itself
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion All times are GMT + 10 Hours
Page 1 of 1

 
Jump to:  
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

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.