Zero-Downtime Deployment and Severity-Based Alert Routing

You're building zero-downtime deployment and rationalized alert routing for Valentina Rios, CTO at DataPulso -- a Bogota SaaS analytics platform whose Sunday 2am maintenance window has stopped working.

The discipline skills: blue/green deployment on ECS via CodeDeploy with a rollback you actually trigger during business hours to prove it works; a defensible Kubernetes-vs-ECS recommendation informed by a working local kind cluster; canary deployment with evaluation criteria named before the deploy begins, not discovered during it; severity-based alert routing wired to PagerDuty with distinct SNS topics for SEV-1, SEV-2, and SEV-3; a pair of SLO burn-rate alerts that fire on error-budget consumption rather than arbitrary thresholds.

The AI-direction lesson is that at this altitude, AI produces the configured shape but omits the safety. It generates a blue/green deployment with a rollback toggle and never suggests testing rollback. It writes Kubernetes manifests without resource limits or probes. It configures a canary with traffic weights but no evaluation criteria. It routes every alert at the same severity because severity is context it does not have. It recommends Kubernetes by default because the training data over-indexes on Kubernetes content. You hold Valentina's specific context -- 40 people, Series B, 200 enterprise clients, ECS works today -- against AI's generic enthusiasm, and you catch what it leaves out.

Your Role

Valentina has the conceptual grasp but not the bandwidth. She has read about blue/green and canary; she has not configured CodeDeploy. She has used Kubernetes at a previous company; she has not stood one up from scratch. You direct Claude Code through the implementation, verify output against DataPulso's specifics, and produce artifacts her five-person infrastructure team will actually use.

The collaborative register continues from P9-P10 but the judgment sharpens. AI drafts each artifact in a recognizable shape. You verify the shape is safe -- probes on the pods, evaluation criteria on the canary, severity differentiation on the alerts, rollback tested on the blue/green.

What's New

Last time in Johannesburg you designed Thabo's operational framework -- a triage model, a post-incident review against SARB expectations, audience-segmented communication templates, a certificate-expiration alarm, and an on-call rotation sketch for a six-person team. The work was organizational design for humans.

This time two columns advance at once -- deployment and observability both step up to mid-high -- and the project is design-forward for an active team rather than framework authoring. You return to Slack for first contact, but with a decisive CTO who writes in four-sentence bursts and mixes Spanish and English. Discovery is full: her opening message names symptoms, and the conversation surfaces what she has not said.

The hard part: "configured" and "tested" look the same from the outside. A blue/green with an untested rollback reads fine in Terraform and fails at 3am. A canary without evaluation criteria is just a small deployment nobody evaluates. AI will produce both without flagging the gap. Your job is to know which safety is real.

Tools

• Claude Code -- drafts CodeDeploy configurations, Kubernetes manifests, canary evaluation criteria, CloudWatch alarms, PagerDuty escalation policies, and the SLO burn-rate metric math. Meta-prompting continues from P9-P10.
• AWS ECS, ECR, CodeDeploy -- blue/green and canary deployments for the datapulso-api service.
• AWS CloudWatch, SNS -- severity-split SNS topics and the alarms wired to each; metric math for burn-rate alerts.
• PagerDuty -- new: on-call integration, escalation policies, severity-to-service mapping; the PagerDuty Terraform provider manages routing as IaC.
• Kubernetes via kind -- new: local cluster for Kubernetes fundamentals; kubectl and kind CLI; a small Helm chart for the evaluation.
• Docker -- container builds for the canary validation and the kind exercises.
• Terraform CLI, AWS CLI v2, AWS Console, checkov, tflint, VS Code, Git/GitHub -- carrying forward. New commit prefixes: deploy:, alert:, k8s:.

Materials

In the project folder:

• Valentina's first-contact Slack message -- four sentences, sparse, the entry artifact. You run full discovery from here.
• AWS sandbox description -- the datapulso-api ECS service, the ALB and target groups, the RDS and Redis backing stores, the 30 CloudWatch alarms piping into one #alerts channel, the PagerDuty service with every engineer on it.
• Deployment-strategy reference -- blue/green, canary, and rolling at a high level. You adapt for the DataPulso case.
• Kubernetes-vs-ECS decision framework -- structure only, factors named (team size, operational overhead, portability, ecosystem). The recommendation is yours.
• Valentina voice-calibration notes -- her Spanish/English code-switching patterns for Slack replies.

No CodeDeploy configuration, no Kubernetes manifests, no canary evaluation criteria, no severity cut-points, no PagerDuty escalation policy, no SLO burn-rate windows, and no recommendation content are provided. You produce all of them.