Scoprire i problemi quando li scoprono i clienti

Il sabato mattina alle 9:37 squilla il telefono del responsabile tecnico. Dall’altra parte c’è un cliente furioso che spiega come il sistema sia completamente inaccessibile da almeno quattro ore. Il responsabile, colto di sorpresa, promette verifiche immediate. Apre il laptop, controlla freneticamente i log, scopre che effettivamente c’è stato un crash alle 5:30 del mattino. Nessun alert è partito. Nessun sistema ha segnalato l’anomalia. Il primo a scoprire il disastro è stato proprio chi non avrebbe dovuto accorgersene: l’utente finale.

Questa non è osservazione proattiva. È archeologia digitale eseguita sotto pressione.

L’illusione della visibilità

Molte organizzazioni confondono avere strumenti con avere consapevolezza. Installano software costosi, configurano cruscotti impressionanti con grafici multicolore, raccolgono terabyte di dati ogni giorno. Poi nessuno li guarda mai. È come comprare un telescopio professionale e tenerlo chiuso in cantina perché “tanto abbiamo buoni occhi”.

Il problema non è la mancanza di informazioni. Anzi, spesso è l’opposto: troppe informazioni, nessuna comprensione. Dashboard che mostrano centinaia di parametri senza indicare quali contano davvero. Metriche accumulate per inerzia, perché “potrebbe servire”, senza che nessuno sappia interpretarle o usarle per decisioni concrete.

La quantità di dati raccolti è inversamente proporzionale alla capacità di agire su quelli rilevanti. Più numeri hai, meno capisci cosa significano. È il paradosso dell’abbondanza applicato all’ingegneria software.

Quando l’automazione è solo un desiderio

Esiste una categoria speciale di organizzazioni che fa affidamento totale su interventi umani per rilevare anomalie. Qualcuno deve controllare manualmente i file di log ogni giorno. Qualcun altro verifica periodicamente che i servizi rispondano. Un terzo controlla lo spazio disco residuo guardando le cartelle.

Questo approccio ha un difetto fondamentale: dipende dalla memoria, dalla disciplina e dalla disponibilità di individui specifici. Cosa succede durante le ferie? Durante i weekend? Di notte? La risposta tipica è un’alzata di spalle seguita da “speriamo non succeda nulla in quel periodo”.

Ma i sistemi informatici non rispettano l’orario d’ufficio. I database non si riempiono solo tra le nove e le diciotto. I server non crashano educatamente durante l’orario lavorativo. Affidarsi esclusivamente a controlli manuali è come pensare che i ladri entrino solo quando sei sveglio e attento.

Il problema dell’assuefazione agli allarmi

C’è poi il fenomeno opposto: sistemi che generano talmente tanti alert da diventare rumore di fondo. All’inizio il team reagisce con urgenza ad ogni notifica. Dopo la trentesima segnalazione falsa in una settimana, le notifiche vengono mentalmente classificate come spam e ignorate sistematicamente.

Questa desensibilizzazione progressiva è pericolosa quanto non avere alert. Anzi, forse peggio, perché crea l’illusione di protezione mentre in realtà hai addestrato il team a ignorare i segnali. Come vivere vicino ai binari del treno: dopo un po’ non senti più i convogli passare, nemmeno quando uno deraglia davanti a casa tua.

Il punto critico arriva quando succede qualcosa di veramente grave e l’alert corrispondente viene trattato con la stessa noncuranza degli altri novantanove falsi positivi. Scopri il disastro solo quando i danni sono già irreversibili, mentre le notifiche accumulate giacevano non lette in qualche casella email ignorata da mesi.

La caccia al colpevole invece dell’apprendimento

Quando finalmente emerge un problema, la prima domanda che risuona nelle sale riunioni raramente è “come possiamo migliorare i nostri sistemi?”. Più frequentemente è “chi ha causato questo?”, seguita a ruota da “chi era di turno?” e “perché nessuno se n’è accorto prima?”.

Questa mentalità punitiva crea un circolo vizioso distruttivo. Le persone iniziano a nascondere piccoli problemi per paura di ritorsioni. Gli incidenti minori che potrebbero essere segnali di tendenze preoccupanti vengono minimizzati o occultati. La cultura della colpa trasforma ogni anomalia in un segreto invece che in un’opportunità di rafforzare il sistema.

Il risultato è un’organizzazione che impara lentamente o non impara affatto, perché ogni fallimento diventa un processo penale invece che una lezione costruttiva. Gli errori si ripetono perché nessuno osa analizzarli apertamente.

Silos informativi che impediscono la comprensione

In organizzazioni frammentate, diversi team osservano aspetti diversi dello stesso ecosistema senza comunicare tra loro. Gli sviluppatori notano anomalie nelle performance applicative. Gli amministratori di sistema vedono pattern strani nell’utilizzo delle risorse. Il supporto clienti riceve segnalazioni di malfunzionamenti sporadici. Ma questi tre flussi di informazione non si incontrano mai.

