Quando mi chiamano, il problema ha già otto mesi

Le telefonate iniziano quasi tutte allo stesso modo: il sito non funziona più.

A volte è vero alla lettera: la pagina non si apre. Più spesso è qualcosa di meno drammatico e più fastidioso: le richieste inviate dai moduli non arrivano più via email, una sezione si è scomposta sul telefono, il browser mostra un avviso di sicurezza, una pagina che portava richieste è sparita dai risultati di ricerca. La domanda che arriva è sempre la stessa: cos'è successo oggi?

Quasi sempre la risposta è che oggi non è successo nulla. È successo mesi fa, un pezzo alla volta, e nessuno stava guardando.

Un sito non si rompe, si degrada

Un sito non è un oggetto finito. È un insieme di parti costruite da persone diverse, e quelle parti continuano a evolvere per conto loro anche quando il sito resta identico. Il programma che lo fa funzionare pubblica nuove versioni. I componenti aggiuntivi che gestiscono i moduli, il catalogo, le traduzioni e il banner dei cookie vengono aggiornati, oppure abbandonati da chi li ha scritti. Il server cambia configurazione. I browser cambiano regole, e cose che funzionavano da anni smettono di comparire senza che nessuno abbia toccato nulla.

Poi c'è tutto quello che semplicemente scade. Il certificato che rende sicura la connessione, e da un giorno all'altro il sito diventa un avviso rosso a schermo intero per chiunque. Il dominio, quando l'avviso di rinnovo arriva a un indirizzo che non esiste più.

Il sito, intanto, sembra sempre uguale. I sintomi, a dire il vero, ci sono quasi sempre: avvisi nel pannello, errori registrati dal server, messaggi respinti, certificati in scadenza con settimane di preavviso. Solo che compaiono dove nessuno guarda mai, in pannelli che non si aprono e in caselle che non si leggono. Il degrado non è silenzioso: è inascoltato. Finché non diventa un guasto, e allora lo sentono tutti.

Poi una parte smette di parlare con un'altra, o peggio continua a parlarle capendola male: il modulo ringrazia per la richiesta e la richiesta non arriva a nessuno. E in una giornata qualunque il sito presenta insieme tutto quello che non è stato fatto.

Le email del sito sono il posto in cui questo succede più spesso e si vede meno. I messaggi che un sito genera smettono di arrivare per conto loro con una certa regolarità: finiscono nella posta indesiderata, vengono rifiutati dai grandi fornitori di posta perché mancano i controlli di autenticità, diventati più severi negli ultimi anni, oppure restano salvati in archivio mentre la notifica non parte. Nessuno se ne accorge, perché il sintomo di una richiesta che non arriva è il silenzio, e il silenzio somiglia moltissimo a un periodo con poche richieste.

Otto mesi di segnalazioni archiviate

Il titolo di questo articolo non è una figura retorica.

Qualche tempo fa mi ha contattato un poliambulatorio: le richieste di prenotazione che arrivavano dal sito erano diventate molte meno di prima. Non zero, meno. È anche per questo che non era scattato nessun allarme.

Il sito funzionava. La pagina si apriva, il modulo si compilava, e per una parte delle persone la richiesta partiva senza problemi. Per un'altra parte no: il pulsante di invio non produceva nulla.

La differenza fra le due parti era una scelta fatta trenta secondi prima, sul banner dei cookie. Il modulo si appoggiava a un controllo esterno che verifica che dall'altra parte ci sia una persona e non un programma automatico. Quel controllo era finito fra gli strumenti di profilazione, e quindi veniva bloccato per chi negava il consenso. Senza di lui il modulo non riusciva a completare l'invio. In pratica, chi rifiutava i cookie non poteva prenotare una visita.

Nessuno, in struttura, poteva accorgersene facendo una prova: chi ci lavora il consenso lo aveva accettato mesi prima, e per lui il modulo ha sempre funzionato.

Le segnalazioni, però, c'erano, e andavano avanti da otto mesi, cioè da quando era stato attivato il nuovo banner dei cookie. Qualcuno che telefonava dicendo di aver scritto e di non aver ricevuto risposta. Qualcuno che riprovava dal telefono. Ogni segnalazione, presa da sola, sembrava un caso isolato: uno che aveva sbagliato indirizzo, uno che non aveva premuto il pulsante giusto. Sono state archiviate una alla volta, finché non sono diventate troppe per archiviarle ancora.

