Incident response

An incident begins with a summary, priority, opened time and affected service. The incident can also point to an asset and an assigned person. Those links matter during triage: a failure on a service with a criticality rating asks for a different response than an isolated asset issue. The Business Overview gives the team a quick distribution by current incident state and a recent delivery evidence queue. The working record remains the incident and its related response history.

Suppose a deployment has just been marked failed for a service. The responder opens the related service, checks whether an incident has been captured, and records the observed issue. The release manager can read the deployment outcome while the responder owns the incident investigation. Keeping those records separate lets each owner make the decision within their work.

• Acknowledge. Capturing the incident starts the acknowledgement workflow and records its first response event.
• Investigate. Beginning investigation moves the incident to Investigating and appends an attributed update.
• Resolve. The responder records the resolution time and uses the incident status to show whether response work remains open.

Agree who receives a new incident, how priority is chosen and which service record owns it. Confirm that the person assigned to an incident maps to the team member who is doing the work. Set a practical rule for when to associate an asset, especially when several assets support the same service. Decide what belongs in an incident update so the next responder can read it without reconstructing a chat thread.

Response events distinguish a page, acknowledgement, escalation, mitigation and resolution. Use the event that describes the action actually taken. Acknowledging a page does not claim that service has been restored. For impact work, attach an assessment to the incident and identify its impact owner; the assessment has its own severity and mitigation procedure.

Rehearse an incident tied to an active service and an assigned asset. Confirm that capture produces the acknowledged state and first response event. Then start investigation and check the author and time on the new update. At shift change, another responder should see the current state, service, asset, assignee and chronology before taking responsibility. If the incident is linked to an outage, compare the outage’s start and restoration times with the incident timeline.

After mitigation, review the recorded outcome rather than assuming a deployment status closed the incident. A healthy deployment and a resolved incident answer different questions. The service desk manager can use acknowledgement timing and incident state reports to find work still awaiting a real response.

• Open Incidents — Incidents still in open, acknowledged or investigating states, with priority and owner visible.
• My Assigned Incidents — The assigned responder’s incidents with service, state and opened time close to hand.
• High Priority Incidents — High and critical items for the next response handoff.

Use the incident response process to rehearse capture, acknowledgement and investigation. The deployment outcome process shows the release evidence the responder may need to examine.