I passaggi strutturati per la risoluzione dei problemi

Le correzioni casuali fanno perdere tempo e a volte peggiorano la situazione. Una metodologia strutturata di troubleshooting offre un percorso logico e ripetibile dal sintomo alla soluzione. CompTIA verifica uno specifico processo in sette fasi perché aiuta i tecnici a mantenere l'organizzazione, evita di trascurare indizi e produce risultati documentabili e ripetibili. Seguire le fasi è più veloce che procedere per tentativi, anche quando una risposta sembra ovvia.

Il modello CompTIA prevede sette fasi:

• 1. Identificare il problema.
• 2. Stabilire una teoria della causa probabile.
• 3. Verificare la teoria.
• 4. Stabilire un piano d'azione.
• 5. Implementare la soluzione.
• 6. Verificare la piena funzionalità.
• 7. Documentare risultati, azioni ed esiti.

Memorizzi quest'ordine: l'esame lo chiede direttamente.

Identifichi il problema raccogliendo informazioni dagli utenti, dai log e dai Suoi test. Chieda che cosa è cambiato, quando è iniziato il problema e chi ne è interessato. Metta in discussione ciò che sembra ovvio e, se possibile, riproduca il problema. Una descrizione chiara e specifica del problema, come "nessun accesso a Internet dalla rete wireless del secondo piano", guida tutto ciò che segue. Una descrizione vaga porta a una soluzione vaga.

Stabilisca una teoria della causa probabile. In base ai sintomi, elabori un'ipotesi ragionata su ciò che non funziona. Cominci dalle cause più probabili e semplici, le cosiddette "low-hanging fruit", prima di considerare quelle insolite. Se un solo PC non ha accesso alla rete, è più probabile un cavo guasto che un bug del protocollo di routing. Potrebbe avere diverse teorie candidate.

Verifichi la teoria per determinare la causa. Esegua un controllo che confermi o escluda la Sua ipotesi. Se viene confermata, proceda. In caso contrario, formuli una nuova teoria e verifichi di nuovo, oppure escalation a una persona con maggiore esperienza o con accesso a ulteriori risorse. Non inizi mai a correggere il problema prima di averne confermato la causa, altrimenti potrebbe danneggiare componenti funzionanti.

Stabilisca un piano d'azione e individui i potenziali effetti. Decida esattamente che cosa farà, in quale ordine e che cosa potrebbe andare storto. Consideri il downtime, gli utenti coinvolti e una procedura di rollback nel caso in cui la correzione non funzioni. La pianificazione evita che una correzione rapida su un dispositivo interrompa accidentalmente un intero sito. Le modifiche più importanti richiedono piani più ampi e accurati.

Implementi la soluzione seguendo il piano, oppure ricorra all'escalation se il problema supera le Sue competenze o la Sua autorità. Quando possibile, apporti una modifica alla volta, così potrà capire che cosa ha effettivamente risolto il problema. Durante l'implementazione, rispetti le regole di change control e le finestre di manutenzione, in modo da ridurre al minimo l'interruzione del traffico in produzione.

Verifichi la piena funzionalità del sistema e, se opportuno, implementi misure preventive. Si assicuri non solo che il sintomo originale sia scomparso, ma anche che non si sia verificato alcun altro problema. Chieda all'utente di eseguire un test e controlli nuovamente i servizi correlati. Se l'interruzione è stata causata da un cavo guasto, potrebbe anche etichettare il cavo o sostituire quello vicino usurato, per evitare che il problema si ripeta.

Documenti risultati, azioni ed esiti. Registri il sintomo, la causa, ciò che ha fatto e il risultato. Una buona documentazione accelera la gestione del successivo incidente simile, favorisce la condivisione delle conoscenze e crea una traccia di audit. Questa fase finale è facile da saltare sotto pressione, ma è ciò che trasforma una correzione occasionale in conoscenza duratura per l'organizzazione.

All'interno del metodo, i tecnici scelgono spesso una direzione usando il modello OSI. L'approccio bottom-up parte dal livello fisico (cavi, collegamenti) e procede verso l'alto; è utile quando si sospetta un guasto totale. L'approccio top-down parte dall'applicazione e procede verso il basso; è utile quando un'applicazione si comporta in modo anomalo, ma la connettività sembra funzionare. L'approccio divide-and-conquer parte dal centro per suddividere l'area del problema.

Faccia attenzione alle abitudini che compromettono il metodo: modificare più elementi contemporaneamente, non poter quindi capire che cosa ha funzionato, saltare la verifica o dimenticare di documentare. Resista anche al bias di conferma, cioè alla tendenza a continuare a credere in una teoria anche quando le prove la contraddicono. La disciplina nel seguire ogni fase, nell'ordine corretto, è ciò che rende affidabile la metodologia sotto pressione.

Metta alla prova le Sue conoscenze del processo.

Ha imparato il metodo strutturato. Punti chiave:

• Sette fasi: identificare, formulare una teoria, verificare, pianificare, implementare, controllare, documentare.
• Cominci prima dalle cause semplici e più probabili.
• Confermi la causa prima di intervenire; ricorra all'escalation quando necessario.
• Approcci: bottom-up, top-down e divide-and-conquer.
• Verifichi e documenti sempre, anche sotto pressione.