Implementación Zero-Downtime

(Sección: Arquitectura y Protocolos)

1) Qué es Zero-Downtime y por qué es necesario

• Cero fácil para clientes e integraciones.
• Versiones predecibles, retroceso rápido y riesgo administrado.
• Mantener SLO/SLI (latencia, errores, disponibilidad) dentro de los límites de los arreglos.

La clave de ZDT no es una técnica «mágica», sino una combinación de patrones de entrega, compatibilidad de datos y enrutamiento competente del tráfico.

2) Principios básicos de Zero-Downtime

1. Compatibilidad de versiones: las versiones nuevas y antiguas deben manejar correctamente el tráfico y los datos al mismo tiempo.
2. Idempotencia de las operaciones: el tratamiento repetido no debe romper el estado.
3. Terminación graciosa (graceful shutdown) y drenaje de conexiones.
4. Control de salud paso a paso: readiness/liveness muestreos, endpoints de salud.
5. Retroceder como ciudadano de primera clase: rollback es más fácil y más rápido que hotfix.
6. Observabilidad por diseño: etiquetas de lanzamiento, dashboards únicos, alertas por SLO.
7. Automatización: scripts de lanzamiento y reversión - código, no instrucciones manuales.

3) Patrones de envío sin downtime

3. 1 Rolling Update

Poco a poco sacamos del tráfico algunas de las instancias de la versión antigua, las actualizamos a la nueva y las devolvemos al pool.

Ventajas: ahorra en infraestructura, sólo en k8s/ASG.
Contras: durante un tiempo, el clúster funciona con dos versiones al mismo tiempo (versión skew).

3. 2 Blue-Green

Dos pilas prod completas: la activa (Azul) y la candidata (Verde). Cambio de tráfico - flip atómico.

Ventajas: retroceso instantáneo, aislamiento puro.
Contras: ↑ el gasto en infraestructura, más difícil con stateful.

3. 3 Canario/Rollout progresivo

Damos una pequeña fracción de tráfico (1-5-10-25-50-100%) a la nueva versión con gates por métricas.

Ventajas: mínimo blast radius, soluciones data-driven.
Contras: necesita una observabilidad madura y un enrutamiento inteligente.

3. 4 Shadow traffic / Dark launch

Espejamos solicitudes reales a una nueva versión (sin responder al usuario) o ejecutamos ocultas para recopilar métricas.

Ventajas: detección temprana de problemas.
Contras: doble carga de dependencia, necesita control de efectos secundarios.

4) Gestión del tráfico y las conexiones

4. 1 Readiness/Liveness

Liveness le dice al orquestador que «me reinicie».
Readiness - «No dirija el tráfico, todavía no estoy listo».
No se puede liberar sin la lógica readiness y los tiempos de espera correctos.

4. 2 Drenaje de conexiones

• dejamos de aceptar nuevas conexiones,
• esperando a que finalicen los activos,
• interrumpimos a los «colgantes» por el tiempo de espera.

4. 3 sesiones de Sticky y enrutamiento de nivel L7

Sticky es útil en scripts stateful, pero complica el equilibrio de carga.
Las reglas L7 (en ruta, título, cookies, versiones API) son convenientes para canary/ring.

4. 4 Conexiones de larga vida

WebSocket/gRPC streaming: antes de actualizar, active el modo drain + la señal «GOAWAY».
Planifique Windows para superar las retracciones de streaming y backoff de los clientes.

5) Compatibilidad de datos y migración de DAB

5. 1 Expand-Migrate-Contract

1. Expansión: agregamos nuevas columnas/índices/tablas sin romper la versión anterior.
2. Migrar: Transferimos datos de fondo e idempotente (batchs, checkpoints).
3. Contrato: eliminamos el viejo sólo después de la estabilización.

5. 2 Prácticas

Evite los locks DDL exclusivos en la ventana de lanzamiento.
Verifique los contratos de API/eventos (registro schema, CDC).
Para migraciones pesadas: herramientas en línea, réplicas, conmutación por etapas.
Grabación de dos circuitos (dual-write) sólo con deduplicación y consumidores idempotentes.
Outbox/Inbox para una integración confiable a través de las colas.

6) Cachés, sesiones y trabajos de fondo

Las sesiones y la caché son externas (Redis/Memcached) para que las versiones sean intercambiables.
Calienta la caché/jits/índices de ritmo antes de incluirla en el grupo.
Divide las colas de fondo por versión o usa el liderazgo para evitar carreras.

