ITIL V3 Incident Definition: Camels and Committees
ITIL defines an incident to be an impact on service or a failure of a CI that might impact service. I think that is clumsy. An incident is an impact on service. Period. A failure of a CI is something else.
In a comment, Aale Roos reminded us that ITIL V3 defines an Incident as
An unplanned interruption to an IT service or reduction in the quality of an IT service. Failure of a configuration item that has not yet impacted service is also an incident, for example failure of one disk from a mirror set.
Talk about camels and committees. ITIL V2 didn't have that second part about broken CIs. "Failure of a configuration item that has not yet impacted service is also an incident". No it isn't. It's a Fault (or some other name).
As Aale also reminded us, Incident Management is now defined as
Incident Management is the process for dealing with all incidents; this can include failures, questions or queries reported by the users (usually via a telephone call to the Service Desk), by technical staff, or automatically detected and reported by event monitoring tools.
No it isn't. They have thoroughly muddied the definition to include a wide variety of requests. Incident Management is the process of restoring normal service operation as quickly as possible and minimising the adverse impact on business operations, just as the very next paragraph (Service Operation 4.2.1) defines it. All that other crap is more general Request Management, including Faults. Most event monitoring tools inform us of Faults. Only the really smart ones know if a service has been impacted or not, unless the event is the detection of a service level target violation by an end-user-experience monitoring tool.
This isn't a camel - I'm not sure it is still a quadruped. Let Incident Management focus on what it is there for, restoration, and leave all the clutter out.
Thanks Aale for drawing our attention to that - I had missed the V3 bastardisation. (I don't agree with Aale that the authors didn't know V2. I just think there were too many cooks spoiling the camel ...er... whatever).
Recently in a comment I published my (humorous) list of classes/types of Requests. I realise now I didn't have "Fault".
Certainly, failure of a CI is something that must be responded to, but if it hasn't impacted a service yet it isn't an Incident.
Actually it is a Problem. If we are lucky enough to have found a busted CI without some Incident drawing our attention to it, then arguably we could just go ahead and open a Problem ticket and be done with it.
But sites might want all Requests/Tickets/Issues/Incoming to go through the same initial recording/gating process before spawning a Problem, in which case it is a new type of request, a Fault. So I will post a new list of Request types. I will give it a thread of its own.