Checklist de Despliegue sin Tiempo de Inactividad

Descripcion General

Los despliegues sin tiempo de inactividad actualizan servicios de produccion sin interrumpir a los usuarios. Este checklist ayuda a los equipos a verificar que los health checks, el enrutamiento de trafico, las migraciones de base de datos y los planes de rollback esten en su lugar antes y durante un release.

Cuando Usar

• For alternatives, see Blue-Green Deployment.

• Liberar una nueva version de un servicio orientado al usuario.

• Desplegar migraciones de esquema o datos que afecten multiples instancias.

• Cambiar infraestructura que pueda impactar la disponibilidad.

• Introducir una nueva estrategia de rollout como canary o blue-green.

• Prepararse para un evento de alto trafico donde la estabilidad es prioritaria.

Prerequisitos

• Un pipeline de despliegue con etapas automaticas de build, test y publish.
• Endpoints de health check que representen la verdadera disponibilidad de la aplicacion.
• Load balancer, ingress o controlador de trafico que soporte rollout gradual.
• Estrategia de migracion de base de datos compatible hacia atras.
• Plan de rollback con artefacto y estado de datos conocidos como buenos.
• Monitoreo y alertas para tasa de error, latencia y metricas de negocio.
• Plan de comunicacion para stakeholders y clientes.

Solucion

Checklist

1. Preparacion Pre-Despliegue

• El cambio de despliegue esta aprobado y documentado.
• El codigo esta mergeado y el artefacto esta construido y taggeado.
• Las pruebas unitarias, de integracion y de contrato pasan automaticamente.
• Las migraciones de base de datos se revisaron para compatibilidad hacia atras.
• Los feature flags estan configurados para habilitacion segura.
• La capacidad y limites de escalado son suficientes para el trafico esperado.
• Los dashboards y alertas de monitoreo estan activos.
• La rotacion de guardia conoce la ventana de despliegue.
• Los pasos de rollback estan documentados y probados en un entorno no productivo.
• La comunicacion orientada al cliente esta preparada si es necesario.

2. Configuracion de Health Checks

Check	Endpoint	Criterio de Exito	Accion ante Falla
Liveness	/health/live	HTTP 200	Reiniciar contenedor
Readiness	/health/ready	HTTP 200 y dependencias arriba	Detener enrutamiento de trafico
Startup	/health/startup	HTTP 200	Retrasar despliegue
Dependency	/health/deps	Base de datos, cache, cola alcanzables	Alertar y detener
Business	/health/business	Flujo critico devuelve valor esperado	Paginar al guardia

3. Seleccion de Estrategia de Rollout

Estrategia	Caso de Uso	Nivel de Riesgo	Velocidad de Rollback
Rolling update	Servicios sin estado, bajo riesgo	Bajo	Media (terminar nuevos pods)
Blue-green	Sesiones stateful, releases predecibles	Medio	Rapida (cambiar trafico de vuelta)
Canary	Alto riesgo, metricas medibles	Medio	Rapida (drenar canary)
Feature flag	Exposicion gradual de usuarios	Bajo	Instantanea (apagar toggle)
A/B deployment	Validar comportamiento de usuarios	Medio	Rapida (re-rutear trafico)

4. Pasos de Ejecucion del Despliegue

Paso	Accion	Verificacion
1	Desplegar en staging y ejecutar pruebas de humo	Pruebas de staging pasan
2	Desplegar canary o subconjunto pequeno	Health checks pasan, tasa de error estable
3	Monitorear metricas clave durante la duracion del canary	Latencia, tasa de error, metricas de negocio dentro de la linea base
4	Incrementar porcentaje de trafico gradualmente	Cada etapa pasa health checks y verificaciones de metricas
5	Completar rollout al 100%	Todas las instancias saludables y sirviendo trafico
6	Validar endpoints de produccion	Pruebas de humo y flujos criticos de usuario pasan
7	Mantener version anterior disponible para rollback	Retener durante la ventana de rollback definida
8	Confirmar que la ventana de rollback ha pasado	Eliminar version anterior o actualizar la linea base del artefacto

