Problem Management

Problem management. This is the other half of incident management, and the exam tests the boundary between them relentlessly.

The scene. The nightly reconciliation job has failed and been manually restarted every night for two weeks. Each morning the on-call engineer restarts it, service is restored, the incident is closed, and everyone moves on. The restart works every time. And every night it fails again, because no one has asked why.

Think about that count. Fourteen incidents, fourteen resolutions, and one unsolved problem. Restarting the job is correct incident handling, it restores service. But if that is all that ever happens, the cause is never removed and the failure recurs indefinitely.

So here is the definition. A problem is the underlying cause of one or more incidents. Incident management gets the users working; problem management makes sure they do not have to be got working again for the same reason next week.

Keep the two apart. Incident management restores service. It cares about now.

Problem management investigates the underlying cause and removes it, so those incidents stop happening. It cares about never again. The two are complementary, and the exam checks constantly that you do not blur them.

The clearest signal that a problem exists is an incident that keeps coming back. The nightly batch failure is not fourteen unrelated incidents; it is one problem generating an incident a day. Restarting restores service each time, but it never touches why it fails.

So good practice raises a problem the moment a pattern appears: investigate why the job fails, find the root cause, and remove it. That converts a nightly firefight into a one-time fix. When a question describes the same incident recurring and asks what should happen, the answer is to raise a problem and pursue the root cause, not to keep re-applying the workaround.

When problem management identifies a cause and documents a workaround or fix, the result is a known error: a problem whose cause is understood and whose handling is written down. That is valuable operationally, because if it recurs before the permanent fix lands, the service desk can resolve it fast using the documented workaround, rather than diagnosing it afresh.

And problem management is not only reactive. It can be proactive, analysing incident trends to find and fix latent problems before they cause the next outage. Fixing it before the next failure is problem management at its best.

Which points at the trap. The costly instinct is to treat recurrence as normal because service is always restored. Fourteen successful restarts feel like fourteen wins; they are fourteen symptoms of one unaddressed problem. Restoring service is incident management doing its job, but a fault that keeps returning is the signal to raise a problem.

So carry this away. Re-fixing forever is not resolution; it is a problem no one has agreed to solve. A fault that keeps returning is a problem to investigate and remove at the root, not an incident to restart one more time.