NexTool Solutions

La gestión de incidentes es la práctica de ITSM que más gente cree dominar y la que más se rompe en la operación real. En el soporte de entornos GLPI de clientes, el problema casi nunca es un técnico que no sabe cerrar un ticket: es el SLA que se incumple sin que nadie se entere, la prioridad que alguien editó a mano y el cron corriendo en el modo equivocado. Esta guía muestra dónde vive el incidente en GLPI, cómo clasificarlo sin inventar campos y las trampas de campo que solo aparecen tras meses operando.

Dónde vive el incidente en GLPI

Incidente y solicitud no son módulos separados: son el mismo objeto Ticket, en la tabla glpi_tickets, diferenciados por la columna type - 1 para incidente, 2 para solicitud. Lo que cambia es el flujo, el SLA y la lectura gerencial. Según ITIL 4, un incidente es una interrupción no planificada o una reducción en la calidad de un servicio, y el objetivo es restaurar el servicio lo más rápido posible, no hallar la causa: eso es gestión de problemas.

Todo incidente recorre una máquina de estados fija. Conocer el código de cada estado importa porque los informes, las reglas de negocio y el SQL de diagnóstico trabajan con el número, no con la etiqueta:

El detalle que arruina un informe: el estado En espera (4) pausa el conteo del SLA cuando lo configuras así. El técnico que lanza todo a En espera para "no incumplir el plazo" enmascara el indicador, no mejora el servicio.

Clasificación: la matriz Urgencia × Impacto

GLPI no deja que el técnico elija la prioridad en el vacío. Se calcula cruzando dos campos que el solicitante y quien triaja informan: urgencia (qué tan rápido lo necesita el negocio) e impacto (cuántos afectados y qué tan críticos). La matriz está en Configuración > General > Asistencia y es totalmente editable. Un recorte simplificado de la lógica:

GLPI admite hasta cinco niveles de urgencia e impacto, más la prioridad Mayor (crítica). La matriz por defecto es simétrica: urgencia e impacto pesan igual. Ajusta los pesos a la realidad del cliente: en retail, un TPV caído en hora pico es urgencia máxima, sin importar cuántas tiendas se vean afectadas.

El flujo de atención, paso a paso

1. Registro: portal de autoservicio, correo (colector), teléfono o integración. Las reglas de negocio (RuleTicket) clasifican categoría, grupo y prioridad automáticamente en el item_add.
2. Take into account (primera respuesta): GLPI guarda en takeintoaccount_delay_stat el tiempo hasta la primera acción del técnico. Es tu SLA de atención (TTO - time to own), distinto del SLA de resolución (TTR - time to resolve).
3. Investigación: base de conocimiento, historial de tickets similares y CMDB. El módulo AI Assist resume hilos largos y sugiere soluciones desde la base.
4. Resolución: definitiva (causa corregida) o solución alterna (workaround). Si es una solución alterna recurrente, vincúlala a un Problema: el incidente no "se convierte" en problema, son objetos distintos.
5. Cierre: tras la confirmación, el ticket pasa a Cerrado y dispara la encuesta de satisfacción.

La trampa nº 1 del soporte: el cron en el modo equivocado

Es la falla que más atendemos en un entorno de cliente nuevo. El SLA está configurado, los niveles de escalado están creados, y aun así nadie recibe el aviso cuando el plazo se incumple y los tickets resueltos nunca se cierran solos. La causa es casi siempre la misma: las acciones automáticas de GLPI están en modo GLPI (web), que solo se ejecuta cuando alguien carga una página. En un cliente con poco tráfico fuera del horario laboral, el escalado de SLA simplemente no corre.

La corrección es poner el planificador en modo CLI, disparado por un cron del sistema operativo. En cada acción automática (Configuración > Acciones automáticas), define Modo de ejecución = CLI y añade la entrada en el crontab:

