Lavoro

Contesto. Il database critico di un gruppo multinazionale: 1 TB, batch notturni pesanti e costi in crescita sul tier in uso.

Vincoli. Sistema in produzione e finestre strette: i tempi dei batch non potevano peggiorare, e serviva una via di ritorno a ogni passo.

Decisione. Ho validato il cambio di tier con benchmark sui batch produttivi reali, condotti con il reparto Data & Analytics, prima di toccare la produzione. Ogni fase aveva il suo piano di rollback, e dopo il taglio una sentinella notturna ha tenuto d'occhio i batch per le prime settimane.

Esito. La migrazione è andata in produzione senza incidenti, e il risparmio è a cinque cifre l'anno.

Contesto. Un parco multi-tenant in crescita, dove l'infrastruttura di ogni nuovo tenant rischiava di nascere come progetto a sé.

Vincoli. Gli standard dovevano valere su tutti i tenant senza bloccare i progetti in corso, e un errore in un modulo condiviso arriva a tutti quelli che lo usano.

Decisione. Ho costruito una libreria interna di moduli Terraform riusabili, con versioning semantico, changelog e rilasci canary. Sopra la libreria ci ho messo un template di onboarding, così un tenant nuovo parte da una configurazione nota. Le pipeline coprono validazione, deploy e audit del drift, e un controllo segnala i moduli deprecati ancora in uso.

Esito. L'onboarding di un tenant è diventato una procedura ripetibile. Il drift lo trova l'audit schedulato.

Contesto. Un parco cresciuto insieme alla piattaforma, con approcci che alla loro epoca erano lo standard: policy di accesso legacy su vari oggetti, credenziali amministrative dove oggi si usano le identità gestite, accessi ai database ancora su SQL login.

Vincoli. Tutto in produzione: nessun fermo era accettabile, e ogni modifica doveva potersi annullare.

Decisione. Ho lavorato per campagne di ammodernamento, sempre con lo stesso metodo: inventario, modifiche generate come script rivedibili, rollback pronto. Le policy di accesso sono passate a RBAC, le credenziali alle identità gestite; per le SQL login un ciclo esplicito: inventario, disabilitazione, trenta giorni di osservazione, poi il drop.

Esito. Decine di risorse sono passate allo standard attuale senza un fermo, e ogni passo si poteva annullare a costo zero.

Contesto. Uno studio di formazione con i corsi nel gestionale e il catalogo su un sito WordPress: due sistemi tenuti allineati a mano.

Vincoli. Il gestionale resta la fonte dei dati e il sito non deve esporre nulla: niente endpoint pubblici, niente token nel browser. Tutto dentro l'ecosistema WordPress ed Elementor dello studio.

Decisione. Ho scritto un plugin che sincronizza i corsi dalle API del gestionale, con schedulazione, lock, backoff sugli errori e finestre di guardia; i cambiamenti li rileva via hash, le sessioni le raggruppa per corso. Le iscrizioni viaggiano server-to-server, e per sviluppare uso fixture locali.

Esito. Il catalogo si aggiorna da solo e le iscrizioni arrivano al gestionale senza superficie esposta. Lo studio pubblica corsi senza toccare il sito.

Contesto. Il gestionale delle mie finanze personali. Nato come backend per agenti con MCP come interfaccia, cresciuto fino a un prodotto completo: backend Fastify e TypeScript su PostgreSQL, frontend React, registri multipli, budget, mese finanziario con giorno di taglio configurabile.

Vincoli. Sono dati finanziari veri: gli agenti hanno permessi delimitati, e le operazioni distruttive nascono dry-run.

Decisione. Le banche entrano via PSD2: il sync porta le transazioni in staging, le categorizza con regole deterministiche e le riconcilia; quello che resta ambiguo finisce in una coda di revisione, e i trasferimenti fra registri sono riconosciuti come tali. Gli agenti restano un'interfaccia di prima classe via MCP.

Esito. In produzione nel mio homelab, in uso ogni giorno.