Laboratori
I laboratori sono il mio banco di prova: ambienti piccoli e riproducibili dove metto insieme AI, automazione e database per vedere cosa regge davvero, prima di pensare alla produzione. Ogni laboratorio è pubblicato su GitHub con il codice e le istruzioni per rifarlo.
LAB 01
Triage AI dei lock su PostgreSQL
L'AI propone, l'umano firma, il database registra. Ogni 5 minuti un flusso cerca i lock su PostgreSQL, recupera il criterio di severità dal vector DB, lo fa valutare a un modello locale e manda la proposta su Telegram: una persona approva o rifiuta.
I controlli non stanno nel flusso ma nel database: anche un flusso sbagliato non può fare più di quanto i ruoli consentono.
Componenti
- PostgreSQL + pgvectorIl database sotto osservazione, il vector DB con i criteri di severità e il registro delle azioni
- OllamaModelli locali: llama3.2:3b per la valutazione, nomic-embed-text per gli embedding
- n8nIl flusso che rileva i lock, interroga il modello e gestisce l'approvazione
- TelegramIl canale dove una persona approva o rifiuta la proposta
- Docker ComposeTutto l'ambiente si avvia con un solo comando
Funzionalità testate
- Il ruolo di monitoraggio vede sessioni e lock ma non modifica nulla
- Il ruolo di azione può solo chiamare la funzione approvata
- Senza la firma di una persona l'azione viene rifiutata
- Superuser e ruoli AI non possono essere terminati
- Ogni esecuzione, anche fallita, finisce nel registro
- Il registro non si modifica e non si cancella, nemmeno da superuser
- La severità P1-P4 arriva dalle soglie salvate nel vector DB
- Timeout sulle query dei ruoli AI: 5 e 10 secondi
LAB 02
Cruscotti real-time con Apache Fluss e Flink
Il calcolo lo fa Flink, una volta per ordine. Il cruscotto legge una copia. Ogni dashboard che si aggiorna ogni pochi secondi è una query sul database di produzione: qui gli ordini finiscono in Fluss, Flink aggiorna i totali in streaming e li copia in PostgreSQL, e Superset li mostra con pochi secondi di ritardo.
Nel laboratorio gli ordini li genera Flink; in un caso reale arriverebbero con la CDC dal log delle transazioni, senza query sulle tabelle di produzione. Tutti i componenti principali sono open source.
Componenti
- Apache FlussStorage per lo streaming: tabelle con chiave primaria che producono da sole il flusso delle modifiche
- Apache Flink + SQL GatewayJob di streaming che aggiornano i totali per cliente e copiano i dati in PostgreSQL
- PostgreSQLLa copia interrogata dal cruscotto, separata dalla sorgente
- Apache SupersetDashboard con aggiornamento automatico ogni 10 secondi
- ZooKeeper e RustFSMetadati del cluster Fluss e storage S3 per i dati più vecchi
- n8nFlusso di prova che scrive e legge tramite il SQL Gateway, solo per prototipazione
- Docker ComposeTutto l'ambiente si avvia con un solo script
Funzionalità testate
- I totali per cliente si aggiornano a ogni ordine, senza ricalcolare la tabella
- La copia in PostgreSQL resta coerente: il numero di ordini coincide con la somma dei totali
- I grafici di Superset leggono solo dalla copia
- La dashboard si aggiorna da sola ogni 10 secondi
- Il flusso n8n inserisce ordini e legge i totali calcolati da Flink
- Dati e metadati restano dopo arresto e riavvio
- Al riavvio i job ripartono e ricalcolano i totali dai dati salvati in Fluss
- Licenza Apache 2.0