Control de versiones de configuración

1) Por qué versionar configuraciones

Una configuración es una política ejecutable: define el enrutamiento, los límites, las marcas de fijación, los accesos, los esquemas de datos. El control de versiones hace que los cambios sean repetibles, previsibles y reversibles: acorta la tasa MTTR y el cambio-failure, elimina la «magia en venta», da auditoría por seguridad y cumplimiento.

2) Taxonomía de configuraciones

Infraestructura (IaC): clústeres, redes, LB, DB, colas.
Servicio: opciones de aplicaciones, recursos, límites, tiempos de espera, retiros.
Lógica de productos/negocios: tarifas, experimentos AB, reglas de contenido.
Data/DataOps: contratos de circuitos, SLA de frescura, transformación.
Seguridad: directivas de acceso, roles, claves/certificados (los propios secretos están fuera del repo).
Observabilidad: SLI/SLO, alertas, dashboards.

Regla: todo lo que afecta al comportamiento del sistema es la configuración y debe vivir bajo la versificación.

3) Principios de gestión de versiones

1. GitOps: la única fuente de verdad es el repositorio; cambios a través de PR y pipelines automáticos.
2. Declaratividad: descripción del estado objetivo, no scripts de pasos.
3. Inmutabilidad de los artefactos: la confección → un snapshot inequívocamente materializable.
4. Esquemas y validación: JSON/YAML-schema, tipos de ajuste estricto, campos obligatorios.
5. Ambientes como código: 'env' - carpetas/overlays (dev/stage/prod), las diferencias son mínimas y explícitas.
6. Idempotencia y retrocesos: cualquier versión de configuración es reversible (revert/rollback).
7. Auditoría y rastreabilidad: autor, causa, ticket/RFC, firmas de cambios.

4) Estrategias de versionamiento

• MAJOR: cambios incompatibles de esquemas/políticas.
• MINOR - nuevos campos/reglas, compatibilidad inversa.
• PARCHE: corrige los valores sin cambiar los esquemas.
• Versiones tag y notas release: lo que se modifica, cómo retroceder, puntos de control.
• Pinning/lock-files: confirmamos versiones de dependencias (módulos, listas).
• Matrix versiones: el artefacto de la aplicación X es compatible con la configuración Y (matriz en el directorio del servicio).

5) Organización del repositorio

config-repo/
policies/     # общие политики (RBAC, SLO, алерты)
services/
checkout/
schema/    # JSON/YAML схемы конфигов base/     # дефолтные значения overlays/
dev/
stage/
prod/
data-contracts/  # схемы данных, SLA свежести releases/     # теги, changelog, артефакты валидации tools/      # линтеры, генераторы, тесты

Rama: trunk-based (main) + corto feature-rama. Merge - sólo a través de PR con CI obligatorio.

6) Validación y pruebas

Diagrama: cada cambio pasa la verificación del esquema (required, enum, ranges).
Linternas estáticas: formato, claves, tomas, campos prohibidos.
Pruebas de compatibilidad: confit + versión del servicio/chart suben en el sandbox.
Pruebas de ejecución: dry-run aplicaciones, «what-if» diff estado de destino.
Políticas-as-code: reglas de tolerancia (Rego/CEL) - quién y qué puede cambiar.

7) Distribución y reversión de configuraciones

Entrega progresiva: canario 1%→5%→25% con SLO-gardriles.
Puerta deploya: no hay SEV-1 activos, alertas verdes, firmas válidas, retroceso listo.
Retroceso: 'revert tag vX. Y.Z 'o cambiar a un snapshot anterior; los comandos de reversión están documentados en runbook.
Anotaciones de lanzamiento: la versión de configuración se publica en métricas/logs para correlacionarse rápidamente con incidentes.

8) Configuración dinámica y remota

Remote config/feature flags: cambiamos los parámetros sin restart; todas las banderas - también bajo GitOps.
Bordes: qué parámetros se permiten cambiar dinámicamente (lista de listas blancas).
Caché y consistencia: TTL, versiones, reemplazo atómico de conjuntos (publicación en dos fases).
Barandillas seguras: límites y rangos para cambios de runtime, auto-rollback al salir por SLO.

9) Secretos y datos sensibles

Nunca guardamos secretos en los repos. En configuraciones, sólo enlaces/playsholder.
Cifrado de archivos de configuración si es necesario: integración con el gestor de secretos/claves.
Rotación y JIT: los accesos se emiten mientras duran las operaciones; el rastro de las acciones es inmutable.
Camuflaje de campo: la validación prohíbe que PII/secretos caigan en la confección.

10) Gestión del entorno

Base + overlays: las diferencias entre dev/stage/prod son mínimas y transparentes.
Promoción por artefactos: el mismo snapshot que pasó por el escenario avanza en prod.
Ventanas temporales: los cambios en las confecciones no ocurren en el momento del cambio de turno; para risk-high - RFC y ventana de servicio.

11) Detección y eliminación de la deriva