La correzione è stata rapida: rimettere quel controllo nella categoria giusta, cosa che in quel caso ha richiesto un'impostazione scritta a mano, perché il pannello del banner non permetteva di cambiare la classificazione. Ma il punto non è la correzione. È che per mesi una struttura sanitaria ha perso richieste di prenotazione senza sapere di perderle, e che il sintomo esisteva da sempre, sotto forma di persone che lo stavano dicendo.

Tre risposte che sembrano manutenzione e non lo sono

Quando chiedo a un'azienda chi si occupa del sito, tre risposte tornano più delle altre. Nessuna delle tre risponde alla domanda.

"Abbiamo l'hosting." L'hosting è la casa in cui il sito abita. Chi lo fornisce risponde della casa: che resti in piedi, che sia raggiungibile, che l'impianto non prenda fuoco. Di quello che avete messo dentro, no. Qualcosa di automatico esiste, ed è una buona cosa: il programma che fa funzionare il sito installa da solo le correzioni di sicurezza più urgenti, alcuni componenti si aggiornano da soli, diversi fornitori tengono un controllo che segnala le parti vulnerabili. Sono cose da tenere accese. Ma coprono una fascia stretta: non toccano quello che è stato scritto su misura per voi, né le parti a pagamento con la licenza scaduta, né quelle che nessuno mantiene più. E soprattutto nessun automatismo guarda il sito dopo: l'aggiornamento che parte da solo alle tre di notte e rompe il modulo di contatto è un classico. Il punto non è chi preme il pulsante, è chi controlla il risultato.

"Abbiamo i backup." Avere un backup è diverso dal saper tornare indietro. Serve che qualcuno sappia quale copia prendere, che quella copia sia integra e che sia chiaro cosa si perde ripristinandola. Serve sapere dove stanno, perché copie tenute sullo stesso server e sullo stesso account del sito spariscono insieme a tutto il resto, e fino a quando indietro si può tornare: quindici o trenta giorni sembrano tanti, finché non si scopre che il problema era cominciato quattro mesi prima e tutte le copie disponibili se lo portano già dentro. Un archivio di copie che nessuno ha mai provato a riaprire è un estintore che nessuno ha mai controllato, con l'aggravante che per l'estintore il controllo è obbligatorio e per il backup no: si scopre se funziona solo nel momento peggiore.

"Il sito è nuovo: l'abbiamo rifatto due anni fa." Due anni sono tanti. E a ripartire da zero è solo il conteggio di quello che è stato rifatto: il dominio, l'hosting, le caselle di posta, gli account dei servizi esterni, i vecchi documenti ancora scaricabili e i vecchi indirizzi delle pagine si portano dietro l'età di prima. Un sito appena rifatto non è un motivo per saltare i controlli: è il momento in cui il conteggio riparte, non quello in cui il rischio sparisce.

Il giorno in cui si rompe

Quando prendo in carico un sito realizzato da altri, la prima cosa che chiedo non è chi lo ha sviluppato. È questa: se domani mattina smette di funzionare, chi risponde? Spesso la domanda non ha una risposta. Chi lo ha costruito ha chiuso il rapporto alla consegna, la persona che aveva le password non lavora più in azienda, il fornitore attuale si occupa d'altro. Il sito esiste, ma non è di nessuno.

Il giorno del guasto il conto arriva davvero, perché al danno si aggiunge il tempo perso a capire da dove cominciare.

Chi interviene deve prima scoprire dove si trova il sito e chi ha le credenziali. Poi se esiste un backup e di quando. Poi cosa è stato installato negli anni e da chi, se qualcuno ci ha messo mano di recente e perché. Sono ore di ricostruzione che nessuno aveva previsto, su un sito che nel frattempo è fermo.

E quasi sempre finiscono con una diagnosi sgradevole. Rimetterlo in piedi si può, e con un po' di lavoro si riesce anche a ricostruire che cosa è stato modificato. Quello che non si riesce a stabilire è che cosa sia stato letto o copiato, e da quando: di quello non resta traccia. Ed è il motivo per cui non si riesce nemmeno a dire con certezza quale copia di backup sia ancora pulita, perché se l'accesso era aperto da mesi lo sono anche le copie.

