Operaciones y Administración → Gestión de cambios

Administración de cambios

1) Nombramiento y principios

Objetivo: proporcionar cambios de forma rápida y segura, reduciendo el riesgo de incidentes, downtime e infracciones regulatorias.

• Predictable & Reversible: cada cambio es planificable, verificable y reversible.
• Risk-based: la profundidad del control depende del riesgo (jurisdicción, dinero, PII).
• Small & Frequent: los incrementos pequeños son más fáciles de evaluar y revertir.
• Automation first: infraestructura como código, pruebas, validaciones, verificaciones automáticas.
• Fuente única de la verdad: un único RFC/ticket, un único calendario y un registro de acciones.

2) Alcance

Código de producto (backend/frontend, SDK móviles).
Infraestructura (IaC, Kubernetes/VM/CDN/Edge).
Datos (diagramas de DB, migraciones, escaparates/ETL).
Configuraciones y banderas de fichas.
Integraciones (PSP, KYC, proveedores de juegos).
Políticas de seguridad y acceso.

3) Roles y RACI

Propietario del cambio (Change Owner) - Responsable.
Comisario de lanzamiento/RelEng - Coordinación del tren de lanzamiento.
SRE/Ops - Operación, puerta SLO/SLA.
Seguridad/Cumplimiento: validación de riesgos y cumplimiento.
AMB (Change Advisory Board) - Aprobación de cambios normales/de alto riesgo.
Stakeholder de negocios/soporte - Informed.

4) Clasificación de cambios

Estándar (tipo, preaprobado): frecuente, de bajo riesgo, por playbook terminado (por ejemplo, actualización de bandera, rotación de claves).
Normal: requieren RFC, una evaluación, un posible CAF, pruebas y un plan de reversión.
Emergencia: ficciones urgentes para incidentes P1; el camino burocrático mínimo, el post-hecho de rugir/SAV.

5) Ciclo de vida del cambio

1. Iniciación (RFC): objetivo, volumen, riesgo, servicios/regiones afectadas, plan de respaldo.
2. Evaluación del Riesgo: Matriz Impact × Likelihood, Impacto en SLO/Cumplimiento/Costo.
3. Planificación: ventana, dependencias, migraciones, comunicaciones, validación de pruebas.
4. Validación: autotestas, análisis estático, cheque de seguridad, performance-running.
5. Despliegue: estrategia progresiva (ver § 8), telemetría y gardrailes.
6. Observación: burn-rate SLO, alertas, métricas de negocios (GGR/NGR, conversión).
7. Finalización: aceptación del resultado, actualización de la documentación, post-mortem en caso de desviaciones.

6) RFC: composición mínima

Contexto: por qué cambiamos, hipótesis de influencia.
Rango: sistemas, regiones, versiones de clientes.
Riesgo: matriz y escenarios de fallo, blast radius.
Plan de despliegue: paso a paso, con criterios de «ir/parar».
Plan de reversión (Backout): comandos/pasos, condiciones de inicio, espera RTO/RPO.
Plan de prueba: que comprobamos antes/después (funcionalidad, rendimiento, seguridad).
Comunicaciones: a quién alertamos, plantillas de mensajes.
Auditoría: referencias a tickets, commits, artefactos CI/CD.

7) Calendario de cambios y ventanas

Calendario único: todos los lanzamientos, migraciones, apagones, eventos externos (deportes/marketing/vacaciones).
Ventanas libres: grandes ventas/campeonatos/horas punta, informes fiscales.
Política de intersecciones: prohibir los cambios conflictivos por los mismos caminos críticos.
Olas regionales: primero las regiones «cálidas »/bajo tráfico, luego las principales.

8) Estrategias técnicas de implementación

Canarias: pequeña proporción de tráfico → comparación de métricas (p95 latencia, error%, conversión).
Azul-Verde: ambientes paralelos, conmutación de ruta atómica.
Progressive Delivery: porcentaje-rollo con condiciones de parada automáticas.
Características Flags: interruptores funcionales, kill-switch, A/B.
Dark Launch/Shadow Traffic: verificación de sombras sin afectar a los usuarios.
Límites escalonados: aumento gradual de QPS/competitividad.

Gardrailes: parada automática cuando se superan los umbrales de p95/error%, aumento de devoluciones/chargebacks, caídas de autorizaciones/depósitos.

9) Cambios en los datos y esquemas

Compatibilidad: migraciones extensivas (additive) → código que lee tanto el antiguo como el nuevo esquema.
Migraciones bifásicas: (1) añadir nuevos campos/índices → (2) cambiar el código de → (3) eliminar el antiguo.
Versificación de contratos: Avro/Protobuf esquemas con registro; back/forward compatible.
Migraciones de grandes volúmenes: batches, pausas, idempotencia, acuñaciones y progreso.
Resistencia al desastre: prueba de RPO/RTO, snapshots, ensayos de recuperación.
Datos BI: cambio de vitrinas/métricas - a través de MR/SR y diccionario de métricas (ID, fórmula).