El controlador compara el estado objetivo con el estado real y reporta diff.
Drift-alerts: Page sólo en discrepancias críticas; los demás son Ticket.
Auto-remediación: cuando se resuelve - volver al estado objetivo.
Auditoría de revisiones manuales: cualquier «kubectl edit/ssh» → un incidente de proceso y CAPA.

12) Directorio de configuraciones y propiedad

Directorio de servicios: propietario, SLO, políticas relacionadas, esquemas, versiones, compatibilidad.
RACI: quién propone, quién ruge, quién aprueba; AMB para el alto riesgo.
Transparencia: cada entrada tiene un historial de versiones y enlaces a PR/tickets/AAR.

13) Métricas de madurez

Cobertura:% de los servicios/políticas bajo GitOps (objetivo ≥ 95%).
Tiempo de respuesta de los cambios de configuración: mediana de PR a prod.
Change failure rate: porcentaje de versiones de configuración con recarga/incidente.
Tasa de arrastre: número de discrepancias/semana y tiempo de eliminación.
Rollback time: mediana de recuperación a la versión anterior.
Audit completeness: proporción de cambios con evidencia completa (validadores, dry-run, revisiones).

14) Hojas de cheques

Antes de cambiar la configuración

• Hay un ticket/RFC y el propietario del cambio.
• Validación de circuitos y linternas.
• Hay un plan de retroceso y comandos en el runbook.
• Puerta: las pruebas son verdes, las firmas son válidas, no hay SEV-1 activos.
• Para alto riesgo: se ha asignado una ventana de servicio.

Durante la distribución

• El canario y SLO-gardrailes están activos.
• Se publican anotaciones de la versión.
• Hay mensajes de eco en el canal; el ruido de alerta se suprime según las reglas del MW.

Después de

• Observation window pasado, SLO verde.
• Los resultados y la evolución (gráficos antes/después, informes dry-run) se adjuntan al ticket.
• Se han actualizado los diagramas/documentación según sea necesario.

15) Mini plantillas

15. 1 Esquema de configuración (YAML-schema, fragmento)

yaml type: object required: [service, timeouts, retries]
properties:
service: { type: string, pattern: "^[a-z0-9-]+$" }
timeouts:
type: object properties:
connect_ms: { type: integer, minimum: 50, maximum: 5000 }
request_ms: { type: integer, minimum: 100, maximum: 20000 }
retries:
type: object properties:
attempts: { type: integer, minimum: 0, maximum: 10 }
backoff_ms: { type: integer, minimum: 0, maximum: 5000 }

15. 2 Configuración básica + sobrecarga prod

yaml services/checkout/base/config.yaml service: checkout timeouts: { connect_ms: 200, request_ms: 1500 }
retries: { attempts: 2, backoff_ms: 200 }
limits:  { rps: 500 }
features:
degrade_search: false psp_a_weight: 80 psp_b_weight: 20

yaml services/checkout/overlays/prod/config.yaml limits:  { rps: 1200 }
features:
psp_a_weight: 70 psp_b_weight: 30

15. 3 Política de admisión (idea)

yaml allow_change_when:
tests: passed schema_validation: passed active_incidents: none_of [SEV-0, SEV-1]
rollback_plan: present signed_by: ["owner:team-checkout","platform-sre"]

15. 4 Tarjeta de liberación de configuración

Release: checkout-config v2.3.1
Scope: prod EU
Changes: psp_b_weight 20→30, request_ms 1500→1300
Risk: Medium (маршрутизация платежей)
Canary: 1%→5%→25% (30/30/30 мин), guardrails: success_ratio, p95
Rollback: tag v2.3.0

16) Anti-patrones

Editar en la venta más allá de GitOps («rápidamente subcrutado»).
Secretos/PII en el repositorio de configuraciones.
Ausencia de esquemas y verificaciones estáticas.
Fuerte divergencia de los alrededores (base≠prod).
Banderas fich «vivas» sin versiones ni historia.
Ignora la deriva y las ediciones manuales en los servidores.
Etiquetas sin notas de release y plan de reversión.

17) Hoja de ruta para la implementación (4-6 semanas)

1. Ned. 1: Inventario de las confecciones; directorios separados, circuitos para los 10 mejores servicios.
2. Ned. 2: incluir los linters/validación y dry-run en el CI; prohibición de merluza sin cheques verdes.
3. Ned. 3: GitOps racat + canarios; anotaciones de versiones en telemetría.
4. Ned. 4: introducir la política de tolerancia (policy-as-code) y las plantillas rollback; alertas a la deriva.
5. Ned. 5-6: cubrir el 90% de los servicios; reducir las diferencias env a overlays; agregar métricas de madurez y revisiones semanales de los cambios de configuración.

18) Resultado

El control de las versiones de configuración es un sistema, no sólo Git. Esquemas y validación, GitOps y directivas de acceso, canarios y retrocesos, detección de deriva y auditoría completa convierten la confección en un artefacto administrado. El resultado es un cambio rápido y seguro, la previsibilidad de SLO y la confianza del equipo en cada lanzamiento.