Despliegue sin Tiempo de Inactividad

El Problema

Cada despliegue es un riesgo: usuarios encontrando errores, sesiones rotas, transacciones perdidas. Los enfoques tradicionales de “detener-desplegar-iniciar” crean ventanas de indisponibilidad que erosionan la confianza y cuestan ingresos. Incluso breves caidas durante horas pico pueden desencadenar perdida de clientes, pagos fallidos y violaciones de SLA que persiguen a tu equipo durante meses.

El Prompt

Eres un arquitecto de infraestructura de despliegue. Diseña una estrategia de despliegue sin tiempo de inactividad para mi aplicacion.

CONTEXTO DE LA APLICACION:
- Arquitectura: [ej., monolito, microservicios, serverless]
- Infraestructura actual: [ej., AWS ECS, Kubernetes, bare metal, Vercel]
- Base de datos: [ej., PostgreSQL, MongoDB, DynamoDB]
- Patron de trafico: [ej., constante, con picos, regional]
- Metodo de despliegue actual: [ej., SSH manual, pipeline CI/CD, orquestador de contenedores]

Analiza y recomienda:
1. **Seleccion de estrategia**: Compara blue-green vs canary vs rolling para mi caso especifico. Recomienda una con justificacion.
2. **Plan de implementacion**: Configuracion paso a paso incluyendo cambios de infraestructura, configuracion del balanceador de carga y diseño de health checks.
3. **Compatibilidad de base de datos**: Como manejar migraciones de esquema sin romper la version anterior (patron expand-contract).
4. **Distribucion de trafico**: Define los porcentajes exactos de division de trafico y duracion para cada fase.
5. **Validacion de salud**: Que metricas verificar antes de enviar el 100% del trafico (tasa de error, latencia p99, saturacion).
6. **Criterios de aborto**: Define triggers automaticos de rollback con umbrales especificos.
7. **Runbook**: Un manual operativo paso a paso para el equipo de despliegue.

Ejemplo de Salida

Estrategia: Despliegue canary (recomendado sobre blue-green para tu arquitectura de microservicios — menor costo de recursos, ciclo de retroalimentacion mas rapido)
Fase 1: Desplegar instancia canary (5% trafico) → monitorear 10 minutos
Fase 2: Escalar a 25% → verificar tasa de error < 0.1%, latencia p99 < 200ms por 15 minutos
Fase 3: Escalar a 50% → mantener 10 minutos, verificar compatibilidad de migracion de BD
Fase 4: Escalar a 100% → decomisionar instancias anteriores tras periodo de estabilizacion de 30 minutos
Aborto: Rollback automatico si tasa de error > 0.5% O p99 > 500ms O fallos de health check > 3 consecutivos

Cuando Usarlo

Usa este skill al desplegar aplicaciones que sirven trafico en vivo y no pueden permitirse tiempo de inactividad — productos SaaS, plataformas de e-commerce, APIs con clientes de pago. Esencial al migrar de despliegues manuales a pipelines automatizados, o cuando tu proceso actual de despliegue causa incidentes.

Consejos Pro

• Comienza con migraciones de base de datos primero — despliega el cambio de esquema antes del cambio de codigo usando el patron expand-contract. Esto asegura que ambas versiones del codigo puedan ejecutarse simultaneamente.
• El tiempo de estabilizacion importa mas que el porcentaje de trafico — un canary al 5% corriendo 30 minutos detecta mas problemas que un canary al 50% corriendo 2 minutos.
• Prueba tu rollback antes de necesitarlo — programa un simulacro donde intencionalmente dispares un rollback. El peor momento para descubrir que tu rollback esta roto es durante un incidente en produccion.
• Los feature flags complementan los despliegues — separa el despliegue de codigo de la activacion de funcionalidades. Despliega en modo oculto, luego activa via flags con capacidad de rollback instantaneo.