Estrategias de Rollback y lanzamientos atómicos

Estrategias de Rollback y lanzamientos atómicos

1) ¿Por qué se necesita un retroceso rápido?

• Reducir MTTR a minutos.
• Limitar el radio de la lesión (mínimo de usuarios/transacciones afectadas).
• Mantener la integridad de los datos y la compatibilidad de los contratos.

Clave: construir lanzamientos para que el retroceso sea una acción trivial y no un mini proyecto.

2) Concepto de «liberación atómica»

Liberación atómica: cuando la inclusión de una nueva versión/comportamiento se puede realizar (y cancelar) con una sola operación atómica sin efectos secundarios duraderos.

• Artefacto inmutable (imagen/paquete firmado).
• Confecciones versionadas (versiones promocionales, no ediciones manuales).
• Separar «entrega» de «encendido» (enrutamiento/banderas).
• Esquema de datos compatible (ambas versiones pueden vivir simultáneamente).
• Runbook back: un paso claro (cambio de selector/peso/bandera) + chequeo.

3) Inventario de mecanismos rollback

3. 1 Nivel de tráfico (el más rápido)

Azul-Verde: cambiar el selector/grupo de destino a una versión estable.
Canarias: bajar el peso al 0% y congelar la progresión.
Gateway/NGINX/Service Mesh: recuperar los pesos/rutas anteriores.

3. 2 Nivel transportador

Helm/Argo Rollouts: 'abort/rollback' a la revisión anterior.
GitOps: revert MR/commit en el repositorio de manifiesto (el controlador hará el resto).

3. 3 Apéndice/ficha

Feature-flags/kill-switch: apaga instantáneamente el camino arriesgado.
Confecciones Toggle: Volver a la configuración de snapshot anterior.

3. 4 Datos

Migración roll-forward (preferida) + compatibilidad.
Recovery Point-in-time (PITR) y backups para accidentes.
Indemnizaciones (Saga) e idempotencia para acciones reversibles.

4) Patrón «expand → migrate → contract» (DB)

Para que la reversión sea segura, el diagrama de datos debe permitir que las versiones antiguas y las nuevas vivan.

1. Expand: agregue nuevos campos/índices (nullable) sin romper la vieja lógica.
2. Migrate - doble escritura/lectura, back-fill, fondo job's con idempotency.
3. Contrato: elimina los campos/códigos antiguos después de salir al 100% y la ventana envejecida.

5) SLO-gaming y auto-retroceso

La entrada a cada paso del lanzamiento debe estar «custodiada» por métricas.

SLO técnico: p95/p99 latencia, 5xx-rate, saturación (CPU/Memoria), error-budget burn.
Métricas de negocio: CR en depósito/cassout, denegación de pago, porcentaje de frod, errores KYC.

• 5xx > 0. 5% 10 minutos → rollback.
• p95 ↑> 20% del → base hold + análisis.
• PSP> 0 tiene un error. 3 p. p. → rollback + cambiar la ruta de pago.

6) Ejemplos: Kubernetes/Helm/Argo/NGINX

6. 1 Blue-Green (K8s Service selector)

yaml
Service points to "blue"; switch to green - change selector apiVersion: v1 kind: Service metadata: {name: app-svc}
spec:
selector: { app: app, version: blue }
ports: [{ port: 80, targetPort: 8080 }]

Retroceder = Devolver el selector a 'blue' (atómico, sin recomposición).

6. 2 Canary (Istio VirtualService веса)

yaml http:
- route:
- destination: { host: app, subset: stable } # 100 weight: 100
- destination: { host: app, subset: canary } # 0 weight: 0

Retroceso = peso canario → 0, stable → 100.

6. 3 Argo Rollouts — abort

yaml kubectl argo rollouts abort app # stop and return to stableService

6. 4 Helm - rollback a la revisión

bash helm history app -n prod helm rollback app 17 -n prod # revert to revision 17

6. 5 pesos NGINX - upstream

nginx upstream app {
server blue:8080 weight=100;
server green: 8080 weight = 0; # rollback - return 100/0
}

7) Feature-flags y kill-switch como «paracaídas»

Kill-switch para flujos de alto riesgo (depósitos/pagos/bonos) - obligatorio.
Stickiness: asignar a los usuarios una «opción» a través de una clave hash - comparaciones predecibles.
Fail-safe: si el servidor de bandera no está disponible, es un default seguro.

ts const enabled = flags. bool("new_cashout_flow", false);
if (! enabled) return classicFlow () ;//instant rollback - disable the return newFlow () flag;

8) Contratos de API y eventos: cómo no «romper el retroceso»

Versionar contratos (OpenAPI/gRPC/Avro): la nueva versión añade campos, no cambia la semántica de los antiguos.
Event-versioning: 'type = v2', los consumidores están obligados a ignorar campos desconocidos.
Outbox + Idempotency: cualquier repetición del evento es segura, el consumidor es idempotente.

