Rolbacks y recuperación de la estabilidad

(Sección: Tecnologías e Infraestructura)

Resumen breve

La reversión es un retorno administrado a la última versión estable con un riesgo mínimo de pérdida de datos e infracciones de SLO. El proceso confiable incluye: señales SLO, gates claros y criterios de retroceso, mecanismo de conmutación (GitOps/Ingress/mesh), esquema de datos compatible, confecciones/secretos/cachés aislados, ciclo de mejora de Runabook-i y post-incidente.

1) Cuándo retroceder (criterios de inicio)

SLO/Business Gates: p95/99 por encima del umbral, error-rate ↑, caída de la conversión de pagos/apuestas, aumento de temporizadores PSP.
Señales técnicas: caídas de pods, fugas de memoria, aumento de colas, degradación de tokens (LLM), 5xx en Edge.
Riesgo de datos: migraciones incorrectas, inconsistencia de réplicas, transacciones/pagos huérfanos.
Seguridad/PII: sospecha de fuga - retroceso/aislamiento inmediato.

Regla: si 2 + métricas clave están más allá de los umbrales> N minutos - se inicia la reversión.

2) Tipos de rolback

1. Aplicación: revierte los contenedores/paquetes a la etiqueta anterior.
2. Fichi: apagado instantáneo a través de feature flag/kill-switch.
3. Enrutamiento: devolver el peso a una versión estable (canary→stable) o Blue→Green.
4. Base de datos: retorno lógico (compensación), retorno gradual del sistema; PITR es una medida extrema.
5. Infraestructura: reversión de manifiestos/Plan Terraform; devuelve configuraciones de red/WAF.
6. Datos/caché/colas: restablecimiento/discapacidad/repetición de mensajes; cachés de versión.

3) Principios arquitectónicos de reversión segura

Compatibilidad de esquemas: estrategia de expand→migrate→contract (la reversión es posible entre expand y contract).
Dependencias aisladas: secretos separados/confecciones/cachés/colas para revisiones.
Operaciones idempotentes: repetir el inicio de las migraciones y job es seguro.
Inmutabilidad de artefactos: imágenes, listas, scripts SQL - versionados y firmados.
GitOps-true: la versión actual y el enrutamiento están registrados en el repositorio de manifiesto.

4) Mecánica de retroceso (Kubernetes/GitOps)

Argo Rollouts (retorno de peso)

yaml apiVersion: argoproj. io/v1alpha1 kind: Rollout metadata: { name: api }
spec:
strategy:
canary:
steps:
- setWeight: 5
- pause: { duration: 10m }
in case of analysis failure → automatic rollback to stable

GitOps-reversión (idea)

git revert <commit_with_bad_version>
git push # Argo CD/Flux revert cluster to previous revision

NGINX: Sweet rápido en stable

nginx map $cookie_canary $to_canary { default 0; 1 1; }
upstream stable { server api-stable:80; }
upstream canary { server api-canary:80; }
server {
location / {
if ($to_canary) { proxy_pass http://canary; }
proxy_pass http ://stable; # removed canary cookie - instant rollback
}
}

5) Rolback DB y protección de datos

• Expand: agregue nuevos campos/índices, el código admite el esquema antiguo y nuevo.
• Migrate: el código comienza a escribirse en un nuevo esquema, el antiguo no se rompe.
• Contrato: eliminamos el viejo sólo después de la estabilización.
• PITR/snapshots: utilice sólo cuando no sea posible la compensación lógica.
• Compensación: scripts/jobs individuales para corregir inserciones/balances/pagos.
• Sólo en las ventanas: cuando se critica, bloqueamos temporalmente la entrada para «congelar» el estado.

sql
-- expand
ALTER TABLE wallet ADD COLUMN bonus_balance NUMERIC DEFAULT 0 NULL;
CREATE INDEX CONCURRENTLY idx_wallet_bonus ON wallet(bonus_balance);

-- migrate in code, two-sided write
-- contract (after stabilization)
ALTER TABLE wallet DROP COLUMN legacy_bonus_balance;

6) Colas y cachés al revertir

Caché de versión: las claves con prefijo de versión ('v2:') → una coexistencia segura.
Discapacidad: al retroceder - limpieza masiva 'v2:', volver a 'v1:'.
Colas: lotes/topics por versión; interrupción de mensajes «desde el punto de control».
Deduplicación/idempotencia: claves de idempotencia para volver a procesar sin tomas.

7) Gates SLO y patines automáticos

