15.08.2018 Views

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

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!