Incident Management

Incident management. This lesson is about one job and one job only: restoring service as fast as possible when something breaks. And the exam tests, hard, that finding the cause is a different job.

Here is the scene. The order-processing system is down and the whole sales floor is idle. A capable engineer has the logs open and is determined to find exactly why it failed before bringing it back, out of professional pride. Forty minutes in, sales are still stopped, and a simple restart would very likely have had everyone working within two. The engineer is doing good work at the wrong moment.

Because incident management has a single primary objective: restore normal service operation as quickly as possible, and minimise the impact on the business while service is degraded. Everything else, understanding the fault, preventing it from happening again, is a different process.

That changes what good looks like during an outage. Success is measured by how fast users are working again, not by how thoroughly the cause was understood in the moment. The engineer who restores service in two minutes with a restart has done incident management well, even if they do not yet know why it failed.

Which is why a workaround is a legitimate resolution to an incident, even when the cause is still unknown. Rebooting the server, failing over to a standby, switching to a manual process: all restore service, all buy back the business impact, none require the cause to be understood first. The underlying fault is not forgotten, it is raised for problem management, next lesson.

Incidents are prioritised the way any service-desk call is: by impact combined with urgency. A customer-facing outage that stops revenue is high impact and high urgency and is worked ahead of a single user’s minor glitch, regardless of which arrived first or which is technically harder.

So the correct order during an incident is restore first, understand later. Holding a service down to diagnose the root cause, as our engineer did, inverts that order and prolongs exactly the impact incident management exists to reduce. Get users working with whatever workaround is available; hand the cause on afterwards.

Keep the boundary clear. Incident management restores service now. It cares about the here and now.

Problem management, the next lesson, finds and removes the underlying cause so the incident stops happening. It cares about never again. Two processes, one boundary between them, and the exam repeatedly checks you keep them apart.

Which brings us to the trap: chasing the root cause during the incident. It feels like the responsible, thorough thing to do, and it is precisely the wrong thing during an outage. It costs the exam question, and it costs the business time it did not have.

One more thing. Severe, wide-impact incidents are often handled as major incidents, with extra coordination and communication. But the objective does not change. Even for a major incident, the job is to restore service, fast.

So carry this away. The objective of incident management is to restore service, not to find the cause. Restore first with whatever workaround is available, then hand the cause to problem management to fix for good.