Incidents and problems

An incident names the service and asset involved in an interruption. Priority, opened time, acknowledgment time and resolution time help the responder explain the sequence of work. The assignee is a person record, so the service team can see who is currently responsible. Incident status moves through Open, Acknowledged, Investigating, Resolved and Closed as the team handles the interruption.

Incident updates carry their own occurrence time, text, author and incident link. That dated thread is useful when a patch attempt fails or a change needs to be rolled back. The responder can describe the symptom and action taken without rewriting the original incident. A Service Owner reviewing the outcome can read the updates alongside the attempt and change records.

• Immediate response. Incidents identify the affected service, asset, priority and assignee.
• Dated updates. Incident Updates preserve who said what and when during response.
• Root cause. Problems track a problem statement, owner and root cause investigation.

Agree how responders assign priority and when a service interruption calls for an incident. Decide who moves an incident from Resolved to Closed and who reviews unresolved work at each handoff. The Incident Responder and Problem Analyst should agree when recurring or serious incidents need a separate problem investigation. A problem record can be Open, Investigating, known error or Resolved, which makes it useful for following the longer inquiry.

Suppose an installation attempt fails on an asset supporting a critical service. The Patch Operator records Failed on the attempt. If users experience disruption, the Incident Responder opens an incident for that service and asset, then records investigation updates. The Problem Analyst may create a problem for the service and document the root cause after the immediate response. The records connect through service context, even when the team reviews them separately.

Open an incident for a known asset and service. Assign a responder and add an update from a named author. Record acknowledgment and resolution dates as those events happen, then compare the incident timeline with the related patch attempt. Create a problem only if further investigation is warranted, and confirm its owner can explain the problem statement and current status.

Review a case that was resolved but later needs root cause work. The incident’s resolution should remain an account of immediate response; the problem’s root cause can continue separately. That division helps the Service Owner see both restoration and the follow-up work still owed.

• Open incidents — Find affected services and assets awaiting response or resolution.
• My incidents — Show a responder the incidents assigned to them.
• My problems — Show the analyst’s current root cause investigations.

Respond and investigate and review patch results.