È il segnale che qualcosa sotto non funziona come dovrebbe. Ma cosa, esattamente, quasi mai è chiaro all'inizio. E la tentazione più forte, quella che vedo ripetersi ovunque, è buttare risorse sul sintomo: raddoppiare il server, comprare un tool, assumere un'altra persona. Soluzioni che calmano il dolore senza curare nulla.

Il mio lavoro inizia prima di qualsiasi proposta. Inizia con il capire.

Cosa guardo per primo

La fattura.

Non l'infrastruttura, non il codice, non i processi. La fattura. Perché i numeri non mentono e raccontano una storia che nessun documento tecnico racconta. Quanto si spende, per cosa, da quanto tempo. Se un costo è stabile, crescente, inspiegabile. Se ci sono servizi accesi che nessuno usa. Se qualcuno ha mai guardato quei numeri con attenzione.

Dal billing scendo nell'infrastruttura: cosa gira, dove, come è configurato. Poi guardo chi sa cosa. Chi fa il deploy. Chi viene chiamato quando qualcosa si rompe. Se quella persona è una sola, il sistema ha un single point of failure che non è tecnico: è umano.

Non ho una checklist rigida. Ho dei punti fissi che so di dover controllare sempre, ma il percorso cambia in base a quello che trovo. Dopo anni, certi pattern li riconosci al volo.

I segnali d'allarme

Ci sono frasi che sento ripetere in quasi tutti i contesti. Ognuna è un indicatore:

• "Funziona ma non sappiamo perché." Il sistema regge per inerzia, non per design. Quando si romperà, nessuno saprà da dove cominciare.
• "Solo Luigi sa come si fa il deploy." Conoscenza orale, non documentata, non trasferibile. Se Luigi cambia lavoro, il sistema si ferma con lui.
• "Abbiamo sempre fatto così." Processi manuali che nessuno ha mai messo in discussione. Funzionano finché funzionano. Poi esplodono.
• "Lo abbiamo messo su in fretta, poi lo sistemiamo." Il "poi" non arriva mai. Il temporaneo diventa permanente, il workaround diventa architettura.

Nessuno di questi è un problema tecnico in senso stretto. Sono tutti problemi di governance: nessuno si è preso la responsabilità di descrivere, documentare e mantenere quello che è stato costruito.

Come decido cosa cambiare

Non tutto va cambiato. Questa è la parte che distingue un assessment da una lista della spesa.

Quando entro in un sistema, classifico quello che trovo in tre categorie:

• Deve cambiare subito. Il rischio è concreto e imminente. Un singolo point of failure critico, un costo che cresce senza controllo, una vulnerabilità esposta. Queste cose non aspettano.
• Può aspettare. Il problema esiste, ma è gestibile nel breve termine. Lo documento, lo pianifico, lo affronto quando il contesto lo permette. Non tutto è un'emergenza.
• Lascialo così. Funziona. Non è elegante, non è come lo farei io, ma funziona. Toccarlo introdurrebbe rischio senza beneficio reale. Il codice brutto che non si rompe mai è meglio del codice bello che nessuno sa mantenere.

La terza categoria è quella più difficile da accettare, per me e per il cliente. Ma cambiare qualcosa che funziona solo perché "si potrebbe fare meglio" non è miglioramento: è rischio gratuito.

Cosa non faccio

Non vendo tecnologia. Non arrivo con una soluzione in tasca prima di aver capito il problema. Non propongo di riscrivere tutto da zero, perché nella stragrande maggioranza dei casi non serve e il rischio è enorme.

E dico "non cambiare niente" più spesso di quanto si possa immaginare. A volte un cliente vuole migrare a Kubernetes perché "è quello che fanno tutti", quando il suo setup attuale regge benissimo il carico. A volte vuole riscrivere un monolite in microservizi perché l'ha visto a una conferenza, quando il monolite funziona e il team è di tre persone. La moda tecnologica non è una strategia.

Il mio lavoro non è portare il nuovo. È capire se il nuovo serve davvero, e se sì, dove e come introdurlo senza rompere quello che già funziona.

Il filo comune

Se leggi gli altri appunti di questo blog, il pattern è sempre lo stesso. Un costo cloud inspiegabile che era un problema di versioning non governato. Un server raddoppiato che era un problema di IOPS sul disco sbagliato. Un'infrastruttura non documentata che dipendeva dalla memoria di una persona.

In tutti i casi, il sintomo era uno e il problema era un altro.

Se hai un sintomo che non riesci a spiegare, o un sistema che "funziona" ma non sai per quanto ancora... parliamone. Ti dico se serve cambiare qualcosa, o se basta capire meglio quello che hai.