- Inizio
- Esempi
Esempi di lavori
Ogni voce racconta un lavoro vero: il problema, quello che abbiamo fatto, il risultato o il punto a cui siamo arrivati. I nomi dei clienti e i dettagli che li renderebbero riconoscibili sono tolti di proposito. Lo stato dice se il lavoro è in esercizio, consegnato, in corso, un prototipo o uno studio.
-
Una rete di sede estesa fino al datacenter
- Il problema
- La LAN e due VLAN della sede dovevano arrivare, a livello 2, ai server ospitati in datacenter; la soluzione precedente su L2TP e IPsec non bastava.
- Cosa abbiamo fatto
- Tre tunnel EoIP sopra WireGuard, con una MTU utile di 1378 byte. Due insidie risolte strada facendo: il NAT del firewall di sede scartava le risposte quando la porta WireGuard di origine coincideva con quella di destinazione, e gli indirizzi ammessi nel tunnel dovevano comprendere tutte le reti instradate.
- Risultato
- Estensione in esercizio. L’alta affidabilità automatica fra i due router di sede è stata studiata e, per ora, giudicata non pronta: lo abbiamo scritto, invece di attivarla.
-
Una sede collegata in 5G con due operatori
- Il problema
- Una sede doveva lavorare su linee 5G in attesa della fibra, senza perdere la gestione remota.
- Cosa abbiamo fatto
- Due router e due linee 5G di operatori diversi: la navigazione esce dalla seconda linea con il policy routing, la prima resta ai tunnel e alla gestione. Uno script a bordo salva un punto di ripristino dopo 30 minuti di funzionamento sano e lo ricarica se gestione e Internet tacciono. La misura di banda ha mostrato che il limite era la CPU del router (97%), non la linea.
- Risultato
- La sede ha lavorato in 5G e oggi il 5G fa da riserva alla fibra; il passaggio fra le due segue una procedura in cinque passi con nove controlli preliminari.
-
VPN verso il sito di disaster recovery in cloud
- Il problema
- Il sito di disaster recovery in cloud doveva essere raggiungibile in modo affidabile, e la configurazione non doveva mai mettere a rischio la produzione.
- Cosa abbiamo fatto
- Due tunnel verso i due punti di terminazione del sito DR. Lo script che li configura ha anteprima, verifica, ritorno indietro e un blocco che protegge la produzione.
- Risultato
- VPN collaudata nei due versi su entrambi i tunnel (16-18 ms) e passaggio manuale al DR pronto. Il passaggio automatico, una macchina a tre stati con isteresi, è una proposta; i due tunnel attivi con BGP sono uno studio.
-
Accesso remoto su un firewall senza SSL-VPN
- Il problema
- Su quel modello di firewall la VPN SSL non esiste, ma gli utenti dovevano lavorare da fuori come se fossero in ufficio.
- Cosa abbiamo fatto
- FortiClient su IPsec IKEv2 con EAP: i client prendono un indirizzo della LAN (con proxy ARP) e raggiungono anche le VPN verso le altre sedi senza modifiche dall’altra parte. Dietro un hotspot il traffico di ritorno si perdeva nel NAT: abbiamo forzato il NAT-T.
- Risultato
- Accesso remoto in esercizio; l’accesso con le credenziali aziendali Microsoft Entra ID via SAML è configurato e in prova.
-
Un server VPN che esauriva la memoria sei volte al giorno
- Il problema
- Il server VPN usato per i backup di un cliente veniva terminato per memoria esaurita fino a sei volte al giorno.
- Cosa abbiamo fatto
- La causa era un bridge su una scheda di rete spenta, che apriva un socket al secondo: 27.233 socket orfani, circa 7 GB di memoria del kernel. Abbiamo tolto il bridge e aggiunto un controllo automatico.
- Risultato
- Memoria usata scesa dal 95% al 3,7%; un controllo automatico sorveglia il servizio.
-
Una firma IPS che isolava un server ogni ora
- Il problema
- Un server perdeva il dominio a cadenza regolare, senza tracce evidenti nei log di traffico del firewall.
- Cosa abbiamo fatto
- Una firma di prevenzione delle intrusioni scattava sul traffico ONVIF verso due telecamere e la sua azione di blocco scartava tutto il traffico del server, 3.700 pacchetti al secondo; il blocco si rinnovava a ogni scadenza. Abbiamo creato l’eccezione attraverso le API del gestore in cloud.
- Risultato
- Server stabile. Ora un controllo automatico legge ogni 3 minuti le tabelle dei blocchi di cinque cluster di firewall e avvisa con un pulsante di sblocco.
-
Regole che sembravano bloccare e non bloccavano
- Il problema
- Le regole distribuite dal gestore in cloud non si leggono nella configurazione locale, e la prova di corrispondenza delle policy restituiva sempre la stessa regola.
- Cosa abbiamo fatto
- Abbiamo usato come riferimento i log e le sessioni, che non mentono, e fatto l’inventario delle pubblicazioni su Internet. Così è emerso che il blocco degli indirizzi malevoli era inefficace: una regola di permesso lo precedeva di 355 posizioni.
- Risultato
- Il blocco è stato spostato prima del permesso; inventario delle pubblicazioni consegnato.
-
La rete nuova di una sede, passata in una giornata
- Il problema
- Sostituire firewall, switch e Wi-Fi di una sede in esercizio, insieme alle VPN verso il cloud e verso le altre sedi.
- Cosa abbiamo fatto
- Cluster FortiGate attivo-passivo, due switch Aruba CX, controller UniFi e tre access point, preparati accanto alla rete esistente. Poi cinque VPN fra sedi (tre basate su route verso Google Cloud, due verso Check Point), l’accesso remoto e la Wi-Fi aziendale e ospiti.
- Risultato
- Passaggio in una giornata, alta affidabilità provata, ritorno indietro non necessario. Il giorno dopo lo script di controllo dava 38 verifiche positive su 38; i contatori hanno fatto emergere una porta guasta, che ogni volta che risaliva provocava un ricalcolo dello spanning tree, ed è stata spenta.
-
Il nodo di distribuzione di una sede logistica
- Il problema
- Il nodo di distribuzione della rete di sede era instabile e l’uplink passava da un modulo ottico difettoso.
- Cosa abbiamo fatto
- Nuovo switch Aruba come radice MSTP, uplink spostato dal modulo difettoso, un server syslog e un cruscotto di disponibilità per 22 apparati.
- Risultato
- Rete di sede stabile e osservabile; lo studio dello spanning tree è applicato in parte.
-
Un anello intermittente fra due tecnologie di aggregazione
- Il problema
- Alcuni server perdevano traffico a tratti, senza un guasto evidente, su una dorsale di otto apparati di due produttori distribuiti su tre campus.
- Cosa abbiamo fatto
- Abbiamo scritto un rilevatore che parte da un principio semplice: i due membri di una coppia VLT non possono essere in disaccordo su dove si trova un indirizzo MAC. Ha individuato i server colpiti, e lo studio delle configurazioni ha localizzato il ciclo nel punto in cui si incontrano due tecnologie MLAG diverse, su un collegamento con lo spanning tree filtrato.
- Dove siamo arrivati
- Tolte 28 VLAN da un collegamento (CPU di un core dal 27% al 12%), riattivato un secondo link senza spostamenti su 578 MAC, ridotti gli spostamenti di MAC da 12 a 2 al minuto e azzerate le incoerenze VLT con un intervento provvisorio. La soluzione strutturale è studiata, con i vincoli dell’hardware verificati.
-
Ridondanza dei router di un sito produttivo
- Il problema
- La coppia di router del sito non garantiva un subentro pulito: le BPDU non si scambiavano perché la VLAN 1 era senza tag da un lato e con tag dall’altro.
- Cosa abbiamo fatto
- Ridondanza rifatta con VRRP e un controllo automatico contro gli anelli.
- Risultato
- Subentro misurato: circa 5 secondi per un guasto del router, 10 per un cavo WAN staccato, rientro senza sovrapposizioni.
-
Gestione chiusa su 26 router dopo un avviso di sicurezza
- Il problema
- Un avviso del CERT segnalava vulnerabilità di RouterOS sfruttate attraverso SSH. Bisognava sapere subito quali apparati erano esposti e chiudere, senza perdere l’accesso a nessuno.
- Cosa abbiamo fatto
- Inventario di 67 apparati di 11 progetti con un semaforo basato sull’esposizione alle vulnerabilità note, non sui numeri di versione. Su 26 apparati abbiamo ristretto l’accesso di gestione agli indirizzi ammessi e spento i servizi inutili, con anteprima obbligatoria, uno scheduler a bordo che ripristina tutto in 10 minuti se la modifica non viene confermata, e una verifica con una connessione nuova.
- Risultato
- Risultato misurato: nessun apparato con SSH esposto. Il piano di aggiornamento in sei ondate è scritto e in corso.
-
Verifica di compromissione su un concentratore VPN
- Il problema
- Escludere con certezza che un concentratore VPN fosse stato manomesso.
- Cosa abbiamo fatto
- Controllo completo di utenti, chiavi, attività pianificate, script, tunnel, firewall, rotte, DNS, proxy, certificati e storico delle modifiche.
- Risultato
- Nessun impianto trovato, con l’elenco puntuale di che cosa è stato verificato.
-
Roaming corretto su oltre cento access point
- Il problema
- Roaming lento e terminali «connessi ma senza indirizzo» in più sedi.
- Cosa abbiamo fatto
- Abbiamo documentato che il controller lavora solo a livello 2, mentre gateway e relay DHCP stanno sul firewall e l’autenticazione 802.1X va ai server RADIUS. Le correzioni (802.11r su 20 SSID, assistente di roaming, DTIM, velocità minima) sono state applicate con uno script e verificate con 57 controlli automatici (56 superati), con un ritorno indietro mirato su tre SSID.
- Risultato
- Roaming corretto. Sui terminali senza indirizzo abbiamo anche corretto per iscritto la nostra prima ipotesi: a sbloccarli è stato il riavvio degli access point, non la disattivazione di 802.11r.
-
Terminali di magazzino che cambiavano access point cinque volte l'ora
- Il problema
- I terminali di magazzino più vecchi perdevano la connessione durante il lavoro.
- Cosa abbiamo fatto
- Dai dati del controller: sullo SSID con 802.11r quei terminali facevano 4,8 roaming e 3,8 disconnessioni all’ora, contro 0 e 0,2 sullo SSID senza. Le cause sono più d’una: soglia per i client «appiccicosi» disattivata, driver datato, assenza di 802.11k e v, problemi noti della combinazione FT-PSK.
- Dove siamo arrivati
- Raccomandazioni consegnate in ordine di priorità.
-
La rete di un grande evento, dal banco alla chiusura
- Il problema
- Una rete temporanea con molte aree, ospiti e produzioni diverse, che doveva reggere per tutto l’evento ed essere governabile da remoto.
- Cosa abbiamo fatto
- Gateway e DHCP su un cluster Linux in alta affidabilità, portato da due a quattro nodi senza fermo; due linee Internet con policy routing per VLAN; 16 VLAN, alcune con limite di banda. Sette router agganciati alla VPN di gestione: alcune unità clonate avevano lo stesso MAC di bridge e portavano la perdita di pacchetti fino al 100%. Undici access point con il piano dei canali costruito sui vincoli italiani (canali DFS, zone dei radar meteorologici). Un pannello web per spostare una VLAN da una linea all’altra, collaudato con 10 prove che hanno fatto emergere tre difetti, tutti corretti.
- Risultato
- Rete in servizio per l’intero evento, con monitoraggio ridondato: rientro automatico misurato in circa 18 secondi.
-
Access point preparati al banco
- Il problema
- Preparare in poco tempo access point nuovi, con firmware, nomi e indirizzi corretti.
- Cosa abbiamo fatto
- Banco con il controller su un portatile e gli access point collegati uno alla volta in PoE; uno script PowerShell li adotta, aggiorna il firmware, li rinomina, assegna l’indirizzo e imposta via SSH l’indirizzo del controller.
- Risultato
- Circa 5 minuti per access point, 8 preparati in una giornata, con le trappole documentate per la volta successiva.
-
Un'applicazione web esposta solo dove serve
- Il problema
- Un’applicazione raggiungibile da Internet riceveva traffico di scanner e tentativi di accesso.
- Cosa abbiamo fatto
- nginx inoltra due soli percorsi e chiude tutto il resto senza rispondere; accesso consentito a un elenco di sorgenti, limite di 10 richieste al secondo per indirizzo, 21 scanner riconosciuti e respinti, quattro regole fail2ban corrette perché non leggevano i log.
- Risultato
- Superficie ridotta a due percorsi. Quando un aggiornamento automatico ha mandato in crash un modulo di terze parti, l’abbiamo individuato dal log del kernel e disattivato.
-
Outlook che faceva bloccare l'ufficio dal sito vetrina
- Il problema
- L’indirizzo Internet della sede finiva nella lista nera del servizio di hosting del sito aziendale.
- Cosa abbiamo fatto
- Abbiamo scoperto che Outlook interrogava il servizio autodiscover sul sito vetrina 378 volte al giorno, e il filtro anti-bot dell’hosting lo scambiava per un attacco. Una regola Cloudflare risponde a quelle richieste prima che arrivino al sito, verificata su 16 varianti.
- Risultato
- Le richieste di Outlook non arrivano più al sito e la sede non finisce più in lista nera.
-
Eventi di videosorveglianza che non arrivavano alla centrale
- Il problema
- Gli eventi delle telecamere non arrivavano alla centrale, eppure i collegamenti fra i server funzionavano tutti.
- Cosa abbiamo fatto
- I log del firewall hanno mostrato che il canale degli eventi viaggiava in UDP verso indirizzi APIPA, annunciati dal software delle schede USB di gestione dei server. Abbiamo disattivato quelle schede e riavviato il servizio solo dove serviva.
- Risultato
- Eventi di nuovo regolari, senza toccare il resto dell’impianto.
-
PC che non si aggiornavano, per tre cause sovrapposte
- Il problema
- Gli aggiornamenti di Windows fallivano su molti PC della sede.
- Cosa abbiamo fatto
- Le cause erano tre. Due sono state risolte sui PC; la terza è stata localizzata con TTL e tempi di risposta in un proxy trasparente dell’operatore, dopo aver scagionato router e firewall con i loro contatori.
- Dove siamo arrivati
- Due cause risolte, la terza documentata e in mano all’operatore.
-
Raccolta dei flussi di rete per un fornitore cloud
- Il problema
- Mancava una visione di chi parla con chi e quanto.
- Cosa abbiamo fatto
- nprobe come collettore NetFlow v9 verso ntopng, con archivio su ClickHouse; definite le reti locali.
- Risultato
- Host riconosciuti come locali passati da 0 a 82, nessun flusso perso.
-
La memoria che la cache del file system si prendeva
- Il problema
- Su un nodo la cache di ZFS occupava 116 GB di RAM e lo swap era al 100%; durante i backup un pool di dischi meccanici portava il carico a 62 su 16 thread.
- Cosa abbiamo fatto
- Un limite alla cache per ogni nodo e la deduplica della memoria (KSM); un tetto di scrittura sui dischi dei repository di backup.
- Risultato
- RAM libera passata da 12,9 a 68 GB sul nodo più carico; durante i backup il carico è sceso da 62 a 22.
-
Un cluster nuovo dimensionato sulle misure
- Il problema
- Scegliere il secondo e il terzo nodo di un cluster senza comprare più del necessario.
- Cosa abbiamo fatto
- Proxmox VE 9 installato attraverso le API del provider. Il secondo nodo scelto sul carico reale (0,36 core di media), sulle prestazioni del singolo core e sulla compatibilità delle CPU virtuali. Due nodi più un voto esterno, repliche ZFS ogni 15 minuti su una rete privata misurata a 918-947 Mbit/s.
- Risultato
- Il terzo nodo, installato in 15 minuti, ha preso il posto del voto esterno.
-
vMotion bloccato da un modulo del kernel
- Il problema
- In una sede estera con 2 host e 31 macchine virtuali le migrazioni a caldo non funzionavano.
- Cosa abbiamo fatto
- Tolte le ISO montate su 7 macchine, azzerato con migrazioni a freddo lo stato di migrazione corrotto di 26 macchine; la causa radice era un modulo del kernel ESXi non caricato su uno degli host.
- Risultato
- vMotion di nuovo funzionante nei due sensi: 14 macchine ribilanciate a caldo in 11,6 minuti, senza fermo.
-
Due host spostati in un cluster con EVC in quattro minuti
- Il problema
- Riorganizzare un vCenter con 9 host e 97 macchine virtuali portando due host in un cluster con compatibilità di CPU uniforme.
- Cosa abbiamo fatto
- Uno studio completo dell’ambiente con analisi critica, poi lo spostamento affidato a uno script provato.
- Risultato
- Quattro minuti in tutto, macchine ferme per circa tre, indirizzi invariati.
-
Un hub VPN spostato senza interrompere nessuno
- Il problema
- Dismettere un host di virtualizzazione presso un provider e portarne i servizi su un nodo di un altro provider, compreso l’hub VPN di molti utenti.
- Cosa abbiamo fatto
- L’hub VPN (33 client OpenVPN e 63 peer WireGuard) è stato spostato un client alla volta. Le macchine ripristinate da backup sono state adattate al nuovo hypervisor e 35 record DNS su tre provider ripuntati via API.
- Risultato
- Ogni client riconnesso in circa 10 secondi, zone DNS ricontrollate tutte, vecchio host verificato vuoto e dismesso.
-
Un database spostato con 41 secondi di fermo
- Il problema
- Portare il backend applicativo da una macchina virtuale a un server nuovo senza perdere dati.
- Cosa abbiamo fatto
- La prova generale ha fatto emergere un percorso scritto nel codice, corretto prima del passaggio. Durante la propagazione del DNS la vecchia macchina ha fatto da reverse proxy verso la nuova.
- Risultato
- Fermo di 41 secondi, 82.954 record prima e dopo.
-
Da un percorso a quattro, senza fermare il cluster
- Il problema
- Durante la manutenzione di un array, 12 macchine virtuali hanno avuto errori di I/O per 23 minuti.
- Cosa abbiamo fatto
- L’analisi in sola lettura ha trovato la causa: destinazioni iSCSI sbagliate nella configurazione, un solo percorso per nodo verso i due array in replica. Correzione a caldo, un nodo alla volta.
- Risultato
- Da uno a quattro percorsi per volume, verificati anche dopo un riavvio.
-
Uno switch Fibre Channel sostituito senza conflitti
- Il problema
- Sostituire uno switch guasto in una SAN di quattro switch su due fabric.
- Cosa abbiamo fatto
- Lo switch nuovo è stato portato alla versione del fabric con quattro aggiornamenti in sequenza; licenze trasferite dall’unità guasta.
- Risultato
- Unione al fabric senza conflitti di zoning.
-
Due cluster di storage dismessi senza sorprese
- Il problema
- Spegnere due cluster NetApp (quattro controller) senza togliere niente a nessuno.
- Cosa abbiamo fatto
- Inventario completo attraverso le API, poi la verifica che nessun sistema li usasse più.
- Risultato
- Dismissione fatta solo dopo aver visto che nulla rispondeva più.
-
Un'appliance di backup piena, svuotata senza perdere copie
- Il problema
- L’appliance di deduplica da 32 TB era a zero byte liberi e i backup di oltre 50 job fallivano.
- Cosa abbiamo fatto
- Prima di cancellare abbiamo verificato, macchina per macchina, dove esisteva un’altra copia. Abbiamo anche scoperto che lo spazio mostrato dalla console era una cache sbagliata (898 GB contro 12.643 reali): da allora si decide sulla fonte diretta. Poi 24 job nuovi dagli snapshot dell’array via Fibre Channel.
- Risultato
- Liberati 5,9 TiB sull’appliance e oltre 14 TB su un repository ReFS; backup ripartiti.
-
Un job fallito 211 volte di fila
- Il problema
- Un job di backup falliva sempre, e nessuno trovava il perché.
- Cosa abbiamo fatto
- Dai log dei singoli task: fallivano tutti quelli che passavano da un certo proxy (160 su 160) e riuscivano tutti gli altri (269 su 269). Abbiamo escluso quel proxy, con il ritorno indietro pronto.
- Risultato
- 9 macchine su 9 salvate in 38 minuti.
-
Crash notturni e una catena di job spezzata
- Il problema
- Il servizio di backup cadeva di notte (13 volte in 14 giorni) e una catena di job si era spezzata in silenzio, lasciando molte macchine senza copie recenti.
- Cosa abbiamo fatto
- Cause in fila: istanza SQL con nome, porta risolta via UDP, memoria sotto pressione, pacchetti scartati. I crash sono stati chiusi con una porta TCP statica; la catena è stata ricucita e i job più vecchi migrati per passare alla versione 13.
- Risultato
- Catena ripristinata; 48 job migrati alla versione 13, nessuno fallito.
-
Dieci terabyte da un volume illeggibile, verificati byte per byte
- Il problema
- Un repository di backup ReFS da 16 TiB era diventato illeggibile; sembrava un guasto dei dischi.
- Cosa abbiamo fatto
- Gli «errori di I/O» erano spazio esaurito nello storage sottostante, i dischi erano sani. Copia integrale su un altro nodo (15,6 TB, verificata). Su un clone abbiamo scoperto che Windows Server 2025 aggiorna il volume in modo irreversibile anche senza montarlo: sull’originale avrebbe bruciato l’unico strumento capace di leggerlo. L’estrazione si è fatta sul clone.
- Risultato
- 1.479 file e 10,08 TB estratti con verifica byte per byte in circa 3,5 giorni invece dei 20 stimati; database dei backup di Microsoft 365 riparati, backup ripartiti, danni residui sotto l‘1,6%.
-
Una macchina di produzione recuperata con 14 ms di fermo
- Il problema
- Una macchina virtuale di produzione stava su un pool thin corrotto.
- Cosa abbiamo fatto
- Recuperata da un clone dello snapshot dell’array su un nodo isolato, poi riportata nel cluster con una migrazione a caldo.
- Risultato
- 14 millisecondi di fermo; la bonifica del pool ha poi liberato circa 23 TiB.
-
I backup ritrovati su un disco uscito dal mirror
- Il problema
- Dopo un attacco servivano copie integre delle macchine virtuali.
- Cosa abbiamo fatto
- Un disco uscito mesi prima dal mirror del NAS conteneva una catena di backup integra: montato in sola lettura forzata e copiato sul nuovo NAS.
- Risultato
- 826 GB e 4 macchine virtuali recuperati.
-
Un sito di disaster recovery spento e riacceso tutto da remoto
- Il problema
- Il sito DR (storage virtualizzato, server blade, 6 host e circa 145 macchine di replica) doveva essere spento e poi riacceso senza nessuno sul posto.
- Cosa abbiamo fatto
- Piano di spegnimento in 10 fasi con uno script che di base simula soltanto, conferme esplicite per i passi che toccano la produzione e blocchi di sicurezza. Riaccensione con un orchestratore in 8 fasi; un controller dello storage fermo al loader è stato riavviato dalla console di gestione remota del server.
- Risultato
- Verifica con un accesso reale a 30 apparati: 30 su 30. Poi abbiamo misurato il vuoto di RPO accumulato (circa 3 giorni) e riattivato in catena i 26 job di replica.
-
Repliche da una sede estera che fallivano sempre
- Il problema
- La replica da una sede estera falliva a ogni esecuzione.
- Cosa abbiamo fatto
- La causa era una catena di 9 snapshot mai consolidata sul lato di arrivo; repliche ricreate via API.
- Risultato
- Repliche di nuovo regolari.
-
Ripartire dopo un blackout con la corrente che andava e veniva
- Il problema
- Uno stabilimento era senza corrente stabile; l’unico accesso rimasto era un router 4G/5G di gestione.
- Cosa abbiamo fatto
- Da lì una sentinella registrava cadute e ritorni della rete elettrica, con una regola semplice: non si accende nulla finché la rete non regge 30 minuti. I controller di gestione dei server dicevano quale sala aveva corrente. Runbook di ripartenza in 9 fasi, scritto per indirizzi IP perché a freddo il DNS non c’è.
- Risultato
- Alla ripartenza circa 90 macchine si erano accese su un solo host (RAM al 94%): 61 ridistribuite a caldo, 61 su 61 riuscite. Il database, passato sul nodo secondario, è stato analizzato e la procedura di riallineamento preparata, da eseguire su autorizzazione.
-
Una scheda di rete che spariva dal bus
- Il problema
- Il cluster andava in crash periodicamente e, dopo il subentro, rispondeva una macchina su tre.
- Cosa abbiamo fatto
- Nei registri hardware letti via Redfish (208 voci, 48 critiche) comparivano sempre gli stessi tre errori PCIe: la scheda 10G di sincronizzazione spariva dal bus.
- Risultato
- Causa dimostrata e spiegato anche il comportamento dopo il subentro; raccomandazione consegnata.
-
Una transazione da 132 byte che riempiva il disco
- Il problema
- Il log del database arrivava a 267-275 GB e riempiva il disco.
- Cosa abbiamo fatto
- La causa era un’applicazione esterna che lasciava aperta una transazione di sola lettura da 132 byte: anche in recovery SIMPLE bastava a impedire il riciclo del log. Rimedio d’emergenza e un tetto al log.
- Risultato
- Disco al sicuro; la correzione dell’applicazione è stata indicata a chi la sviluppa.
-
RMAN bloccato da archivelog cancellati a mano
- Il problema
- I backup RMAN non partivano più dopo che alcuni archivelog erano stati cancellati a mano.
- Cosa abbiamo fatto
- Rimossi 22.527 record orfani dal controlfile, catalogo registrato di nuovo, 11 sessioni bloccate terminate.
- Risultato
- Backup di prova riuscito e procedure di arresto e riavvio scritte.
-
Sette milioni di permessi letti in otto minuti
- Il problema
- Serviva sapere chi può leggere che cosa su un file server cresciuto negli anni.
- Cosa abbiamo fatto
- Uno scanner dei permessi NTFS scritto apposta.
- Risultato
- 465.280 cartelle e 7,3 milioni di permessi analizzati in meno di 8 minuti.
-
Il ritiro di EWS in Exchange Online, spiegato ai clienti
- Il problema
- Il ritiro di Exchange Web Services in Exchange Online rischiava di fermare i backup di Microsoft 365.
- Cosa abbiamo fatto
- Una guida per i clienti (impostazioni del tenant, tempi di propagazione, aggiornamenti) e lo script per applicare le impostazioni.
- Risultato
- Una guida e uno script che ogni cliente può applicare da sé.
-
Un gateway di posta rifatto accanto al vecchio
- Il problema
- Il server di posta di frontiera girava su un sistema operativo fuori supporto.
- Cosa abbiamo fatto
- Il nuovo server è stato costruito accanto al vecchio e la catena SMTP provata prima dello scambio di indirizzo.
- Risultato
- Nuovo server in servizio, con il vecchio tenuto pronto come ritorno.
-
Una macchina che rifiutava SSH, e non era la memoria
- Il problema
- Una macchina virtuale rifiutava le connessioni di amministrazione e sembrava a corto di memoria.
- Cosa abbiamo fatto
- 151 apparati si collegavano di continuo (circa 53 connessioni al minuto) e, con la macchina rallentata, saturavano le connessioni non ancora autenticate; la causa di fondo erano 16 processi Java senza limite di memoria. I log, misurati in 151,9 GiB in 30 giorni, sono stati ridotti tenendo le metriche.
- Risultato
- Causa chiarita e carico ridotto; una rete aggiunta alla VPN con runbook e ritorno indietro, con 2 minuti e 54 secondi di fermo e verifica da tre reti diverse.
-
La copia pesante di mezzogiorno era un fuso orario
- Il problema
- I backup con agent delle macchine Linux fallivano e una copia pesante partiva in pieno giorno.
- Cosa abbiamo fatto
- Secure Boot bloccava il modulo del kernel usato per gli snapshot: i job sono stati rifatti senza snapshot. La copia di mezzogiorno era il fuso orario sbagliato dei server di backup.
- Risultato
- Nove macchine salvate con regolarità, negli orari giusti.
-
Da 250 notifiche al giorno a zero, tenendo gli allarmi veri
- Il problema
- Un monitoraggio di 36 nodi in 8 gruppi produceva allarmi perenni e centinaia di notifiche di oscillazione.
- Cosa abbiamo fatto
- Archivio su due livelli (dati grezzi per 7 giorni, aggregati orari per 400), soglie tarate sullo storico, un ritardo di conferma prima di notificare. Un controllo sull’età dell’ultimo backup, letta dal database invece che dal job.
- Risultato
- Da 5 allarmi, 3 perenni, a 2 veri; notifiche di oscillazione da circa 250 al giorno a zero; un grafico di 30 giorni si apre in circa 25 ms. Il controllo sui backup ha trovato database senza una copia completa recente mentre il job risultava riuscito.
-
La parete di monitoraggio di un grande evento
- Il problema
- Tenere sotto controllo apparati, linee e Wi-Fi di una rete temporanea, con una vista leggibile da lontano in sala regia.
- Cosa abbiamo fatto
- Portale in Python senza framework né database esterni: 20 apparati controllati ogni 60 secondi, banda ed errori ogni 10, radio e client degli access point ogni 45; parete con colori solo semantici, verificata con screenshot; avvisi su Telegram. La regola d’allarme a episodi è stata validata rigiocando 24 ore di dati reali.
- Risultato
- Notifiche da circa 80 a 4 al giorno. Sono emersi anche un resolver DNS che impiegava 3-4 secondi per nome e gli access point spinti dai radar meteorologici su canali a potenza ridotta, riportabili a 1 W con un pulsante.
-
La CPU nuova non serviva
- Il problema
- Capire se un nodo andava potenziato.
- Cosa abbiamo fatto
- Misure di carico reali: in media 0,41 core su 24. Misurato anche il costo della cifratura del disco: circa l‘1,5% di un core nei picchi.
- Dove siamo arrivati
- Il limite era il disco, non la CPU: lo studio indica dove conviene intervenire.
-
Esfiltrazione con estorsione: quanto era uscito davvero
- Il problema
- Gli attaccanti avevano pubblicato una parte dei dati sottratti e ne rivendicavano molti di più. Per decidere le notifiche serviva una misura oggettiva di che cosa fosse uscito.
- Cosa abbiamo fatto
- Abbiamo acquisito il materiale pubblicato su una macchina forense isolata, ne abbiamo verificato l’autenticità con hash e metadati e lo abbiamo analizzato documento per documento, ricavando solo numeri aggregati: categorie di dati, presenza di dati particolari e di documenti d’identità, codici fiscali validati e mascherati. Nessun dato personale è stato estratto in chiaro.
- Risultato
- Una base di fatti per le notifiche, con il confine dichiarato fra ciò che il campione dimostra e ciò che resta da verificare sui log dei server. In più, un controllo orario automatico del sito di pubblicazione con un avviso per posta a ogni cambiamento.
-
Ransomware a doppia estorsione con dati particolari
- Il problema
- Capire quali dati, quanti e di che tipo gli attaccanti dichiaravano di avere, per documentare l’incidente verso le autorità.
- Cosa abbiamo fatto
- Abbiamo aperto il fascicolo dell’incidente (raccolta iniziale, piano d’indagine, richiesta strutturata di informazioni e prove, registro delle evidenze, cronologia) e preparato lo strumento che classifica i dati sulla macchina isolata restituendo solo valori aggregati e mascherati.
- Dove siamo arrivati
- Fascicolo e strumenti pronti: l’analisi prosegue man mano che arriva il materiale.
-
Bonifici dirottati: la casella violata non era quella del cliente
- Il problema
- L’azienda aveva pagato più bonifici su coordinate fraudolente e temeva che la propria posta fosse stata violata.
- Cosa abbiamo fatto
- Abbiamo analizzato i log di accesso alle caselle interne: nessun accesso anomalo, nessuna regola di inoltro nascosta. Incrociando le intestazioni dei messaggi abbiamo dimostrato che la casella compromessa era quella del fornitore; il dominio contraffatto è emerso calcolando la distanza fra i nomi.
- Risultato
- Rapporto forense con cronologia completa, indicatori e azioni: richiamo dei bonifici, blocco del dominio sosia, verifica delle coordinate bancarie su un canale indipendente, audit delle caselle e una regola contro lo spoofing dei domini dei fornitori.
-
Esecuzione di codice da remoto, senza un solo accesso
- Il problema
- Un’applicazione web vulnerabile, eseguita con privilegi elevati, aveva permesso di installare un programma malevolo e due meccanismi di persistenza.
- Cosa abbiamo fatto
- Abbiamo dimostrato che l’attaccante non aveva mai effettuato un accesso: il codice passava dal processo dell’applicazione, quindi i log di autenticazione erano puliti per definizione. Dai log dell’applicazione abbiamo ricostruito quali credenziali erano state davvero lette e quali solo esposte, poi abbiamo rimosso la persistenza.
- Risultato
- Perimetro dell’incidente chiarito, credenziali sottratte sostituite e verificate una per una, esposizione ridotta.
-
Pacchetto di notifica per un responsabile del trattamento
- Il problema
- L’incidente riguardava dati che il fornitore trattava per conto dei propri clienti: le comunicazioni dovevano tenere conto di entrambi i ruoli.
- Cosa abbiamo fatto
- Abbiamo preparato le bozze per il Garante, per gli interessati e per i clienti titolari, con i campi da completare evidenziati, i dati particolari mascherati e le scadenze calcolate: 72 ore per il Garante; 24 ore, 72 ore e un mese per gli stadi NIS2.
- Risultato
- Testi pronti per la revisione e la firma di DPO e legale, coerenti fra loro e con le evidenze.
-
Il SIEM era verde, ma non raccoglieva più niente
- Il problema
- Un certificato interno era scaduto e tutti gli agenti avevano smesso di inviare dati nello stesso momento. Il cruscotto restava verde e per mesi nessuno se n’era accorto.
- Cosa abbiamo fatto
- Abbiamo trovato la causa e riemesso il certificato con la stessa autorità interna, così gli agenti non andavano riarruolati uno per uno. Poi abbiamo allungato la conservazione del registro di sicurezza sui controller di dominio, installato gli agenti mancanti e costruito un cruscotto per seguire l’uso di un account amministrativo critico.
- Risultato
- SIEM di nuovo alimentato, copertura più ampia e due controlli fissi per non ricadere nel guasto silenzioso: l’ultimo dato ricevuto da ogni sorgente e la scadenza dei certificati.
-
Macchine virtuali che sembravano protette
- Il problema
- Gran parte delle macchine risultava senza protezione e alcuni record della console davano un quadro falso.
- Cosa abbiamo fatto
- Abbiamo incrociato l’inventario reale con quello della console, riconoscendo le macchine con un identificativo affidabile e non per nome; installato gli agenti mancanti, corretto i casi di antivirus installato ma spento, messo a punto la politica per un server senza interfaccia grafica e misurato il carico sulla CPU.
- Risultato
- Copertura completa e verificata, con le anomalie residue elencate una per una.
-
EDR sui server di un sistema di localizzazione dei mezzi
- Il problema
- I server Linux del sistema che localizza i mezzi della flotta dovevano entrare nella copertura EDR, senza disturbare il servizio.
- Cosa abbiamo fatto
- Agente installato via SSH, verifica della registrazione e della piena funzionalità sulla console; i falsi positivi del controllo automatico sono stati ricondotti a nomi ricostruiti dagli indirizzi.
- Risultato
- Copertura del parco verificata.
-
Credenziali sostituite e verificate apparato per apparato
- Il problema
- Dopo una compromissione, alcune password di apparati di rete e di server risultavano lette dall’attaccante.
- Cosa abbiamo fatto
- Abbiamo cambiato le credenziali di tutti gli apparati coinvolti con un giro di verifica per ognuno: accesso con la password nuova, rifiuto della vecchia, controllo che utenti, attività pianificate e chiavi non fossero stati alterati.
- Risultato
- Credenziali esposte sostituite e verificate, ed elencati gli altri sistemi su cui le stesse password andavano cambiate.
-
Da Internet, solo la porta 443
- Il problema
- Le porte di amministrazione dei server erano raggiungibili da Internet.
- Cosa abbiamo fatto
- Abbiamo lasciato aperta solo la 443, spostato l’amministrazione dietro tre tunnel WireGuard indipendenti con più strade per ogni macchina, aggiunto il blocco automatico dei tentativi falliti con un avviso a ogni accesso riuscito e scritto le procedure di rientro d’emergenza.
- Risultato
- Superficie esposta ridotta a un solo servizio, con le procedure per rientrare anche se un tunnel cade.
-
Certificazione Cyber Essentials
- Il problema
- Ottenere la certificazione britannica Cyber Essentials, che impone di installare gli aggiornamenti di gravità alta entro 14 giorni dalla pubblicazione.
- Cosa abbiamo fatto
- Requisiti dello schema, questionario, inventario degli apparati, registro dei bollettini di sicurezza e procedure di aggiornamento con conservazione delle evidenze.
- Dove siamo arrivati
- Percorso avviato, con le scadenze dei 14 giorni tenute sotto controllo.
-
Centocinquanta dispositivi tornati a rispondere in un'ora
- Il problema
- Su un parco di circa 300 iPad supervisionati, quasi tutti avevano smesso di eseguire i comandi di gestione.
- Cosa abbiamo fatto
- Prove attive (la conferma del comando, non il «visto per ultimo»), divisione del parco per data di arruolamento e registri letti via USB: il certificato del canale di notifica era stato sostituito con uno di argomento diverso. Abbiamo ricaricato l’originale, ancora valido, con un passaggio di console non documentato.
- Risultato
- 149 dispositivi tornati a rispondere in un’ora e almeno 1.587 app installate o aggiornate, senza un solo intervento fisico e senza perdita di dati. Poi l’inventario della postura di sicurezza, con le raccomandazioni.
-
Un kit da campo per i dispositivi muti
- Il problema
- Alcuni dispositivi non rispondevano più e andavano ripristinati in sede, da personale non tecnico.
- Cosa abbiamo fatto
- Un eseguibile unico, senza bisogno di Internet né di diritti di amministratore, che salva i dati, cancella il dispositivo e lo fa riarruolare automaticamente.
- Risultato
- Un iPad muto da 28 giorni riarruolato in 23 minuti, che risponde ai comandi in 3 secondi.
-
La barra che mancava a un contact center con più sedi
- Il problema
- L’agente web standard della piattaforma non bastava: il microfono restava bloccato nella cornice della pagina e gli eventi delle chiamate non erano accessibili.
- Cosa abbiamo fatto
- Una barra con una vista web isolata e un’integrazione approfondita con la piattaforma. Nel tempo ha aggiunto l’inoltro automatico del telefono fisico all’interno virtuale, la scheda del cliente alla risposta, la presa delle chiamate dalla coda (con conteggi identici ai contatori nativi), la pausa comandata dal supervisore e il passaggio al sito di disaster recovery.
- Risultato
- In esercizio quotidiano, con sviluppo continuo nel 2026.
-
Una barra che partiva ma non si vedeva
- Il problema
- Su alcune postazioni la barra risultava avviata ma non compariva sullo schermo.
- Cosa abbiamo fatto
- Il registro della postazione mostrava registrazioni SIP senza alcun clic dell’operatore. La causa: un’immagine VDI con la composizione del desktop disattivata, che non disegna le finestre trasparenti.
- Risultato
- Ora la barra si apre opaca quando la composizione manca e lo annota nel registro.
-
Chiamate assegnate a operatori già al telefono, ridotte del 97%
- Il problema
- Il distributore automatico assegnava chiamate in ingresso a operatori già impegnati in una chiamata in uscita.
- Cosa abbiamo fatto
- Osservando il protocollo abbiamo visto che l‘88% delle collisioni partiva dallo stato di pausa, per un meccanismo di recupero della barra, e che prima dell’avvio della chiamata mancava il comando che segnala «in chiamata uscente». Due correzioni, poi la misura con un osservatore lato server indipendente dalla barra.
- Risultato
- Sovrapposizioni scese da 23.600 al giorno, nel giorno di picco, a 608: meno 97%.
-
Chiamate in uscita che cadevano a 90 secondi esatti
- Il problema
- Alcune chiamate in uscita si interrompevano sempre dopo 90 secondi.
- Cosa abbiamo fatto
- Abbiamo scartato con prove le piste del session timer, del telefono e della rete, e dimostrato sui log del server che un timer non azzerato rimetteva l’operatore in attesa a chiamata ancora in corso.
- Risultato
- Causa corretta e verificata.
-
Due registrazioni per postazione dove ne era ammessa una
- Il problema
- Le registrazioni degli operatori risultavano «irraggiungibili» a raffica (2.722 in 14 ore su 64 interni), con interruzioni dell’audio.
- Cosa abbiamo fatto
- Abbiamo dimostrato, anche con il client web ufficiale, che ogni postazione apre due agenti SIP sullo stesso interno mentre la configurazione ne accettava uno solo. Prova pilota su due interni, poi estensione a 112.
- Risultato
- Segnalazioni ridotte del 97% nel monitoraggio a 5 minuti, interruzioni audio azzerate, ingresso verificato con una cattura SIP: nessun doppio squillo.
-
Un disco pieno sull'SBC di disaster recovery
- Il problema
- L’SBC del sito di disaster recovery aveva il disco pieno.
- Cosa abbiamo fatto
- Spazio liberato togliendo 12 milioni di righe di un registro di debug, senza perdere un solo record delle chiamate, e disco esteso a caldo.
- Risultato
- Spazio recuperato e disco più grande, senza fermare il servizio.
-
Duecentotrenta «sospette cadute» al giorno, nessuna di rete
- Il problema
- Un indicatore contava circa 230 sospette cadute al giorno, il 4,9% delle chiamate servite, e si pensava a un problema di rete.
- Cosa abbiamo fatto
- Abbiamo ricostruito 147 casi uno per uno: tutte le richiamate erano chiamate nuove e nessuna era una caduta di rete. Le cause erano soprattutto tre comportamenti della postazione: microfono senza segnale, attesa premuta prima del collegamento, doppio clic su rispondi e riaggancia.
- Risultato
- Misure e protezioni aggiunte alla barra, da attivare dopo un periodo di misura.
-
Clienti in attesa che cadevano, o forse no
- Il problema
- Si stimavano circa 200 clienti al giorno persi durante l’attesa per una consultazione.
- Cosa abbiamo fatto
- Abbiamo contato i casi veri dal registro degli eventi del centralino.
- Risultato
- Erano 7 in 14 giorni su 12.076 consultazioni: la prima stima contava anche i trasferimenti riusciti.
-
Un trunk che completava meno chiamate degli altri
- Il problema
- Le chiamate in uscita cadevano pochi secondi dopo la risposta.
- Cosa abbiamo fatto
- Dai contatori di prestazione del centralino, un trunk completava il 77% delle chiamate contro l‘89% e il 97% degli altri; esclusi uno per uno client, piattaforma, SBC e controllo di banda.
- Risultato
- Causa ricondotta all’operatore telefonico e documentata in un dossier.
-
Un interruttore per passare al disaster recovery
- Il problema
- In caso di guasto le postazioni dovevano passare al sito di DR senza riconfigurazioni e senza toccare il DNS.
- Cosa abbiamo fatto
- La barra legge lo stato da un portale e, se serve, rimappa server, STUN e database sul DR con gli stessi nomi, così i certificati restano validi; se il portale non risponde si resta in produzione. Nel collaudo abbiamo trovato e corretto STUN e dialplan ancora legati alla produzione, che davano audio a una via.
- Risultato
- Passaggio validato da capo a fondo in ingresso, compreso il riavvio del nodo DR (circa 2 minuti di fermo).
-
Riavvio ordinato della piattaforma
- Il problema
- Riavviare i tre server della piattaforma senza sorprese per gli operatori.
- Cosa abbiamo fatto
- Una procedura nell’ordine database, SBC, web, con 13 controlli finali.
- Risultato
- Eseguita più volte, anche prima dell’apertura del servizio, sempre con esito positivo.
-
Un centralino per l'assistenza al pubblico, compilato da sorgenti
- Il problema
- Serviva un centralino per 16 postazioni su un sistema operativo che non distribuisce più Asterisk.
- Cosa abbiamo fatto
- Asterisk 22 compilato su Debian 13; IVR con informativa, tre code a rotazione con memoria, festivi fino al 2035 nel database del centralino, dieci messaggi con la stessa voce sintetica, nftables e fail2ban, trigger SQL per il cruscotto statistico già in uso, documentazione in 12 capitoli.
- Risultato
- Centralino consegnato e collaudato con chiamate generate nel dialplan.
-
Il messaggio notturno che si sentiva di giorno
- Il problema
- Di giorno chi chiamava sentiva il messaggio della notte.
- Cosa abbiamo fatto
- Abbiamo confrontato 31 backup giornalieri del centralino: 84 moduli su 88 identici, una sola modifica rilevante, con la sua data.
- Risultato
- Modifica individuata e annullata.
-
Uscite bloccate da una rotta senza trunk
- Il problema
- Su un centralino nuovo le chiamate in uscita non partivano.
- Cosa abbiamo fatto
- La rotta creata dalla procedura guidata non aveva un trunk associato: corretta via API. La diagnosi SIP si è fatta con tcpdump dall’hypervisor, perché l’accesso diretto al centralino era spento.
- Risultato
- Centralino in servizio con coda, orari e messaggio notturno.
-
Telefono fisico e interno virtuale, senza pensarci
- Il problema
- Gli operatori avevano un telefono Cisco sulla scrivania e un interno virtuale sulla piattaforma: le chiamate dovevano arrivare al posto giusto.
- Cosa abbiamo fatto
- Al login la barra imposta via AXL l’inoltro di tutte le chiamate all’interno virtuale e lo toglie al logout, con un recupero automatico dopo un’eventuale chiusura anomala.
- Risultato
- Inoltri sempre coerenti con lo stato dell’operatore.
-
Numeri principali spostati in una federazione di centralini
- Il problema
- I numeri principali di due sedi dovevano arrivare al centralino della sede principale.
- Cosa abbiamo fatto
- Modificate le mappe di instradamento in ingresso, con le vecchie regole come ripiego, configurazioni salvate prima e dopo e ritorno indietro documentato.
- Risultato
- Provato e funzionante.
-
Gli esiti delle chiamate, registrati alla fine di ognuna
- Il problema
- La finestra di fine chiamata, scritta anni prima, andava rifatta.
- Cosa abbiamo fatto
- Riscritta da C# WinForms a Electron: mostra il contatto dalla rubrica (circa 8.300 voci), registra uno di sette esiti in SQL Server con query parametrizzate e si aggiorna da sola.
- Risultato
- Collaudata sul database reale.
-
La scheda del cliente alla risposta
- Il problema
- La scheda del cliente nel gestionale e nell’help desk non si apriva dopo la presa di una chiamata dalla coda.
- Cosa abbiamo fatto
- Corretto il difetto e aggiunti il codice dell’operatore e il filtro delle chiamate interne; verifica dal vivo.
- Risultato
- La scheda si apre alla risposta e alla presa dalla coda.
-
Livello di servizio pesato sui volumi veri
- Il problema
- I cruscotti giornalieri per coda non davano una misura mensile affidabile.
- Cosa abbiamo fatto
- 132 cruscotti giornalieri, da ottobre 2025 a febbraio 2026, rielaborati in un report mensile di chiamate servite e livello di servizio pesato sul volume.
- Risultato
- Un report mensile su decine di migliaia di chiamate al mese, ripetibile.
-
Popup di autenticazione a ogni ricerca, eliminati
- Il problema
- A ogni ricerca di un contatto comparivano richieste di autenticazione, e un utente non riusciva ad accedere.
- Cosa abbiamo fatto
- L’accesso era bloccato da un attributo mancante in Active Directory; i popup venivano dall’autenticazione OAuth del server e dalle foto lette da Exchange Online.
- Risultato
- Accesso e ricerche senza interruzioni; documentata anche la scelta di non ricostruire un’integrazione basata su tecnologia ritirata.
-
Federazione con l'esterno sbloccata
- Il problema
- Alcuni utenti non riuscivano a comunicare con organizzazioni esterne in Teams.
- Cosa abbiamo fatto
- Abbiamo individuato la causa nella modalità di coesistenza fra Skype for Business e Teams.
- Risultato
- Due utenti portati alla modalità solo Teams, con un aggiramento documentato.
-
Le sette strade per il fuori orario
- Il problema
- Il servizio era chiuso 119 ore su 168 e le chiamate fuori orario andavano perse.
- Cosa abbiamo fatto
- Sette opzioni messe a confronto, dalla segreteria trascritta all’IVR collegato al gestionale fino all’assistente vocale con IA: budget di latenza di 800 ms, linee dimensionate con Erlang B, obblighi di trasparenza dell’AI Act e del GDPR.
- Dove siamo arrivati
- Studio consegnato come proposta.
-
Due sorgenti di energia che non devono mai toccarsi
- Il problema
- Commutare i carichi fra rete elettrica e fotovoltaico senza che le due sorgenti vadano mai in parallelo.
- Cosa abbiamo fatto
- Una scheda a 8 ingressi e 8 relè pilota due contattori interbloccati anche meccanicamente, con un timer di stabilità di 15 minuti, il funzionamento manuale come stato di partenza e il ritorno al manuale dopo una perdita del fotovoltaico. L’accesso remoto passa da un tunnel WebSocket in uscita: WireGuard sulla scheda è stato provato e scartato.
- Dove siamo arrivati
- In funzione continua dal maggio 2026; una scheda gemella per il riscaldamento, bloccata in un ciclo di avvio da una revisione rara del chip, è ripartita con un bootloader diverso.
-
Una porta «USB» che era una seriale RS-232
- Il problema
- La porta di servizio di un inverter, marcata come USB, non rispondeva a nessuna prova.
- Cosa abbiamo fatto
- Quattro tentativi falliti (USB device, USB host, seriale TTL, cavo dati), poi il multimetro: −5 V a riposo sul filo dati, cioè RS-232 a tre fili. Sul bus RS-485 fra inverter e batteria, un ascolto passivo con validazione del CRC Modbus ha mostrato che l’inverter interroga 14 indirizzi con una funzione proprietaria.
- Dove siamo arrivati
- Banco di prova definito e decodificatore pronto dalla mappa dei registri del costruttore; il dialogo diretto è ancora in corso.
-
Un cloud del produttore reso stabile
- Il problema
- Nell’attesa del dialogo diretto, i dati arrivavano dal cloud del produttore, che faceva scadere la sessione (127 accessi in due ore) e rinominava i campi.
- Cosa abbiamo fatto
- Autenticazione a token e lettura tollerante, con segnalazione dei campi spariti invece di un valore sbagliato.
- Dove siamo arrivati
- Zero nuovi accessi in nove minuti di prova e nessuna batteria mostrata «allo 0%» per un campo rinominato.
-
Quota del cloud esaurita in due giorni
- Il problema
- La quota gratuita del cloud dei dispositivi finiva in due giorni, a circa 26.000 chiamate al giorno.
- Cosa abbiamo fatto
- Letture accorpate con un tetto mensile e un servizio su Raspberry Pi che usa il protocollo locale, con una connessione aperta per dispositivo; il cloud resta di riserva.
- Dove siamo arrivati
- Quattro dispositivi letti e comandati in locale, collaudo 24 prove su 24, sei comandi su sei dal cruscotto.
-
Una parete informativa e il limite della scheda grafica
- Il problema
- Un Raspberry Pi 3 doveva mostrare un portale a 1920×1080, ma il browser era fermo a una versione troppo vecchia.
- Cosa abbiamo fatto
- Reinstallazione con il sistema operativo attuale e Chromium aggiornato; schermo nero all’avvio risolto cambiando driver video; 15 cali di tensione in 26 minuti eliminati con un gruppo di continuità.
- Dove siamo arrivati
- Parete funzionante, e un requisito scritto: la GPU del Pi 3 arriva a WebGL 1, per le mappe interattive serve un Pi 4 o 5.
-
Un DVR senza RTSP, ripubblicato come flusso standard
- Il problema
- Un DVR analogico a 4 canali non offriva RTSP, ONVIF né un’interfaccia web.
- Cosa abbiamo fatto
- Con l’SDK del costruttore abbiamo scoperto che il flusso proprietario contiene MPEG-PS con video H.264: copiato senza ricodifica con ffmpeg verso un server RTSP.
- Dove siamo arrivati
- Quattro canali disponibili in RTSP standard (704×576, circa 25 fotogrammi al secondo).
-
Video in ritardo fino a 27 secondi, riportato a 1,5
- Il problema
- Tre telecamere 4K e un videocitofono via VPN arrivavano con 14-27 secondi di ritardo, e il citofono a pezzi.
- Cosa abbiamo fatto
- 10 fotogrammi al secondo alla sorgente a parità di risoluzione e collegamento diretto al posto del relay; per il citofono UDP con una coda di riordino.
- Dove siamo arrivati
- Sulla camera misurata, 10 fotogrammi su 10 letti con 1,5 secondi di ritardo; errori H.264 del citofono da circa 1.600 a 18 ogni tre minuti. Poi il limite è diventato la banda in salita, misurata in circa 11 Mbit/s.
-
Un'auto scura in controluce, da invisibile a vista
- Il problema
- Il modello più piccolo non vedeva un’auto scura in controluce.
- Cosa abbiamo fatto
- Scelta misurata del modello e soglie per classe (persona 0,50, veicolo 0,35, animale 0,45); inferenza spostata su una macchina dedicata.
- Dove siamo arrivati
- Da 0 a 205 rilevamenti su 205 fotogrammi; l’inferenza su un fotogramma 4K è scesa da 1.350 a 24 ms.
-
Sirene riconosciute senza reti neurali
- Il problema
- Riconoscere una sirena nel rumore ambientale senza falsi allarmi.
- Cosa abbiamo fatto
- Una regola sullo spettro: il tono deve emergere di almeno 40 dB sul fondo della sua banda per almeno 8 secondi. Prova con sirene sintetiche mescolate a 12,5 minuti di audio reale.
- Dove siamo arrivati
- Zero falsi allarmi e sirena riconosciuta in 8 secondi.
-
Un rover che si spegneva da solo
- Il problema
- Il firmware di fabbrica non comunicava lo stato della batteria (il rover si spegneva senza preavviso) e lasciava i motori accesi se il comando si interrompeva.
- Cosa abbiamo fatto
- Nuovo firmware sull’ESP32 e una patch al microcontrollore di bordo, con la memoria flash al 98%: lettura della batteria, arresto sotto 6,5 V, cane da guardia di un secondo, rotazione guidata dal giroscopio.
- Dove siamo arrivati
- Collaudo 13 su 13; una rotazione comandata di 90° misurata in 86,4°.
-
Venticinque trasmettitori che non esistevano
- Il problema
- Una scansione larga dello spettro «trovava» 25 trasmettitori inesistenti.
- Cosa abbiamo fatto
- Erano la curva di guadagno del ricevitore: confronto con una mediana mobile locale ed errore del quarzo stimato, con ripetibilità dichiarata di ±3 ppm.
- Dove siamo arrivati
- Banco di misura affidabile, con i limiti scritti.
-
Un'HMI bloccata dopo un blackout, per un PC spento
- Il problema
- Dopo un blackout l’HMI si bloccava a ogni avvio; una decina di riavvii non era servita.
- Cosa abbiamo fatto
- Analisi di circa 21.000 record di diagnostica con uno script ed esclusione documentata delle altre cause: due copie del progetto identiche byte per byte, tutti i PLC raggiungibili, licenze e database a posto. La causa: un PC che ospitava un server del sistema distribuito era rimasto spento.
- Risultato
- Riacceso il PC, l’HMI è ripartita. Consegnati il rapporto sull’incidente, la scheda del sistema, il runbook e una lista di controllo per le ripartenze dopo un blackout.
-
Referti che devono resistere a chi prova a smentirli
- Il problema
- Un’analisi completa fatta da più agenti produceva referti convincenti, ma non tutto ciò che affermavano era vero.
- Cosa abbiamo fatto
- Un secondo flusso ha cercato di smentire le tre affermazioni principali di ogni referto, andando a controllare file, processi e registri.
- Risultato
- Alcune affermazioni sono cadute (copie e risvegli automatici dichiarati, ma inesistenti) e sono state corrette. Da allora la verifica avversariale fa parte del processo.
-
L'errore che non diventava allarme
- Il problema
- In tutte e dieci le sessioni di monitoraggio un errore del controllo stesso restava silenzioso invece di diventare un allarme.
- Cosa abbiamo fatto
- Due canali distinti: le novità si segnalano una volta, le anomalie attive sempre. Poi una misura prima e dopo su 21 rischi, sulla stessa metrica: arrivano davvero a una persona?
- Risultato
- Tre guasti nascosti sono ricomparsi. La misura ha mostrato che la notifica alle persone non era ancora migliorata, e da allora i problemi critici nuovi arrivano con un avviso del portale.
-
Un preventivo da otto portali in 40-70 secondi
- Il problema
- Per un preventivo bisognava aprire uno per uno i portali B2B dei distributori, rifare gli accessi scaduti e confrontare prezzi e disponibilità a mano.
- Cosa abbiamo fatto
- Un comando interroga otto portali, rifà gli accessi scaduti e restituisce prezzo netto, listino, disponibilità, promozioni e varianti, compreso il venditore reale nelle offerte dei marketplace.
- Risultato
- Risposta in 40-70 secondi; accesso automatico provato su 7 portali. Una prima versione basata su un modello multimodale che leggeva le pagine è stata sostituita da script deterministici, più rapidi e prevedibili.
-
Ricalcoli di tributi locali, con il controllo dopo l'inserimento
- Il problema
- Ricalcolare avvisi di accertamento di un tributo locale secondo la norma, pratica per pratica, su un gestionale web senza API.
- Cosa abbiamo fatto
- Sette moduli Python, lettori degli avvisi in due formati, lo studio della normativa (sanzioni, oneri, interessi di mora, notifiche, sospensione feriale) e otto modelli di lettera. Dopo l’inserimento il programma confronta il residuo con la lettera e, oltre la tolleranza, annulla e reinserisce.
- Risultato
- Nel secondo lotto 34 pratiche su 39 completate (2 scartate, 3 passate alla verifica manuale), circa 4,6 minuti a pratica; 22 difetti corretti strada facendo.
-
Fatture dei fornitori scaricate e verificate
- Il problema
- Raccogliere le fatture dei fornitori in un archivio ordinato e leggibile.
- Cosa abbiamo fatto
- Scarico attraverso le API con l’XML originale, PDF generati dal foglio di stile ufficiale e un indice.
- Risultato
- 16 fatture archiviate, tutte le verifiche superate.
-
Relazioni nel formato aziendale del cliente
- Il problema
- Produrre relazioni lunghe nel modello aziendale del cliente, senza rifare a mano formattazione, tabelle e immagini.
- Cosa abbiamo fatto
- Un generatore che clona il modello originale e ne conserva formattazione, tabelle e immagini, con una suite di prove automatiche.
- Dove siamo arrivati
- Ha prodotto una relazione di avanzamento di 43 pagine con 93 tabelle e una relazione sull’implementazione della NIS2.
-
Posta aziendale senza password negli script
- Il problema
- Leggere una casella Microsoft 365 su dominio federato e preparare risposte senza affidare le credenziali a un programma.
- Cosa abbiamo fatto
- Autorizzazione OAuth con PKCE dopo un accesso fatto dal titolare, token di rinnovo che cambia a ogni uso; le risposte diventano bozze nella casella.
- Risultato
- Lettura automatica e invio sempre nelle mani del titolare.
-
Dichiarazioni firmate e verificate in modo indipendente
- Il problema
- Produrre dichiarazioni firmate digitalmente e avere la certezza che la firma fosse valida prima di inviarle.
- Cosa abbiamo fatto
- PDF generati dai dati ufficiali, applicazione di firma remota guidata da script con PIN e OTP digitati dal titolare, poi una verifica indipendente: byte coperti, impronta, firma sugli attributi, certificato.
- Risultato
- Documenti firmati in PAdES e pratica conclusa.
-
Cinquecento contatti in due caselle, zero errori
- Il problema
- Importare una rubrica in due caselle Exchange.
- Cosa abbiamo fatto
- Importazione attraverso Exchange Web Services, con controllo dei risultati.
- Risultato
- 504 contatti importati, zero errori.
-
Un portale di monitoraggio costruito e migliorato ogni giorno
- Il problema
- Raccogliere in un solo posto lo stato di molti perimetri sorvegliati, con documenti separati per ogni cliente.
- Cosa abbiamo fatto
- Un portale con viste per cliente, una pagina per ogni problema, PDF per singolo cliente verificati da una prova automatica sul testo, e avvisi solo sui problemi critici nuovi.
- Risultato
- In esercizio dal 17 ottobre 2026, con miglioramenti continui.
-
Non disturbare durante le videochiamate
- Il problema
- Le chiamate in arrivo interrompevano le videochiamate degli utenti.
- Cosa abbiamo fatto
- Un’applicazione Windows riconosce le videochiamate dal livello audio e dai titoli delle finestre e imposta lo stato «non disturbare»; distribuzione con pacchetti MSI a 64 bit in installazione silenziosa.
- Risultato
- Versione 2.4 consegnata; la riscrittura in Rust e Tauri è un prototipo.
-
Navigazione sulle piste, anche senza rete
- Il problema
- Orientarsi sulle piste da sci anche dove il telefono non ha copertura.
- Cosa abbiamo fatto
- App Android con GPS filtrato con Kalman, bussola calibrata, calcolo del percorso con Dijkstra su un grafo ricavato da OpenStreetMap, quote e dati disponibili offline.
- Dove siamo arrivati
- Prototipo funzionante, distribuito solo in prova interna.
-
Un assistente di programmazione e il GDPR
- Il problema
- Capire se un assistente di programmazione con IA tiene i dati in Europa.
- Cosa abbiamo fatto
- Analisi delle condizioni del fornitore: sul servizio standard i dati sono trattati anche fuori dall’Unione europea; restano in regione solo con l’edizione enterprise a residenza dei dati e una regola apposita, disattivata per impostazione.
- Dove siamo arrivati
- Quadro documentato, compreso ciò che esce comunque: telemetria, fatturazione, supporto e controlli sui segreti.
-
Ogni cliente vede solo i propri dati
- Il problema
- Un portale che serve più clienti non deve mai mescolare i loro dati nei documenti.
- Cosa abbiamo fatto
- PDF separati per cliente con una prova automatica sul testo, ricerca di segreti nelle segnalazioni (al server arrivano solo impronte), pagine senza risorse esterne.
- Risultato
- Ogni PDF passa una prova automatica sul testo prima di essere consegnato.