Controllo delle versioni delle configurazioni

1) Perché versionare le configurazioni

La configurazione è un criterio eseguibile che definisce instradamento, limiti, flag, accessibilità, schemi di dati. Il controllo delle versioni rende le modifiche ripetibili, visibili e reversibili, riducendo MTTR e change-failure rate, eliminando la «magia in vendita», fornendo un controllo per la sicurezza e la compliance.

2) Tassonomia delle configurazioni

Infrastrutture (IaC): cluster, reti, LB, database, code.
Servizi: impostazioni delle applicazioni, risorse, limiti, timeout, retrai.
Logica alimentare/aziendale: tariffe, esperimenti AB, regole di contenuti.
Dati/WorldOps - Contratti di schema, SLA freschezza, trasformazione.
Protezione: criteri di accesso, ruoli, chiavi/certificati (i segreti stessi sono fuori repo).
Osservabilità: SLI/SLO, alert, dashboard.

Regola: tutto ciò che influisce sul comportamento del sistema è la configurazione e deve vivere sotto versioning.

3) Principi di gestione delle versioni

1. GitOps: l'unica fonte di verità è il repository; modifiche tramite PR e pipline automatiche.
2. Dichiarazione: descrizione dello stato di destinazione, non script di passo.
3. L'immutabilità dei manufatti, il config, è un snapshot perfettamente materializzabile.
4. Diagrammi e convalida: JSON/YAML-schema, rigido indicatore dei tipi, campi obbligatori.
5. Gli ambienti come codice sono cartelle/overlay (uv/stage/prod) e le differenze sono minime ed evidenti.
6. Idampotenza e ripristini: qualsiasi release di configurazione è reversibile (revert/rollback).
7. Controllo e tracciabilità: autore, motivo, ticket/RFC, firma modifiche.

4) Strategie di versioning

• MAJOR - Modifiche agli schemi/regole incompatibili.
• MINOR - nuovi campi/regole, compatibilità inversa.
• PATCH - Correzioni dei valori senza modificare gli schemi.
• Rilasci tag e release note - Che cosa è cambiato, come ribaltarsi, i punti di controllo.
• File pinning/lock - Registra le versioni delle dipendenze (moduli, liste).
• Matrix versione - Il manufatto dell'applicazione X è compatibile con la configurazione Y (matrice nella directory del servizio).

5) Organizzazione del repository

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

Ramo: trunk-based (main) + feature brevi. Mierj, solo attraverso il PR con l'ICI obbligatorio.

6) Convalida e test

Schema: ogni modifica viene sottoposta a un controllo dello schema (richired, enum, ranges).
Lenti statici: formato, chiavi, prese, campi non consentiti.
Test di compatibilità: config + versione del servizio/scaletta salgono nella cassetta di sabbia.
Controlli: applicazioni dry-run, «what-if» lo stato di destinazione.
Criteri-as-code - Regole di tolleranza (Rego/CEL) - Chi e cosa può cambiare.

7) Disconnessione e ripristino delle configurazioni

Progressive delivery: canarino % con SLO.
Gate deploy: nessun SEV-1 attivo, gli alert sono verdi, le firme sono validi, il ritorno è pronto.
Ritorno: «revert tag». Y.Z 'o il passaggio a uno snap precedente; i comandi di ripristino sono documentati nel runbook.
Annotazioni di rilascio - La versione di config viene pubblicata in metriche/fogli per essere rapidamente correlata agli incidenti.

8) Configurazione dinamica e remota

Remote config/feature flags - Modifica dei parametri senza restart; Tutte le bandiere sono sotto tiro.
Bordi - Quali parametri possono essere modificati dinamicamente (elenco degli elenchi bianchi).
Cache e consistenza: TTL, versioni, set di sostituzione atomica (pubblicazione a due fasi).
Ringhiere sicure: limiti e intervalli per modifiche runtime, auto-rollback in uscita per SLO.

9) Segreti e dati sensibili

