NexTool Solutions

La visibilità non significa avere più report - significa vedere lo stato della coda mentre puoi ancora agire. GLPI conserva già tutto ciò che ti serve; il problema è che il dato è sparso e la dashboard nativa mostra solo il passato. Questa guida mostra dove vive la visibilità reale in GLPI, quali query di diagnostica eseguiamo quando prendiamo in carico la manutenzione di un ambiente, come anticipare lo sforamento di uno SLA prima che accada e come trasformare tutto questo in un avviso automatico.

La visibilità che GLPI ti dà già - e dove si ferma

GLPI arriva con dashboard nella Centrale e una ricerca filtrata potente. Per il quotidiano, questo risolve molto: conteggi per stato, per tecnico, per categoria. Il limite compare in tre punti:

• È su richiesta, non proattivo. La dashboard si aggiorna solo quando qualcuno apre la schermata. Nessuno viene avvisato quando si forma un collo di bottiglia - devi andare a guardare.
• Conta ciò che il tuo profilo può vedere. Il numero in dashboard dipende dall'entità e dal profilo di chi è connesso. Il coordinatore di un'entità e l'amministratore globale vedono totali diversi della stessa coda.
• Mostra l'aggregato, non il ticket dimenticato. "42 ticket aperti" non ti dice quale è fermo da 20 giorni.

La visibilità vera inizia quando smetti di guardare il totale e inizi a guardare la forma della coda e ciò che sta per andare storto.

Passo 1: dove si accumula il backlog

Prima di qualsiasi bella dashboard, la prima radiografia è la distribuzione del backlog per gruppo e stato. Tutto vive in glpi_tickets; l'assegnazione al gruppo in glpi_groups_tickets (tipo 2 = assegnato). Gli stati che contano: 1 Nuovo, 2/3 In corso, 4 In attesa, 5 Risolto, 6 Chiuso.

-- Backlog aperto per gruppo assegnato (type 2 = assegnato)
SELECT
  g.completename                    AS gruppo,
  COUNT(*)                          AS aperti,
  SUM(t.status = 1)                 AS nuovi_non_smistati,
  SUM(t.status = 4)                 AS in_attesa
FROM glpi_tickets t
JOIN glpi_groups_tickets gt
     ON gt.tickets_id = t.id AND gt.type = 2
JOIN glpi_groups g ON g.id = gt.groups_id
WHERE t.status NOT IN (5, 6)
  AND t.is_deleted = 0
GROUP BY g.id
ORDER BY aperti DESC;

In pochi secondi vedi quale gruppo è sovraccarico e quanta parte del backlog sono ticket nuovi che nessuno ha smistato - il numero che la dashboard nativa nasconde dietro il totale.

Passo 2: lo SLA che sta per sforare prima di sforare

Qui sta la differenza tra un'operatività che reagisce e una che anticipa. Quando uno SLA corrisponde al ticket, GLPI scrive la scadenza in colonne dedicate di glpi_tickets: time_to_resolve (scadenza di risoluzione) e time_to_own (scadenza di presa in carico). È un orologio - puoi guardare cosa scade nelle prossime ore, non solo ciò che è già scaduto:

-- Ticket aperti con SLA di risoluzione in scadenza entro le prossime 4h
SELECT
  t.id,
  t.name,
  t.time_to_resolve,
  TIMESTAMPDIFF(MINUTE, NOW(), t.time_to_resolve) AS minuti_rimasti
FROM glpi_tickets t
WHERE t.status NOT IN (4, 5, 6)        -- escluso In attesa, Risolto, Chiuso
  AND t.is_deleted = 0
  AND t.time_to_resolve IS NOT NULL
  AND t.time_to_resolve > NOW()
  AND t.time_to_resolve <= NOW() + INTERVAL 4 HOUR
ORDER BY t.time_to_resolve ASC;

La trappola sul campo è in quel IS NOT NULL. La colonna time_to_resolve viene valorizzata solo quando una regola di SLA ha corrisposto al ticket in fase di apertura. Un ticket che non ha corrisposto ad alcuna regola resta con la scadenza NULL - e sparisce silenziosamente dalla dashboard di rischio. In altre parole: i ticket senza SLA, proprio quelli che nessuno sta misurando, sono invisibili a qualsiasi avviso basato sulla scadenza. Quando prendiamo in carico un ambiente, il primo conteggio che eseguiamo è quanti aperti hanno time_to_resolve IS NULL. Abbiamo già visto un cliente con il 60% del backlog senza alcuno SLA associato: la dashboard diceva "tutto nei tempi" perché metà della coda semplicemente non aveva scadenza.

Passo 3: il responsabile che non esiste

