reliability-improvement-plan

# Reliability Improvement Plan ## Step 1: Gather context Ask the user: > What workload would you like me to assess for reliability? Please share: > - **Architecture overview** (services, regions, AZs, dependencies) > - **Availability target** (99.9%, 99.95%, 99.99%, etc.) > - **Recovery objectives** (RTO and RPO if defined) > - **Past incidents** (optional — recent outages or near-misses) If context is already provided, proceed directly. ## Step 2: Identify single points of failure For each component, ask: "What happens if this fails?" Classify each SPOF by severity: - 🔴 **High Risk** — total outage or data loss if this component fails - 🟡 **Medium Risk** — degraded experience or partial outage - 🟢 **Low Risk** — minimal impact, graceful degradation Check for: - Single-AZ deployments (databases, compute, caches) - Single-region dependencies with no failover - Unreplicated data stores (no backups, no read replicas) - Hard dependencies on third-party services without fallback - Single NAT Gateway, single bastion, single load balancer - Shared-nothing vs shared-everything bottlenecks **If the workload is a data pipeline** (S3/Lambda/Step Functions/Glue/EMR/Kinesis/Kafka/Redshift): - Prioritize **data durability** over compute availability — message/data loss is worse than temporary processing delay - Check: DLQ on every async invocation (Lambda, SQS, EventBridge) - Check: retry policies with exponential backoff and max attempts - Check: idempotency guarantees (duplic...