NexTool Solutions

La gestione degli incidenti è la pratica ITSM che più persone credono di padroneggiare e quella che più si rompe nell'operatività reale. Nella gestione continuativa di ambienti GLPI dei clienti, il problema non è quasi mai un tecnico incapace di chiudere un ticket: è lo SLA che scade senza che nessuno venga avvisato, la priorità che qualcuno ha modificato a mano e il cron che gira nella modalità sbagliata. Questa guida mostra dove vive l'incidente in GLPI, come classificarlo senza inventare campi e le trappole sul campo che emergono solo dopo mesi di esercizio.

Dove vive l'incidente in GLPI

Incidente e richiesta non sono moduli separati: sono lo stesso oggetto Ticket, nella tabella glpi_tickets, distinti dalla colonna type - 1 per incidente, 2 per richiesta. Ciò che cambia è il flusso, lo SLA e la lettura gestionale. Secondo ITIL 4, un incidente è un'interruzione non pianificata o una riduzione della qualità di un servizio, e l'obiettivo è ripristinare il servizio il più rapidamente possibile, non trovarne la causa: quella è gestione dei problemi.

Ogni incidente attraversa una macchina a stati fissa. Conoscere il codice di ogni stato conta perché i report, le regole di business e l'SQL di diagnostica lavorano con il numero, non con l'etichetta:

Il dettaglio che rovina un report: lo stato In attesa (4) mette in pausa il conteggio dello SLA quando lo configuri così. Il tecnico che scarica tutto in In attesa per "non sforare la scadenza" maschera l'indicatore, non migliora il servizio.

Classificazione: la matrice Urgenza × Impatto

GLPI non lascia che il tecnico scelga la priorità nel vuoto. È calcolata incrociando due campi che il richiedente e chi fa triage compilano: urgenza (quanto rapidamente serve al business) e impatto (quanti sono colpiti e quanto critici). La matrice si trova in Configurazione > Generale > Assistenza ed è completamente modificabile. Un estratto semplificato della logica:

GLPI supporta fino a cinque livelli di urgenza e impatto, più la priorità Maggiore (critica). La matrice predefinita è simmetrica: urgenza e impatto pesano allo stesso modo. Adatta i pesi alla realtà del cliente: nel retail, una cassa fuori uso in ora di punta è urgenza massima, indipendentemente dal numero di negozi colpiti.

Il flusso di gestione, passo per passo

1. Registrazione: portale self-service, e-mail (collettore), telefono o integrazione. Le regole di business (RuleTicket) classificano categoria, gruppo e priorità automaticamente all'item_add.
2. Presa in carico (prima risposta): GLPI registra in takeintoaccount_delay_stat il tempo fino alla prima azione del tecnico. È il tuo SLA di presa in carico (TTO - time to own), diverso dallo SLA di risoluzione (TTR - time to resolve).
3. Indagine: knowledge base, storico di ticket simili e CMDB. Il modulo AI Assist riassume i thread lunghi e suggerisce soluzioni dalla base.
4. Risoluzione: definitiva (causa corretta) o workaround. Se è un workaround ricorrente, collegalo a un Problema - un incidente non "diventa" un problema, sono oggetti distinti.
5. Chiusura: dopo la conferma, il ticket passa a Chiuso e attiva il sondaggio di soddisfazione.

La trappola nº 1 della gestione: il cron nella modalità sbagliata

È il guasto che gestiamo più spesso in un ambiente cliente nuovo. Lo SLA è configurato, i livelli di escalation sono creati, eppure nessuno riceve l'avviso quando la scadenza sfora e i ticket risolti non si chiudono mai da soli. La causa è quasi sempre la stessa: le azioni automatiche di GLPI sono in modalità GLPI (web), che gira solo quando qualcuno carica una pagina. In un cliente con poco traffico fuori dall'orario lavorativo, l'escalation dello SLA semplicemente non parte.

La correzione è mettere lo scheduler in modalità CLI, avviato da un cron del sistema operativo. Su ogni azione automatica (Configurazione > Azioni automatiche), imposta Modalità di esecuzione = CLI e aggiungi la voce nel crontab:

