This document outlines the process for rolling back infrastructure changes in PredictIQ.
All infrastructure is managed through Terraform and stored in version control. Rollbacks are performed by reverting to a previous Terraform state or code version.
- AWS CLI configured with appropriate credentials
- Terraform installed (version 1.5.0+)
- Access to the Terraform state bucket
- Appropriate IAM permissions for the target environment
For code-based rollbacks:
# Identify the commit to revert
git log --oneline infrastructure/terraform/
# Revert the commit
git revert <commit-hash>
# Push the revert commit
git push origin main
# GitHub Actions will automatically plan and apply the rollbackFor emergency rollbacks without code changes:
# Navigate to infrastructure directory
cd infrastructure/terraform
# Initialize Terraform
terraform init
# List available state versions
aws s3api list-object-versions \
--bucket predictiq-terraform-state \
--prefix prod/terraform.tfstate
# Restore previous state version
aws s3api get-object \
--bucket predictiq-terraform-state \
--key prod/terraform.tfstate \
--version-id <VERSION_ID> \
terraform.tfstate.backup
# Backup current state
cp terraform.tfstate terraform.tfstate.current
# Restore previous state
cp terraform.tfstate.backup terraform.tfstate
# Plan the rollback
terraform plan -var-file="environments/prod.tfvars"
# Apply the rollback
terraform apply -var-file="environments/prod.tfvars"To rollback only specific resources:
# Taint the resource to force recreation
terraform taint module.ecs.aws_ecs_service.api
# Plan and apply
terraform plan -var-file="environments/prod.tfvars"
terraform apply -var-file="environments/prod.tfvars"After rollback, verify the infrastructure:
# Check Terraform state
terraform show
# Verify AWS resources
aws ec2 describe-instances --filters "Name=tag:Environment,Values=prod"
aws rds describe-db-instances --filters "Name=db-instance-id,Values=predictiq-prod"
aws elasticache describe-cache-clusters --cache-cluster-id predictiq-prod
# Test API connectivity
curl https://api.predictiq.example.com/health| Environment | Rollback Time | Data Loss Risk |
|---|---|---|
| Dev | 5-10 minutes | Low |
| Staging | 10-15 minutes | Low |
| Prod | 15-30 minutes | Medium |
- Infrastructure Team: infrastructure@predictiq.example.com
- On-Call Engineer: Check PagerDuty
- AWS Support: AWS Support Console
- Notify stakeholders of the rollback
- Document the reason for rollback
- Create incident report
- Schedule post-mortem if needed
- Update runbooks based on lessons learned
The rollback procedure must be exercised at least once per quarter in the staging environment to verify it remains accurate and executable under time pressure.
Drills are calendar events owned by the Infrastructure team. The recurring event is titled "PredictIQ Infrastructure Rollback Drill" and runs on the first Tuesday of each quarter (January, April, July, October) at 14:00 UTC.
To add or update the calendar invite, contact infrastructure@predictiq.example.com or the current on-call rotation lead.
- Announce the drill in
#infrastructureat least 24 hours in advance. - Pick a recent non-critical infrastructure change (e.g., a variable or tag update) as the target.
- Execute the Rollback via Git Revert procedure documented above against the staging environment.
- Time the end-to-end duration and record it in the table below.
- Run the verification commands from the Rollback Verification section to confirm the environment recovered.
- File a PR updating this table and any procedure corrections before the end of the same business day.
| Date | Environment | Procedure used | Duration | Issues found | Fixed in PR |
|---|---|---|---|---|---|
| 2026-04-01 | Staging | Git revert | 12 min | None | — |
| 2026-01-07 | Staging | Git revert | 18 min | Step 3 link broken in old runbook | #612 |
Add a new row after each drill. If no issues are found, write "None". If the drill is skipped, record the date, reason, and the name of the person who approved the skip.
If a drill reveals that a step is wrong or missing:
- Fix the procedure in this file in the same PR that records the drill result.
- Have a second on-call engineer review the correction before merging.
- Re-run the affected step in staging to confirm the fix before the PR is merged.
- Always test infrastructure changes in dev/staging first
- Use
terraform planto review changes before applying - Implement code review for infrastructure changes
- Maintain automated backups of critical data
- Monitor infrastructure metrics for anomalies