La differenza tra un sito seguito e un sito abbandonato non si nota nei giorni normali. Si vede esattamente qui: non nel fatto che il guasto non capiti, ma nel fatto che qualcuno sappia immediatamente dove guardare e come tornare indietro.

Quando a invecchiare non è la tecnologia

Se quello che sta dentro al sito ha conseguenze fuori dal sito, il problema cambia natura.

Un poliambulatorio ha moduli che raccolgono richieste di appuntamento. Non sono dati qualsiasi: se il modulo chiede la prestazione o il motivo della visita, si sta raccogliendo un'informazione sulla salute delle persone, che ha regole più severe di un normale contatto commerciale. A chi arrivano oggi quelle richieste? Sono ancora gli indirizzi giusti, o la casella di chi è andato in pensione l'anno scorso continua a riceverle senza che nessuno le legga? Quella casella, tra l'altro, non è soltanto un disservizio: è un accesso aziendale che nessuno ha chiuso, su corrispondenza che riguarda la salute di qualcuno. E quello che il banner dei cookie blocca o lascia passare è stato guardato di recente? La mappa, il video, la chat e i pixel aggiunti negli ultimi due anni sono finiti nella categoria giusta, o partono comunque prima che la persona abbia scelto?

Un ente di formazione pubblica sul sito i calendari, i bandi e i documenti scaricabili. Quei documenti si possono leggere davvero, o sono fotografie di un foglio, dove non c'è nulla da cercare, nulla da ingrandire e nulla che un lettore di schermo possa pronunciare? Lo erano alla consegna; poi ne sono stati caricati altri, da altre persone, senza che nessuno controllasse.

Un'azienda manifatturiera pubblica schede tecniche e certificazioni, e spesso sono la prima cosa che un cliente nuovo guarda per decidere se il fornitore è affidabile. Sono aggiornate all'ultima revisione? E quella di tre anni fa è ancora scaricabile? Quando si carica un documento aggiornato, quasi sempre il file precedente non viene sostituito: viene affiancato. Resta al suo indirizzo, continua a comparire nei risultati di ricerca ed è ancora il collegamento contenuto nelle email e nei preventivi di allora.

In tutti e tre i casi, quello che invecchia in silenzio non è l'aspetto del sito: è la correttezza di ciò che ci sta dentro. E questo tipo di degrado non viene segnalato da alcun avviso automatico. Lo trova una persona che va a guardare.

Le cinque domande

Se il sito lo gestisci tu o se ti è capitato fra le mani senza averlo scelto, queste sono le domande da porre a chi in azienda decide. Non servono competenze tecniche per farle. Servono a capire se qualcuno sa rispondere, e ognuna finisce con la stessa richiesta implicita: mostramelo.

1. A nome di chi sono intestati il dominio e l'hosting, chi ha accesso oggi al sito e ai servizi collegati (statistiche, posta, pagamenti, gestore del consenso), e cosa succede se quella persona non risponde?
2. Quando è stata fatta l'ultima verifica, che cosa comprendeva e dove è scritto? Possiamo vedere anche quella precedente?
3. Se domani il sito smette di funzionare, chi chiamiamo, fino a quando indietro possiamo tornare, e quando è stata l'ultima volta che un ripristino è stato provato davvero?
4. Esiste un elenco scritto di quello che è installato sul sito, di che cosa è stato fatto su misura per noi e di chi lo mantiene oggi? Possiamo vederlo?
5. Quali dati raccoglie il sito, oltre a quelli dei moduli: chi li riceve, dove restano, per quanto tempo, e chi risponde se qualcuno chiede di cancellarli?

Scrivile su un foglio, portale alla prossima riunione e segna quante caselle restano vuote.
Se le risposte ci sono tutte, il sito è in buone mani e questo articolo non serviva.
Se mancano, non vuol dire che oggi ci sia un problema. Vuol dire che se ci fosse, non lo sapresti.

Dello stesso tema si parla anche in una conversazione di sei minuti, generata con AI a partire da questo articolo.