# /etc/cron.d/glpi - esegue lo scheduler di GLPI ogni minuto
# GLPI 10 e 11: front/cron.php e il percorso portabile tra le versioni
* * * * * www-data /usr/bin/php /var/www/glpi/front/cron.php >/dev/null 2>&1

Dipendono da questo cron per funzionare: closeticket (chiude automaticamente ciò che è rimasto Risolto oltre la scadenza), createinquest (genera il sondaggio di soddisfazione) e l'escalation per livello di SLA. Un dettaglio di portabilità che frega molti: in GLPI 11 non esiste il comando console glpi:cron che alcuni tutorial di GLPI 10 citano - il percorso che funziona in entrambe le versioni è il front/cron.php qui sopra.

Diagnostica: trovare gli incidenti che sforano lo SLA

Quando il cliente dice "lo SLA non regge", il primo passo è guardare il dato grezzo, non la dashboard. Questo SQL elenca gli incidenti aperti la cui scadenza di risoluzione è già passata e segnala quelli mai nemmeno presi in carico (takeintoaccount_delay_stat = 0):

SELECT t.id,
       t.name AS titolo,
       c.completename AS categoria,
       t.priority,
       t.time_to_resolve,
       IF(t.takeintoaccount_delay_stat = 0,
          'SENZA PRIMA RISPOSTA', 'ok') AS gestione
FROM glpi_tickets t
LEFT JOIN glpi_itilcategories c ON c.id = t.itilcategories_id
WHERE t.is_deleted = 0
  AND t.type = 1                       -- 1 = incidente
  AND t.status NOT IN (5, 6)           -- esclude Risolto e Chiuso
  AND t.time_to_resolve IS NOT NULL
  AND t.time_to_resolve < NOW()        -- scadenza di risoluzione gia superata
  AND t.solvedate IS NULL
ORDER BY t.time_to_resolve ASC;

Eseguendo questo in gestione, il pattern che emerge di più non è un alto volume di ticket: è una manciata di incidenti ad alta priorità fermi In attesa da giorni, con il cronometro "in pausa", mentre il richiedente crede che vengano trattati.

Una notifica di escalation che il manager legge davvero

Il template di escalation predefinito invia un blocco generico. Un modello snello, con i tag giusti, fa agire il supervisore senza aprire GLPI. I tag ##ticket.*## vengono risolti da GLPI all'invio:

Oggetto: [SLA superato] Ticket ##ticket.id## - ##ticket.title##

Il ticket qui sotto ha superato la scadenza di risoluzione.

Titolo:       ##ticket.title##
Categoria:    ##ticket.category##
Priorita:     ##ticket.priority##
Stato:        ##ticket.status##
Assegnato a:  ##ticket.assigntousers##
Scadenza (TTR): ##ticket.time_to_resolve##

Apri il ticket: ##ticket.url##

Errori comuni sul campo

• "Tutto è urgente": quando ogni ticket entra come priorità alta, non hai priorizzazione, hai una coda cronologica costosa. Blocca l'urgenza nel modulo guidato ed educa con la matrice.
• Priorità modificata a mano: il tecnico che sovrascrive la priorità calcolata rompe la lettura dello SLA e la matrice. Se devono sempre riclassificare, il difetto è nella matrice, non nel tecnico.
• Confondere TTO con TTR: "ho aperto il ticket per leggerlo" conta già come presa in carico e rispetta lo SLA di prima risposta senza che nessuno abbia risolto nulla. Misura il TTR (risoluzione), non solo il TTO.
• Un workaround che diventa permanente: workaround applicato e ticket chiuso, senza Problema aperto - l'incidente torna la settimana dopo. Collega i workaround ricorrenti a un Problema.

Prossimo passo

Con la gestione degli incidenti solida, passa alla gestione dei problemi (eliminare la causa radice) e alla gestione dei cambiamenti. Per accelerare il triage, il modulo Smart Assign distribuisce gli incidenti tra i tecnici per regole di carico e competenza, e la guida SLA e OLA copre la configurazione delle scadenze.

Ti serve un GLPI che regge davvero lo SLA? NexTool gestisce ambienti GLPI end to end, dalla matrice di priorità al cron di escalation. Scopri il nostro servizio di supporto e mantenimento.

Revisionato dal team NexTool Solutions.