Incident Response

An incident names the service, asset, priority and assigned person. Those links tell the responder what is affected and who is expected to act. The opening and acknowledgment times show when the newly opened case entered response; the assigned responder then investigates. A priority helps the service manager order work, but it does not replace the service and asset context needed to investigate.

An incident may concern a failed backup, an unavailable instance or another service issue. Use the affected asset and its service to connect the database to its operational context. If the investigation identifies a recurring cause, the service manager can open a problem record under the same service and give it an owner.

• Assignment. The assigned person is visible on the incident and in their own working list.
• Progress. The incident status moves through open, acknowledged, investigating, resolved and closed states.
• Updates. Each update has its own number, time, author and narrative tied to the incident.

Choose who opens incidents from incoming operational signals and how an asset is selected. Agree how the assigned responder receives a newly acknowledged incident and who can move it into investigation or resolution. Agree what an update should explain: what was observed, what action was taken and what remains unresolved. The update author should be the person who wrote the note, rather than a shared operational account.

The service manager should also decide when a repeated incident warrants a problem record. Problem investigation has its own statement, root cause, owner and status. It can support later change review without making every incident into a change request. The team can assess patterns using service, priority, assignee and the recorded times.

Take a failed backup on a known database. Find its host asset and service, then open an incident against that service and asset. Assign an incident responder and choose the recorded priority. Check that the new incident carries its acknowledgment time, then have the responder add an update with the observed backup failure. Another person reviewing the case should be able to see the update author and time.

Move the incident into investigation while the responder checks the database and backup records. Once service work is complete, record resolution time and status. If the root cause is still under review, the service manager can keep that inquiry in a problem record; closing the incident should not silently erase the issue being investigated.

• My Incidents — Assigned cases with opening and acknowledgment times.
• Incident Board — Current cases grouped by state for the handoff meeting.
• Open Problems — Recurring service issues with an owner and current investigation state.

See incident handling and service context.