10) Gestión de configuraciones y secretos

Config as Data: confecciones versionadas, validación de circuitos, promoción a través de los alrededores.
Secretos: rotación de claves, principios de privilegios mínimos, auditoría de accesos.
Sobreexplotación regional: límites/socios (PSP/KYC) - a través de parametrización, no a través de forks de código.

11) Cumplimiento y auditoría (contexto iGaming)

Huellas de cambio: quién/cuándo/qué cambió (banderas, configuraciones, rutas, migraciones).
Segregación de Duties: diferentes roles para autor, revolver y deploer (SOX-similar).
Informes regulatorios: fix releases, control de versiones de liquidación (GGR/NGR, bonificaciones), control de accesos PII.
Proveedores: versiones fijas de los certificados SDK/proveedores, obligaciones SLA.

12) Comunicaciones

Plantillas de alerta: antes de la liberación (qué/cuándo/riesgos), durante (estado,% del tráfico, métricas), después (resultados).
Mensajes externos: banners/status page cuando afecta a los clientes.
Coordinación: canal # release-war-room, propietario de la versión, frecuencia de los apdates.

13) Métricas de eficacia

DORA: Deployment Frequency, Lead Time for Changes, Change Failure Rate (CFR), MTTR.
SLO Impact: la proporción de tiempo en SLO antes/después de los lanzamientos.
Backout Rate: tasa de reversión por categoría de cambio.
Release Debt: migraciones/flags pendientes en el limbo.
Business Impact: conversión, KYC TTV, éxito rate PSP, GGR/NGR drift en rodillos.

14) Anti-patrones

Grandes lanzamientos de bang: muchos cambios a la vez - es difícil entender la razón de la regresión.
Migraciones incompatibles: eliminar/cambiar el nombre de los campos sin doble lectura.
Banderas sin propietarios y plazos de retirada: ramificaciones «eternas» de la lógica.
Lanzamientos sin telemetría y criterios de parada: «a la vista» y posterior detección de daños.
Ignorar calendario: intersecciones con eventos/campañas pico.
Pasos manuales sin playbooks y auditorías: alta variabilidad y riesgo.

15) Hojas de cheques

Antes de comenzar (RFC listo)

• Los cambios de objetivo y KPI están formulados
• Riesgo y blast radius evaluado, clase de cambio seleccionado
• El plan de implementación y Backout se especifican paso a paso
• Hay un plan de prueba y resultados en stage/canar
• Se actualizan las comunicaciones y el calendario, se notifican los stakeholder

Durante la distribución

• Las métricas de p95/error%, las señales de negocio y los registros se monitorizan en tiempo real
• Los pasos de progreso se confirman mediante cheques-puntos
• Cuando se activan los gardrailes - auto-parada y retroceso

Después

• Los resultados del lanzamiento están registrados (changelog, versiones, artefactos)
• Post-mortem en caso de desviaciones (≤ 5 días hábiles)
• Las deudas (eliminación de banderas, migraciones finales) se registran en el backklog con los propietarios

16) Mini plantillas

• Objetivo/Hipótesis
• Volumen e influencias (servicios, regiones, datos, clientes)
• Riesgo (Impact × Likelihood) y medidas de reducción
• Plan de distribución (pasos,% de tráfico, criterios go/no-go)
• Plan de respaldo (pasos, RTO/RPO, datos)
• Plan de prueba (funcionalidad/rendimiento/seguridad)
• Comunicaciones (canales, frecuencia)
• Artefactos (tickets, PR, números de build)

• Cambio: "Payments-Service v2. 14 + migración psp_limits"
• Ventana: 2025-11-02 00: 00-01: 00 EET
• Regiones afectadas: UE, LATAM (10%→50%→100%)
• Riesgos/gardrailes: error%> 2% 10 min - parar y retroceder
• Contactos: @ Owner, @ SRE-on-call, @ Support-lead

• Desencadenadores: p95> + 25% 10 min, éxito PSP <97%
• Pasos: (1) tráfico −→ 0% por v2. 14; (2) cambiar las banderas a v2. 13; (3) reversión de la migración a través de snapshot/checkpoint; (4) pruebas de humo; (5) informe.

17) Integración con el tren de lanzamiento

Tren de lanzamiento: ranuras fijas (por ejemplo, 2 × por semana), SLA en merge-cut.
Política de Hotfix: trenes/ramales separados, vía acelerada en prod.
Versioning: semver, etiquetas en artefactos y entornos, SBOM.

18) Resultado

El control de cambios no es un freno para la velocidad, sino un mecanismo de aceleración segura. La clasificación orientada al riesgo, los buenos RFC, el enrollamiento progresivo, las migraciones de datos compatibles, las comunicaciones claras y la medición del efecto convierten las versiones en un proceso administrado, repetible y auditable.