Supporto IT Fatto Bene: Una Guida Pratica di Campo

La maggior parte del lavoro di supporto IT viene giudicata sulla velocità, ma la velocità senza metodo sposta semplicemente lo stesso problema altrove. Un ticket chiuso in cinque minuti che si riapre tra tre giorni costa più di uno che richiede venti minuti e viene effettivamente risolto. Questa guida copre le abitudini che separano chi chiude ticket da chi risolve problemi.

Inizia con una vera acquisizione, non con una supposizione

Prima di toccare una macchina, fai descrivere il problema all'utente con parole sue, poi fai tre domande di follow-up: quando è iniziato, cosa è cambiato di recente, e succede ogni volta o saltuariamente. "Internet è lento" potrebbe significare risoluzione DNS, un canale Wi-Fi saturo, una NIC difettosa, o un browser con quaranta schede aperte. Scrivi il testo esatto dell'errore se ce n'è uno. Gli screenshot battono le descrizioni ogni volta — chiedine uno prima di chiedere all'utente di provare qualcosa.

Resisti all'impulso di saltare direttamente a "hai provato a riavviare." Funziona abbastanza spesso che la gente vi ricorre di default, ma se salti l'acquisizione perderai i pattern. Se tre persone sullo stesso switch segnalano la stessa lentezza nella stessa ora, è un ticket diverso da un singolo laptop con un driver difettoso.

Riproduci prima di fixare

Se non riesci a riprodurre un problema, non puoi confermare di averlo fixato. Chiedi all'utente di eseguire i passaggi esatti su una screen share, oppure fallo tu stesso sulla sua macchina se gli strumenti remoti lo permettono. Controlla ipconfig /all su Windows o ip a su Linux per la sanità di base della rete, guarda Event Viewer (eventvwr.msc) per errori di applicazione e di sistema attorno all'ora segnalata, e controlla journalctl -xe --since "1 hour ago" su macchine Linux per la stessa finestra.

Per crash di applicazioni, ottieni il numero esatto della build e la versione del SO. "È crashato" non ti dice nulla; "Outlook 16.0.17726 crasha quando apri un invito di calendario con allegato .ics" ti dice dove guardare. Fai una verifica incrociata rispetto ai problemi noti nelle note di rilascio del fornitore prima di presumere che sia locale.

Triage per impatto, non per chi urla più forte

Un singolo utente bloccato dalla posta è scomodo. Un server di file condiviso irraggiungibile per quaranta persone è un'interruzione. Costruisci una semplice scala di severità — qualcosa come P1 per interruzioni che riguardano più utenti o sistemi critici, P2 per blocchi di singoli utenti, P3 per funzionamento degradato, P4 per richieste cosmetiche o di convenienza — e applicala coerentemente, anche sotto pressione da un manager che vuole risolvere il suo problema per primo.

Documenta la decisione di severità nel ticket stesso. Questo ti protegge più tardi quando qualcuno chiede perché il loro P3 è rimasto fermo per due giorni mentre tu gestivi tre P1.

Fixia la causa radice, non il sintomo

Riavviare un servizio che continua a crashare guadagna tempo, non una soluzione. Se uno spooler di stampa muore ogni giorno, controlla Get-WinEvent -LogName Application -MaxEvents 50 per l'errore effettivo prima di riavviarlo di nuovo. Se la password di un utente continua a scadere inaspettatamente, controlla la group policy applicata alla loro OU piuttosto che semplicemente resettarla e andare avanti.

Tieni un log personale di fix ricorrenti. Se ti ritrovi a digitare lo stesso comando PowerShell o lo stesso fix di registro tre volte, è un segno che appartiene in uno script o in un runbook documentato, non nella tua testa.

Documenta come se qualcun altro lo leggerà

Ogni risoluzione di ticket dovrebbe rispondere a: qual era la causa effettiva, qual era il fix, e cosa controlleresti per primo se questo succede di nuovo. "Fixato" come nota di risoluzione è inutile per il prossimo tecnico, incluso te stesso tra sei mesi senza memoria di questo ticket.

Una buona nota di risoluzione è così: "Causa radice: scope DHCP su VLAN 20 esaurito, i nuovi dispositivi hanno ottenuto indirizzi APIPA. Fix: scope esteso da /24 a /23, prenotazione per stampante aggiunta. Verifica: controlla il conteggio dei lease DHCP mensilmente, soglia di allarme impostata al 90%." Quella terza frase è quella che la maggior parte dei tecnici salta, ed è quella che previene il ticket ripetuto.

Escalate con contesto, non solo un inoltro

Quando un ticket va al tier 2 o a un fornitore, includi quello che hai già escluso. "Ho controllato i cavi, scambiato la porta, confermato la config VLAN, ancora nessuna spia di link" risparmia al prossimo di rifare i tuoi primi venti minuti. Escalation vaghe come "l'utente dice che è rotto, per favore consigliami" semplicemente muove il ritardo invece di eliminarlo.

Chiudi il loop con l'utente

Di' all'utente cosa è andato male in linguaggio semplice, non solo "fixato." Le persone si fidano del supporto di più quando capiscono cosa è successo, e riduce il numero di volte che la stessa persona presenta lo stesso ticket il mese prossimo perché non realizzano che è collegato.

Se vuoi approfondire il lato tecnico di uno qualsiasi di questi — fondamenti di networking, log di Windows, o scripting dei tuoi stessi strumenti diagnostici — Korra Studio ha segmenti su Networking, Systems, e Scripting che vale la pena affrontare dopo.