Che cosa fa un sistemista, e quali competenze servono per diventarlo? Ne ho parlato con Marvin Pascale, online InMarvinWeTrust, partendo dal lavoro vero: reti, server, cloud, sicurezza, formazione.

Sono più di due ore di domande, il 20 settembre 2025, comprese quelle arrivate dalla chat. Marvin porta la consulenza e l'amministrazione dei sistemi; io intervengo dal lato dello sviluppo software. Il filo che tiene tutto è come si fanno stare insieme tecnologie diverse perché un'organizzazione possa lavorare.

Il sistemista sta fra la tecnologia e l'attività dell'azienda

Un sistema informatico non serve solo a chi produce software. Ordini, fatture, comunicazioni e processi produttivi dipendono da applicazioni, connessioni e dispositivi — e quando qualcosa si ferma, il problema esce dal reparto IT in pochi minuti.

Marvin descrive il sistemista come una figura che deve conoscere i fondamenti di più ambiti: sistemi operativi, reti, servizi, virtualizzazione, sicurezza. Non specialista di tutto: capace di riconoscere le relazioni fra i pezzi, di capire dove approfondire e con chi collaborare.

La manutenzione comprende quello che nessuno vede: aggiornamenti, monitoraggio, gestione degli accessi, preparazione al ripristino. Il risultato non è una configurazione da mostrare, è un servizio su cui gli altri possono contare.

La responsabilità può stare dentro l'azienda o essere affidata a un professionista esterno. Dimensioni ed esigenze decidono l'organizzazione: non tutte hanno bisogno di un reparto, ma i sistemi che usano hanno bisogno di qualcuno che li gestisca.

Linux o Windows: prima il problema, poi la tecnologia

C'è un approccio su cui siamo d'accordo: la scelta della tecnologia viene dopo aver capito il problema. Marvin distingue un'applicazione web costruita su componenti tipici dell'ecosistema Linux da un ambiente con integrazioni già cresciute intorno a tecnologie Microsoft.

Preferire un sistema operativo non basta a giustificare una migrazione. Contano applicazioni, competenze disponibili, compatibilità, investimenti già fatti e costi di manutenzione. Anche quando un componente gira ovunque, è l'infrastruttura intorno a decidere quale soluzione regge meglio.

Conoscere Linux resta centrale nel suo percorso: lo usa professionalmente e incontra strumenti aperti ovunque, nelle reti e nei servizi. La competenza che conta però è saper leggere il contesto. Trasformare una preferenza in regola universale restringe le possibilità invece di allargarle.

Cloud e infrastruttura locale: chi gestisce che cosa

Per spiegare il cloud si parte da un'immagine semplice: usare risorse messe a disposizione da qualcun altro. Dietro quell'immagine ci sono servizi molto diversi, con livelli di controllo e responsabilità diversi.

Marvin racconta come il cloud riduca alcuni investimenti iniziali e permetta di adattare le risorse. Da qui non segue che costi sempre meno: dipende dal servizio scelto, da quanto lo usi e dal lavoro di gestione che resta comunque a te.

Affidare l'infrastruttura a un fornitore non azzera le tue responsabilità. Il modello di responsabilità condivisa di AWS distingue gli obblighi in base al servizio: una macchina virtuale ti lascia in carico cose che un servizio più gestito copre. Configurazione, accessi e dati non diventano irrilevanti perché il server sta altrove.

Dalla chat arriva il percorso inverso: riportare in casa ciò che era stato spostato. Marvin invita a guardare dipendenze, integrazioni e migrazione. Cambiare destinazione non è copiare un disco: è ricostruire il funzionamento dell'insieme e organizzare il passaggio.

Parliamo anche di virtualizzazione e alta disponibilità. Proxmox VE integra macchine virtuali KVM e container LXC: conviene distinguere la piattaforma dalle tecnologie che usa, invece di metterle sullo stesso piano. E l'alta disponibilità è un progetto, non una promessa di assenza di guasti.

Prima degli strumenti viene la conoscenza dell'infrastruttura

Che cosa succede quando chiama un cliente nuovo? Marvin distingue l'analisi ordinaria dall'emergenza. Nel primo caso pianifichi; nel secondo devi capire il guasto e contenerne l'impatto senza perdere di vista il resto.

Il problema che incontra più spesso è la documentazione assente. Salta fuori un dispositivo dimenticato, un servizio configurato da qualcuno che non lavora più lì, una dipendenza di cui nessuno aveva idea.

Per questo la prima risorsa non è un programma. È un inventario attendibile: che cosa esiste, a che cosa serve, chi lo gestisce, da che cosa dipende. Gli strumenti aiutano a ricostruire quella mappa, ma leggerla richiede competenza.

