A runbook is a document of steps for operating a service, or for handling a known situation, written so a responder can follow it under pressure. A service is an activity or capability offered for another party, rather than a physical product unit. Runbook service is the service whose operation the runbook describes. A document is an identifiable body of recorded information, which can provide evidence without being the agreement or the activity itself. A problem is a cause, or a potential cause, of one or more incidents. A known error is a problem that has been analysed and has not been resolved. A problem workaround is a way to reduce or eliminate the impact of a problem when a full resolution is not yet available. A postmortem is a document written after an incident, once the service is restored, recording what happened, how the service was restored, what contributed, and what will change. A playbook, in ordinary operations talk, is a wider set of guidance for a kind of situation, and playbook is not a MeaningGraph core id.
The page opened when the feed goes dark
In this invented Repair Day, Lantern Works is running Projector setup. That service name, and the difference between the name and the activity, is What is a service name?. At 19:05 the projector feed goes dark. Priya opens a document titled "Projector feed dark". The steps say: check the cable, power-cycle the player, and if the vendor stream is still refused, keep the backup slide deck on and pass the ticket on. Those steps are the runbook.
Runbook = a document of steps a responder can follow under pressure.
The evening is made up. The split between the records is the part worth keeping.
The steps point at a service
The document title is the title of the recorded information. In the example the title is "Projector feed dark". The title is not the service. Runbook service is the service the steps describe. Here that service is Projector setup. A document that uses the same words in its title, and does not point at the service, is a document with a similar label.
The document reference is the identifier used to retrieve the document. The document revision is the revision designation of this document record. In the invented example Priya is holding revision 3 while a newer revision sits unreleased. The steps she follows are the revision she opened. Editing the title does not change which service the runbook describes.
The known error is the analysed cause
Incident vs problem vs change keeps the interruption, the cause, and a proposed modification apart. In this invented evening the feed failed at 19:05. Restoring the picture belongs to the incident. The cause, once analysed and still unresolved, is the known error: the vendor stream drops when the player retries. Analysis is what makes the problem a known error. A workaround is often recorded with a known error and is not required for that status. The known error can still be in the service. It is a name for that analysed problem, not a completed fix, and not the runbook.
The problem workaround in the example is "keep the backup slide deck on". It can be written on the problem before the problem is a known error. The runbook may quote that sentence. The workaround is not the runbook. An incident workaround is a way to reduce or avoid the impact of this incident without removing the cause. Switching the backup deck on at 19:12 can do that for this evening, and it can be found before any problem has been analysed. The root cause is the cause the investigation has settled on, when it has one. The workaround is not that cause.
The postmortem is the write-up after restore
The picture is back at 19:20. On Monday someone writes what happened, how the feed returned, what contributed, and what will change. That document is the postmortem. The postmortem incident is the incident this document reviews. Writing it does not reopen the incident. It is not the problem record and not the runbook. A meeting about how Repair Day felt is a different practice and is not this document.
Playbook is not a core id
People use playbook for a wider collection: who decides, which principles apply, and several procedures for a kind of work. MeaningGraph does not register an id named playbook. Calling the file a playbook does not merge the records. The steps a tired person can follow are the runbook. The analysed cause is the known error. The temporary avoidance is the workaround. The write-up after restore is the postmortem. A team can keep all four in one file. The file still holds four facts.
Who follows the steps, and what called them
A support tier is the depth of a support response. Level 1 (L1) takes the report, applies a known fix or a runbook, and passes on what it cannot close. Level 2 (L2) investigates further. Level 3 (L3) is specialist depth: a change to the software, a vendor, or the team that builds it. Level 1 (L1), level 2 (L2), and level 3 (L3) support is who holds the support ticket while those records are open. The runbook may tell the reader to pass the ticket on. The tier is the depth of the response. The runbook is the steps.
An alert is an observation that a stated condition was met and that a person may need to act. A person is an individual human being. In the example an alert says the projector feed is dark. The alert does not by itself establish the cause, or that an incident has occurred. Several alerts can be one incident, and an alert can be a false signal. The runbook is what the responder opens next. The alert is the signal. It is not the steps.
The promise, the target, and the measurement
A service level agreement (SLA) is a documented agreement between a service provider and a customer. It identifies the services required and the expected level of service. It is a contract in this graph, because it creates commitments between those parties. A service level objective (SLO) is a target value or range for a service level over a stated window. A service level indicator (SLI) is a quantitative measure of one aspect of the level of service. SLA vs SLO vs SLI keeps the promise, the target, and the measurement apart. A runbook may say what to do when an indicator misses a target. The agreement is the promise, the objective is the target, and the indicator is the measurement.
| Record | The question it answers | Invented Repair Day |
|---|---|---|
| Runbook | What should the responder do? | Check the cable, power-cycle, keep the backup deck on |
| Runbook service | Which service are the steps about? | Projector setup |
| Known error | What cause is analysed and still unresolved? | The vendor stream drops on retry |
| Problem workaround | What reduces the impact while resolution waits? | Keep the backup slide deck on |
| Incident workaround | What avoids the impact of this incident? | The backup deck, switched on at 19:12 |
| Postmortem | What is written after restore? | Monday's write-up of the dark feed |
| Playbook | No MeaningGraph core id | A wider file, if a team uses that word |
When someone asks what a runbook means, answer with the steps a responder can follow under pressure, then name the service those steps describe. The title, the known error, the workaround, and the postmortem can share an evening and stay separate records. The names, the times, and the vendor story are made up.
