3.1Incident management

When a service outage or quality degradation occurs, the first question a service manager faces is not "why did it break?" but "how quickly can we return it to the agreed level?" The purpose of incident management is the rapid restoration of service; permanent investigation of the cause is the job of problem management in the next section. This section covers the operational judgments of, under limited staff and SLA-target constraints, which incident to handle first, when and to whom to hand it off, and what counts as "restored" while the root cause is still unknown.

3.1.1The purpose is rapid restoration, not root-cause investigation

• An incident is an unplanned interruption to a service or a reduction in its quality (an event failing to meet the agreed level). The sole purpose of incident management is to restore normal service operation as quickly as possible while minimizing the impact on the business.
• Identifying the root cause or permanently preventing recurrence is not the purpose—that belongs to problem management in the next section. Restoring service does not require fully understanding the cause; if a workaround such as a restart or switching to an alternate path clears the symptom, the incident may be treated as "resolved (restored)."
• The key is not to confuse restoration (returning the service to a working state) with permanent resolution (ensuring it never recurs). Prioritizing restoration and handing the pursuit of the cause to problem management makes it easier to stay within the outage-time ceiling agreed in the SLA.

3.1.2Priority = impact x urgency, and escalation

• Priority is determined by combining impact (the number of affected users and the importance of the business) with urgency (how little time is available before action is needed). The rule is to order incidents by this priority rather than by order of arrival (FIFO).
• Functional escalation (horizontal) hands an incident that the first-line (service desk) cannot resolve to second- or third-line technical groups with specialist knowledge. Hierarchical escalation (vertical) notifies and seeks decisions from managers or senior staff when major impact or an authority-level decision is required. The two serve different purposes.
• A major incident has both high impact and high urgency. Separately from the normal flow, a dedicated procedure is invoked: a designated incident manager is appointed, stakeholders are convened, and resources are concentrated on rapid restoration.

Suppose a service manager receives a report that "the core sales-management system is not responding" during the month-end billing batch. At the same moment, a minor report arrives that "one internal user cannot change their desktop wallpaper." The first thing to do is not to analyze the cause but to prioritize by impact x urgency. The sales-management system is used by the entire sales division (hundreds of people) for the time-critical month-end process, so both impact and urgency are at their highest—this is declared a major incident, invoking the separate procedure and concentrating resources on restoration under a dedicated incident manager. The wallpaper issue is low in both impact and urgency; deferring it will not breach the SLA. For the sales-management system, since the first line cannot restore it, it is functionally escalated to the specialist infrastructure team, and because the business impact is large it is simultaneously hierarchically escalated to notify the division head. Investigation cannot pin down the cause, but exhaustion of the DB connection pool is suspected, and restarting the service temporarily restores it. Here the service manager chooses to restore service with a workaround (the restart) even though the root cause is unresolved, returning the service within the SLA outage ceiling. The investigation of "why do the connections get exhausted?" and the permanent fix are then handed off to problem management and pursued separately. Clearly separating restoration (incident management) from root-cause investigation (problem management) and prioritizing restoration first is the core judgment of a service manager handling simultaneous failures.

3.1.3Section summary

• The purpose of incident management is the rapid restoration of service, not root-cause investigation (that is problem management)
• Order of handling is set by priority = impact x urgency, using functional escalation (to a specialist group) and hierarchical escalation (to senior staff) for different purposes
• Even without identifying the root cause, clearing the symptom with a workaround counts as restoration, and the pursuit of the cause is handed to problem management