Feedback on My Disaster Recovery Plan and Runbook Structure

I’d make the handoff between the document types especially clear. DIAG pages should contain inputs, checks, dashboards, and expected versus abnormal signals. DRPs should contain severity, impact, decision branches, communication requirements, approvals, and stop conditions. RUN pages should contain prerequisites, commands, expected output, verification, cleanup, rollback details, and an abort point.

For each procedure, it’s useful to record the expected duration, potential blast radius, owner, reviewer, and last successful test date. By blast radius, I mean the systems, users, data, or dependent services that could be affected if the procedure succeeds, fails, or is performed incorrectly.

The most valuable improvement may be regular rehearsal rather than more categorization. Pick the most important scenarios and run tabletop exercises with a non-SRE teammate driving from the DRP. Every question they ask is a sign that the documentation could be clearer.

Keeping the DRP and runbooks separate is a good idea. They answer different questions: the DRP explains what is happening, how serious it is, who makes decisions, and which recovery path is appropriate. The runbook explains exactly how to perform one technical action.

I’d make the workflow explicit near the top of every DRP: start here, run the linked diagnostics, select the appropriate recovery branch, execute the linked runbook, then validate the result. The DRP should be the map, not a second copy of the commands.

Diagnostics can be treated as a shared reference library rather than a mandatory stage. Both DRPs and runbooks can link to the same diagnostic pages, depending on what needs to be confirmed.

For scenario maturity, add a clear status such as observed, rehearsed, tabletop-only, or hypothetical. Also track the owner, last review date, last rehearsal date, expected blast radius, rollback or stop conditions, and post-recovery checks. A stop condition is especially valuable because it prevents someone from continuing when the situation is becoming worse.

The most important test is whether somebody else can actually use the documents under pressure. A procedure that looks complete but has never been fire-drilled is still mostly an assumption. Run the whole chain with another coworker, measure where they get stuck, and update the DRP and runbooks based on what happens. The folder structure matters much less than whether the process works in practice.

Your overall structure is already more disciplined than what many larger teams maintain. I would keep the three document types separate:

- DIAG proves which state the system is in.
- DRP decides what recovery path to take.
- RUN executes one specific procedure.

The DRP can remain the human entry point. A typical flow would be: identify the symptom, use linked diagnostics to confirm the situation, choose a recovery case, run the relevant procedure, validate the result, and record the incident.

For scenarios that have never happened, label them clearly with something like tested, tabletop-tested, synthetic-tested, or theoretical, along with a last-reviewed date. A tabletop exercise is useful when reproducing the failure safely is impractical, and it also provides useful evidence that the process is being reviewed for compliance purposes.

In larger organizations, the concepts are usually similar but more formalized. They tend to define service tiers, assign owners, schedule recovery drills, record RTO and RPO targets, and automate failover where the cost is justified.

Your largest risk is probably the dependency on one person. The workshop and training area is therefore important. Have someone unfamiliar with the systems follow a DRP while you only observe. Record every question, hesitation, and point where they need help. Those observations usually reveal more than adding another page of documentation.