Scripts de reversión de cambios

(Sección: Operaciones y Gestión)

1) Por qué se necesitan escenarios de reversión

Incluso con pruebas perfectas, parte de los cambios conducen a la degradación. La reversión es una operación de retorno administrada a una versión «segura» predefinida sin pérdida de datos ni cumplimiento. Objetivos: reducir el MTTR, proteger el dinero/datos, mantener la confianza de los socios y reguladores.

2) Clasificación de cambios y enfoques de retroceso

Código y contenedores: artefactos versionables → azul-verde, canario, rolling con retroceso instantáneo a la imagen anterior.
Configuraciones/fichflags: feature toggle rollback, conmutadores atómicos con TTL y auditoría.
Esquemas DB: expand → migrate → contract, migraciones bidireccionales, columnas «sombreadas», backfill en el fondo.
Datos/listas de precios/impuestos: versiones de artefactos ('fx _ version', 'tax _ rule _ version', 'pricelist _ version'), 'congelación' y devoluciones.
Integraciones (PSP/KYC/proveedores de contenido): conmutación de rutas/grupos, fallback a proveedor de respaldo.
Infraestructura/red/CDN: retroceso gradual de reglas/rutas, reversión de certificados/claves de doble arranque.

3) Patrones arquitectónicos para la reversibilidad

Releases inmutables: cada lanzamiento es un artefacto firmado (imagen/configuración) con la opción de seleccionar instantáneamente el anterior.
Capas de compatibilidad: schema-compat (agregar, no eliminar), tolerant-reader en el lado de los consumidores.
Grabación doble (dual-write) y shadow-reads: compara consistencia antes de «conmutar».
Idempotencia y sagas: pasos compensatorios para transacciones de servicios cruzados.
Fichflags: apagado rápido/activación por etapas en lugar del redeploy «caliente».

4) Estrategias de laminación con puntos de retorno

Canary N%: métricas/guardaespaldas → en degradación auto-retroceso; con éxito - extensión hasta 100%.
Blue-Green: dos pilas prod; Cambiar el tráfico y volver al rollback instantáneo.
Rolling with pause: actualización por lotes con «puntos de pausa» y posibilidad de retroceder a la ola anterior.
Fichflags por cohorte: «dark start», whitelists, banderas regionales/tenant.

5) Reversión de la DB y las migraciones: plantillas seguras

1. Expand: añadir nuevas columnas/índices/endpoints, el código escribe en ambas versiones.

2. Migrate: backfill y validaciones; leer «sombra» de la nueva estructura.

3. Contrato: deshabilitar el antiguo después de la estabilidad.

Bidireccionalidad: cada migración tiene un 'down ()'; para conjuntos grandes - revertir logical (banderas, enrutamiento) en lugar de eliminar físicamente.

Snapshots/point-in-time: PITR/snapshot de tablas antes del lanzamiento crítico.

Control de esquemas: validadores de contratos en CI/CD + "dry-run' en staging/réplica.

6) Reversión de los datos del catálogo/precios/impuestos

Versione las listas de precios y las normas fiscales; guarde los recibos de publicación.
En los pedidos, confirme 'fx _ version '/' tax _ rule _ version' - la devolución no rompe los cheques antiguos.
En «PriceMismatch» → memoria caché de fuerza-invalidez, devolución a la versión anterior del artefacto, compensación por política.

7) Integraciones y proveedores externos

PSP/KYC/contenido: mantenga las rutas de respaldo, muestras de salud, conmutación rápida DNS/LB, claves individuales.
Webhooks: activa write-drop y colas; cuando se desactiva - un replay de «cartas muertas» con llaves idempotentes.
Certificados/claves: doble carga (antiguo + nuevo), comprobación de compatibilidad antes de cambiar.

8) Automatización de retrocesos («runas») y guardaires

Руны (кнопки): Rollback Release, Disable Flag, Re-route, Flush Cache, Scale Back, Restore Schema.
Guardrailes: el inicio de la reversión está disponible para IC/propietario; registro firmado (DSSE), límites de frecuencia de operación, lista de verificación de confirmación.
Auto-retroceso: condiciones de SLO/percentils/errores/señales financieras (por ejemplo, Δ quote↔checkout ≠ 0).

9) Comunicaciones y artefactos

En la tarjeta de lanzamiento: versión, hashes, lista de cheques de prepago, playback, responsables.
Al retroceder: marcas de tiempo, causa, volumen de tráfico afectado, artefactos (enlaces de registro, métricas antes/después).
Comunicaciones externas (status page/partners): concisa y factual.

10) Playbucks de retroceso (referencia)

1. Re-route/Blue-Green back → 2) Fijar la versión → 3) bloquear otros clips → 4) forensic.