Solo durante le autopsie post-incidente emerge che tutti stavano osservando manifestazioni diverse dello stesso problema sottostante. È la parabola degli osservatori che esaminano parti separate di un fenomeno complesso senza mai confrontare le osservazioni. La soluzione sembrerebbe ovvia: parlare. Ma nelle organizzazioni disfunzionali, i confini tra reparti diventano muri invalicabili.

L’investimento invisibile che nessuno vuole fare

Il lavoro di osservazione accurata non produce funzionalità vendibili. Non puoi mostrarlo ai clienti durante le presentazioni commerciali. Non genera entusiasmo nelle demo. È fondamentalmente invisibile quando funziona correttamente, e diventa visibile solo quando fallisce.

Questa caratteristica lo rende difficile da giustificare in budget sempre limitati. Dedicare risorse a prevenire problemi che non sono ancora successi sembra uno spreco, specialmente quando ci sono feature nuove che potrebbero attrarre clienti o aumentare fatturato.

Il management spesso vede questo investimento come costo puro invece che come assicurazione. “Perché dedicare tempo a qualcosa che già funziona?” domandano, con la stessa logica di chi evita la manutenzione dell’auto finché il motore non si guasta definitivamente. La risposta arriva puntuale sotto forma di downtime costoso, clienti persi, e notti insonni passate a risolvere emergenze che potevano essere prevenute.

Formazione assente e aspettative irrealistiche

Installare uno strumento complesso e aspettarsi che le persone lo usino efficacemente senza addestramento è una fantasia ricorrente. “Ecco il link alla piattaforma, arrangiati” è l’approccio standard. Nessuna spiegazione su quali valori sono normali e quali preoccupanti. Nessuna guida su come interpretare i pattern. Nessun contesto su cosa fare quando qualcosa sembra anomalo.

Le persone responsabili dell’osservazione si ritrovano a fissare schermi pieni di numeri senza capire cosa significhino. Come dare a qualcuno uno strumento musicale senza insegnargli a suonarlo e poi lamentarsi che non produce melodie gradevoli. La confusione risultante porta a due comportamenti ugualmente dannosi: o ignorano tutto assumendo che vada bene, o si allarmano per ogni variazione normale creando panico inutile.

Costruire sistemi che ti svegliano nel momento giusto

L’obiettivo di un’architettura di osservazione efficace non è raccogliere ogni possibile dato. È identificare i segnali critici che richiedono azione immediata, separarli dal rumore irrilevante, e comunicarli alle persone giuste nel momento opportuno.

Questo significa soglie calibrate accuratamente, non inventate casualmente. Significa alert che partono solo per condizioni che richiedono veramente intervento umano, non per ogni fluttuazione normale. Significa escalation intelligente che considera gravità, persistenza e contesto.

Un sistema ben progettato dovrebbe permetterti di risolvere incidenti prima che gli utenti ne siano consapevoli. Dovrebbe trasformare crisi potenziali in interventi routinari. Dovrebbe darti la tranquillità di sapere che se qualcosa va seriamente storto, ne sarai informato tempestivamente.

Il lusso di dormire tranquilli

La differenza tra organizzazioni mature e quelle improvvisate emerge chiaramente in questo ambito. Le prime hanno investito in sistemi robusti di osservazione, formazione adeguata, processi chiari di escalation, e cultura che valorizza l’apprendimento dagli errori. Quando succede un problema, lo rilevano rapidamente, lo risolvono metodicamente, e lo analizzano costruttivamente.

Le seconde scoprono i disastri quando glieli segnalano i clienti arrabbiati. Passano ore a ricostruire cosa è successo perché i dati rilevanti non erano monitorati o sono andati persi. Ripetono gli stessi errori perché nessuno ha mai fatto retrospettive serie. Vivono in uno stato di ansia permanente perché sanno che potrebbero esserci problemi critici in corso di cui non sono consapevoli.

La qualità del sonno notturno dei team tecnici è un indicatore affidabile della maturità dell’infrastruttura di osservazione. Se puoi addormentarti serenamente sapendo che eventuali problemi ti sveglieranno tempestivamente con informazioni sufficienti per intervenire, hai costruito qualcosa di solido. Se invece ti svegli periodicamente in preda al panico chiedendoti se nel frattempo è esploso qualcosa, hai un problema architetturale serio.

Questo articolo è tratto da “Non funziona niente! – I progetti IT in crisi”, il primo libro della collana Nothing Works! — una tragicommedia aziendale per chi ha visto troppi Gantt chart trasformarsi in fiction.

Scopri la collana completa, gli altri libri e le prossime uscite su nothingworks.it

Vuoi il libro subito? Compralo su Amazon

Potrebbe interessarti anche

• Sistemista IT in una PMI: mansioni e competenze
• DIRETTORE ACQUISTI
• Perché documentare gli interventi IT potenzia la posizione del Sistemista?
• Da sistemista IT a IT Manager: un, possibile, percorso di carriera nell’ambito manifatturiero
• I problemi quotidiani di un Sistemista IT e come risolverli
• SISTEMISTA
• Quanto guadagna un Sistemista a Torino?
• SISTEMISTA IT
• Cosa fa un Sistemista in un Managed Service Provider: ruolo e giornata tipo
• Dieci clienti, un solo Sistemista: come si gestiscono le priorità in un Managed Service Provider