NexTool Solutions

Configurare SLA e OLA in GLPI è la parte facile - ciò che si rompe nell'operatività reale è l'escalation che non scatta mai. Nella manutenzione di ambienti GLPI dei clienti, la richiesta più frequente non è "come creo uno SLA", ma "ho configurato tutto e nessuno viene avvisato quando la scadenza salta". Questa guida configura SLA e OLA in GLPI 11 da zero e mostra le query SQL che usiamo per diagnosticare perché le scadenze non notificano.

SLA vs OLA: cosa cambia in pratica

SLA (Service Level Agreement) è l'accordo con il cliente (interno o esterno): definisce l'impegno sui tempi di risposta e di risoluzione. Esempio: "i ticket ad alta priorità vengono presi in carico in 1h e risolti in 4h".

OLA (Operational Level Agreement) è l'accordo interno tra i team che sostengono quello SLA. Esempio: "l'infrastruttura risponde alle escalation del L1 entro 30 minuti". In GLPI, lo SLA scrive le scadenze in time_to_own e time_to_resolve del ticket; l'OLA scrive in internal_time_to_own e internal_time_to_resolve. I due corrono in parallelo - e qui sta il primo equivoco: fare escalation al L2 NON mette in pausa lo SLA del cliente.

Come GLPI modella SLA e OLA internamente

Capire il modello dati evita la maggior parte degli errori di configurazione. In GLPI, SLA e OLA non sono oggetti a sé: vivono dentro un SLM (Service Level), ed è lo SLM a portare il calendario.

• SLM (glpi_slms): l'ombrello. Porta il calendars_id - quindi il calendario appartiene allo SLM, non al singolo SLA.
• SLA (glpi_slas) e OLA (glpi_olas): ogni riga è una scadenza, con type (TTO o TTR), number_time e definition_time (minute / hour / day).
• Livelli di escalation (glpi_slalevels / glpi_olalevels): le azioni scatenate all'X% della scadenza.

Due concetti che confondono spesso chi arriva da un altro strumento:

TTO - Time to Own (tempo di risposta)

Tempo entro cui il ticket viene "preso in carico" (assunto da un tecnico). Attenzione: il TTO non si chiude quando qualcuno apre semplicemente il ticket a schermo; si chiude alla prima assegnazione o al primo follow-up - è ciò che GLPI registra in takeintoaccount_delay_stat.

TTR - Time to Resolve (tempo di risoluzione)

Tempo entro cui il ticket viene risolto.

Passo dopo passo: configurare lo SLA in GLPI 11

1. Prima il calendario. Prima dello SLA, definisci il calendario di servizio (Configurazione > Calendari) con le fasce orarie reali (es.: lun-ven, 08:00-18:00). Se lo SLM resta senza calendario (calendars_id = 0), GLPI conta 24h di fila; con il calendario, conta solo le ore lavorative.
2. Crea lo SLM e associa il calendario. È il contenitore che raggruppa gli SLA e gli OLA del servizio.
3. Crea uno SLA per priorità, uno per il TTO e uno per il TTR. Usa la matrice qui sotto come punto di partenza.
4. Assegna tramite regola di business (Amministrazione > Regole > Regole di business per i ticket): criterio Priorità = Alta, azione "Assegna SLA (TTR)" e "Assegna SLA (TTO)". Lo SLA viene applicato alla creazione; se la priorità cambia dopo, serve una regola che ricalcoli.
5. Configura i livelli di escalation in ogni SLA (azioni al 75%, 100% e 150% della scadenza).

Sono fasce oneste di partenza: ricalibra dopo 60-90 giorni con i numeri reali del tuo Service Desk e non copiare mai le scadenze da un altro cliente.

Configurare l'OLA

L'OLA segue la stessa struttura (TTO/TTR più livelli di escalation), ma misura l'impegno interno tra i team. Lo scenario tipico: quando il L1 fa escalation al L2, l'OLA del L2 inizia a contare - e GLPI registra quelle scadenze in internal_time_to_own e internal_time_to_resolve, separate dallo SLA del cliente. Ripetendo il punto che genera più dubbi: l'OLA non congela lo SLA.