9) Transacciones compensatorias (Saga)

• Se realizó un cargo - compensación: devolución, reversión, registro de corrección.
• Registro de operaciones compensatorias y retiros hasta el éxito.
• Llaves idempotentes para cada operación.

json
{
"sagaId": "b7d2...",
"action": "withdraw. execute",
"idempotencyKey": "user123:withdraw:7845",
"compensation": "withdraw. refund"
}

10) Configuraciones y secretos: retroceder como versión

Almacene las confecciones como artefactos con versiones (semver/commit-sha).
Revertir = devolver la configuración a la versión anterior (GitOps revert) en lugar de «corregir con las manos».
Secretos - a través del almacenamiento (KMS/Vault); la rotación y la versificación se incluyen en el lanzamiento.

11) Runbook de retroceso (mínimo)

1. Pausa de progresión (canario/rollouts).
2. Retorno del tráfico (peso/selector).
3. La validación de las métricas SLO/Business ha vuelto a la línea de base.
4. Estabilización del fondo job's (detener las migraciones/back-fill si es necesario).
5. Incidente y post-factum: artefactos (logs/tracks/métricas), hipótesis, corrección.
6. Limpieza: cierra las banderas, elimina el código dejado, devuelve los horarios de job's.

12) Políticas de protección automática

Prohibición de 'latest' y etiquetas mutables para imágenes.
Control Admission: sólo los artefactos firmados.
Puerta CI: SAST/SCA/Policy-checks debe ser verde para la promoción.
Ventana libre: prohibición de lanzamientos/peso> X% en períodos de riesgo.

13) Anti-patrones frecuentes

«Retroceder» la base DDL-abajo en lugar de la compatibilidad - bloqueo largo/simple.
Migraciones instantáneas «de frente» sin idempotencia y back-fill.
Mezclar «entrega» e «inclusión»: no hay manera de recuperar el tráfico rápidamente.
Correcciones manuales en la configuración prod sin auditoría.
No hay kill-switch en los pagos/retiros.
Reconfiguración del artefacto para prod (infracción «build once - run many»).
No hay un solo botón de retroceso/runbook no usado.

14) Lista de verificación de implementación (0-45 días)

0-10 días

Habilitar Blue-Green/Canary en los servicios clave.
Prohibir 'latest', incluir la firma de la imagen y el historial de Helm/Argo.
Conectar tableros SLO (latency, 5xx, señales clave de negocio).

11-25 días

Implementar kill-switch para el flow de riesgo.
Traducir migraciones de DB a expand-migrate-contract + idempotency.
Añadir auto-stop/rollback por SLO (Argo AnalysisTemplate/alerts).

26-45 días

Versionar las configuraciones (GitOps), revertir a través de MR-revert.
Enrollar el runbook en «game-day» (simulación de incidente y retroceso).
Introducir la Saga-compensación donde no es posible retroceder «hacia abajo».

15) Métricas de madurez

MTTR de retroceso: objetivo <5 min.
% de las versiones en las que el retroceso = cambio de ruta/bandera (sin reenvío)> 90%.
Porcentaje de migraciones según el esquema expand-migrate-contract> 90%.
Cobertura de servicios kill-switch con banderas> 95%.
Número de incidentes debidos a esquemas/contratos incompatibles → 0.

16) Aplicaciones: mini plantillas

Argo AnalysisTemplate: parada de 5xx

yaml apiVersion: argoproj. io/v1alpha1 kind: AnalysisTemplate metadata: { name: guard-5xx }
spec:
metrics:
- name: http_5xx_rate interval: 1m successCondition: result < 0. 005 provider:
prometheus:
address: http://prometheus. monitoring:9090 query:
sum(rate(http_requests_total{app="app",status=~"5.."}[5m])) /
sum(rate(http_requests_total{app="app"}[5m]))

Kubernetes: retroceso rápido de Deployment

bash kubectl rollout undo deploy/app -n prod

Helm: liberación atómica

bash helm upgrade --install app chart/ \
--atomic \
--timeout 5m \
--set image. tag=v1. 9. 3

NGINX: «grúa» para Canarias

nginx map $cookie_canary $weight {
default 0;
"~ on" 10; # enable 10% by cookie
}

17) Conclusión

Un retroceso fiable no es un «botón de fuego», sino una propiedad de la arquitectura: artefactos inmutables, separación de entrega e inclusión, esquema de datos compatible, banderas de fichas y juego de SLO. Construya lanzamientos atómicos, ensaye el runbook y automatice las puertas de seguridad - y cualquier lanzamiento será reversible en minutos, sin dolor para las empresas y los usuarios.