NexTool Solutions

Il tempo medio di risoluzione misura chi è già uscito dalla coda. L'età media dei ticket misura chi è ancora dentro - ed è lì che si nasconde il backlog dimenticato. Questa guida mostra da dove esce il numero in GLPI, perché la media da sola inganna, come separare età e stagnazione e come trasformarla in una revisione settimanale del backlog negli ambienti che manteniamo.

Cosa misura l'età media - e cosa nasconde

L'età media dei ticket è la media di giorni tra l'apertura e oggi, contando solo i ticket ancora aperti. A differenza del TMR, che vede solo ciò che è già risolto, fotografa lo stato attuale della coda. Il problema è che la media, da sola, riassume male una coda reale: un backlog tipico è bimodale - decine di ticket nuovissimi di poche ore convivono con una coda di ticket fermi da settimane. La massa di ticket nuovi tira la media verso il basso e nasconde proprio i vecchi, che sono quelli da trovare. Per questo la media non viaggia mai da sola: arriva con una distribuzione e una mediana.

Da dove esce il numero in GLPI

Tutto vive nella tabella glpi_tickets. L'età usa la colonna date (data di apertura); il filtro "aperto" usa status. Gli stati che contano:

• 1 - Nuovo (non ancora smistato)
• 2 - In corso (assegnato)
• 3 - In corso (pianificato)
• 4 - In attesa (in attesa di terzi)
• 5 - Risolto e 6 - Chiuso (fuori dal backlog)

L'errore più comune qui è mettere tutto ciò che non è 5 né 6 nello stesso calderone. I ticket in In attesa (stato 4) sono legittimamente fermi in attesa di un fornitore, del cliente o di un pezzo - gonfiano l'età media senza che nessuno abbia dimenticato nulla. Segmentare per stato è il primo filtro onesto:

-- Età media per stato (segmentare: "In attesa" gonfia la media)
SELECT
  status,
  ROUND(AVG(DATEDIFF(NOW(), date)), 1) AS giorni_eta_media,
  COUNT(*)                             AS total
FROM glpi_tickets
WHERE status NOT IN (5, 6)   -- esclusi Risolto e Chiuso
  AND is_deleted = 0
GROUP BY status
ORDER BY giorni_eta_media DESC;
-- stato: 1 Nuovo, 2 assegnato, 3 pianificato, 4 In attesa

L'età non è la stagnazione

