Operazioni e Gestione → Gestione delle modifiche

Gestione delle modifiche

1) Assegnazione e principi

L'obiettivo è fornire il cambiamento in modo rapido e sicuro, riducendo il rischio di incidenti, interruzioni e violazioni regolatorie.

• Predictable & Reversibile: ogni modifica è pianificata, verificabile e reversibile.
• Risk-based: la profondità del controllo dipende dal rischio (giurisdizione, denaro, PII).
• Small & Frequent: i piccoli incarichi sono più facili da valutare e da ritrattare.
• Automation first: infrastruttura come codice, test, convalida, automezzi.
• Single Source of Truth è un unico RFC/ticket, un unico calendario e un unico elenco di azioni.

2) Ambito di copertura

Codice prodotto (backend/frontend, SDK mobile).
Infrastruttura (IaC, Kubernets/VM/CDN/Edge).
Dati (diagrammi di database, migrazioni, vetrine/ETL).
Configurazioni e flag fich.
Integrazioni (PSP, KYC, provider di giochi).
Politiche di sicurezza e accessibilità.

3) Ruoli e RACI

Proprietario modifica - Responde.
Il responsabile del lancio/RelEng è il coordinatore del treno di lancio.
SRE/Ops - funzionamento, gate SLO/SLA.
Sicurezza/Compliance - Verifica dei rischi e della conformità.
CAV (Change Advisory Board) - Approvazione di modifiche normali/ad alto rischio.
Steikholder business/supporto - Informed.

4) Classificazione delle modifiche

Standard (tipici, pre-approvati): frequente, a basso rischio, in base alla playbook pronta (ad esempio, aggiornamento del flag, rotazione delle chiavi).
Normale: richiedono RFC, valutazione, possibile AB, test e piano di ripristino.
Emergency: registri urgenti per incidenti P1; Percorso burocratico minimo, post-fattura/CAV.

5) Ciclo di vita delle modifiche

1. Avvio (RFC) - Obiettivo, volume, rischio, servizi/regioni interessati, backout.
2. Valutazione del rischio: matrice di Impatto x Likelihood, impatto SLO/compilation/costo.
3. Pianificazione: finestra, dipendenze, migrazioni, comunicazioni, test di convalida.
4. Convalida: autostop, analisi statiche, assegno di sicurezza, test di performance.
5. Implementazione: strategia progressiva (vedere l'articolo 8), telemetria e gardrel.
6. Osservazione: burn-rate SLO, alert, metriche aziendali (GGR/NGR, conversione).
7. Fine: accettazione dei risultati, aggiornamento della documentazione, post mortem in caso di deviazione.

6) RFC: composizione minima

Contesto: perché cambiare, ipotesi di influenza.
Gamma: sistemi, regioni, versioni client.
Rischio: matrice e script di errore, blast radius.
Piano di installazione passo passo, con i criteri «avanti/stop».
Piano di ripristino (Backout) - Comandi/fasi, condizioni di avvio, attesa RTO/RPO.
Test Plan: cosa testare prima/dopo (funzionalità, performance, sicurezza).
Comunicazioni: chi ti avvisa, modelli di messaggio.
Controllo - link a ticetti, committenti, artefatti CI/CD.

7) Calendario modifiche e finestre

Calendario unico: tutte le release, migrazioni, disattivazioni, eventi esterni (sport/marketing/festività).
Finestre Freeze: grandi vendite/campionati/orologi di punta, rendicontazione fiscale.
Criteri di intersezione: impedisce le modifiche in conflitto attraverso gli stessi percorsi critici.
Onde regionali: prima le regioni calde/basse, poi le principali.

8) Strategie di implementazione

Canary: una piccola percentuale di traffico si confronta con le metriche (p95 latency, errore%, conversione).
Blue-Green: ambienti paralleli, cambio di percorso atomico.
Progressive Delivery: percentuale-rollout con condizioni di arresto automatiche.
Feature Flags - Pulsanti di scelta funzionali, kill-switch, A/B.
Dark Launch/Shadow Traffic - Controlla le ombre senza influire sugli utenti.
Limiti di passo: aumento graduale della competitività QPS.

Gardreille: stop automatico al superamento delle soglie p95/errore%, aumento dei rimborsi/charjbeek, calo delle autorizzazioni/depositi.

9) Modifiche ai dati e agli schemi

Compatibilità: migrazioni estensive (additive): codice che legge sia il vecchio che il nuovo schema.
Migrazioni bidirezionali: (1) aggiungere nuovi campi/indici di → (2) cambiare codice di → (3) eliminare il vecchio.
Versioning dei contratti: schemi Avro/Protobuf con registro; back/forward compatible.
Migrazioni di grandi volumi: batch, pause, idimpotenza, checkpoint e progresso.
Resistenza catastrofica: test RPO/RTO, snapshot, prove di recupero.
Dati BI - Modifica delle vetrine/metriche tramite MR/SR e il dizionario delle metriche (ID, formula).

