Processo di approvazione dei comunicati

1) Obiettivo e zona di responsabilità

Il processo di approvazione dei comunicati fornisce modifiche prevedibili e sicure alla piattaforma senza compromettere SLO, ricavi e compilation. Copre tutto il percorso, dal pull sollest alla promozione completa in prode e post-monitoraggio.

2) Principi

1. SLO-first: rilascio consentito solo con SLI verde/senza burn-rate.
2. Piccole partite e reversibilità: spedizione canaria/progressiva, rollback veloce.
3. Policy-as-Code: gate, SoD, finestre freeze e classi di rischio sono automaticamente verificabili.
4. Un'unica fonte di verità: manufatti/confighi/bandiere - in Git, l'ambiente è riportato da GitOps-reconsiler.
5. Verifiche e prove: registri WORM, tracce decisionali, proprietari chiari.
6. Protezione predefinita: segreti separati, privilegi minimi, geo-gate.
7. Comunicazioni senza sorprese: modelli preparati per aggiornamenti interni/esterni.

3) Ruoli e RACI

Release Manager (RM) - proprietario della catena di montaggio, calendario, gate. A/R

Service Owner (SO) - Proprietario del dominio, accetta il rischio, prepara gli artefatti. A/R

SRE/Platform - SLO-gate, disegni, autotrasportatori. R

QA Lead - strategia di verifica, risultati dei test. R

Sicurezza/Compliance - scani, SoD, regolazione. C/A

CAV (Change Advisory Board) è una soluzione per la classe Normale. A

On-call IC/CL - Pronto per incidenti e comunicazioni. R/C

Stakeholders (Biz/Support/Partners) - Informazioni. I

4) Classi di modifica e percorsi di negoziazione

Classe	Esempi	Percorso di negoziazione	Scadenze
Standard	Sicuro, modello (docu-report, configi non invasivi)	Auto-gate + post-notifica	Orologio
Normal	Nuove fitte, schemi di database con migrazione, modifiche al routing PSP	Gate + CAV + consegna progressiva	1-3 giorni
Emergency	Fissi P1 hot, disattivazione fitta/export PII pericoloso	IC/RM soluzione + post-fattura CAV	Minuti e ore

Aumentare la classe quando si attraversano i limiti di rischio (pagamenti, RG, PII, limiti).

5) Catena di rilascio e gate (flusso di flusso)

Fase 0. Pianificazione e calendario

Le finestre freeze (feste/partite), slot-call e CL, la preparazione dei modelli di stato.

Fase 1. PR → Build

Linter/licenze, SBOM, unit/contract test, segreto-scan.

Fase 2. Integrazione/Sicurezza

E2E (fornitori virtualizzati PSP/KYC), SAST/DAST, dipendency review.

Fase 3. Staging/Prove

Parità con la vendita, migrazioni con reversibilità, ficcoflagi tra il 5 e il 25%, «release drill».

Gate A - Qualità e sicurezza (obbligatorio)

+ tutti i test/scan sono verdi

+ schemi/configi validi, niente «rosso» SLI staging

+ SoD/4-eyes per modifiche high-risk

Fase 4. Pre-prod (spedizione canaria)

1-5% del traffico per segmenti (tenant/geo/banca), runtime-validatori, guardrail.

Gate B - SLO/Business gate

+ nessun degrado SLO/KRI (latitanza/errore/pagamento)

+ nessun SRM/anomalie nelle metriche degli esperimenti

+ Comms pronto: bozza di stato/partner

Fase 5. Rampo-up 25% 100% (regione/tenante)

Promozione passo passo con i timer post-monitoraggio.

Fase 6. Post-monitoraggio (30-60 min)

Dashboard release, burn-rate, lamentele/ticket, auto-chiusura/rollback in caso di violazioni.

6) Soluzioni automatizzate (policy-engine)

Regole pseudonime:

SLO-гейт: `deny promote if slo_red in {auth_success, bet_settle_p99}`
PII-export: `require dual_control if config. affects == "PII_EXPORT"`
Freeze: `deny deploy if calendar. freeze && not emergency`
Rollback: `auto if auth_success_drop > 10% for 10m in geo=TR`

7) Artefatti di lancio

Release Manifest (obbligatorio): obiettivo, classe di rischio, aree (tenant/region), bandiere, migrazioni, piano di individuazione, piano di recupero, proprietario, contatti colla.
Evidence Pack - Risultati dei test/scene, screenshot di dashboard staging, dry-run migrazioni.
Comms Kit: modelli di stato (interno/esterno/partner), ETA/ETR.
Backout Plan - Le fasi esatte di ripristino e i criteri in cui funziona.