1. Disable Feature Flag (100%) → 2) limpieza de caché/folback → 3) ticket para corrección.

1. detener el heavy-backfill → 2) devolver la lectura al esquema antiguo (dual-read off) → 3) bajar la carga/índices → 4) estimar el 'down ()' o retroceso lógico.

1. retroceder 'pricelist _ version '/' tax _ rule _ version' → 2) invalidar la caché edge → 3) compensar y conciliar los cheques.

1. conmutación a PSP redundante → 2) cuarentena de transacciones «grises» → 3) repetición de cola después de la estabilización.

1. volver a la clave anterior (dual-key) → 2) rotación y replish.

11) RACI

12) Métricas de calidad y SLO

Change Failure Rate (CFR) - Porcentaje de lanzamientos con retirada (objetivo ↓).
MTTR (con retroceso) - mediana del tiempo de retorno a la estabilidad.
Time-to-Rollback - Desde el disparador hasta la finalización del retroceso (P1 ≤ 15-20 min).
Δ-métricas antes/después (p95, error-rate, E2E éxito).
Repeticiones de la misma razón ≤ N/trimestre.
Cobertura de auditoría: 100% de retrocesos con artefactos y firmas.

13) Seguridad, privacidad, cumplimiento

Registros WORM para lanzamientos/revisiones; almacenamiento de artefactos por reguladores.
PII/Finanzas: verificar que la reversión no abra el acceso a zonas no resueltas/políticas antiguas.
SoD: «¿Quién rueda» ≠ «quién aprueba» ≠ «quién inicia el retroceso».
Créditos/secretos: dual-rollover y devolución instantánea a la clave anterior.

14) Efectos financieros y operacionales

Costo de tiempo de inactividad vs costo de reversión: automatice la solución a través de guardaespaldas SLO.
Compensaciones/Créditos de SLA - Plantillas en playbooks.
Egress/compute-cap: el retroceso puede elevar temporalmente la carga (replay/bombeo de cachés) - planifique las ventanas.

15) Lista de verificación antes del lanzamiento (go/no-go)

• Artefactos firmados y punto de retorno (imagen/configuración/versión de datos).
• Plan de aplanamiento y playbook de retroceso (por pasos).
• Migraciones validadas: expand→migrate→contract, PITR está activo.
• Dials/guardaespaldas SLO: condiciones de auto-retroceso en el sistema de alertas.
• Canales de comunicación: IC/Owners/Comms on-call.
• Pruebas de compatibilidad inversa y «carrera seca» en staging.
• Rutas de respaldo para integraciones críticas.
• Plan de comunicaciones (interno/externo.) y plantillas.

16) Lista de verificación en caso de reversión (durante el incidente)

• Confirmar el disparador y el volumen afectado (región/tenante/canal).
• Fijar la versión «a lo que retrocedemos».
• Ejecutar la runa de retroceso (código/bandera/ruta/datos).
• Comprobar SLI/SLO y métricas de negocio (E2E, checkout, webhooks).
• Conciliar directorios/versiones (FX/Tax/PriceList).
• Consolidar la condición: prohibición de nuevos cismas, recolección de artefactos.
• Comunicación: status page, socios, internos.

17) Errores frecuentes y anti-patrones

Retroceder «manualmente» sin artefactos ni firmas.
Migraciones disruptivas sin bidireccionalidad y PITR.
Feature-flag sin «interruptor global».
No hay rutas de respaldo a PSP/KYC.
Limpia la memoria caché sin calentarla → una avalancha de solicitudes en frío.
quote≠checkout no contabilizado después de la devolución de la lista de precios.

18) FAQ

¿Cuándo es mejor retroceder en lugar de arreglar «in situ»?
Cuando se infringe un SLO/riesgo de dinero/datos, es más rápido y seguro volver a una versión estable conocida.

¿Se pueden revertir las migraciones «destructivas»?
Sí, si están diseñados como expand→migrate→contract con 'down () '/PITR y follback lógico.

¿Cómo automatizar una decisión de reversión?
SLO-guardaires (p95, error-rate, Δ-vals, éxito webhooks) + matriz de riesgo → auto-runa.

¿Qué hacer con los pedidos/transacciones «entre»?
Llaves idempotentes, cuarentena de operaciones «grises», réplica de colas con el dedoop.

Resumen: Los escenarios de retroceso no son improvisación, sino una capacidad prediseñada para volver rápidamente a la estabilidad. Versione todo, mantenga un diagrama de datos reversible, use fichflags y canary, automatice runas, fije artefactos y guardaespaldas SLO. Entonces, cualquier lanzamiento sigue siendo manejable y el negocio es previsiblemente estable.