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

La conversazione del 20 settembre 2025 attraversa più di due ore di domande e interventi della chat. Marvin porta la propria esperienza nella consulenza e nell’amministrazione dei sistemi; io intervengo soprattutto dal punto di vista dello sviluppo software. Il filo conduttore è capire come tenere insieme tecnologie diverse perché un’organizzazione possa lavorare.

Il sistemista collega tecnologia e attività dell’azienda

Un sistema informatico non serve soltanto alle imprese che producono software. Ordini, fatture, comunicazioni e processi produttivi dipendono spesso da applicazioni, connessioni e dispositivi. Quando qualcosa si ferma, il problema può uscire rapidamente dal reparto IT.

Marvin descrive il sistemista come una figura che deve conoscere almeno i fondamenti di più ambiti: sistemi operativi, reti, servizi, virtualizzazione e sicurezza. Questo non significa essere specialisti di tutto. Significa riconoscere le relazioni fra i componenti, individuare dove approfondire e collaborare con le competenze necessarie.

La manutenzione comprende anche ciò che l’utente non vede: aggiornamenti, monitoraggio, gestione degli accessi e preparazione al ripristino. Il risultato desiderato non è una configurazione impressionante da mostrare, ma un servizio affidabile per chi lo usa.

La responsabilità può essere affidata a personale interno oppure a un professionista o a una società esterna. Le dimensioni dell’azienda e le sue esigenze determinano l’organizzazione del lavoro: non tutte hanno bisogno di un reparto dedicato, ma i sistemi che utilizzano hanno comunque bisogno di gestione.

Linux o Windows: partire dalle esigenze

Nel confronto emerge un approccio che condivido: la scelta della tecnologia viene dopo la comprensione del problema. Marvin distingue, per esempio, un’applicazione web basata su componenti tipici dell’ecosistema Linux da un ambiente con integrazioni già costruite intorno a tecnologie Microsoft.

Non basta preferire un sistema operativo per giustificare una migrazione. Contano applicazioni, competenze disponibili, compatibilità, investimenti precedenti e costi di manutenzione. Anche quando un componente può funzionare su piattaforme diverse, l’infrastruttura che lo circonda può rendere una soluzione più adatta di un’altra.

Conoscere Linux rimane importante nel percorso raccontato da Marvin: lo usa professionalmente e incontra molti strumenti aperti nelle reti e nei servizi. La competenza utile, però, è saper analizzare il contesto. Trasformare una preferenza personale in una regola universale restringe le possibilità invece di ampliarle.

Cloud e infrastruttura locale: chi gestisce che cosa?

Per spiegare il cloud partiamo da un’immagine semplice: utilizzare risorse informatiche messe a disposizione da qualcun altro. Dietro questa immagine ci sono servizi diversi, con livelli differenti di controllo e responsabilità.

Marvin racconta come il cloud possa ridurre alcuni investimenti iniziali e permettere di adattare le risorse alle esigenze. Non ne ricaviamo la promessa che costi sempre meno: bisogna considerare il servizio scelto, l’utilizzo e il lavoro di gestione che rimane.

Affidare l’infrastruttura a un fornitore non elimina ogni responsabilità del cliente. Per esempio, il modello di responsabilità condivisa di AWS distingue gli obblighi in funzione del servizio: una macchina virtuale richiede al cliente attività diverse rispetto a un servizio maggiormente gestito. Configurazione, accessi e dati non diventano irrilevanti perché il server si trova altrove.

La chat solleva anche il percorso inverso: riportare internamente ciò che era stato spostato nel cloud. Marvin invita a considerare dipendenze, integrazioni e migrazione. Cambiare destinazione non significa soltanto copiare un disco: bisogna ricostruire il funzionamento dell’insieme e organizzare il passaggio.

Parliamo inoltre di virtualizzazione e alta disponibilità. Proxmox VE, citato nell’intervista, integra macchine virtuali KVM e container LXC. È utile distinguere la piattaforma dalle tecnologie che utilizza, senza presentarle come alternative sullo stesso piano. L’alta disponibilità, a sua volta, richiede un progetto: non è una promessa di assenza totale di guasti.

Prima degli strumenti viene la conoscenza dell’infrastruttura

Che cosa succede quando un nuovo cliente chiama un sistemista? Marvin distingue una richiesta di analisi ordinaria da un’emergenza. Nel primo caso si può pianificare il lavoro; nel secondo bisogna capire il guasto e contenere il suo impatto senza perdere di vista il contesto.

Un problema ricorrente nella sua esperienza è la documentazione incompleta. Può emergere un dispositivo dimenticato, un servizio configurato da una persona che non lavora più in azienda o una dipendenza della quale nessuno ha una visione chiara.

Per questo la prima risorsa non è un programma capace di risolvere tutto. È un inventario attendibile: che cosa esiste, a che cosa serve, chi lo gestisce e da che cosa dipende. Gli strumenti aiutano a ricostruire questa mappa; interpretarli richiede conoscenza.

Marvin cita Nmap, tcpdump e altri strumenti di analisi, oltre a supporti di avvio per lavorare su ambienti diversi. Non propone una lista da installare indiscriminatamente. Ogni strumento risponde a una domanda, e le verifiche vanno svolte sui sistemi per i quali si dispone dell’autorizzazione.