Métricas: p95/99, error-rate, saturations (CPU/IO/GPU), queue depth, tokens/sec, conversión de pagos.

if p95_latency_ms > 250 for 5m OR error_rate > 1. 5% for 3m OR payment_conv < baseline-0. 3%
then rollback release && open incident && freeze deploys

8) Runabooks (playbooks)

A) Crecimiento p99 y 5xx después del lanzamiento

1. Stop promote (congelar canario/azul-verde).
2. Tráfico Switch para una revisión estable.
3. Compruebe los retardos de caché/cola/PSP.
4. Desmontar diagnósticos: registros, perfiles, versiones de clientes/esquemas.
5. Comunicación: ChatOps, canal de estado, incidente-tarjeta.
6. Iniciar la acción correctiva: parche/fix en caliente/cancelar fiches.

B) Error en la migración de la DB

1. Freeze writes (read-only, breve).
2. Revertir la aplicación → una versión estable (compatible con el esquema antiguo).
3. Ejecutar el script de compensación/rollback.
4. Descongelar la grabación; observar la deriva/errores.

C) Degradación de pagos (PSP)

1. Cambiar el enrutamiento PSP a la ruta anterior.
2. Reversión de la versión de procesamiento.
3. Conciliación de todos los pagos pendientes, repetición con llaves idempotentes.

D) LLM/recomendaciones degradadas

1. Desactivar el nuevo modelo/parámetros (feature flag).
2. Devolver el anterior endpoint/peso; borrar la caché KV de la nueva revisión.
3. Comprobar tokens/s, primer token latency, toxicidad.

9) Comunicaciones y versiones de congelación

Ventana libre: después de la reversión - pausa de lanzamientos a RCA/fix.
Canal único: status-updates, cronología de acciones, quién hizo qué.
Stakeholder: producto/CS/pagos/abogados (bajo PII).

10) Post-incidente: manejo y prevención

RCA (sin cargos): la causa raíz, la contribución de los factores por los que las gaitas no funcionaron (si no funcionaron).
Acciones: pruebas de migración, límites, gates de fixflag, observabilidad.
Umbral SLO: ajuste si es demasiado «blando «/» duro ».
Documentación: actualizar runabooks, añadir alertas, entrenamientos (game-day).

11) Herramientas y plantillas

GitOps: Argo CD/Flux - 'revert '/' rollback' commita con versión.
Entrega progresiva: Argo Rollouts/Flagger - parada/retroceso métrico.
Edge/Ingress: enrutamiento de peso, enrutamiento de cookies, sweet rápido.
Feature flags: fractional rollout, kill-switch.
Migración de DB: Unos pocos frameworks con up/down, dry-run, throttling.
Observabilidad: dashboards terminados «release compare» (stable vs canary).

12) Lista de verificación de preparación para reversión

1. Artefactos versionados y firmados (imágenes/listas/SQL).
2. Confecciones/secretos/cachés/colas de dos carriles (prefijos de versión).
3. Diagrama de DB por expand→migrate→contract.
4. Lanzamientos canarios y azules con gatitos SLO y patines automáticos.
5. Runabooks en escenarios clave (pagos/DB/caché/LLM).
6. Los botones ChatOps son: '/rollback ', '/freeze', '/promote '.
7. Auditoría y lógica: quién, cuándo, qué retrocedió; artefactos de diagnóstico.
8. Entrenamiento de día de juego: simulando fallos y recuperaciones.
9. Un plan de comunicaciones con negocios y sapport.
10. Métricas de comparación (stable vs new) en una pantalla.

13) Anti-patrones

Migraciones destructivas antes de la distribución de código (sin compatibilidad inversa).
Cachés/colas compartidas sin versiones → reversión «sucia».
La falta de GitOps/historial de cambios → las ediciones «manuales» en el prod.
Lanzamiento canario sin gates/telemetría → detección posterior.
Retroceso sin freeze y RCA → repetición del incidente.
Supervise sólo los Tehdmétricos sin métricas de negocio (pagos/apuestas).
Los «secretos comunes» a todas las revisiones → difíciles de aislar el incidente.

los Totales

El robusto rolback no es un «stop-grifo», sino un proceso incorporado en las versiones: versionabilidad e interoperabilidad, dependencias aisladas, gates SLO, realidad GitOps, retrocesos automáticos y rúbricas claras. Este enfoque permite que las plataformas iGaming recuperen estabilidad rápidamente, minimizando la pérdida de datos e ingresos, y convirtiendo cada incidente en una fuente de mejoras.