10) Gestione di configurazioni e segreti

Config as Data: confighi versionati, convalida dello schema, promozione attraverso gli ambienti.
I segreti sono rotazione delle chiavi, principi di privilegi minimi, controllo delle richieste.
Gli override regionali: limiti/partner (PSP/KYC) - Tramite la parametrazione, non tramite la forza codice.

11) Compilazione e verifica (contesto iGaming)

Segni di cambiamento: chi/quando/cosa ha cambiato (bandiere, configi, percorsi, migrazioni).
Segregation of Duties - ruoli diversi per l'autore, il revolver e il deploeur (SOX-simile).
Rapporti regolatori: feedback, controllo delle versioni dei calcoli (GGR/NGR, bonus), controllo delle disponibilità di PII.
Fornitori: versioni registrate SDK/certificati provider, obblighi SLA.

12) Comunicazioni

Modelli di avviso: prima del lancio (cosa/quando/rischi), durante (stato,% traffico, metriche), dopo (riepilogo).
Messaggi esterni: banner/pagina di stato per l'impatto sui client.
Coordinamento: canale # release-war-room, proprietario della release, frequenza degli update.

13) Metriche di efficienza

DORA: Deployment Frequency, Lead Time for Changes, Change Failure Rate (CFR), MTTR.
SLO Impatto: quota di tempo in SLO prima/dopo i rilasci.
Backout Rate: frequenza dei ripristini per categoria di modifiche.
Release Debt - Migrazioni/flag inattive in stato sospeso.
Business Impact: conversione, KYC TTV, success rate PSP, GGR/NGR draft durante gli scatti.

14) Anti-pattern

Release Big Bang: molti cambiamenti in una volta - difficile da capire il motivo della regressione.
Migrazioni incompatibili - Rimuove o rinomina i campi senza doppia lettura.
Le bandiere senza proprietari e i tempi di ritiro sono i rami «eterni» della logica.
Rilasci senza telemetria e criteri di stop: «a vista» e in seguito rilevamento danni.
Ignora calendario: intersezione con eventi/campagne di punta.
Passaggi manuali senza playbook o controllo: elevata variabilità e rischio.

15) Assegno fogli

Prima di iniziare (RFC pronto)

• Scopo e KPI modifiche formulate
• Rischio e blast radius valutati, classe di modifica selezionata
• Il piano di implementazione e Backout sono stati definiti passo passo
• Il piano di prova e i risultati sullo sterzo/canaro sono disponibili
• Comunicazioni e calendario aggiornati, stakeholder notificati

Durante l'espansione

• Metriche p95/errore%, segnali aziendali e loghi monitor in tempo reale
• Le fasi di avanzamento sono confermate da un assegno-punto
• Quando si attivano gli gardreil - auto-stop e rientro

Dopo

• Riepilogo registrato (changelog, versioni, manufatti)
• Post mortem per deviazioni (5 giorni lavorativi)
• Debiti (rimozione bandiere, migrazioni finali) sono inseriti nel backlog con i proprietari

16) Mini modelli

• Obiettivo/ipotesi
• Quantità e impatto (servizi, regioni, dati, client)
• Rischio (Impatto x Likelihood) e misure di riduzione
• Piano di individuazione (passaggi,% di traffico, criteri go/no-go)
• Piano backout (passi, RTO/RPO, dati)
• Piano di prova (funzionalità/prestazioni/sicurezza)
• Comunicazioni (canali, frequenza)
• Manufatti (ticetti, PR, numeri di bilico)

• Modifica: "Payments-Service v2. 14 + migrazione psp _ limits"
• Finestra 2025-11-02 00: 00-01: 00 EET
• Regioni interessate: EU, LATAM (10%→50%→100%)
• Rischi/guardrail: errore%> 2% 10 min - Stop e ripristino
• Contatti @ Owner, @ SRE-on-call, @ Support-lead

• Trigger: p95> + 25% 10 min, PSP success <97%
• Passaggi: (1) traffic 0% su v2. 14; (2) Passare le bandiere a v2. 13; (3) reimpostazione della migrazione tramite snap/checkpoint; (4) test smoke; (5) report.

17) Integrazione con il treno di lancio

Release Treno: slot fisse (ad esempio 2 x a settimana), SLA su merge-cut.
Criteri Hotfix: treni/rami separati, percorso accelerato verso la prua.
Versioning: semver, etichette in manufatti e ambienti, SBOM.

18) Totale

Il controllo delle modifiche non è un freno alla velocità, ma un meccanismo di accelerazione sicura. La classificazione orientata al rischio, il buon RFC, il progressivo display, le migrazioni dei dati compatibili, le comunicazioni chiare e la misurazione dell'effetto trasformano i rilasci in un processo gestibile, ripetibile e verificabile.