Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.
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.
Search
Languages
Select Interface Language:
Advertising
Please contact us via the feedback page to discuss advertising rates.
The Itil Community Forum: Forums
ITIL :: View topic - Child incidents for 'Potential' Major Incidents
Posted: Mon Jul 09, 2012 2:53 pm Post subject: Child incidents for 'Potential' Major Incidents
Regarding child incidents raised for major incidents. When I get a major incident which impacts or potentially impacts multiple high ranking applications I escalate the incident ticket to a major incident status as per usual.
When escalating the Major Incident ticket we have particular field we fill in under the ‘Impacted Service’ area where we name the Configuration Item (the Application/Service) that is being affected.
In this case however where we have multiple impacted/potentially impacted services and to avoid sending multiple forms of communications to the business (i.e: sending out 6 SMSs for 6 different services affected by the same issue/technical fault) we use a ‘@ Multiple Services Affected’ to stipulate the fact in the ‘Impacted Services’ field.
Now say for example a Major Incident (In my company we treat Priority 1 and 2 incidents as ‘Major Incidents’ with ‘Potential’ impacts falling generally under the P2 category) was escalated for 1 of 3 servers close to reaching a certain threshold whereby failing will cause multiple outages. The Major Incident was resolved in a timely manner and mitigated any impacts to the business.
After which I was asked to create Child incidents for the list of potentially impacted services as a result of the technical fault. My question at the time was “why are we raising child incidents for services which were never impacted or felt any degradation?” My train of thought was that we tackled the technical fault which could have ‘potentially’ impacted multiple services however that was mitigated by fixing the issue prior to impact actually being felt. Thus there should be no need for child incidents created for services which were never ‘actually’ impacted. Your thoughts?
Hope this makes sense. If it doesn’t I’m happy to clarify any part that is unclear.
Joined: Jul 05, 2012 Posts: 8 Location: St.Petersburg, Russia
Posted: Mon Jul 09, 2012 3:42 pm Post subject:
Hi Tony
Referring to the ITIL definitions an incident is an unplanned interruption to an IT service, or reduction in the quality of an IT service, or a failure of a CI that has not yet impacted an IT service.
So, according to the ITIL if there was a failure of a CI without any impact on an IT service you can create an incident. I don't see any benefit in creation of additional child incidents. If you need to see the services which might be affected by the server, then it can be found from a relation between server CI and services CIs which run on the server.
In our company we don't create incidents for the services which might be potentionally affected. If a server is down - we create an incident using the server CI. From the CMDB we can see which services run on the server.
Joined: Mar 04, 2008 Posts: 1894 Location: Helensburgh
Posted: Tue Jul 10, 2012 2:37 am Post subject:
Tony,
I'd like to raise two points.
1. If you have such a sophisticated management system that has clear definitions of what a major incident is, why does it not also stipulate what the rules are for the raising of "child" incidents? Have you established the purpose of "child" incidents within your organization. The answer to your question should lie in that purpose.
2. Just my curiosity (because this is the second or third instance I have seen on the board recently):
What kind of priority assignment method requires you to deal with all level 1 and 2 priorities as major incidents? and What are the management differences in the way you handle major incidents as against "just" incidents?
I am more used to thinking of major incidents as requiring exceptional resources and extended time frames, and high priority incidents requiring immediate attention regardless how little resource or time is required for their resolution. Obviously, a major incident is likely to be of high priority, but most high priority incidents are not likely to be major incidents in this scheme.
My second reason for asking this question is that, if it is becoming normal to use the term "major incident" in such disparate ways, then it is becoming likely that misunderstandings will abound in such fora as this when someone uses the label "major incident" without additional qualification (such as you kindly provided). Or to put it another way, is "major incident" losing its status as a quasi-technical term, that we all understand in a broadly similar way? _________________ "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
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