Da tre nodi morti a una rete con un cuore che batte
La notte del 25 ottobre un picco di tensione ha spento tre computer della mia rete domestica. Quando la corrente è tornata, nulla si è riavviato da sola. E io ho scoperto che il modo più rapido per sapere se un PC sotto la scrivania è acceso è chinarsi e guardare il LED.
Non era nemmeno la prima volta. Giorni prima, uno dei tre nodi aveva smesso di fare boot e l'avevo reinstallato da zero. Quella notte, un altro si era impallato così bene che mi ci sono voluti due riavvii manuali per rientrarci in SSH. Strisciando sotto la scrivania, al buio, ho scritto due righe di diario: “Mai più.”
La sera dopo, alle 18:40, ho riavviato l'hub — broker, database, API e dashboard insieme — senza toccare una tastiera. In 4 minuti era tutto di nuovo online. Il giorno dell'incidente era diventato la suite di test che il sistema supera da solo.
Ma la vera storia non è il riavvio. È come ci sono arrivato senza impazzire, partendo da una sola certezza: l'AI da sola produce rumore.
Il fantasma degli agenti meteo
Qualche tempo fa ho giocato con degli agenti AI per il meteo. Esperienza istruttiva: a ogni modifica richiesta, il file generato era diverso. Layout ribaltato, UI rifatta, struttura cambiata. Ogni iterazione era un piccolo giorno della “marmotta”: ripartire quasi da capo per una correzione da dieci righe.
Lo chiamano “vibe programming”: incontrollato, caotico, non riproducibile. Divertente per un prototipo, insostenibile per qualsiasi altra cosa.
Il problema era chiaro già da allora, ma quella notte sotto la scrivania ha preso forma concreta: se devo costruire un sistema che controlla qualcosa, devo poter controllare prima di tutto il sistema stesso. Un monitoraggio da rifare a ogni modifica non è monitoraggio, è un generatore di ansia.
La alternativa allo vibe programming è lo sviluppo su specifiche: controllato, ordinato, estendibile. Si definisce cosa il sistema deve fare prima di chiedere all'AI di farlo. Fine del sentimento, inizio della razionalità e del metodo.
Costruire i binari, non il treno
Premessa onesta: non so programmare e non sono un sistemista. Sono, al massimo, un utente esperto con molta curiosità e un debole per il metodo.
Quindi il primo gesto non è stato scrivere codice, né tantomeno prompt. È stato chiedere all'AI le domande giuste: quali sono i punti da definire? Su quali parametri devo prendere decisioni? Mi ha aiutato a esplorare il problema e a valutare le soluzioni possibili. Quelle risposte sono diventate mie decisioni: il design dell'architettura, gli obiettivi, i confini del sistema.
Solo dopo è entrato in scena OpenSpec, un framework per scrivere specifiche e guidare lo sviluppo con l'AI: proposal, specifiche, design, tasks. Ogni modifica al codice passa da lì — niente più “sistemami questa cosa” al vento. Generazione e validazione del codice avvenivano dentro i binari delle specifiche, non nell'estro del momento.
Il punto è questo: le competenze che mi mancavano non le ho delegate all'AI. Le ho acquisite attraverso l'AI e poi cristallizzate nelle specifiche. Ho costruito dei binari dentro cui l'AI si è mossa. Non un treno che parte da solo: un percorso che decidevo io, anche dove non sapevo ancora esattamente dove portasse.
La mappa: come parlano tra loro i pezzi
L'architettura che è uscita da quell'esplorazione guidata è banale di proposito. Ed è questa la sua forza.
Al centro, un message broker MQTT (Mosquitto) che lavora come una bacheca dei messaggi: chi produce pubblica, chi consuma ritira, e nessuno dei due sa dell'altro. Attorno alla bacheca:
- Le sentinelle — piccoli agenti in Python che girano su ogni nodo e pubblicano il proprio heartbeat: il bollettino di salute del proprio computer. Ognuna scrive solo nel proprio spazio, e nessuno può scrivere addosso agli altri.
- Il collector — il consumatore: ritira i messaggi dalla bacheca e li registra in un database SQLite, timbrandoli con l'orario d'ingresso al momento della ricezione.
- Le API — espongono i dati del database a chi li vuole leggere.
- La dashboard — HTML e CSS nativi, niente framework, niente CDN: uno specchio passivo che legge le API e non comanda nulla. Se cade internet, continua a funzionare. E non mente: un nodo che non si fa sentire mostra “nessun contatto”, non metriche vecchie spacciate per fresche.
Bacheca dei messaggi al centro: le sentinelle pubblicano, il collector archivia, la dashboard riflette. Tutti disaccoppiati.
Dettaglio che mi piace: anche l'hub si monitora passando dalla stessa bacheca degli altri nodi. Una sola via per gli stessi dati — così database, API e dashboard raccontano sempre la stessa storia.
Il principio che tiene insieme tutto è il disaccoppiamento: produttori e consumatori non si parlano, parlano alla bacheca. E le scelte architetturali non erano dettate solo dal monitoraggio: erano anche l'occasione per dotarmi di un assetto riutilizzabile in altri progetti. Quel bus di messaggi è destinato a diventare il backbone dei miei sistemi di casa — su questo torno alla fine.
La montagna russa
Il resto della giornata è stata una corsa a ostacoli durata circa sette ore. Tre nodi da sistemare, sei bug incontrati, e l'AI come compagno di squadra sotto la supervisione delle specifiche.
Non vi racconto i bug nel dettaglio — la documentazione cruda vive nella knowledge base del repository — ma la cosa interessante è il pattern: ogni bug nasceva, il metodo lo catturava, la diagnosi diventava una voce di knowledge base con la propria causa radice, e si proseguiva.
Il messaggio della giornata, alla fine, non è stato “l'AI ha sbagliato sei volte”. È stato “sei volte il metodo ha trasformato un errore in patrimonio”.
La pigrizia come forza dell'ingegneria
Installato il primo nodo a mano, guardando i due che restavano mi sono fermato dubbioso: altre due volte la stessa sequenza di comandi manuali, detestandola sempre un po' di più.
È il momento in cui scatta la regola d'oro del pigro devops: se devi farlo più di una volta e odi farlo, allora lo devi automatizzare.
Così è nato l'installer: un singolo script che incorpora il codice, chiede le credenziali in sicurezza, verifica che funzionino davvero contro il sistema vivo prima di toccare il disco, ripara ciò che trova rotto e si dichiara finito solo quando vede il primo heartbeat nel log. Il “verifica che funzionino davvero” non è un vezzo, è un approccio end-to-end allo sviluppo.
Aggiungere un quarto nodo ora costerebbe un comando. Ma questo lo dico con orgoglio a fine post.
La prova regina
Un sistema di monitoraggio che non superi i test non è monitoraggio, è buona fede. Quindi il giro di prove finale:
- Heartbeat end-to-end, persistenza sul database, API e dashboard vive.
- Spegnimento deliberato di un nodo: dopo dieci minuti la sua card diventa grigia e mostra solo “ultimo contatto”. Nessuna fandonia di metriche stantie. Riacceso: card verde.
- Riavvio completo dell'hub: il computer che porta broker, database, API e dashboard. Zero interventi, e quando sono tornato a guardare la card segnalava 4 minuti di uptime — tutto lì, in ordine, da solo. Stesso copione col secondo nodo: 6 minuti, card verde.
La notte in cui tre nodi sono morti è diventata il test che quegli stessi tre nodi ora superano da soli. C'è una simmetria, in questo, che apprezzo molto.
Sviluppo su specifiche: l'umano decide il percorso, l'AI posa i binari dentro cui muoversi.
Cosa ho imparato
L'AI può scrivere codice, ma realizzare un prodotto software è un'altra cosa. Serve guidarla sui binari giusti, con metodo e controllo — altrimenti è il caos, in salsa leggermente più elegante del mio caos da scrivania del 25 ottobre, ma comunque caos che non ci si può permettere.
La realizzazione che mi ha sorpreso di più: l'ingegneria sta nella stesura delle specifiche, non nel codice. Il codice, ormai, l'AI lo sa scrivere. Quello che distingue un sistema da un ammasso di file è ciò che si decide prima del codice: contratti, confini, verifiche falsificabili. E la buona notizia per chi, come me, non è un programmatore: quelle competenze si possono acquisire insieme all'AI, se la si usa nella direzione giusta, creando i binari entro cui farla correre.
Resta il futuro. Il bus di messaggi al centro dell'architettura non è nato solo per il monitoraggio: è l'asset su cui intendo far convergere i sistemi di casa. Il passo successivo è la domotica — sensori e dispositivi che producono e consumano messaggi sulla stessa bacheca delle sentinelle. E poi notifiche, nuovi eventi da monitorare, e magari un quarto nodo. Che ormai, lo ripeto con noncuranza, costerebbe un comando. Insomma la fantasia è il limite!
Il repository è pubblico su Codeberg: codice, method e knowledge base.
“La tecnologia libera non è solo codice, è la libertà di capire cosa c'è sotto il cofano.”
👤 Lorenzo | ItsMeLarry 🧪 Esperimenti AI & Open Source | 🕹️ Retro Gaming & Graphic Novel 🎸 Rock, Folk, Jazz, Punk | 🔒 Privacy First 📍 Toscana / Digitale
🔗 noblogo.org | 🐙 Codeberg