Contenuti
- Il problema si presentava solo su alcuni dispositivi
- Capire la causa non era così semplice
- Il problema scompare
- Il problema era risolto?
- Un problema che scompare non è necessariamente un problema risolto
- La soluzione può essere corretta anche quando la causa rimane sconosciuta
- Una soluzione può diventare una pezza
- Il costo di non sapere
- Tornare a funzionare non significa aver capito
- La domanda da porsi
Un sito può avere un problema.
Si può intervenire.
Il problema può scomparire.
Eppure, alla fine dell’intervento, potrebbe essere ancora impossibile dire con certezza che cosa lo aveva causato.
Questa distinzione è importante perché un sistema che torna a funzionare non è necessariamente un sistema del quale abbiamo compreso il comportamento.
Il problema si presentava solo su alcuni dispositivi
In una situazione reale, un sito funzionava normalmente nella maggior parte dei casi.
Su alcuni dispositivi, invece, non si comportava come previsto.
Il problema non era quindi facilmente riproducibile.
Il sito funzionava.
La configurazione del server sembrava corretta.
Ma in determinate condizioni il comportamento cambiava.
L’analisi portò a ricondurre il problema al modo in cui veniva gestito il protocollo HTTP.
Ma questa non era ancora una spiegazione completa.
Era un’indicazione.
Capire la causa non era così semplice
Sullo stesso provider era presente anche un altro sito dello stesso cliente che funzionava correttamente utilizzando lo stesso protocollo.
Questo rendeva ancora più difficile attribuire il problema semplicemente all’infrastruttura.
I due siti non erano però identici.
Avevano configurazioni differenti.
Avevano subito modifiche differenti.
E uno dei due aveva accumulato nel tempo una quantità significativa di personalizzazioni.
Dire:
“È il provider.”
non avrebbe quindi spiegato il problema.
Ma nemmeno dire:
“È il protocollo.”
permetteva di stabilire quale fosse realmente la causa.
Per arrivare a una risposta sarebbe stato necessario continuare l’analisi e isolare le diverse variabili.
Non fu possibile farlo.
Il problema scompare
A quel punto venne introdotta una CDN davanti al sito.
La CDN esponeva il sito utilizzando un altro protocollo.
Il problema sui dispositivi interessati scomparve.
Il sito tornò a comportarsi correttamente.
Dal punto di vista operativo, il risultato era quello che serviva.
Ma rimaneva una domanda:
Perché prima non funzionava?
A questa domanda non era stata data una risposta definitiva.
Il problema era risolto?
Dipende da cosa intendiamo per “risolto”.
Se intendiamo:
“Il sito adesso funziona?”
la risposta era sì.
Se invece intendiamo:
“Abbiamo individuato e rimosso la causa del problema?”
la risposta era diversa.
La causa non era stata individuata con certezza.
Era stato modificato il percorso attraverso il quale il sito veniva raggiunto e, cambiando quel percorso, il problema aveva smesso di manifestarsi.
È una differenza tutt’altro che teorica.
Un problema che scompare non è necessariamente un problema risolto
Quando un intervento elimina un sintomo, è naturale considerare concluso il lavoro.
Il sito funziona.
Il cliente è soddisfatto.
L’anomalia non si presenta più.
Ma se la causa non è stata compresa, una parte del rischio può essere rimasta.
Potrebbe cambiare nuovamente qualcosa.
Il server potrebbe essere aggiornato.
La configurazione potrebbe cambiare.
Il codice potrebbe evolvere.
Il comportamento dei dispositivi potrebbe modificarsi.
E potremmo ritrovarci nuovamente davanti allo stesso problema.
Non necessariamente perché la soluzione adottata non funzionasse.
Ma perché non abbiamo mai stabilito quale condizione producesse il problema originale.
La soluzione può essere corretta anche quando la causa rimane sconosciuta
Questo è un punto importante.
Non sempre è possibile completare un’indagine.
A volte il costo necessario per individuare la causa non è proporzionato al problema.
A volte il sistema deve semplicemente tornare operativo.
A volte una soluzione alternativa permette di eliminare il problema in modo sufficientemente affidabile.
Non c’è nulla di sbagliato nell’adottarla.
Il problema nasce quando si confondono due risultati diversi:
il problema non si manifesta più
e
abbiamo capito perché si manifestava.
Non sono la stessa cosa.
Una soluzione può diventare una pezza
Nel glossario di Sito Fermo, una pezza è:
Un intervento che elimina il sintomo senza individuare o risolvere la causa del problema.
In questa casistica la CDN ha eliminato il sintomo.
Ma non ha permesso di stabilire con certezza quale fosse la causa.
Questo non significa che una CDN sia una pezza in quanto tale.
Significa che in questo caso specifico l’intervento ha risolto il comportamento osservato senza risolvere la causa che lo produceva.
La distinzione è importante.
Una soluzione tecnica può essere perfettamente valida.
Ma se viene utilizzata per evitare di comprendere un problema, potrebbe lasciare dietro di sé un’incognita.
Il costo di non sapere
Finché il sito continua a funzionare, questa incognita può sembrare irrilevante.
In questo caso, però, c’era un’ulteriore difficoltà: il problema non era facilmente riproducibile.
Si verificava soltanto con determinati dispositivi e soltanto dopo una determinata sequenza di azioni.
Non bastava quindi aprire il sito e verificare che una pagina si caricasse correttamente.
Per riprodurre il problema era necessario trovarsi nelle condizioni specifiche in cui si manifestava.
Questo rendeva difficile anche pensare a un controllo automatico capace di intercettarlo.
Il sito poteva quindi continuare a risultare funzionante durante i normali controlli, mentre alcuni utenti potevano incontrare un comportamento anomalo durante la navigazione.
E questo avrebbe potuto avere una conseguenza molto concreta: un’esperienza di navigazione negativa per una parte degli utenti, senza che il problema fosse immediatamente visibile a chi gestiva il sito.
La conoscenza del sistema ha quindi un valore.
Sapere perché una determinata configurazione è necessaria permette di capire cosa potrebbe succedere se quella configurazione cambia.
Non saperlo significa dover nuovamente investigare quando qualcosa si modifica.
Il problema quindi non è soltanto tecnico.
È anche di progettazione e di conoscenza del sistema.
Un sito del quale nessuno riesce a spiegare completamente il comportamento può essere più difficile da mantenere e più difficile da diagnosticare quando qualcosa cambia.
Tornare a funzionare non significa aver capito
Questa casistica mostra una distinzione che può essere facilmente trascurata.
Un intervento può produrre tre risultati diversi:
Il sintomo è scomparso.
Il sito torna a funzionare.
La causa è stata individuata.
Sappiamo perché il problema si verificava.
Il rischio è stato eliminato.
Abbiamo modificato il sistema in modo da impedire che quella condizione possa nuovamente produrre lo stesso problema.
Il primo risultato non garantisce automaticamente gli altri due.
La domanda da porsi
Quando un problema scompare dopo un intervento, è naturale dire:
“Funziona.”
Ma prima di considerare concluso il lavoro può essere utile chiedersi:
“Abbiamo risolto il problema oppure abbiamo semplicemente fatto in modo che non si manifestasse più?”
A volte le due cose coincidono.
A volte no.
Saper distinguere le due situazioni significa conoscere meglio il sistema che stiamo gestendo.
E significa anche sapere quanto rischio stiamo realmente lasciando dietro di noi.
Un problema che non si manifesta più non è necessariamente un problema risolto.