L'errore comune: l'escalation che non scatta mai

In manutenzione, il ticket ricorrente sullo SLA non riguarda la configurazione - è "la scadenza è saltata e nessuno è stato avvisato". In quasi tutti i casi la causa è la stessa: l'azione automatica slaticket, che scorre i livelli di escalation, è in modalità interna (gira solo quando qualcuno naviga in GLPI) oppure il cron esterno di GLPI non è attivo. Il livello esiste, la scadenza è registrata in time_to_resolve, ma nulla scatta al 75% perché il processo che legge i livelli non viene mai eseguito. Per questo, nella nostra checklist di implementazione, verificare slaticket viene PRIMA di creare qualsiasi livello di escalation.

Assicurati che il cron di GLPI giri in modalità esterna:

# /etc/cron.d/glpi - esegue le azioni automatiche di GLPI (incluso slaticket)
* * * * * www-data /usr/bin/php /var/www/glpi/front/cron.php >/dev/null 2>&1

Poi verifica nel database che l'azione sia viva e in modalità esterna:

-- Stato dell'azione automatica di escalation dello SLA.
-- mode:  1 = interna (male, dipende dalla navigazione), 2 = esterna (corretta)
-- state: 1 = in attesa, 2 = in esecuzione, 0 = disabilitata
SELECT name, state, mode, lastrun, frequency
FROM glpi_crontasks
WHERE name = 'slaticket';

E la query che eseguiamo ogni giorno in manutenzione: ticket con scadenza di risoluzione già saltata e ancora aperti.

-- Ticket con TTR scaduto e non ancora risolti.
-- status: 5 = risolto, 6 = chiuso (esclusi)
SELECT t.id, t.name, t.time_to_resolve, t.status
FROM glpi_tickets t
WHERE t.time_to_resolve IS NOT NULL
  AND t.time_to_resolve < NOW()
  AND t.status NOT IN (5, 6)
  AND t.solvedate IS NULL
ORDER BY t.time_to_resolve ASC;

Per verificare la configurazione (e beccare lo SLM senza calendario prima che rompa le scadenze):

-- SLA configurati e il calendario ereditato dallo SLM.
-- calendario NULL/vuoto = conteggio 24h di fila (la trappola classica).
SELECT s.name AS sla,
       CASE s.type WHEN 1 THEN 'TTO' WHEN 0 THEN 'TTR' END AS tipo,
       s.number_time, s.definition_time,
       cal.name AS calendario
FROM glpi_slas s
JOIN glpi_slms slm ON slm.id = s.slms_id
LEFT JOIN glpi_calendars cal ON cal.id = slm.calendars_id
ORDER BY s.name;

Buone pratiche di chi opera

• Parti con 3-5 livelli e ricalibra dopo 60-90 giorni con dati reali.
• Calendario realistico: non configurare 24x7 se il team lavora in orario d'ufficio - altrimenti la scadenza "corre" di notte e il ticket nasce già scaduto.
• Avvisa prima della violazione (75%) per dare tempo di reagire, non solo alla violazione.
• Non modificare mai stati o scadenze in massa via SQL: aggiri il ricalcolo del tempo di attesa (sla_waiting_duration) e la scadenza resta sbagliata.
• Documenta quale regola di business assegna ogni SLA - una regola orfana è la seconda causa di "SLA non applicato".

Prossimo passo

Con SLA e OLA attivi, costruisci il tuo catalogo dei servizi e monitora i KPI del Service Desk per capire se le scadenze sono realistiche.

Se la tua operatività è cresciuta e lo SLA diventa una discussione settimanale, il servizio di manutenzione GLPI di NexTool assume la configurazione, il cron e il monitoraggio delle scadenze per te.

Revisionato dal team NexTool Solutions.