Service Operation, Incident and Problem Management
This domain tests how services are run day to day, especially how incidents are restored and problems are investigated. Expect event, incident, service request, problem, known error and workaround, plus priority, major incident handling and the service desk role.
Core rules and concepts
- An incident is an unplanned interruption or degradation. A problem is a cause, or potential cause, of one or more incidents.
- A workaround reduces or eliminates impact when a full fix is not yet available. A known error is a problem with a documented root cause and workaround.
- Priority is derived from impact and urgency, not from who shouted loudest. Severity describes technical effect; priority drives response.
- Major incidents need a defined trigger, an incident commander, communications and escalation. Restore service first; investigate cause later.
- Service requests are normal user needs, handled through a request model, not treated as incidents.
Worked example
Payment failures spike. The team declares a major incident, brings in an incident commander, communicates to affected users, and restores service by failing over to a secondary node. Root-cause analysis is not allowed to delay restoration. After service is stable, a problem record is opened, the failover defect is analysed, a known error is recorded with a workaround, and a permanent fix is raised as a normal change. The reasoning is that incident management optimizes time to restore; problem management optimizes removal of cause.
Traps
Running root-cause analysis during a major incident; closing incidents without user confirmation; raising a problem for every incident; equating severity with priority; using workarounds as permanent fixes without review.