Change Risk & Rollback
Overview
Produce explicit risk and rollback analysis before deployment. Enumerate failure
modes, assess impact, define rollback procedures, and establish Go/No-Go criteria.
REQUIRED: superpowers:verification-before-completion,
superpowers:systematic-debugging
When to Use
- Planning release or deployment changes
- Requesting assessment of operational risk
- Discussing rollback procedures
- Planning infrastructure or configuration changes
- Preparing production deployment
Core Workflow
- Identify change scope (component, dependencies, traffic, window)
- Enumerate failure modes (minimum 3 with symptom, detection, impact, probability)
- Rate each risk (impact x probability)
- Define rollback procedure (detection, Go/No-Go criteria, execution steps, timeline)
- List prerequisites (backups, monitoring, on-call, previous version)
- Select deployment strategy (Blue-Green, Canary, Rolling, Big-Bang)
- Define success criteria (measurable, time-bound)
See references/failure-modes.md, references/rollback-templates.md,
and references/deployment-strategies.md for details.
Quick Reference
| Risk Level |
Impact x Probability |
Action Required |
| Critical |
HIGH x HIGH |
Executive approval, full plan |
| High |
HIGH x MED |
Full rollback plan required |
| Medium |
MED x MED |
Standard rollback procedures |
| Low |
LOW x LOW |
Minimal documentation |
Red Flags - STOP
- "Deployment is straightforward"
- "Can roll back if needed"
- "No time for risk analysis"
- "Testing caught everything"
- "We'll figure it out if something breaks"
All mean: Apply skill before deployment or document explicit risk acceptance.
Rationalizations Table
| Excuse |
Reality |
| "Deployment is simple" |
No deployment is risk-free. Even simple changes have unexpected impacts. |
| "Can roll back if needed" |
Rollback must be defined BEFORE deployment, not during incident. |
| "No time for risk analysis" |
15 minutes of analysis prevents hours of incident response. |
| "Tested in staging" |
Staging doesn't replicate production. Risk analysis still required. |
| "Too much work to back out" |
Sunk cost fallacy. Better to delay than rush and fail. |
Evidence Checklist
1---2name: change-risk-rollback3description: Use when planning release, deployment, or infrastructure changes. Produces risk assessment with failure modes, impact rating, rollback procedures, and prerequisite execution criteria before deployment.4---56# Change Risk & Rollback78## Overview910Produce explicit risk and rollback analysis **before** deployment. Enumerate failure11modes, assess impact, define rollback procedures, and establish Go/No-Go criteria.1213**REQUIRED:** superpowers:verification-before-completion,14superpowers:systematic-debugging1516## When to Use1718- Planning release or deployment changes19- Requesting assessment of operational risk20- Discussing rollback procedures21- Planning infrastructure or configuration changes22- Preparing production deployment2324## Core Workflow25261. **Identify change scope** (component, dependencies, traffic, window)272. **Enumerate failure modes** (minimum 3 with symptom, detection, impact, probability)283. **Rate each risk** (impact x probability)294. **Define rollback procedure** (detection, Go/No-Go criteria, execution steps, timeline)305. **List prerequisites** (backups, monitoring, on-call, previous version)316. **Select deployment strategy** (Blue-Green, Canary, Rolling, Big-Bang)327. **Define success criteria** (measurable, time-bound)3334See `references/failure-modes.md`, `references/rollback-templates.md`,35and `references/deployment-strategies.md` for details.3637## Quick Reference3839| Risk Level | Impact x Probability | Action Required |40| ---------- | -------------------- | ----------------------------- |41| Critical | HIGH x HIGH | Executive approval, full plan |42| High | HIGH x MED | Full rollback plan required |43| Medium | MED x MED | Standard rollback procedures |44| Low | LOW x LOW | Minimal documentation |4546## Red Flags - STOP4748- "Deployment is straightforward"49- "Can roll back if needed"50- "No time for risk analysis"51- "Testing caught everything"52- "We'll figure it out if something breaks"5354**All mean: Apply skill before deployment or document explicit risk acceptance.**5556## Rationalizations Table5758| Excuse | Reality |59| --------------------------- | ------------------------------------------------------------------------ |60| "Deployment is simple" | No deployment is risk-free. Even simple changes have unexpected impacts. |61| "Can roll back if needed" | Rollback must be defined BEFORE deployment, not during incident. |62| "No time for risk analysis" | 15 minutes of analysis prevents hours of incident response. |63| "Tested in staging" | Staging doesn't replicate production. Risk analysis still required. |64| "Too much work to back out" | Sunk cost fallacy. Better to delay than rush and fail. |6566## Evidence Checklist6768- [ ] Change scope documented (component, dependencies, traffic)69- [ ] Minimum 3 failure modes identified with detection criteria70- [ ] Risk rating for each failure mode71- [ ] Rollback procedure with timeline72- [ ] Go/No-Go criteria explicit and measurable73- [ ] Prerequisites checklist provided74- [ ] Deployment strategy selected with rationale75- [ ] Success criteria defined
mcj-coder