← 목록

Disaster Recovery Drills That Actually Work

devto 2026-07-14 원문 보기 ↗


Most DR Drills Are Theater

Someone schedules a meeting. A few senior engineers walk through a runbook. Everyone agrees "yes, we could do this" and marks it complete.

Then the real disaster hits and nobody remembers the procedure, the runbook is 2 years out of date, and half the backup systems don't work.

Real DR drills test whether your team can actually recover, not whether they can talk about recovery.

The Three Levels of DR Testing

Level 1: Tabletop

Level 2: Partial Failure Test

Level 3: Full Production Drill

Most teams stop at Level 1. Good teams do Level 2 quarterly. The best teams do Level 3 twice a year.

A Real DR Drill Scenario

Scenario: Primary database becomes unreachable

Setup (48 hours before):

Execution:

  1. At T+0, block network access to primary database via iptables
  2. Start stopwatch
  3. Watch the team respond
  4. Do NOT intervene or give hints
  5. Document every action, every decision, every delay

Metrics to capture:

Scoring the Drill

Good scores:

If any of these are 5x longer than target, you have a real problem.

What Always Goes Wrong

In every DR drill we run:

  1. Runbook is out of date. The one that worked 6 months ago has wrong commands now.
  2. Credentials don't work. The service account was rotated, nobody updated the runbook.
  3. Backup is untested. The restore fails because the backup is corrupted.
  4. Escalation paths are stale. The "DBA on-call" has left the company.
  5. Dependencies are missing. The recovery playbook assumes Service X is up, but Service X depends on the failed component.

Every drill uncovers 3-5 of these. Fix them, then drill again.

Chaos Engineering vs. DR Drills

These are different. Chaos engineering is continuous (daily/weekly) and usually automated. DR drills are intentional and large-scale.

Chaos engineering answers: "Can we survive small failures routinely?"

DR drills answer: "Can we survive catastrophic failures at all?"

You need both.

The Blame-Free Rule

DR drills expose weaknesses. Those weaknesses are process problems, not people problems.

The rules:

If the team is afraid of the drill, you'll never learn anything real.

Frequency That Actually Works

Level 1 (Tabletop): Monthly, 1 hour
Level 2 (Partial): Quarterly, 4 hours including retro
Level 3 (Full Production): Twice a year, full day

Also: after every major infrastructure change, drill the affected components.

The Hardest Lesson

The drill is the easy part. The hard part is making the fixes from the drill a priority when there's feature pressure.

We track "DR drill remediation items" as a standing OKR. If after two quarters the same items are still open, the SRE team has authority to freeze feature work until they're fixed.

Starting Point

If you've never done a DR drill:

  1. Pick one scenario (database failure, region outage, API gateway down)
  2. Schedule it for a quiet hour
  3. Run a tabletop first — find the obvious gaps
  4. Fix those gaps
  5. Run a partial failure test in staging
  6. Measure everything
  7. Run a retro focused on process
  8. Schedule the next one

Do this for three scenarios, and you'll have a DR program. Do it for ten, and you'll have a resilient company.

Written by Dr. Samson Tanimawo
BSc · MSc · MBA · PhD
Founder & CEO, Nova AI Ops. https://novaaiops.com