Non teniamo mai segreti nei repo. Le configurazioni includono solo collegamenti/playsholder.
Crittografia dei file di configurazione se necessario: integrazione con il gestore dei segreti/chiavi.
Rotazione e JIT Non c'è traccia di azione.
Travestimento sul campo: la validazione vieta l'ingresso di PII/segreti in config.

10) Gestione degli ambienti

Base + overlays - Le differenze tra dave/stage/prod sono minime e trasparenti.
Promozione degli artefatti: lo stesso snapshot che ha superato lo stage avanza in prod.
Finestre temporanee: le modifiche alle configurazioni non avvengono al momento del cambio di servizio; risk-high - RFC e finestra di servizio.

11) Rilevamento e rimozione della deriva

Il controller confronta lo stato di destinazione con quello effettivo e il diff reportage.
Drift-alert: Pagina solo in caso di situazioni critiche gli altri sono Ticket.
Remediazione automatica - Durante la risoluzione, ritorna allo stato di destinazione.
Controllo delle modifiche manuali: qualsiasi «kubectl edit/ssh» è un incidente del processo e del CAPO.

12) Directory e proprietà delle configurazioni

Catalogo del servizio: proprietario, SLO, regole, schemi, versioni, compatibilità.
RACI: chi offre, chi rivitalizza, chi approva; CAV per high-risk.
Trasparenza: ogni record ha una cronologia delle versioni e dei collegamenti a PR/ticket/AAR.

13) Metriche di maturità

Coverage:% di servizi/regole sotto controllo (obiettivo 95%).
Lead time modifiche config: mediana da PR a prato.
Cambio failure rate: percentuale di rilasci config con ripescaggio/incidente.
Draft rate: numero di soluzioni temporanee/settimana e tempi di risoluzione.
Rollback time: la mediana di ripristino alla versione precedente.
Audit completeness - Percentuale di modifiche con evidence completa (validatori, dry-run, recensioni).

14) Assegno fogli

Prima di modificare la configurazione

• C'è un ticket/RFC e il proprietario della modifica.
• Convalida degli schemi e dei linter completata.
• C'è un piano di recupero e un comando nel runbook.
• Gate - Test verde, le firme sono validi, nessun SEC-1 attivo.
• High-risk - È stata assegnata una finestra di manutenzione.

Durante la scansione

• Canary e SLO Gardreil sono attivi.
• Vengono pubblicate le annotazioni di versione.
• Ci sono messaggi eco nel canale; il rumore alert è soppresso secondo le regole MW.

Dopo

• Osservatorio window superato, SLO verde.
• Riepilogo ed evidence (grafici prima/dopo, report dry-run) sono allegati al ticket.
• Schemi/documentazione aggiornati se necessario.

15) Mini modelli

15. 1 Schema di configurazione (YAML-schema, porzione)

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 Config base + overlay 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 Criterio di tolleranza (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 Carta di rilascio config

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-pattern

Le modifiche sono passate di sopra («veloce»).
Segreti/PII nel repository di configurazioni.
Nessun schema o controllo statico.
Forte discrepanza degli ambienti (base≠prod).
Flag live senza versione e senza storia.
Ignora la deriva e le modifiche manuali sui server.
Tag senza release note o piano di ripristino.

17) Road map di implementazione (4-6 settimane)

1. Ned. 1: inventario delle configurazioni cataloghi separati, diagrammi per i primi 10 servizi.
2. Ned. 2: includere lenti/validazione e dry-run in CI; Vietare l'incantesimo senza assegni verdi.
3. Ned. 3: + canarini; annotazioni di versione nella telemetria.
4. Ned. 4 - Immissione di criteri di tolleranza (policy-as-code) e modelli rollback alert alla deriva.
5. Ned. 5-6 - Coprire il 90% dei servizi; ridurre le differenze uv a overlays; aggiungere le metriche della maturità e la review settimanale dei cambiamenti config.

18) Totale

Il controllo delle versioni delle configurazioni è un sistema, non solo un Git. Gli schemi e la validazione, le regole di accesso, i canarini e i rimborsi, il rilevamento della deriva e il controllo completo trasformano il config in un manufatto controllato. Il risultato è un cambiamento rapido e sicuro, prevedibilità SLO e fiducia del team in ogni comunicato.