5. Seguridad de Migraciones de Base de Datos

• Las migraciones son aditivas y compatibles hacia atras con la version anterior.
• El codigo viejo puede leer el nuevo esquema sin errores.
• El codigo nuevo puede leer el esquema viejo si se requiere rollback.
• Los indices se crean concurrentemente donde se soporta.
• Las migraciones grandes se dividen en lotes mas pequenos.
• Los jobs de relleno de datos o migracion son idempotentes.
• El script de rollback o operacion compensatoria esta disponible.
• Los cambios de base de datos se prueban en staging con datos similares a produccion.

6. Disparadores de Rollback

Disparador	Umbral	Accion
Pico de tasa de error	> 0.5% durante 2 minutos	Pausar despliegue e investigar
Aumento de latencia	p99 > linea base + 30% durante 5 minutos	Revertir trafico
Caida de metrica de negocio	Tasa de conversion cae > 5%	Rollback inmediato
Falla de health check	> 10% fallando	Rollback inmediato
Alerta critica	Cualquier incidente P1	Rollback y paginar al guardia
Timeout de canary	La etapa canary excede la duracion sin aprobar	Rollback del canary

7. Validacion Post-Despliegue

• Los logs de aplicacion no muestran errores inesperados.
• La tasa de error y latencia estan dentro de la linea base.
• Las metricas de negocio son estables o mejoran.
• Todos los feature flags estan en el estado deseado.
• Los recursos antiguos se limpian despues de la ventana de rollback.
• El resumen del despliegue se comparte con el equipo.
• Cualquier problema se registra en el issue tracker con duenos.

Explicacion

Los despliegues sin tiempo de inactividad dependen de tres cosas: mecanismos de rollout seguros, senales de salud confiables y rollback rapido. Un checklist asegura que cada release considere el enrutamiento de trafico, la compatibilidad de datos y la observabilidad antes de que cualquier usuario sea expuesto. Combinar esta disciplina con la automatizacion reduce el riesgo de incidentes en produccion y mejora la confianza en los releases.

Configuracion de Rolling Update en Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-gateway
spec:
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 3
      maxUnavailable: 0
  template:
    spec:
      containers:
        - name: api
          image: registry.example.com/api:v2.3.1
          readinessProbe:
            httpGet:
              path: /health/ready
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 5
            failureThreshold: 3
          livenessProbe:
            httpGet:
              path: /health/live
              port: 8080
            initialDelaySeconds: 10
            periodSeconds: 10
            failureThreshold: 3
          lifecycle:
            preStop:
              exec:
                command: ["sh", "-c", "sleep 15 && kill -SIGTERM 1"]
      terminationGracePeriodSeconds: 60

Configuracion de Canary con Argo Rollouts

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: api-gateway
spec:
  replicas: 10
  strategy:
    canary:
      steps:
        - setWeight: 10
        - pause: { duration: 5m }
        - analysis:
            templates:
              - templateName: success-rate
            args:
              - name: service-name
                value: api-gateway
        - setWeight: 30
        - pause: { duration: 5m }
        - analysis:
            templates:
              - templateName: success-rate
            args:
              - name: service-name
                value: api-gateway
        - setWeight: 50
        - pause: { duration: 10m }
        - setWeight: 100
  selector:
    matchLabels:
      app: api-gateway
  template:
    metadata:
      labels:
        app: api-gateway
    spec:
      containers:
        - name: api
          image: registry.example.com/api:v2.3.1
          ports:
            - containerPort: 8080

Variantes

