Reversión automática de versiones

1) ¿Por qué necesitas un auto-retroceso?

• reduce CFR y MTTR;
• protege SLO (auth-success, p99 «stavka→settl», error-rate);
• previene incidentes de cumplimiento (PII/RG/AML).

2) Principios

1. Revert is a feature: se planea un retroceso durante el diseño de la versión.
2. Policy-as-Code: umbrales, ventanas, excepciones - validación en la canalización.
3. Canary-first: promoción a través de los pasos, retroceso - espejado a los pasos.
4. Data-safe: las migraciones son reversibles/sumativas; configuraciones - versionables.
5. SLO-gates: SLI/guardrails rojos → retroceso automático inmediato.
6. Explainability: timeline, diffs, causas - en la revista WORM.
7. No hay botón único de doom: restricciones, confirmaciones de riesgo, SoD.

3) Disparadores de retroceso automático (señales)

3. 1 SLI/KRI técnico

auth_success_rate drop por GEO/PSP/BIN (por ejemplo, −10% en TR ≥10 min).
latency p99/error-rate de las maneras clave (depósito/retiro/settl).
queue lag / DLQ rate / retry storm.
db replication lag / cache miss surge.

3. 2 Señales de negocios

deposit_conversion −X p.p. en Canarias contra el control.
settle throughput caída con respecto a la línea base.
chargeback/decline spikes (soft/hard).

3. 3 Eventos críticos

Falla de SRM en la A/B activa (distorsión del tráfico).
Activación del guardrail de seguridad/PII.
Incompatibilidad de esquemas/configuraciones (validador/linter).

4) Patrones de reversibilidad arquitectónica

Canarias → Ramp → Full: promoción del 5%→25%→100%; retroceder - en orden inverso (100→25→5→0).
Blue-Green: sweet atómico de tráfico entre Blue y Green, retroceso - retorno instantáneo.
Características Flags: kill-switch para cambios de comportamiento (TTL, guardrails, SoD).
Config as Data: GitOps-promoción/re-promoción de la versión anterior; runtime-snapshots.

• dos fases (expand→contract),
• reversible (scripts down),
• write-shadow (se escriben nuevos campos duplicados),
• read-compat (el código antiguo entiende el nuevo esquema).

5) Políticas de retroceso (policy-engine)

• `auto_rollback if auth_success_rate. drop(geo="TR") > 10% for 10m AND coverage>=5%`
• `auto_rollback if bet_settle_p99 > SLO1. 25 for 15m`
• `auto_pause_flag if api_error_rate > 1. 5% for 5m`
• `deny_promote if slo_red in {"auth_success","withdraw_tat_p95"}`
• `require_dual_control if change. affects in {"PSP_ROUTING","PII_EXPORT"}`

Todas las reglas son versionadas, probadas y sometidas a rugido.

6) Flujo de auto-retroceso (end-to-end)

1. El detector de regresión se activa (métrica/alerta/validador).
2. Comprobación de excepciones (picos festivos, ventanas de prueba).

7) Integraciones

Incidente bot: '/release rollback <id> ', auto-timelines, enlaces a dashboards y diffs.
Metrics API: estados SLO-view y guardrail terminados; exemplars para RCA.
Características Flags: '/flag off <id> ', autocaravana por guardrail.
GitOps/Config: `/config rollback <snapshot>`; el detector drift confirma el resultado.
Página de estado: apdates públicos opcionales (a través de CL/política).

8) Observabilidad y telemetría de retroceso

Release Dashboard: auth-success, error-rate, p95/p99, settle throughput, PSP по GEO/BIN.
Guardrail Board: reglas activas/activas, ventanas, histéresis.
Historia de las coberturas:% canarias/banderas/regiones en el tiempo.
Auditoría: quién/qué/cuándo/por qué; Los diffs de artefactos; versión de directivas; el resultado.

9) Seguridad, SoD y cumplimiento

4-eyes/JIT para las acciones que afecten a los pagos/PII/RG.
Geo-fences: los retrocesos que afectan a los requisitos regulatorios se aplican localmente.
Registros WORM: rastro inmutable para comprobaciones.
Paquetes de comm públicos: congruentes con CL/Legal; los detalles de los experimentos hacia afuera no se revelan.

10) Ejemplos de artefactos

10. 1 Política de retroceso automático (YAML)

