Consulenza IT, DevOps e continuità operativa per PMI italiane

Tre dati che spiegano perché la differenza la fa la governance, non la tecnologia:

Il filo conduttore: la tecnologia si compra facilmente, il valore no. Quello che separa un progetto che ripaga da uno che viene cancellato è la governance: criteri di successo misurabili, controllo dei costi, scelte architetturali difendibili. È il pezzo su cui lavoro.

Che differenza c'è tra te e una società di consulenza IT?

Con una società parli con un commerciale, poi con un account, poi (forse) con chi esegue, spesso un junior o un subappaltatore. Con me parli direttamente con l'ingegnere senior che fa il lavoro e ne prende la responsabilità. Niente catena, niente ricarico su più livelli, decisioni rapide. Il rovescio della medaglia: sono una persona sola, quindi per progetti che richiedono un team grande e continuativo coordino specialisti indipendenti o ti indico la struttura giusta. Sono trasparente su quando NON sono la scelta migliore.

Cosa intendi per consulenza IT strategica?

Affiancare chi decide nelle scelte tecnologiche senza venderti nulla che non ti serva. Scelta dello stack e dei fornitori, valutazione build-vs-buy, analisi del TCO, roadmap evolutiva, due diligence tecnica su software che stai per comprare o su un'azienda che stai per acquisire. Tradurre tra linguaggio ingegneristico e linguaggio di business: spiegare al management cosa c'è davvero sotto una decisione tecnica e quanto costa nel tempo, non solo oggi.

Cosa fai concretamente sul DevOps?

Pipeline CI/CD (GitHub Actions, Deployer) per build, test e deploy automatizzati; infrastruttura come codice dove ha senso; gestione VPS Linux su Hetzner, OVHcloud, Aruba, AWS, Google Cloud con hardening, monitoring e backup; strategie di deploy blue-green o canary con rollback documentato; observability (log strutturati, metriche, alert). L'obiettivo è rendere i rilasci noiosi e prevedibili invece che eventi a rischio.

Potete gestire la nostra infrastruttura in modo continuativo?

Sì, con un retainer mensile: monitoring, aggiornamenti di sicurezza, gestione dei backup, interventi su incidenti, piccole evoluzioni. È la formula adatta a chi non ha (e non vuole assumere) un sistemista interno ma ha bisogno che qualcuno competente tenga in piedi i sistemi e risponda quando qualcosa va storto. Per chi ha già un team interno, lavoro come supporto specialistico sui problemi difficili.

Cosa offrite su business continuity e disaster recovery?

Analisi di impatto (cosa succede al business se questo sistema si ferma per un'ora, un giorno, una settimana), definizione di RTO e RPO concordati col management, strategia di backup con test di ripristino reali, piano di disaster recovery documentato e provato, ridondanza dove il rischio la giustifica. Un piano di continuità che non è mai stato testato è un documento, non una garanzia.

Aiutate anche a modernizzare sistemi e software vecchi?

Sì, è una parte rilevante del lavoro. Migrazione di server e applicazioni da sistemi operativi a fine vita, aggiornamento di stack obsoleti, refactoring incrementale del codice legacy, riduzione del debito tecnico, uscita da soluzioni in vendor lock-in. Sempre con approccio incrementale e senza fermo produzione dove possibile. Per il lato sviluppo del codice vedi anche la pagina Programmatore PHP.

Fai supporto continuativo su Debian e Ubuntu, o solo interventi una tantum?

Entrambi, e la differenza conta. L'intervento una tantum ha senso quando il problema è circoscritto: un major upgrade da pianificare, un filesystem da recuperare, un hardening da fare bene una volta. Il supporto continuativo è un retainer mensile e serve a un'altra cosa: aggiornamenti di sicurezza applicati davvero, backup di cui viene provato il ripristino, monitoraggio con qualcuno che risponde. La domanda che discrimina non è tecnica, è questa: chi risponde alle tre di notte se il server si ferma? Se la risposta oggi è "nessuno", il una tantum non risolve il problema, lo rinvia.

Intervieni anche su un server che non hai configurato tu?

È il caso più frequente, non l'eccezione. Quasi sempre il server lo ha installato qualcuno che non lavora più lì, la documentazione non esiste e le scelte di allora non sono spiegate da nessuna parte. Il primo passo è quindi sempre lo stesso: capire cosa c'è davvero sulla macchina prima di cambiare qualunque cosa, e scriverlo. Serve accesso amministrativo e la libertà di dire che una parte va rifatta invece che aggiustata. Se un fornitore precedente è ancora coinvolto, preferisco saperlo in partenza: non lavoro contro qualcuno a sua insaputa.