• Checklist de rolling update en Kubernetes: Enfoque en readiness probes, max surge, max unavailable y pod disruption budgets.
• Checklist de despliegue blue-green: Enfoque en el switch de trafico, compatibilidad de base de datos y retencion de versiones.
• Checklist de despliegue canary: Enfoque en umbrales de metricas, pesos de trafico progresivos y puertas de rollback automatico.
• Checklist de despliegue serverless: Enfoque en versionado de funciones, enrutamiento de alias y gestion de etapas de API Gateway.
• Checklist de despliegue con mucha base de datos: Enfoque en compatibilidad de esquema, orden de migraciones y scripts de rollback.
• Checklist de despliegue movil o cliente: Enfoque en rollout escalonado, manejo de actualizaciones forzadas y compatibilidad de API.

Lo que funciona

• Manten los despliegues pequenos y frecuentes para reducir el riesgo.
• Haz que los cambios de base de datos sean compatibles hacia atras con el codigo viejo y nuevo.
• Usa health checks que verifiquen dependencias reales, no solo la vida del proceso.
• Automatiza el rollback basado en metricas, no solo en puertas de decision manual.
• Monitorea metricas de negocio, no solo metricas tecnicas.
• Manten un artefacto baseline conocido como bueno para rollback rapido.
• Practica rollbacks en staging o durante game days.
• Documenta las decisiones y resultados del despliegue para futuras revisiones.

Errores Comunes

• Omitir health checks o usar verificaciones HTTP 200 triviales.
• Desplegar cambios de base de datos que no son compatibles hacia atras.
• Enrutar el 100% del trafico antes de validar metricas.
• No tener un plan de rollback antes de iniciar el despliegue.
• Ignorar el aumento de latencia a favor solo de la tasa de error.
• Limpiar versiones antiguas demasiado pronto.
• Desplegar durante picos de trafico sin planificacion de capacidad.

Troubleshooting

• Pipeline fails silently: enable verbose logging and store pipeline artifacts between stages so you can inspect the exact state that failed.
• Container crashes on startup: check that environment variables, secrets, and config files are mounted correctly. Read the first 50 lines of logs before scaling replicas.
• Deployment rolls back repeatedly: verify health checks, resource limits, and startup probes. A failing readiness probe is a common cause of rolling restarts.
• Slow CI builds: cache dependencies and docker layers. Split large test suites into parallel jobs to reduce wall-clock time.
• Drift between environments: use infrastructure-as-code and immutable artifacts.

Lectura Adicional

• Documentación oficial: consulta la referencia actualizada del framework o herramienta utilizada.
• Guías relacionadas: explora las guías de deployment y zero-downtime para profundizar.
• Patrones complementarios: revisa los patrones de diseño aplicables a tu stack tecnológico.
• Postmortems públicos: estudia incidentes reales de equipos que enfrentaron problemas similares en producción.

Notas de Producción

• Despliega gradualmente usando canary o blue-green para detectar regresiones temprano.
• Configura alertas para errores, latencia p99 y tasa de fallos antes de habilitar en producción.
• Documenta el rollback en el runbook; prueba el procedimiento en staging al menos una vez por trimestre.
• Revisa logs estructurados con correlation IDs para trazar requests end-to-end en incidentes.

Puntos Clave

• Aplica checklist de despliegue sin tiempo de inactividad cuando necesites una solución práctica para tu caso de uso.
• Monitorea el rendimiento después de implementar; mide latencia, errores y uso de recursos antes y después.
• Revisa la sección de Troubleshooting ante errores comunes; la mayoría tienen causa raíz documentada con solución.
• Mantén dependencias actualizadas y ejecuta tests en CI para prevenir regresiones en producción.

Errores Comunes en Producción

• Dejar campos requeridos vacíos o usar respuestas vagas de una palabra.
• Llenar el documento una vez y nunca actualizarlo cuando cambia el alcance o las decisiones.
• Guardar el documento donde el equipo no lo busque durante incidentes o revisiones.
• No asignar un responsable, fecha límite o cadencia de revisión.
• Copiar texto base sin eliminar secciones que no aplican.
• Saltar el control de versiones, lo que impide rollback y responsabilidad.
• No vincular el documento con decisiones relacionadas o acciones de seguimiento.
• Evitar revisiones trimestrales que retirarían secciones obsoletas o sin uso.