yaml apiVersion: policy.platform/v1 kind: AutoRollbackRule metadata:
id: "payments-auth-success-tr"
spec:
scope: { tenants: ["brandA","brandB"], regions: ["EU"], geo: ["TR"] }
signal:
metric: "auth_success_rate"
condition: "drop > 10% for 10m"
compareTo: "canary_control"
action:
strategy: "step_down"  # 100%->25%->5%->0%
cooldown: "15m"
exceptions:
calendar: ["2025-11-29:black_friday"]
manualOverride: false audit:
owner: "Payments SO"
riskClass: "high"

10. 2 Manifiesto de reversión de configuración

yaml apiVersion: cfg.platform/v1 kind: ConfigRollback metadata:
id: "psp-routing-revert-2025-11-01"
spec:
from: "payments-routing-2025-11-01"
to:  "payments-routing-2025-10-29"
criteria:
- metric: "auth_success_rate"
where: "geo=TR"
condition: "drop>10% for 10m"
notify:
incidentBot: true stakeholders: ["Payments","SRE","Support"]

10. 3 bandera Kill-switch

yaml apiVersion: flag.platform/v1 kind: KillSwitch metadata:
id: "deposit.flow.v3"
spec:
guardrails: ["api_error_rate<1.5%","latency_p99<2s","slo_green:auth_success"]
autoPauseOnBreach: true ttl: "30d"

11) Trabajo con migraciones de datos

• Expansión: añadir nuevas columnas/índices sin romper la lectura.
• Migrate: doble grabación/réplica, conciliación de consistencia.
• Contrato: eliminar el antiguo sólo después de una versión exitosa + ventana de vigilancia.
• Scripts down: obligatorios; estimación de tiempo y bloqueos.
• Lecturas de sombras: comparación de los resultados de la vía antigua/nueva (sin efectos secundarios).
• Criterios de cancelación del contrato: cualquier guardrail «rojo».

12) Procesos y RACI

Release Manager: propietario de la canalización y las políticas.
Service Owner: aprueba las reglas del dominio, acepta el riesgo.
SRE: implementa detectores, mecánicas de retroceso, dashboards.
Seguridad/Cumplimiento: SoD, control PII/RG, auditoría.
On-call IC/CL: comunicaciones, status page.
AMB: revisión post-factum de las revisiones automáticas, ajuste de las reglas.

13) KPI/KRI función

Tasa Auto-Rollback: proporción de lanzamientos que se retrotraen automáticamente (norma: baja, pero no cero).
Time-to-Rollback: detekt→otkat (mediana/p95).
SLO-Breach Avoided: casos en los que el retroceso automático evitó la violación de objetivos.
False Positives: proporción de retrocesos «falsos» (el objetivo es ↓).
CFR antes/después de la introducción de auto-reversión.
Costo de Rollbacks: tiempo extra, canarios, recursos informáticos.
Audit Completeness:% de los eventos con línea de tiempo completa y diffs.

14) Hoja de ruta para la implementación (6-10 semanas)

Ned. 1-2: catálogo de métricas críticas y umbrales básicos; selección de estrategias (canary/blue-green/flags); Inventario de reversibilidad de las migraciones.
Ned. 3-4: implementación de detectores y policy-engine; integración con el incidente bot; GitOps-rollback para las confecciones; dashboards guardrails.
Ned. 5-6: piloto en el dominio Payments (auth-success, PSP routing), entrenamiento tabletop; registro WORM e informes.
Ned. 7-8: expansión en Games/KYC; pausa automática de las banderas; Enseñanzas de DR con azul-verde.
Ned. 9-10: calibración de umbrales, reducción de falsos positivos, valoración de costes de FinOps, formalización de RACI y formación.

15) Antipattern

«Retrocedamos de alguna manera»: la falta de plan y la reversibilidad de las migraciones.
Activación/desactivación instantánea global sin escalones.
Retroceder por métricas crudas sin contexto (sin estratificación GEO/PSP/BIN).
Ignora el SRM y el peeking en experimentos.
Alertas de lanzamiento sin histéresis → patines de flapping.
Edición manual de las confecciones en venta sin Git/Audit.
Elimina el esquema antiguo antes de pasar la ventana de vigilancia.

Resultado

La reversión automática de lanzamientos es una rejilla protectora de la plataforma: políticas como código, señales y umbrales correctamente seleccionados, soluciones arquitectónicas reversibles (canary/blue-green/flags/reversible migrations), comunicaciones integradas y auditoría completa. Este circuito reduce drásticamente el riesgo de lanzamientos, protege los SLO y los ingresos y aumenta la confianza de los reguladores y socios.