# /etc/cron.d/glpi - ejecuta el planificador de GLPI cada minuto
# GLPI 10 y 11: front/cron.php es la ruta portable entre versiones
* * * * * www-data /usr/bin/php /var/www/glpi/front/cron.php >/dev/null 2>&1

Dependen de este cron para funcionar: closeticket (cierra automáticamente lo que quedó Resuelto pasado el plazo), createinquest (genera la encuesta de satisfacción) y el escalado por nivel de SLA. Un detalle de portabilidad que atrapa a muchos: en GLPI 11 no existe el comando de consola glpi:cron que citan algunos tutoriales de GLPI 10; la ruta que funciona en ambas versiones es el front/cron.php de arriba.

Diagnóstico: hallar incidentes que incumplen el SLA

Cuando el cliente dice "el SLA no está cumpliendo", el primer paso es mirar el dato crudo, no el panel. Este SQL lista incidentes abiertos cuyo plazo de resolución ya venció y marca los que ni siquiera se han tomado en cuenta (takeintoaccount_delay_stat = 0):

SELECT t.id,
       t.name AS titulo,
       c.completename AS categoria,
       t.priority,
       t.time_to_resolve,
       IF(t.takeintoaccount_delay_stat = 0,
          'SIN PRIMERA RESPUESTA', 'ok') AS atencion
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)           -- excluye Resuelto y Cerrado
  AND t.time_to_resolve IS NOT NULL
  AND t.time_to_resolve < NOW()        -- el plazo de resolucion ya vencio
  AND t.solvedate IS NULL
ORDER BY t.time_to_resolve ASC;

Ejecutando esto en soporte, el patrón que más aparece no es un alto volumen de tickets: es un puñado de incidentes de alta prioridad detenidos En espera desde hace días, con el reloj "pausado", mientras el solicitante cree que se están atendiendo.

Una notificación de escalado que el gerente sí lee

La plantilla de escalado por defecto envía un bloque genérico. Un modelo escueto, con las etiquetas correctas, hace que el supervisor actúe sin abrir GLPI. Las etiquetas ##ticket.*## las resuelve GLPI al enviar:

Asunto: [SLA incumplido] Ticket ##ticket.id## - ##ticket.title##

El ticket de abajo supero su plazo de resolucion.

Titulo:      ##ticket.title##
Categoria:   ##ticket.category##
Prioridad:   ##ticket.priority##
Estado:      ##ticket.status##
Asignado a:  ##ticket.assigntousers##
Plazo (TTR): ##ticket.time_to_resolve##

Abrir el ticket: ##ticket.url##

Errores comunes de campo

• "Todo es urgente": cuando cada ticket entra como prioridad alta, no tienes priorización, tienes una cola cronológica cara. Bloquea la urgencia en el formulario guiado y educa con la matriz.
• Prioridad editada a mano: el técnico que sobrescribe la prioridad calculada rompe la lectura del SLA y la matriz. Si siempre necesitan reclasificar, el defecto está en la matriz, no en el técnico.
• Confundir TTO con TTR: "abrí el ticket para leerlo" ya cuenta como take into account y cumple el SLA de primera respuesta sin que nadie haya resuelto nada. Mide el TTR (resolución), no solo el TTO.
• Una solución alterna que se vuelve permanente: workaround aplicado y ticket cerrado, sin Problema abierto: el incidente vuelve la semana siguiente. Vincula las soluciones alternas recurrentes a un Problema.

Siguiente paso

Con la gestión de incidentes sólida, avanza a gestión de problemas (eliminar la causa raíz) y gestión de cambios. Para acelerar el triaje, el módulo Smart Assign distribuye incidentes entre técnicos por reglas de carga y competencia, y la guía de SLA y OLA cubre la configuración de plazos.

¿Necesitas un GLPI que de verdad sostenga el SLA? NexTool da soporte a entornos GLPI de punta a punta, desde la matriz de prioridad hasta el cron de escalado. Conoce nuestro servicio de soporte y mantenimiento.

Revisado por el equipo de NexTool Solutions.