Il sintomo non è mai il problema

È 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.
• "Il backup c'è, ma non l'abbiamo mai provato a ripristinare." Un backup che non è mai stato testato non è un backup. È una speranza. L'ho visto succedere più volte di quanto vorrei ammettere: il giorno in cui serve davvero, si scopre che il file è corrotto, il processo è incompleto, o il restore richiede tre ore che nessuno aveva previsto.
• "Abbiamo tre ambienti ma non sono allineati." Dev, staging, produzione. Sulla carta esistono tutti e tre. Nella pratica, staging non viene aggiornato da mesi, dev ha configurazioni che non c'entrano nulla con la produzione, e i test passano in un ambiente che non somiglia a quello dove il codice dovrà girare. Quando qualcosa si rompe in produzione, la prima reazione è "da noi funzionava". Certo, perché "da noi" è un altro sistema.
• "Il monitoring c'è, ma nessuno guarda le dashboard." Strumenti installati, grafici configurati, alert impostati. Tutto perfetto, tranne che nessuno li consulta. Il monitoring che nessuno legge è rumore, non informazione. Ho trovato dashboard con alert rossi da settimane che nessuno aveva notato: non perché fossero negligenti, ma perché nessuno aveva definito chi dovesse guardarli e quando.

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. Un caso concreto: un team di tre persone con un singolo server Docker che gestiva tutto senza problemi. Il carico era prevedibile, i deploy erano semplici, il sistema girava da due anni senza incidenti. Kubernetes avrebbe introdotto una complessità operativa che quel team non aveva le risorse per gestire. La risposta giusta era: non toccare nulla, semmai documenta meglio quello che hai.

A volte la spinta viene dal linguaggio. "PHP è morto, dobbiamo riscrivere tutto in Go." Il monolite PHP in questione serviva 50.000 richieste al giorno senza problemi di performance, il team lo conosceva a fondo, e il codebase era stabile. Riscrivere significava mesi di lavoro, un periodo di doppia manutenzione, e il rischio concreto di introdurre bug in un sistema che funzionava. Il problema vero non era PHP: era che mancavano test automatici e il deploy era manuale. Due cose risolvibili in settimane, non in mesi.

La moda tecnologica non è una strategia. A volte vuol dire riscrivere un monolite in microservizi perché l'ha visto a una conferenza, quando il monolite funziona e il team non ha l'esperienza per gestire la complessità distribuita che i microservizi portano con sé.

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.

Non è un caso che questo pattern si ripeta con questa regolarità. Non è incompetenza. È che i sistemi crescono in modo incrementale: una feature alla volta, un workaround alla volta, un "per ora facciamo così" alla volta. Nessuno si sveglia un giorno e decide di costruire un sistema fragile. Succede perché chi lavora dentro il sistema non ha il tempo (o il mandato) di fermarsi e guardare il quadro completo. Le priorità sono le scadenze, le richieste dei clienti, i ticket aperti. Il debito si accumula in silenzio, e quando diventa visibile si manifesta come sintomo, non come causa.

Ecco perché uno sguardo esterno fa la differenza. Non perché chi è dentro non sia capace, ma perché chi è dentro è occupato a far funzionare le cose giorno per giorno. Un assessment serve esattamente a questo: fermarsi, prendere distanza, e separare quello che va cambiato da quello che va solo capito meglio.

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.