Contenuti
- Il sito continuava a raccogliere contatti
- Il problema rimase invisibile per undici giorni
- Come facciamo a non perdere i dati?
- Una seconda destinazione ha fatto la differenza
- Anche i sistemi migliori possono avere delle dipendenze
- Non bisogna duplicare tutto
- La ridondanza può proteggere il risultato
- La lezione
- Conclusione
Per 11 giorni il sistema ha perso contatti senza che nessuno se ne accorgessePer 11 giorni il sistema ha perso contatti senza che nessuno se ne accorgesseIl sito funzionava.
Il modulo contatti funzionava.
Gli utenti continuavano a compilare il form e a inviare le loro richieste.
Eppure, per undici giorni, quei contatti non arrivarono alla casella di posta aziendale.
Nessuna pagina bianca.
Nessun sito offline.
Nessun errore evidente per l’utente.
Il problema era nascosto in un punto del percorso che portava il contatto dal sito all’azienda.
Il sito continuava a raccogliere contatti
L’azienda utilizzava Google Workspace per la posta aziendale.
Il sito, invece, utilizzava Amazon SES per l’invio delle email.
A causa di un problema di spam all’interno dell’azienda venne cambiata la password utilizzata dal servizio SMTP.
La password configurata nel sito non venne aggiornata.
Da quel momento il sito non riuscì più a utilizzare correttamente il servizio di invio delle email.
Il modulo, però, continuava a essere disponibile.
Gli utenti continuavano a compilarlo.
Il sito continuava quindi a ricevere richieste, ma una parte del processo si era interrotta.
Il problema rimase invisibile per undici giorni
Dal punto di vista dell’utente, il sito continuava a funzionare.
Il modulo poteva essere compilato e inviato.
Non c’era un’indicazione evidente che permettesse di capire che la richiesta non sarebbe arrivata alla casella aziendale.
Anche internamente il problema non venne individuato subito.
Per undici giorni il sito continuò quindi a ricevere contatti senza che questi arrivassero attraverso il percorso abituale.
Il processo di acquisizione dei lead era interrotto.
Ma il sito era online.
Come facciamo a non perdere i dati?
Quando il problema venne individuato, la prima domanda non fu soltanto perché le email non arrivassero.
Bisognava capire quanti contatti fossero stati ricevuti durante quei giorni e, soprattutto, se fosse possibile recuperarli.
I log del sito permisero di ricostruire quanti lead erano arrivati.
Ma c’era anche un’altra traccia.
I contatti venivano contemporaneamente inviati a Mailchimp per il processo di lead nurturing.
Quella seconda destinazione aveva continuato a ricevere i dati.
I lead quindi non erano stati persi.
Era stato interrotto un percorso di consegna, ma il dato prodotto dal form esisteva ancora in un altro punto.
Una seconda destinazione ha fatto la differenza
La situazione può essere rappresentata in modo semplice.
Il percorso principale era:
sito → SMTP → posta aziendale
Il cambio della password aveva interrotto questa strada.
Ma esisteva contemporaneamente un secondo percorso:
sito → Mailchimp
Quello continuava a funzionare.
La seconda destinazione non era stata necessariamente progettata per gestire un problema di continuità operativa.
Serviva al marketing per il lead nurturing.
Ma, quando una delle due strade si è interrotta, ha svolto anche un’altra funzione: ha conservato il risultato prodotto dal sito.
Non era stato necessario duplicare il server.
Non era stato necessario duplicare il sito.
Non era stato nemmeno necessario sostituire il servizio SMTP.
Il dato aveva semplicemente un’altra destinazione.
Anche i sistemi migliori possono avere delle dipendenze
Potrebbe sembrare che il problema fosse dovuto a una scelta tecnologica poco affidabile.
Ma non era così.
La posta aziendale utilizzava Google Workspace.
L’invio delle email dal sito utilizzava Amazon SES.
I lead venivano inoltre gestiti attraverso Mailchimp.
Erano presenti quindi servizi professionali e affidabili.
Eppure il processo si è interrotto.
Non perché uno di questi servizi fosse necessariamente guasto.
È bastato un cambiamento: la password del servizio SMTP è stata modificata e il sito non è stato aggiornato di conseguenza.
La lezione non è quindi che bisogna evitare i servizi esterni.
È un’altra.
L’affidabilità di una componente non equivale all’affidabilità del processo che la utilizza.
Un servizio può essere estremamente affidabile e il processo che dipende da quel servizio può comunque interrompersi.
Non bisogna duplicare tutto
Quando si parla di ridondanza è facile pensare immediatamente a due server, due connessioni o due sistemi identici.
Ma non sempre è questo che serve.
In questo caso non serviva un secondo sistema per inviare la stessa email.
Serviva evitare che la perdita di una parte del percorso facesse sparire anche il risultato già prodotto dal sito.
Il lead era il valore da proteggere.
La seconda destinazione del dato ha permesso di conservarlo anche quando il percorso principale non funzionava.
La ridondanza può proteggere il risultato
Questa casistica mostra una forma di ridondanza diversa dalla semplice duplicazione dell’infrastruttura.
Il processo produce un dato importante.
Quel dato passa attraverso più sistemi.
Se una delle destinazioni diventa indisponibile, il processo può essere progettato in modo da non perdere immediatamente ciò che è già stato prodotto.
Non significa che il problema non esista.
Il processo principale, in questo caso, era comunque interrotto.
Significa che l’interruzione di una parte del percorso non ha comportato automaticamente la perdita del risultato.
Ed è una differenza importante.
La lezione
Un sito può dipendere da servizi affidabili e continuare comunque ad avere punti deboli.
Non è sufficiente chiedersi se ogni singola componente sia affidabile.
Bisogna osservare il percorso che il dato compie e capire cosa succede se una delle sue dipendenze smette di funzionare.
In questo caso il problema è rimasto invisibile per undici giorni.
Ma i lead sono stati recuperati perché il dato aveva una seconda destinazione.
La ridondanza, quindi, non riguarda necessariamente soltanto server, connessioni o infrastrutture.
Può riguardare anche il modo in cui un processo conserva e trasferisce ciò che ha prodotto.
Conclusione
Per undici giorni il sito ha continuato a ricevere contatti.
Una parte del processo era interrotta, ma il sito non lo mostrava.
Il problema avrebbe potuto trasformarsi nella perdita di tutti i lead ricevuti in quel periodo.
Non è successo perché quei dati avevano già un’altra destinazione.
Quella seconda destinazione non era stata necessariamente pensata per questo problema.
Ma ha permesso al processo di conservare il valore che aveva già prodotto.
È questo uno dei motivi per cui la ridondanza non consiste semplicemente nel duplicare una componente.
Consiste anche nel fare in modo che un singolo problema non faccia perdere ciò che il processo ha già prodotto.
