Establish practice
Define cadence, owner, participation, and success signals for a recurring team practice.
Establish the practice
Define cadence, owner, participation, and success signals so the method works as a recurring team practice.
Variant for Operating practice. The plan is derived from method form, method steps, and runsheet.
RunsheetAn operating practice works through repetition. The cadence should be small enough to hold reliably.
The steps describe one repetition and are adjusted after review.
- 1
Section 1: Header and trigger
20 minFill header: title, service, owner, reviewer, last update, severity. Describe trigger and symptoms concretely (alert name, metric threshold, log entries).
OwnerIf symptoms are vague, runbook is pulled on wrong alert. Concrete example log entry or screenshot helps enormously. - 2
Section 2: Prerequisites and access
20 minTools, permissions, VPN, configurations needed for execution. List pre-checks: what must be present before step 1 starts.
TeamNothing is more frustrating than reaching step 4 and not having tool access. Pre-checks force permissions to be maintained upfront. - 3
Section 3: Steps
60-120 minPer step: number, action (command or UI instruction), expected response, next step. Decision points as If/Then. Check idempotency per step.
TeamSteps must be concrete enough that someone without prior experience can execute them. No implicit assumptions. Better too detailed than too short. - 4
Section 4: Verification and rollback
20 minVerification steps: how operator knows action succeeded. Rollback steps if effect does not occur or side effect appears.
TeamVerification is not "see if it runs". Concrete command or metric with threshold. Rollback is mandatory section, not optional. - 5
Section 5: Escalation and postcheck
15 minWhen to escalate, to whom, with what context. Postcheck: what follows afterward (close ticket, start postmortem, inform owner).
TeamEscalation trigger explicit: after 30 min without effect, on severity increase, on security indicators. Otherwise operator hesitates too long in incident. - 6
Section 6: Drill and review
1-2 h per drillTest pilot executes runbook on staging or in Game Day. Incorporate feedback. Set review cadence (for example semiannual or after change).
TeamA runbook that was never practiced will not work in incident. At least one drill after creation and after larger change.
Practice Charter
Copyable charter with purpose, cadence, owner, participation, flow, success signals, and review.
practice-charter.md
Practice Charter: Runbook
Purpose
The method helps clarify workflows, data, causes, and improvements concretely. It identifies patterns, causes, bottlenecks, or constraints and derives actions. The outcome is captured as a runbook, checklist, and escalation path.
Cadence
weekly
Owner and Participation
- Owner: open
- Participants: 1-4
- Mode: synchronous
Flow per Iteration
- Section 1: Header and trigger (20 min) Fill header: title, service, owner, reviewer, last update, severity. Describe trigger and symptoms concretely (alert name, metric threshold, log entries).
- Section 2: Prerequisites and access (20 min) Tools, permissions, VPN, configurations needed for execution. List pre-checks: what must be present before step 1 starts.
- Section 3: Steps (60-120 min) Per step: number, action (command or UI instruction), expected response, next step. Decision points as If/Then. Check idempotency per step.
- Section 4: Verification and rollback (20 min) Verification steps: how operator knows action succeeded. Rollback steps if effect does not occur or side effect appears.
- Section 5: Escalation and postcheck (15 min) When to escalate, to whom, with what context. Postcheck: what follows afterward (close ticket, start postmortem, inform owner).
- Section 6: Drill and review (1-2 h per drill) Test pilot executes runbook on staging or in Game Day. Incorporate feedback. Set review cadence (for example semiannual or after change).
Success Signals
Runbook, Checklist, Escalation Path
Review
4 weeks