Sicurezza come lavoro continuo

Una parte importante dell’intervista riguarda la sicurezza. Marvin insiste sul rapporto fra aggiornamenti, configurazione e persone: un singolo prodotto non sostituisce la gestione dell’intera infrastruttura.

La discussione distingue una verifica svolta in un momento preciso dal lavoro continuativo sulle vulnerabilità. Un test può fornire informazioni utili, ma il suo risultato non descrive per sempre il sistema. Bisogna interpretare ciò che emerge, assegnare priorità, intervenire e verificare di nuovo. Test di intrusione e valutazione delle vulnerabilità hanno finalità differenti e possono completarsi.

Anche le copie di sicurezza richiedono una prova concreta. Avere un’attività di backup configurata non dimostra, da solo, che i dati necessari siano recuperabili. Nel confronto il ripristino diventa un esempio del passaggio dalla convinzione alla verifica.

Per le realtà più piccole, Marvin richiama la riduzione della complessità: capire quali servizi servano davvero e come siano configurati. Il rafforzamento della sicurezza, spesso chiamato hardening, non consiste nello spegnere processi a caso. Richiede di conoscerne la funzione e valutare gli effetti delle modifiche.

Formare le persone fa parte dello stesso lavoro. Un problema tecnico può coinvolgere dati di clienti, fornitori e collaboratori; le conseguenze non rimangono necessariamente dentro l’organizzazione che lo ha subito.

Intelligenza artificiale: il valore dell’analisi

Parliamo anche dell’uso dei chatbot per interpretare errori, log e codice. La domanda che pongo a Marvin riguarda il contributo del professionista quando uno strumento automatizza alcune attività.

La risposta del confronto è continuare a capire ciò che si sta facendo. Per formulare una richiesta utile bisogna già riconoscere il problema, selezionare il contesto e valutare il risultato. Copiare una risposta senza comprenderla non rende più affidabile un’infrastruttura.

L’invio di materiale aziendale a un servizio esterno apre inoltre una questione di riservatezza. Le condizioni cambiano fra prodotti, piani e impostazioni: non è corretto dedurre dalla sola gratuità o dal pagamento come vengano trattati tutti i dati. Prima di condividere log o codice servono verifiche sul servizio e sulle regole dell’organizzazione.

L’intervista fotografa il dibattito del settembre 2025. Le ipotesi sull’evoluzione dell’IA restano opinioni e prospettive discusse in quella data, non previsioni certe sulle professioni.

Come diventare sistemista: fondamentali e pratica

Quando gli chiedo da dove iniziare, Marvin torna sulla curiosità. Racconta gli studi a Bologna e ricorda l’importanza di capire il funzionamento degli elaboratori, delle reti e dei sistemi operativi.

Il suo esempio è efficace: conoscere un singolo modello di motore non equivale a comprendere come funziona un motore. Nel lavoro informatico, imparare soltanto una sequenza di pulsanti può lasciare senza riferimenti quando cambia l’interfaccia. I concetti permettono invece di orientarsi anche davanti a un prodotto nuovo.

Parliamo sia di università sia di corsi professionali e certificazioni. Sono percorsi da valutare in relazione agli obiettivi e alle conoscenze di partenza; nessuno sostituisce automaticamente l’esperienza. Marvin racconta anche la formazione seguita su sicurezza e apparati MikroTik, distinguendo ciò che aveva imparato dai problemi incontrati sul lavoro.

La specializzazione può nascere da un interesse personale. Nel suo caso, lo studio dei database NoSQL ha preceduto alcune opportunità di consulenza e docenza. È la sua esperienza, non una garanzia che anticipare una tecnologia produca sempre uno sbocco professionale.

Insegnare significa costruire autonomia

Durante la live emerge anche il lavoro di Marvin come formatore. Racconta l’affiancamento dei nuovi colleghi e i corsi rivolti ad aziende e persone che volevano entrare nel settore.

Il suo obiettivo è far comprendere il percorso che porta alla soluzione. Consegnare una procedura può risolvere un problema immediato; aiutare qualcuno a ragionare gli permette di affrontare anche il successivo. La formazione richiede inoltre di coinvolgere persone con motivazioni e conoscenze differenti.

Questo tema ci porta alla divulgazione online. Io racconto di raccogliere idee e scalette in Zettlr; Marvin cita Obsidian per i propri appunti. Entrambi cerchiamo di ridurre il lavoro necessario per iniziare una registrazione, preparando scene e postazione. Sono abitudini personali, da distinguere dagli strumenti usati per amministrare i sistemi.

Il mestiere del sistemista, oltre la lista dei programmi

Il punto che porto via dall’intervista è la relazione fra competenze tecniche e responsabilità. Un sistemista deve capire i bisogni, documentare le scelte, verificare il funzionamento e continuare a imparare. Sapere usare uno strumento è una parte del mestiere; sapere quando e perché usarlo gli dà valore.

Il video incorporato permette di seguire la conversazione completa e le domande della chat. Ho dedicato anche tre approfondimenti ai suoi temi: sicurezza in azienda, strumenti del sistemista e metodo di lavoro e formazione.