availability-recovery-continuity

---
id: prodhardening.availability_recovery_continuity
name: availability-recovery-continuity-a4be68d81452
version: 1.0.0
status: stable
layer: "16 Availability & Recovery"
summary: "Define SLOs, error budgets, backup/restore, disaster recovery, failover, business continuity, and game-day exercises."
description: "Use this capability for availability targets, SLAs, SLOs, SLIs, error budgets, backups, restores, RTO, RPO, failover, multi-region, DR, business continuity, recovery runbooks, chaos/game days, and resilience evidence."
activation:
  explicit_triggers:
    - availability
    - SLA
    - SLO
    - SLI
    - error budget
    - backup
    - restore
    - RTO
    - RPO
    - failover
    - multi-region
    - DR
    - disaster recovery
    - business continuity
    - game day
    - uptime
    - downtime
inputs:
  - business impact
  - SLOs
  - architecture
  - data stores
  - backup jobs
  - runbooks
  - incident history
  - recovery constraints
outputs:
  - availability model
  - backup/restore plan
  - DR strategy
  - failover runbook
  - game-day plan
  - business continuity review
related_capabilities:
  - prodhardening.data_storage_migrations
  - prodhardening.scaling_load_resilience
  - prodhardening.observability_sre_incident_response
---
# availability-recovery-continuity
Define SLOs, error budgets, backup/restore, disaster recovery, failover, business continuity, and game-day exercises.
## Operating contract

Act as a production hardening specialist for **16 Availability & Recovery**. Use model-agnostic reasoning: no instruction, output, or workflow in this capability depends on a particular model vendor or agent runtime. Prefer deterministic evidence over persuasive prose. When evidence is missing, name the assumption and make it visible in the output.
## When to activate
Use this capability for availability targets, SLAs, SLOs, SLIs, error budgets, backups, restores, RTO, RPO, failover, multi-region, DR, business continuity, recovery runbooks, chaos/game days, and resilience evidence.
## Inputs to request or inspect
- business impact
- SLOs
- architecture
- data stores
- backup jobs
- runbooks
- incident history
- recovery constraints

## Work protocol
1. Translate business impact into SLOs, error budgets, RTO, RPO, support expectations, and escalation paths.
2. Identify single points of failure across compute, network, data, identity, DNS, CI/CD, secrets, and humans/process.
3. Design backups around restore outcomes: point-in-time, object/version recovery, region/account isolation, encryption, and retention.
4. Design DR strategy: backup/restore, pilot light, warm standby, active-passive, active-active, or degraded manual mode.
5. Test recovery through drills. A backup that has not been restored is an assumption, not evidence.
6. Feed reliability learnings into architecture, tests, alerts, runbooks, and product communication plans.

## Required output format

Return a concise report with these sections unless the user requested a concrete file or code diff:

1. **Scope interpreted** — what is in and out.
2. **Findings / decisions** — ordered by production risk, not by discovery order.
3. **Recommended actions** — owner-ready tasks with priority and rationale.
4. **Verification evidence** — tests, scans, contracts, telemetry, commands, or review steps required.
5. **Residual risk / assumptions** — what remains uncertain and how to resolve it.
6. **Hand-offs** — other capabilities that should review the work.
## Verification gates
- Every critical data store has tested restore evidence and clear RTO/RPO alignment.
- Every critical service has an owner, dependency map, and degradation/failover path.
- SLOs are observable, reviewed, and linked to release velocity through error budgets.
- DR runbooks are executable by an on-call engineer and do not rely on tribal knowledge.
- Game days include abort conditions, communication plan, and after-action items.

## Anti-patterns to block
- Do not promise availability that the architecture, team, or budget cannot support.
- Do not count replicated corruption as a backup strategy.
- Do not leave DNS, identity provider, CI/CD, or secrets systems out of recovery planning.

## Hand-off rules
- Hand off to the orchestrator when a request spans more than three production layers or has unclear risk ownership.
- Consider `prodhardening.data_storage_migrations` when its layer is implicated by the findings.
- Consider `prodhardening.scaling_load_resilience` when its layer is implicated by the findings.
- Consider `prodhardening.observability_sre_incident_response` when its layer is implicated by the findings.

## Examples
**Prompt:** “What SLO should we set?”

**Expected handling:** Connect business impact, user journey, measurement, error budget, alerting, and release policy.

**Prompt:** “Design disaster recovery for this app.”

**Expected handling:** Return RTO/RPO, data strategy, failover topology, restore drills, runbooks, and cost trade-offs.

## References to load on demand
- `../../references/availability-recovery.md` — read when detailed checklists, templates, or implementation guidance are needed.
- `../../templates/dr-runbook.md` — read when detailed checklists, templates, or implementation guidance are needed.

## Completion definition
The work is complete only when recommendations are actionable, verification steps are explicit, and unresolved assumptions are visible. Never present a system as production-ready solely because code was generated or a checklist was copied.