| « "Eliminato l'impossibile, tutto ciò che resta, per quanto improbabile, è la verità". » |
| (Sherlock Holmes in "Il segno dei quattro" e "Il diadema di berilli" di Sir Arthur Conan Doyle) |
La funzione del troubleshooter è ripristinare il corretto funzionamento di un sistema in caso di presenza di una anomalia.
Per farlo egli deve trovare le cause o almeno delimitare un ambito "accettabilmente ristretto" in cui si trovano le cause del problema (diagnosi) e rimuoverle (soluzione).
Per una soluzione efficace è necessario delimitare l'ambito in cui si trovano le cause del problema. In linea teorica, in assenza assoluta di idee sulla causa, qualsiasi azione correttiva (es. sostituzione apparecchio, software, sistema operativo, server) potrebbe non eliminare il problema; ad esempio, l'azione di sostituzione di un apparecchio difettoso con uno del medesimo modello è inutile se la causa è un difetto di progettazione del modello stesso. Così come è inutile installare una versione più aggiornata di un software se la causa dell'anomalia non è stata rimossa tra una versione e l'altra.
Per la soluzione non è in genere necessaria una individuazione precisa delle cause dell'anomalia. Ogni intervento di correzione/riparazione ha un costo, così come l'attività di diagnosi. L'attività di diagnosi andrebbe arrestata quando la stima della somma dei costi ulteriori per limitare ulteriormente l'ambito sia uguale o ecceda il costo di riparare il problema nell'ambito attualmente individuato. Ad esempio, l'individuazione di modulo elettronico difettoso conclude in genere la diagnosi almeno presso la occorrenza del cliente.
Per la diagnosi è in genere necessario che il problema sia riproducibile/sistematico. Riproducibile significa che il problema possa essere scatenato a piacimento, in modo che si presenti con costanza oppure almeno entro un tempo finito o seguendo un determinato iter. Fin quando il problema non possa essere riprodotto a volontà in un tempo limitato viene detto erratico o intermittente. Ad esempio: 1) il problema di un apparecchio non si accende è sistematico. 2) Il problema di un programma che funziona bene ma si blocca tutte le volte che si cerca di stampare è sistematico. 3) Il problema di una macchina che di tanto in tanto si mette a fare rumore senza apparente motivo né regolarità temporale è erratico.
L'intermittenza è una circostanza soggettiva e non oggettiva: si ha fino a che una procedura di riproduzione non sia nota, dopo di ché "diventa" sistematico. Il fatto che la procedura di riproduzione non sia nota non significa che non esista. Ad esempio, il problema di un programma che funziona bene ma si blocca tutte le volte che si cerca di stampare è intermittente finché non ci si rende conto che il blocco del programma consegue all'azione di stampa.
Verificare e trovare una procedura di riproducibilità è il primo passo in assoluto per il troubleshooting. In situazione di erraticità il processo di esclusione è ostacolato in quanto non si possono sperimentare gli effetti di una azione di esclusione. Il metodo di esclusione si applicherebbe ugualmente ma tra una esclusione e l'altra occorre effettuare un congruo numero di prove perché siamo in un ambito probabilistico; anche una prova ad esito negativo impone la prosecuzione dell'iter. Inoltre non sarebbe possibile testare una soluzione.
E' prioritario eseguire pertanto l'operazione e scatenare il problema, anche se il cliente ha spiegato chiaramente l'iter. Eventualmente spiegare all'utente che non è che si dubita della sua parola o della sua competenza, ma che si deve essere certi di poter ricreare il problema a volontà. In molti casi, si evitano equivoci e perdite di tempo.
L'erraticità del problema va distinta primariamente in:
La classificazione varia naturalmente durante il processo diagnostico e deve essere aggiornata.
E' utile poter riprodurre il problema anche in un diverso ambiente, di sviluppo o di test, in laboratorio o da cliente, per evidenziare/testare eventuali anomalie di design o transazioni di modifica/danno irreparabile senza arrecare disagio a cliente.
Per la massima efficienza del processo è consigliabile iniziare a testare le cause più probabili o meglio quelle che si verificano più di frequente. Il principio di semplicità dice che le spiegazioni più semplici o banali (es. la classica mancata accensione dell'apparecchio) sono anche le più probabili; indagini in tal senso vanno fatta con un certo tatto (consigliabile telefono invece di scrivere). Eliminare possibili cause banali per negligenza o timidezza non solo è inefficiente ma può portare a fallimento o a figure ben peggiori. E' conveniente formulare check list/questionari delle domande chiave e compilarne una ogni volta. Il contenuto delle domande dipende dal contesto in cui si manifesta il problema quindi non può essere stabilita a prescindere dal tipo di problema/piattaforma su cui si opera.
Bisogna però, inversamente, essere elastici ed aperti ad ogni tipo di ipotesi per quanto improbabile (es. imperizia o addirittura sabotaggio da parte degli addetti).
Registrare accuratamente l'iter, le operazioni effettuate e le conclusioni parziali. Saranno utili anche per i test post-risoluzione anomalia. Non avere fretta. Verificare immediatamente l'esito di ciascuna prova; si possono rilevare eventuali errori nell'esecuzione (es. alterazione negli input) e spunti utili per l'esecuzione di altre prove.
In genere i sistemi sono suddivisi in schede/moduli. Ciò rende rapida sia la ricerca che la soluzione; la sostituzione di un modulo è in genere economicamente ottimale rispetto alla ricerca/sostituzione del singolo componente elettronico difettoso o la sostituzione dell'intero apparecchio se questo ha costo relativo elevato. Inoltre il cliente non ha l'idea che il suo sistema sia difettoso in toto. I casi estremi:
Sia per l'hardware che per il software sostituire un modulo potenzialmente difettoso con uno che si presume correttamente funzionante è uno strumento estremamente efficace ed efficiente sia per la diagnosi che per la soluzione. Quando si tratta di hardware (una occorrenza di un modello) in un unico tentativo si è trovata la causa e ottenuta la soluzione del problema. La prova va effettuata prioritariamente specialmente qualora non si hanno altre segnalazioni simili e non si riesce a riprodurre l'errore in altri ambienti.
Provare dopo ciascuna sostituzione. Se il tutto funziona, probabilmente il modulo sostituito è difettoso; ad esempio, se un oggetto generatore di report produce risultati anomali, verificare se ne esiste una versione che da' risultati corretti e sostituirla nell'ambiente difettoso. In caso di test positivo la causa resta localizzata nel modulo e in genere il processo di ricerca si può concludere senz'altro. In caso negativo, provare a sostituire moduli comuni, poi quelli che non sembrano direttamente coinvolti.
In caso che si voglia isolare una parte di codice, inserire dei diagnostici che comunichino la situazione in vari passaggi per escludere segmenti di codice.
Tale operazione presuppone di disporre di un database consistente e ben classificato di casi di anomalie o FAQ e consente di stilare un elenco di possibili cause e soluzioni. La prima attività è escludere i casi storici dissimili e isolare solo quelli simili. Il vantaggio della base di conoscenza di problemi e soluzioni è avere indicazione di ambiti ad alta probabilità di generazione errore a cui dare priorità nel processo.
Se la sostituzione non sortisce effetti, è probabile che si tratti di una situazione che il programma non gestisce, in cui la causa può essere attribuita in modo non alternativo a:
E, nel caso il programma non dia luogo ad errori fatali, anche a:
In caso venga enucleato un problema di comportamento inspiegabilmente diverso a parità di situazioni o comportamento inspiegabilmente uguale in situazioni diverse (più raramente), occorre una cosiddetta "analisi di impatto". Partire dall'ovvio: verificare scrupolosamente l'uguaglianza di tutti i fattori rilevanti o rispettivamente la rilevanza dei fattori differenti. In caso di confronti per prova di impatto verificare molto scrupolosamente che l'input e le circostanze siano diversi solo per i fattori di cui si vuole rilevare l'impatto. Pianificare in modo razionale e simulare l'effetto delle combinazioni di elementi di possibile impatto rilevante anche al di fuori dell'insieme segnalato. L'obiettivo è trovare una combinazione di una o più circostanze influenti sul manifestarsi del problema.
Consiste nel cercare di provocare l'errore in altri casi rispetto a quelli segnalati. Serve per testare l'ipotesi di impatto di una combinazione di circostanze sul problema.
Trovare una procedura di test che possa ridurre man mano l'insieme dei dati coinvolti. In caso negativo (insieme dei dati che da' errore), testare anche l'insieme complementare: anche in questo ci possono essere casi di errore.
E' importante testare altri casi oltre a quello del cliente e andare fino in fondo nell'iter. Questo può evidenziare la presenza di ulteriori problemi rispetto a quelli individuati e rimossi. Ad esempio, se si tratta di un problema di dati sporchi, ci possono essere un numero imprecisato di situazioni simili; per identificare tutti i dati, occorre sempre eseguire il test dopo aver eliminato il problema o anche per i casi complementari rispetto all'insieme dei dati difettosi per escludere la presenza di altri difetti.