7) Observabilidad y getas por SLO

Señales de oro: latencia p95/p99, error rate, RPS, saturation, maga colas.
SLA de negocios: autorizaciones, conversiones, pagos exitosos, denegación de pasos de embudo.
Gates: el rollout sólo avanza si canary ≤ baseline + umbrales de degradación y error budget no se quema.

8) Finalización y retroceso seguros

Un retroceso es la misma pipeline, sólo hacia atrás: comandos fijos, no «manual kraft».
Para blue-green - flip back; para canario - restablecer el peso hasta 0% o el paso anterior estable.
Datos: transacciones compensatorias, re-procesamiento, deduplicación de eventos.

9) Hojas de cheques Zero-Downtime

Antes de la versión

• Se ha recogido un artefacto firmado (immutable), un SBOM y una verificación de dependencias.
• Readiness/liveness implementado y probado.
• Plan de migración en modo expand, reversibilidad confirmada.
• Los dashboards y alertas para la nueva versión están listos, las marcas de lanzamiento están listas.
• Reversión verificada en staging/pre-prod.

Durante la versión

• El drenaje de compuestos está habilitado, los temporizadores son adecuados.
• El tráfico se traduce gradualmente (canary/ring) o flip (blue-green).
• Las métricas se comparan con la baselina, se respetan los umbrales de las gatitas.

Después de la

• Seguimiento Post-N horas, no hay incidentes.
• Se han completado las migraciones de contrato, se han eliminado las banderas/rutas temporales.
• Retrospectiva, actualización de playbooks.

10) Anti-patrones

Recreate-deploy sin drenaje y readiness ⇒ acantilados de solicitudes.
DDL no preparados ⇒ bloqueos y tiempos de espera en prime time.
Mezcla de esquemas incompatibles entre versiones del servicio.
Ninguna idempotencia en procesadores y workers.
«Montar por sensaciones» sin gates y comparaciones con baseline.
Largo DNS-TTL en azul-verde, lo que hace que el flip dure horas.
Sesiones locales/caché en memoria de instancia en rolling/canary.

11) Escenarios de implementación

11. 1 Kubernetes (rolling + canary)

Deployment с `maxUnavailable=0`, `maxSurge=25%`.
Readiness está esperando para calentarse (inicialización de caché, migración minor).
Mesh/Ingress con routing weighted (1-5-10-25-50-100%).
Alertas: p95, 5xx, fila de magos, embudo de negocios.

11. 2 Azul-Verde en la nube

Dos pilas detrás del equilibrador: 'blue. example. com` и `green. example. com`.
Calentamiento verde, smoke/regresión, luego listener/route swap (o conmutación DNS con baja TTL).
En caso de problemas, flip back instantáneo.

11. 3 Stateful-servicio

Réplicas de datos + migración en línea; doble lectura con validación.
Los frijoles de fondo se transfieren según la versión de «liderazgo» o las colas divididas.
Sesiones/caché fuera de instancia; sticky sólo está activado temporalmente.

12) Fichflags y aplicaciones de cliente

Los nuevos fichajes se activan con banderas (segmentos: empleados → beta → todos).
En el caso de los clientes móviles/de escritorio, tenga en cuenta los límites de compatibilidad del protocolo y la vitalidad de las versiones antiguas (política de depreción, servidor-lado fallback).

13) Rendimiento y costo

Rolling es más barato, pero requiere una compatibilidad cuidadosa.
Blue-Green es más caro para el tiempo de lanzamiento, pero la vuelta es instantánea.
Canarias equilibra los riesgos y el coste, pero requiere una fuerte observabilidad.
Ahorre dinero a través de la previsualización ephemeral y la limpieza automática de los stands.

14) Pipeline de referencia mínima ZDT

1. Build: un solo artefacto, firma, SBOM.
2. Test: unit/integration/contract + security.
3. Staging: smoke, carga, migraciones en modo expand, comprobación de reversión.
4. Prod: shadow → canary (gates) o blue-green flip.
5. Post-deploy: observación, aprox-cleanup, retro.

15) Breve resumen

Zero-Downtime es una disciplina: versiones compatibles + enrutamiento correcto + migraciones gestionadas + observabilidad y reversión rápida. Elija un patrón bajo contexto (rolling, blue-green, canary), automatice las gateways por SLO, mantenga los datos idempotentes - y las liberaciones dejarán de ser un evento, convirtiéndose en un proceso de rutina confiable.