Assets and runbooks

An asset carries its tag, serial number, location, state and linked service. An asset-to-service link can record a dependency type and the time it was verified. These records help a responder identify which equipment supports an affected service. Monitored devices add a device identifier, department, criticality and service due date against an asset. The Monitoring Operator can start with a service, inspect its linked assets and compare server samples for the likely device before assigning an incident.

Runbooks hold an owner, service, title, category, body, state and publication time. They give responders a place to read an operating procedure while investigating an incident. A draft or review copy should be treated as work in progress. A published runbook is the version the responder uses during a shift. Reader feedback records whether the runbook was helpful and a comment, tied to the runbook. Feedback can guide a revision after the incident without changing the historical incident update.

• Dependencies. Keep asset and service links current, with a verification time for important connections.
• Working procedures. Attach runbooks to services and give each one a named owner.
• Learning. Record feedback after use so the procedure can be improved with a concrete example.

Set conventions for asset tags, locations and service names before importing existing assets. Decide who verifies each dependency and how often the verification date should be refreshed. Assign runbook owners and agree which states mean a procedure is ready for operational use. Where a runbook describes a risky action, identify the Change Reviewer who will decide on the change before the Release Operator implements it.

Pick a service supported by two assets. Verify the links and record a server sample for each asset. Open an incident for one affected asset, then ask the Incident Responder to find the service runbook and record the action actually taken in an attributed update. The Service Owner should be able to trace from the incident to its asset, from the asset to the service and from the service to the applicable runbook. Ask another responder to submit feedback after following the procedure.

Repeat after an asset moves to maintenance. The asset state should remain visible in the register while the service link and incident history retain their references. If the procedure needs an amendment, the runbook owner edits it and moves it through review before publication. The response update remains a record of what the team did at the time.

• Verified Asset Service Links — Inspect confirmed dependencies and their verification times.
• Published Runbooks — Find service procedures ready for responders.
• Server Sample History — Compare observations for linked assets.

See incident response for working an affected asset and change review before a risky operational change.