Un ticket aperto 40 giorni fa ma con un'attività registrata ieri è molto diverso da uno aperto 40 giorni fa che nessuno ha toccato. L'età (dall'apertura) misura l'anzianità; la stagnazione (dall'ultima azione umana) misura l'abbandono - ed è la stagnazione a indicare il ticket dimenticato.

In manutenzione, l'errore che abbiamo visto costare caro è usare date_mod come "ultima azione". La colonna date_mod del ticket viene aggiornata da qualsiasi cosa: una notifica inviata, un osservatore aggiunto, il cron dello SLA che ricalcola una scadenza, una regola di business che scatta. In pratica dà l'illusione di movimento su ticket che nessuno ha davvero lavorato. La vera ultima azione umana vive nel seguito e nell'attività - glpi_itilfollowups e glpi_tickettasks. Quando abbiamo sostituito date_mod con la data massima di quelle due tabelle, la lista dei ticket fermi di un cliente è passata da 3 a 17: gli altri 14 sembravano vivi solo perché un'automazione li sfiorava ogni giorno.

-- Stagnazione reale: giorni dall'ultima interazione umana
-- date_mod non è affidabile (notifiche, follower e cron lo aggiornano)
SELECT
  t.id,
  t.name,
  DATEDIFF(NOW(), t.date) AS giorni_eta,
  DATEDIFF(NOW(), GREATEST(
      t.date,
      COALESCE(MAX(f.date), t.date),
      COALESCE(MAX(k.date), t.date)
  ))                       AS giorni_fermo
FROM glpi_tickets t
LEFT JOIN glpi_itilfollowups f
       ON f.itemtype = 'Ticket' AND f.items_id = t.id
LEFT JOIN glpi_tickettasks k
       ON k.tickets_id = t.id
WHERE t.status NOT IN (4, 5, 6)   -- esclusi In attesa, Risolto, Chiuso
  AND t.is_deleted = 0
GROUP BY t.id, t.name, t.date
HAVING giorni_fermo >= 7
ORDER BY giorni_fermo DESC;

La distribuzione, non solo la media

Prima di reagire a una media salita, guarda la forma della coda. La query qui sotto suddivide il backlog in fasce di età e rivela la lunga coda che la media appiattisce:

-- Distribuzione del backlog per fascia di età
SELECT
  CASE
    WHEN DATEDIFF(NOW(), date) <= 3  THEN '0-3 giorni'
    WHEN DATEDIFF(NOW(), date) <= 7  THEN '3-7 giorni'
    WHEN DATEDIFF(NOW(), date) <= 15 THEN '7-15 giorni'
    WHEN DATEDIFF(NOW(), date) <= 30 THEN '15-30 giorni'
    ELSE '30+ giorni'
  END        AS fascia,
  COUNT(*)   AS ticket
FROM glpi_tickets
WHERE status NOT IN (4, 5, 6)
  AND is_deleted = 0
GROUP BY fascia
ORDER BY MIN(DATEDIFF(NOW(), date));

Come intervallo di riferimento onesto (giorni di calendario, non lavorativi): sotto i 3 giorni è sano, da 3 a 7 giorni è accettabile, da 7 a 15 giorni accende l'allerta e oltre i 15 giorni richiede una revisione ticket per ticket. Non sono obiettivi universali - il numero giusto dipende dal contratto e dal tipo di operazione.

Dal numero all'azione: matrice decisionale

Un'età elevata non è un problema; è un sintomo con più cause. Ciò che lo risolve è leggere il segnale tecnico e classificare prima di agire:

Un caso silenzioso da evidenziare: ticket bloccati in Nuovo perché la regola di business di assegnazione non ha corrisposto alla categoria e non ha mai impostato un gruppo. Invecchiano invisibili - spariscono dai cruscotti per gruppo e riemergono solo quando guardi l'età media senza filtro di gruppo.

Automatizzare la revisione settimanale

Eseguire la query a mano non scala. Salviamo la query di stagnazione in un file .sql e la pianifichiamo nel cron di sistema, leggendo le credenziali da un file .cnf (chmod 600) per non lasciare mai una password sulla riga di comando. Il risultato è un CSV settimanale che diventa l'ordine del giorno della revisione del backlog:

# /etc/cron.d/glpi-idade  ->  ogni lunedì 07:30, come www-data
# Genera l'elenco dei ticket fermi (7+ giorni) per la revisione del backlog
30 7 * * 1 www-data /usr/bin/mysql --defaults-file=/etc/glpi/kpi-ro.cnf glpi \
  < /opt/glpi-kpi/estagnados.sql \
  > /var/log/glpi-kpi/estagnados-$(date +\%Y-\%m-\%d).csv 2>&1

Errori comuni sul campo

• Guardare solo la media: appiattisce la coda. Segui sempre la distribuzione e, quando possibile, la mediana.
• Mescolare In attesa nel calderone: lo stato 4 è un'attesa legittima; da solo alza la media e genera un falso allarme.
• Usare date_mod come ultima azione: le automazioni lo aggiornano. Usa le date di seguito e di attività.
• Confrontare entità con calendari diversi: DATEDIFF conta i giorni di calendario; entità con orari diversi non sono comparabili una a una.
• Dimenticare is_deleted = 0: il cestino di GLPI non esce dalla tabella e contamina qualsiasi media.

Prossimo passo

Combina l'età media con il resto dei tuoi KPI del Service Desk e metti tutto su un cruscotto in Metabase o Grafana con filtri per entità e gruppo. Così l'età smette di essere un numero a fine mese e diventa un allarme che scatta finché c'è ancora tempo di agire.

In NexTool, età e stagnazione del backlog entrano nel report mensile di manutenzione che consegniamo ai clienti, insieme alla lista dei ticket da recuperare. Se vuoi questo monitoraggio sul tuo GLPI, scopri il nostro servizio di supporto e manutenzione.

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