| id | prodhardening.availability_recovery_continuity |
| name | availability-recovery-continuity |
| 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
- Translate business impact into SLOs, error budgets, RTO, RPO, support expectations, and escalation paths.
- Identify single points of failure across compute, network, data, identity, DNS, CI/CD, secrets, and humans/process.
- Design backups around restore outcomes: point-in-time, object/version recovery, region/account isolation, encryption, and retention.
- Design DR strategy: backup/restore, pilot light, warm standby, active-passive, active-active, or degraded manual mode.
- Test recovery through drills. A backup that has not been restored is an assumption, not evidence.
- 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:
- Scope interpreted — what is in and out.
- Findings / decisions — ordered by production risk, not by discovery order.
- Recommended actions — owner-ready tasks with priority and rationale.
- Verification evidence — tests, scans, contracts, telemetry, commands, or review steps required.
- Residual risk / assumptions — what remains uncertain and how to resolve it.
- 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.
