become-itil-foundation-certified-abhinav-kaiser(www.ebook-dl.com)
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Chapter 7 ■ Service Operations<br />
In cases of autologged incidents, event management tools are designed to select<br />
a predetermined category that does not falter. User-raised incidents are automatically<br />
categorized based on the keywords mentioned in the incident summary and description.<br />
It is quite possible that the incident could be categorized incorrectly in this scenario, but<br />
in the interests of automation, this is the price we have to pay.<br />
7.5.2.6.4 Step 4: Incident Prioritization<br />
Earlier I discussed extensively incident prioritization. This is the step where the process of<br />
incident prioritization gets acted upon.<br />
The service desk measures the urgency and impact and sets the incident priority.<br />
Event management tools have the ability to set the right priority based on an algorithm.<br />
User-created incidents are normally assigned a default priority, and the resolver group<br />
changes the priority once it begins resolving the incident.<br />
Incident priorities are not set in stone. They can be changed throughout the lifecycle<br />
of an incident. It is possible that the end user has hyped the impact of the incident and<br />
could have gotten a higher priority incident raised. During the resolution process, the<br />
resolver group validates the impact and urgency and alters the priority as needed. Some<br />
critical incidents are monitored after resolution. The observation period could see the<br />
priority pushed down until closure.<br />
7.5.2.6.5 Step 5: Diagnosis and Investigation<br />
The service desk performs the initial diagnosis of an incident by understanding the<br />
symptoms of the incident. The service desk tries to understand exactly what is not<br />
working and then tries to take the user through some basic troubleshooting steps to<br />
resolve the incident. This is a key substep, as it provides the necessary data points for<br />
further investigation on the incident. It is analogous to a doctor asking you about the<br />
symptoms you have: Do you have throat pain? Do you have a cough? Do you have a cold?<br />
Do you have a headache? You get the drift. Likewise, the service desk is expected to ask a<br />
series of questions to provide the necessary information to resolve the incident quickly,<br />
which is the objective of the incident management process.<br />
Not all incidents can be resolved by the service desk. They get functionally escalated<br />
to the next level of support, generally referred to as level 2, or L2. The L2 group is normally<br />
a part of an expert group, such as the server group, network group, storage group, or<br />
software group.<br />
The resolver group diagnoses the incident with the available information, and if<br />
needed, calls the user to obtain more information. It is possible that the service desk’s<br />
line of questioning could be on the wrong path, and perhaps the resolver group must start<br />
all over again by asking the right set of questions.<br />
Investigation of the incident digs deeper into the incident by understanding one or<br />
more of the following thought processes:<br />
• What is the user expecting to obtain through the incident?<br />
• What has gone wrong?<br />
• What are the sequence of steps that led to the incident?<br />
172