Esempio (spremitore YAML):

yaml release:
id: "2025. 11. 01-payments-v42"
owner: "Payments SO"
risk_class: "normal"
scope: { tenants: ["brandA","brandB"], regions: ["EU"] }
rollout:
steps:
- { coverage: "5%", duration: "20m" }
- { coverage: "25%", duration: "40m" }
- { coverage: "100%" }
migrations:
- id: "ledger_ddl_0042"
reversible: true flags:
- id: "deposit. flow. v3"
guardrails: ["api_error_rate<1. 5%","latency_p99<2s"]
rollback:
autoIf:
- metric: "auth_success_rate"
where: "geo=TR"
condition: "drop>10% for 10m"

8) Canarie/Blue-Green/Feature-Flag

Canary è un default sicuro: piccola copertura, segmentazione GEO/tenant/BIN.
Blue-Green - per le modifiche pesanti: cambio di rotta, ripristino rapido.
Le bandiere sono TTL, kill-switch, guardrail, SoD.

9) Gestione di configurazioni e segreti

Confighi come dati, schemi e validatori; Promozione GitOps con rilevatore draft.
I segreti sono in KMS/Secret Manager, accesso JIT, controllo e occultamento.

10) Comunicazioni e stato delle pagine

Interni: war-rum/chat, avvisi di colle, modelli di update.
Esterni: solo pubblicazioni CL, bozze precompilate.
Partner (PSP/KYC/Studio) - Notifiche targeted per le integrazioni.
Stato: il rilascio non è un incidente, ma ha una finestra di sorveglianza con metriche.

11) Comunicati di emergenza (Emergency)

Trigger: degrado P1, vulnerabilità, rischi PII/RG.
Percorso: la soluzione IC + RM un set minimo di gate (linter/assemblaggio) canary 1-2% per monitorare la promozione.
È obbligatorio: post-fattura del CAV, post-mortem del D + 5, documentazione dei compromessi.

12) Controllo, controllo e conformità

SoD/4-eyes - Modifiche al routing PSP, ai limiti di bonus, all'esportazione dei dati.
Registro WORM: chi/cosa/quando/perché; Versioni dei criteri diff di rilascio/bandiere/configh.
Geo/Privacy: dati e loghi nella giusta giurisdizione; Non c'è PII nei manufatti.

13) Osservabilità e post-controllo

Dashboard release: SLI (auth-success, bet→settle p99), errato-rate, denunce, conversione, code.
Alert: burn-rate, SRM, crescita 5xx, degrado PSP su banche/GEO.
Rapporti: CFR, MTTR release-incidenti, tempo medio post-monitoraggio, auto-rollback rate.

14) KPI/KRI processo

Lead Time for Change (PR→prod), Change Failure Rate, MTTR release.
SLO-gates pass rate, Auto-rollback rate, Freeze compliance.
Coverage of Release Drill (prove di stage), SoD violations (obiettivo 0).
Comms SLA (bozze, timing).

15) Road map di implementazione (6-10 settimane)

Ned. 1-2 - definire le classi di cambiamento, gate e manufatti; Abilitare linter, SBOM, segreto-scan; calendario delle release e freeze.
Ned. 3-4: GitOps per configure, canary/blue-green, gate SLO, modelli Comms e war-rum.
Ned. 5-6: policy-engine (SoD/4-eyes, risk-rule), auto-rollback per metriche; Il dashboard dei comunicati.
Ned. 7-8: prove (staging drills), integrazione con phicheflag/incidente-bot, rapporti KPI/KRI.
Ned. 9-10: controllo WORM, esercitazioni di release DR, ottimizzazione del CFR, formazione dei ruoli (RM/SO/CL/IC).

16) Antipattern

Comunicati senza reversibilità e canary hanno causato incidenti di massa.
Ignorare i gate SLO per la deadline.
Confighi/bandiere senza diagrammi e TTL sono stati bloccati.
Click manuali in vendita senza git/controllo.
Update pubblici senza CL o modelli.
Segreti nel repository accessibili senza JIT o registrazioni.
AB come freno senza dati: le soluzioni devono essere supportate da metriche di rilascio.

Totale

Il processo di approvazione dei comunicati è una struttura di progettazione e gestione che unisce qualità, sicurezza e velocità: policy come codice, gate SLO, spedizioni progressive, comunicazioni trasparenti e verifiche dimostrabili. Questo approccio riduce CFR e MTTR, protegge i ricavi e la compilazione e consente ai team di produrre valore spesso e in modo sicuro.