Problems

An incident captures a disruption now. A Problem records the recurring or underlying issue that may produce more disruptions. It has a service, owner, opened date, problem statement, root cause and status. The Service Manager can keep investigation open after an immediate incident is resolved, giving the team a place to record what remains to be fixed.

The problem status distinguishes open work, an investigation, a known error and resolution. A known error can be useful operational context for responders facing another incident on the same service. The status should reflect what the team knows, while the problem statement and root cause explain the reasoning in plain terms.

• Open the issue. Describe the recurring service problem and assign a person responsible for investigating it.
• Record the finding. Add the root cause when the evidence supports one, then keep the status aligned with the investigation.
• Plan a remedy. Use a separate Change when fixing the underlying issue needs scheduled work or a rollback plan.

Decide when several incidents justify a Problem. Agree who owns root-cause investigation and who reviews the wording before it is treated as a known error. Keep the problem statement about the observed issue and reserve the root-cause field for a supported conclusion. If the team publishes postmortems elsewhere, agree how the problem record contributes to that process.

Review incidents by shared service and use the problem statement to identify the affected pattern. Check each incident’s symptoms before grouping it with the recurring issue. The review should preserve the distinction between observed disruption and confirmed underlying issue.

Several incidents affect the same service over a short period. Each incident is resolved after mitigation, but the manager sees the recurring pattern and opens a Problem for investigation. The owner records the observed symptoms in the statement, then adds a root cause when evidence is sufficient. If the team has a temporary workaround, the known-error status makes that context easy to find.

The longer-term fix may require a planned change. The manager prepares its risk, time window and rollback plan and moves it for review. After implementation and verification, the Problem owner checks whether the underlying issue is resolved. The change being verified does not by itself explain every earlier incident; the problem record preserves that reasoning.

• Open problems — Underlying service issues that are open, being investigated or known errors.
• Active incidents — Current disruptions that may prompt a separate problem investigation.

Investigate a recurring issue and plan a change.