Cita Nmap, tcpdump e altri strumenti di analisi, più i supporti di avvio per lavorare su ambienti diversi. Non è una lista da installare in blocco: ogni strumento risponde a una domanda, e le verifiche si fanno solo sui sistemi per cui hai l'autorizzazione.

Sicurezza come lavoro continuo

Marvin insiste sul rapporto fra aggiornamenti, configurazione e persone: nessun prodotto sostituisce la gestione dell'infrastruttura.

C'è poi la differenza fra una verifica fatta in un momento e il lavoro continuo sulle vulnerabilità. Un test dà informazioni utili, ma non descrive il sistema per sempre: va interpretato, vanno assegnate priorità, si interviene e si verifica di nuovo. Test di intrusione e valutazione delle vulnerabilità hanno scopi diversi e si completano.

Anche i backup vogliono una prova. Avere un'attività di backup configurata non dimostra che i dati siano recuperabili: il ripristino è il momento in cui una convinzione diventa un fatto, o non lo diventa.

Per le realtà piccole richiama la riduzione della complessità: capire quali servizi servono davvero e come sono configurati. L'hardening non è spegnere processi a caso, è conoscerne la funzione e valutare gli effetti di ogni modifica.

Formare le persone fa parte dello stesso lavoro. Un problema tecnico coinvolge dati di clienti, fornitori e collaboratori, e le conseguenze non restano dentro l'azienda che lo ha subito.

Intelligenza artificiale: il valore dell'analisi

Parliamo anche dei chatbot per interpretare errori, log e codice. La mia domanda è che cosa resti del contributo del professionista quando uno strumento automatizza una parte del lavoro.

La risposta è continuare a capire quello che si fa. Per formulare una richiesta utile devi già riconoscere il problema, selezionare il contesto e saper valutare il risultato. Copiare una risposta senza capirla non rende affidabile nessuna infrastruttura.

C'è poi la riservatezza: mandare materiale aziendale a un servizio esterno apre una questione seria. Le condizioni cambiano fra prodotti, piani e impostazioni, e non si deduce nulla dal fatto che un servizio sia gratuito o a pagamento. Prima di condividere log o codice si verifica il servizio e si guardano le regole dell'organizzazione.

Questa conversazione fotografa il dibattito del settembre 2025. Le ipotesi sull'evoluzione dell'IA restano opinioni discusse in quella data, non previsioni.

Come si diventa sistemista

Quando gli chiedo da dove partire, Marvin torna sulla curiosità. Racconta gli studi a Bologna e l'importanza di capire come funzionano elaboratori, reti e sistemi operativi.

Il suo esempio è efficace: conoscere un modello di motore non è capire come funziona un motore. Nell'informatica, imparare una sequenza di pulsanti ti lascia in mezzo al guado appena cambia l'interfaccia. I concetti invece reggono anche davanti a un prodotto che non hai mai visto.

Parliamo di università, corsi professionali e certificazioni. Sono percorsi da valutare rispetto agli obiettivi e al punto di partenza, e nessuno sostituisce l'esperienza. Racconta anche la formazione su sicurezza e apparati MikroTik, distinguendo quello che aveva imparato dai problemi che ha poi incontrato sul campo.

La specializzazione può nascere da un interesse personale: nel suo caso lo studio dei database NoSQL è arrivato prima di alcune opportunità di consulenza e docenza. È la sua storia, non la garanzia che anticipare una tecnologia produca sempre un lavoro.

Insegnare significa costruire autonomia

Marvin fa anche il formatore: affianca i nuovi colleghi e tiene corsi per aziende e per chi vuole entrare nel settore.

Il suo obiettivo è far capire il ragionamento che porta alla soluzione. Consegnare una procedura risolve il problema di oggi; insegnare a ragionare permette di affrontare anche quello di domani. E significa avere davanti persone con motivazioni e conoscenze molto diverse.

Da lì si finisce a parlare di divulgazione. Io raccolgo idee e scalette in Zettlr, lui usa Obsidian per gli appunti. Entrambi cerchiamo di ridurre l'attrito prima di una registrazione, tenendo pronte scene e postazione. Sono abitudini personali, niente a che vedere con gli strumenti di amministrazione.

Il mestiere, oltre la lista dei programmi

Quello che mi porto via è il rapporto fra competenze tecniche e responsabilità. Un sistemista capisce i bisogni, documenta le scelte, verifica il funzionamento e continua a studiare. Saper usare uno strumento è una parte del mestiere; sapere quando e perché usarlo è quello che lo rende un mestiere.

Ho dedicato tre approfondimenti ai suoi temi: sicurezza in azienda, strumenti del sistemista e metodo di lavoro e formazione.