NexTool Solutions

A gestão de incidentes é a prática de ITSM que mais gente julga dominar e a que mais parte na operação real. Na sustentação de ambientes GLPI de clientes, o problema quase nunca é um técnico que não sabe fechar um pedido - é o SLA que estoura sem ninguém ser avisado, a prioridade que alguém alterou à mão e o cron a correr no modo errado. Este guia mostra onde o incidente vive no GLPI, como classificá-lo sem inventar campos, e as armadilhas de terreno que só aparecem ao fim de meses de operação.

Onde o incidente vive no GLPI

Incidente e pedido não são módulos separados: são o mesmo objeto Ticket, na tabela glpi_tickets, distinguidos pela coluna type - 1 para incidente, 2 para pedido. O que muda é o fluxo, o SLA e a leitura de gestão. Segundo a ITIL 4, um incidente é uma interrupção não planeada ou uma redução na qualidade de um serviço, e o objetivo é repor o serviço o mais depressa possível, não descobrir a causa - isso é gestão de problemas.

Todo o incidente percorre uma máquina de estados fixa. Conhecer o código de cada estado importa porque os relatórios, as regras de negócio e o SQL de diagnóstico trabalham com o número, não com o rótulo:

O pormenor que deita abaixo um relatório: o estado Em espera (4) pausa a contagem do SLA quando o configura assim. O técnico que despeja tudo em Em espera para "não estourar o prazo" está a mascarar o indicador, não a melhorar o serviço.

Classificação: a matriz Urgência × Impacto

O GLPI não deixa o técnico escolher a prioridade no vácuo. Ela é calculada pelo cruzamento de dois campos que o requerente e quem faz a triagem preenchem: urgência (a que velocidade o negócio precisa) e impacto (quantos afetados e quão críticos). A matriz está em Configuração > Geral > Assistência e é totalmente editável. Um recorte simplificado da lógica:

O GLPI suporta até cinco níveis de urgência e impacto, mais a prioridade Maior (crítica). A matriz por omissão é simétrica - urgência e impacto pesam por igual. Ajuste os pesos à realidade do cliente: num retalho, um POS em baixo em hora de ponta é urgência máxima, independentemente do número de lojas afetadas.

O fluxo de atendimento, passo a passo

1. Registo: portal self-service, e-mail (coletor), telefone ou integração. As regras de negócio (RuleTicket) classificam categoria, grupo e prioridade automaticamente no item_add.
2. Tomada de conhecimento (primeira resposta): o GLPI grava em takeintoaccount_delay_stat o tempo até à primeira ação do técnico. É o seu SLA de atendimento (TTO - time to own), diferente do SLA de resolução (TTR - time to resolve).
3. Investigação: base de conhecimento, histórico de pedidos semelhantes e CMDB. O módulo AI Assist resume threads longas e sugere soluções a partir da base.
4. Resolução: definitiva (causa corrigida) ou contorno (workaround). Se for um contorno recorrente, associe-o a um Problema - o incidente não "se transforma" em problema, são objetos distintos.
5. Fecho: após confirmação, o pedido passa a Fechado e dispara o inquérito de satisfação.

A armadilha nº 1 da sustentação: o cron no modo errado

É a falha que mais atendemos num ambiente de cliente novo. O SLA está configurado, os níveis de escalonamento estão criados, e mesmo assim ninguém recebe o aviso quando o prazo estoura e os pedidos resolvidos nunca se fecham sozinhos. A causa é quase sempre a mesma: as ações automáticas do GLPI estão em modo GLPI (web), que só corre quando alguém carrega uma página. Num cliente com pouco tráfego fora do horário de expediente, o escalonamento de SLA simplesmente não corre.

A correção é pôr o agendador em modo CLI, despoletado por um cron do sistema operativo. Em cada ação automática (Configuração > Ações automáticas), defina Modo de execução = CLI e adicione a entrada no crontab:

# /etc/cron.d/glpi - executa o agendador do GLPI a cada minuto
# GLPI 10 e 11: front/cron.php e o caminho portavel entre versoes
* * * * * www-data /usr/bin/php /var/www/glpi/front/cron.php >/dev/null 2>&1

Dependem deste cron para funcionar: closeticket (fecha automaticamente o que ficou Resolvido além do prazo), createinquest (gera o inquérito de satisfação) e o escalonamento por nível de SLA. Um pormenor de portabilidade que apanha muita gente: no GLPI 11 não existe o comando de consola glpi:cron que alguns tutoriais de GLPI 10 citam - o caminho que funciona nas duas versões é o front/cron.php acima.

Diagnóstico: encontrar incidentes a estourar o SLA

Quando o cliente diz "o SLA não está a cumprir", o primeiro passo é olhar o dado em bruto, não a dashboard. Este SQL lista incidentes abertos cujo prazo de resolução já passou e assinala os que nunca foram sequer tomados de conhecimento (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,
          'SEM PRIMEIRA RESPOSTA', 'ok') AS atendimento
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)           -- exclui Resolvido e Fechado
  AND t.time_to_resolve IS NOT NULL
  AND t.time_to_resolve < NOW()        -- prazo de resolucao ja estourou
  AND t.solvedate IS NULL
ORDER BY t.time_to_resolve ASC;

Ao correr isto na sustentação, o padrão que mais aparece não é volume elevado de pedidos: é um punhado de incidentes de prioridade alta parados Em espera há dias, com o relógio "em pausa", enquanto o requerente julga que estão a ser tratados.

Uma notificação de escalonamento que o gestor lê mesmo

O modelo de escalonamento por omissão envia um bloco genérico. Um modelo enxuto, com as etiquetas certas, faz o supervisor agir sem abrir o GLPI. As etiquetas ##ticket.*## são resolvidas pelo GLPI no envio:

Assunto: [SLA estourado] Pedido ##ticket.id## - ##ticket.title##

O pedido abaixo ultrapassou o prazo de resolucao.

Titulo:      ##ticket.title##
Categoria:   ##ticket.category##
Prioridade:  ##ticket.priority##
Estado:      ##ticket.status##
Atribuido a: ##ticket.assigntousers##
Prazo (TTR): ##ticket.time_to_resolve##

Abrir o pedido: ##ticket.url##

Erros comuns de terreno

• "Tudo é urgente": quando cada pedido entra como prioridade alta, não tem priorização, tem uma fila cronológica cara. Bloqueie a urgência no formulário guiado e eduque pela matriz.
• Prioridade editada à mão: o técnico que sobrepõe a prioridade calculada parte a leitura do SLA e a matriz. Se precisam de reclassificar sempre, o defeito está na matriz, não no técnico.
• Confundir TTO com TTR: "abri o pedido para ler" já conta como tomada de conhecimento e cumpre o SLA de primeira resposta sem ninguém ter resolvido nada. Meça o TTR (resolução), não só o TTO.
• Um contorno que se torna definitivo: workaround aplicado e pedido fechado, sem Problema aberto - o incidente volta na semana seguinte. Associe os contornos recorrentes a um Problema.

Próximo passo

Com a gestão de incidentes sólida, avance para a gestão de problemas (eliminar a causa raiz) e a gestão de mudanças. Para acelerar a triagem, o módulo Smart Assign distribui incidentes entre técnicos por regras de carga e competência, e o guia de SLA e OLA cobre a configuração de prazos.

Precisa de um GLPI que segura mesmo o SLA? A NexTool faz sustentação de ambientes GLPI de ponta a ponta - da matriz de prioridade ao cron de escalonamento. Conheça o serviço de suporte e sustentação.

Revisto pela equipa NexTool Solutions.