NexTool Solutions

Configurar SLA y OLA en GLPI es la parte fácil - lo que se rompe en la operación real es el escalado que nunca se dispara. En el mantenimiento de entornos GLPI de clientes, la petición que más llega no es "cómo creo un SLA", sino "lo configuré todo y nadie recibe aviso cuando se incumple el plazo". Esta guía configura SLA y OLA en GLPI 11 desde cero y muestra las consultas SQL que usamos para diagnosticar por qué los plazos no notifican.

SLA vs OLA: qué cambia en la práctica

SLA (Service Level Agreement) es el acuerdo con el cliente (interno o externo): define el compromiso de tiempo de respuesta y de resolución. Ejemplo: "los tickets de prioridad alta se responden en 1h y se resuelven en 4h".

OLA (Operational Level Agreement) es el acuerdo interno entre los equipos que sostienen ese SLA. Ejemplo: "infraestructura responde los escalados del N1 en 30 minutos". En GLPI, el SLA graba los plazos en time_to_own y time_to_resolve del ticket; el OLA graba en internal_time_to_own e internal_time_to_resolve. Ambos corren en paralelo - y aquí está el primer malentendido: escalar al N2 NO pausa el SLA del cliente.

Cómo modela GLPI el SLA y el OLA por dentro

Entender el modelo de datos evita la mayoría de los errores de configuración. En GLPI, SLA y OLA no son objetos sueltos: viven dentro de un SLM (Service Level), y es el SLM el que lleva el calendario.

• SLM (glpi_slms): el paraguas. Tiene el calendars_id - es decir, el calendario pertenece al SLM, no a cada SLA.
• SLA (glpi_slas) y OLA (glpi_olas): cada fila es un plazo, con type (TTO o TTR), number_time y definition_time (minute / hour / day).
• Niveles de escalado (glpi_slalevels / glpi_olalevels): las acciones disparadas al X% del plazo.

Dos conceptos que suelen confundir a quien viene de otra herramienta:

TTO - Time to Own (tiempo de respuesta)

Plazo hasta que el ticket es "tomado en cuenta" (asumido por un técnico). Atención: el TTO no se cierra cuando alguien solo abre el ticket en pantalla; se cierra con la primera asignación o el primer seguimiento - es lo que GLPI graba en takeintoaccount_delay_stat.

TTR - Time to Resolve (tiempo de resolución)

Plazo hasta la solución del ticket.

Paso a paso: configurar SLA en GLPI 11

1. El calendario primero. Antes del SLA, define el calendario de atención (Configuración > Calendarios) con los segmentos de jornada reales (ej.: lun-vie, 08:00-18:00). Si el SLM se queda sin calendario (calendars_id = 0), GLPI cuenta 24h corridas; con calendario, cuenta solo horas laborables.
2. Crea el SLM y asocia el calendario. Es el contenedor que agrupa los SLA y OLA del servicio.
3. Crea un SLA por prioridad, uno para TTO y otro para TTR. Usa la matriz de abajo como punto de partida.
4. Asigna mediante regla de negocio (Administración > Reglas > Reglas de negocio para tickets): criterio Prioridad = Alta, acción "Asignar SLA (TTR)" y "Asignar SLA (TTO)". El SLA se aplica en la creación; si la prioridad cambia después, hace falta una regla que recalcule.
5. Configura los niveles de escalado en cada SLA (acciones al 75%, 100% y 150% del plazo).

Son rangos honestos de punto de partida: recalíbralos tras 60-90 días con los números reales de tu Service Desk y nunca copies los plazos de otro cliente.

Configurar OLA

El OLA sigue la misma estructura (TTO/TTR más niveles de escalado), pero mide el compromiso interno entre equipos. El escenario típico: cuando el N1 escala al N2, el OLA del N2 empieza a contar - y GLPI graba esos plazos en internal_time_to_own e internal_time_to_resolve, separados del SLA del cliente. Repitiendo el punto que más dudas genera: el OLA no congela el SLA.

El error común: el escalado que nunca se dispara

En mantenimiento, el ticket recurrente sobre SLA no es de configuración - es "se incumplió el plazo y nadie avisó". En casi todos los casos la causa es la misma: la acción automática slaticket, que recorre los niveles de escalado, está en modo interno (solo se ejecuta cuando alguien navega por GLPI) o el cron externo de GLPI no está activo. El nivel existe, el plazo está grabado en time_to_resolve, pero nada se dispara al 75% porque el proceso que lee los niveles nunca se ejecuta. Por eso, en nuestro checklist de implantación, verificar slaticket va ANTES de crear cualquier nivel de escalado.

Asegura el cron de GLPI ejecutándose en modo externo:

# /etc/cron.d/glpi - ejecuta las acciones automáticas de GLPI (incluye slaticket)
* * * * * www-data /usr/bin/php /var/www/glpi/front/cron.php >/dev/null 2>&1

Después, confirma en la base de datos que la acción está viva y en modo externo:

-- Estado de la acción automática de escalado de SLA.
-- mode:  1 = interno (malo, depende de la navegación), 2 = externo (correcto)
-- state: 1 = en espera, 2 = ejecutándose, 0 = deshabilitado
SELECT name, state, mode, lastrun, frequency
FROM glpi_crontasks
WHERE name = 'slaticket';

Y la consulta que ejecutamos a diario en mantenimiento: tickets con plazo de resolución ya incumplido y aún abiertos.

-- Tickets con TTR vencido y aún no resueltos.
-- status: 5 = resuelto, 6 = cerrado (excluidos)
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;

Para auditar la configuración (y pillar el SLM sin calendario antes de que rompa los plazos):

-- SLAs configurados y el calendario heredado del SLM.
-- calendario NULL/vacío = conteo 24h corridas (la trampa clásica).
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;

Buenas prácticas de quien opera

• Empieza con 3-5 niveles y recalibra tras 60-90 días con datos reales.
• Calendario realista: no configures 24x7 si el equipo atiende en horario comercial - si no, el plazo "corre" de madrugada y el ticket nace ya incumplido.
• Avisa antes del incumplimiento (75%) para dar tiempo de reacción, no solo en el incumplimiento.
• Nunca edites estados o plazos en masa vía SQL: te saltas el recálculo del tiempo de espera (sla_waiting_duration) y el plazo queda mal.
• Documenta qué regla de negocio asigna cada SLA - una regla huérfana es la segunda mayor causa de "SLA no aplicado".

Siguiente paso

Con SLA y OLA en marcha, monta tu catálogo de servicios y sigue los KPIs del Service Desk para saber si los plazos son realistas.

Si tu operación ya creció y el SLA se vuelve una discusión semanal, el servicio de mantenimiento de GLPI de NexTool asume la configuración, el cron y la supervisión de los plazos por ti.

Revisado por el equipo de NexTool Solutions.