Un altro punto cieco classico: ticket assegnato solo a un gruppo, senza tecnico nominato. A schermo sembra assegnato; in pratica, nessuno si sente il responsabile. Questi ticket spariscono dalle dashboard personali ("i miei ticket") e invecchiano invisibili. L'assegnazione alla persona vive in glpi_tickets_users con type = 2:

-- Aperti assegnati a un gruppo ma SENZA tecnico responsabile nominato
SELECT COUNT(*) AS senza_responsabile
FROM glpi_tickets t
WHERE t.status NOT IN (5, 6)
  AND t.is_deleted = 0
  AND NOT EXISTS (
    SELECT 1 FROM glpi_tickets_users tu
    WHERE tu.tickets_id = t.id AND tu.type = 2
  );

I livelli di visibilità: cosa usare per cosa

Non esiste uno strumento unico. Ogni livello risolve un problema e ha un limite. Ecco come decidiamo dove mettere ciascun indicatore:

Passo 4: trasformare la diagnosi in avviso automatico

Eseguire la query a mano non scala e, peggio, dipende dal fatto che qualcuno si ricordi di guardare. Due modi per chiudere il cerchio in GLPI:

1. Nativo, senza infrastruttura aggiuntiva: salva la ricerca "SLA in scadenza" o "in attesa da più di 7 giorni" e crea un avviso di ricerca salvata. Il cron di GLPI esegue la ricerca periodicamente e invia un'e-mail quando il conteggio supera la soglia che imposti.
2. Fuori da GLPI, per schermo a muro e storico: pianifica la query di diagnostica nel cron di sistema, leggendo la credenziale da un file .cnf (chmod 600) per non lasciare mai la password sulla riga di comando.

# /etc/cron.d/glpi-visibilita  ->  ogni ora lavorativa, come www-data
# Elenca i ticket con SLA in scadenza entro 4h per la coda di reperibilità
0 8-18 * * 1-5 www-data /usr/bin/mysql --defaults-file=/etc/glpi/kpi-ro.cnf glpi \
  < /opt/glpi-kpi/sla-in-scadenza.sql \
  > /var/log/glpi-kpi/sla-rischio-$(date +\%Y-\%m-\%d-\%H).csv 2>&1

Prima di pianificare, assicurati che il cron di GLPI giri davvero in modalità esterna (il cron di sistema che chiama front/cron.php) - altrimenti le scadenze SLA e gli avvisi nativi non vengono nemmeno ricalcolati, e staresti leggendo un orologio fermo.

La svolta, dalla pratica della manutenzione

Quando prendiamo in carico il GLPI di un cliente, la prima radiografia non è mai la dashboard nativa - è il conteggio dei ticket assegnati solo a un gruppo (senza responsabile) e dei ticket con time_to_resolve nullo. In un caso, il 40% del backlog era "assegnato" a un gruppo di otto persone e nessuno si sentiva responsabile; nessuno di quei ticket compariva su una dashboard personale e il più vecchio aveva 90 giorni. La correzione non è stata una nuova dashboard - è stata una regola di business che imponeva un tecnico nominato all'assegnazione, più un avviso di SLA a 4 ore dalla scadenza. La visibilità non è arrivata comprando uno strumento; è arrivata guardando i campi giusti.

Errori comuni sul campo

• Fidarsi del totale della dashboard: aggrega e nasconde il ticket fermo; guarda la distribuzione per gruppo e per anzianità.
• Credere che ogni ticket abbia uno SLA: time_to_resolve NULL = fuori da ogni avviso di scadenza. Conta prima quelli senza SLA.
• Trattare "assegnato a un gruppo" come "ha un responsabile": senza una riga in glpi_tickets_users con type = 2, nessuno è responsabile.
• Confrontare entità con lo stesso numero: la dashboard nativa filtra già per profilo ed entità; il totale cambia in base a chi è connesso.
• Dimenticare is_deleted = 0: il cestino di GLPI non esce dalla tabella e inquina qualsiasi conteggio.
• Misurare con il cron fermo: senza il cron esterno in funzione, SLA e avvisi nativi non si aggiornano.

Prossimo passo

Parti dai tre conteggi di questa guida (senza responsabile, senza SLA, SLA in scadenza), porta quei tagli su una dashboard in Metabase o Grafana e collega i tuoi KPI di Service Desk agli avvisi. Così la coda smette di essere un numero a fine mese e diventa un segnale che scatta finché c'è ancora tempo di agire.

In NexTool, questa radiografia di visibilità è il primo deliverable quando prendiamo in carico la manutenzione di un GLPI: mappiamo i punti ciechi, colleghiamo gli avvisi e consegniamo la dashboard. Se vuoi questo monitoraggio sul tuo ambiente, scopri il nostro servizio di supporto e manutenzione.

Questo contenuto è stato prodotto con l'ausilio dell'intelligenza artificiale e revisionato dal team di Nextool Solutions.