Make the readiness decision survive a game day
What This Concept Is
Readiness is a justified decision about a particular system version and operating scope. It includes known limitations and blockers; it is not a permanent property acquired by completing a form.
Why It Matters Here
The original game day and runbook must lead to repairs that are verified, not only documented.
Concrete Example
During a synthetic dependency outage the alert fires, but the operator cannot locate the safe fallback. The service recovers after manual investigation. The outcome is useful evidence of a runbook gap, not a successful rehearsed response. Repair the instruction and ask another operator to follow it in a fresh scenario.
Common Confusion / Misconception
A recovery timeline without customer-visible validation can stop too early. An unresolved severe access-control or restore defect cannot be averaged away by strong dashboards.
How To Use It
Capture detection, triage, mitigation, communication rehearsal, recovery checks and follow-up owner. Separate blocker, accepted scoped risk and future improvement. Require evidence before closing a blocker.
Check Yourself
What failure blocks release? Who owns accepted risk? How do you know the follow-up worked?
Mini Drill or Application
Run a second, changed failure after repair. Record the readiness decision and the system version it applies to; preserve the previous failed rehearsal.
Read This Only If Stuck
Building Secure and Reliable Systems provides selective operational reasoning. Use the module sources below for current tool behavior; do not read a whole book before attempting the exercise.