NexTool Solutions

O tempo médio de resolução mede quem já saiu da fila. A idade média dos pedidos mede quem ainda está nela - e é aí que mora o backlog esquecido. Este guia mostra de onde sai o número no GLPI, porque a média sozinha engana, como separar idade de estagnação e como transformar isso numa rotina semanal de revisão de backlog nos ambientes que mantemos.

O que a idade média mede - e o que esconde

A idade média dos pedidos é a média de dias entre a abertura e hoje, considerando apenas os pedidos que continuam em aberto. Ao contrário do TMR, que só vê o que já foi resolvido, ela fotografa o estado atual da fila. O problema é que a média, sozinha, é um péssimo resumo de uma fila real: um backlog típico é bimodal - dezenas de pedidos novos com poucas horas de vida convivem com uma cauda de pedidos parados há semanas. A massa de pedidos novos puxa a média para baixo e esconde justamente os antigos, que são o que precisa de encontrar. Por isso a média nunca anda sozinha: vem acompanhada da distribuição e da mediana.

De onde sai o número no GLPI

Tudo vive na tabela glpi_tickets. A idade usa a coluna date (data de abertura); o recorte de "em aberto" usa status. Os estados que importam:

• 1 - Novo (ainda não triado)
• 2 - Em curso (atribuído)
• 3 - Em curso (planeado)
• 4 - Pendente (a aguardar terceiro)
• 5 - Resolvido e 6 - Fechado (fora do backlog)

O erro mais comum aqui é juntar tudo o que não é 5 nem 6 no mesmo saco. Pedidos em Pendente (estado 4) estão legitimamente parados a aguardar um fornecedor, o cliente ou uma peça - inflacionam a idade média sem que ninguém se tenha esquecido de nada. Segmentar por estado é o primeiro filtro honesto:

-- Idade média por estado (segmentar: "Pendente" inflaciona a média)
SELECT
  status,
  ROUND(AVG(DATEDIFF(NOW(), date)), 1) AS dias_idade_media,
  COUNT(*)                             AS total
FROM glpi_tickets
WHERE status NOT IN (5, 6)   -- fora Resolvido e Fechado
  AND is_deleted = 0
GROUP BY status
ORDER BY dias_idade_media DESC;
-- estado: 1 Novo, 2 atribuído, 3 planeado, 4 Pendente

Idade não é o mesmo que estagnação

Um pedido aberto há 40 dias mas com uma tarefa registada ontem é muito diferente de um aberto há 40 dias sem ninguém tocar. A idade (desde a abertura) mede antiguidade; a estagnação (desde a última ação humana) mede abandono - e é a estagnação que aponta o pedido esquecido.

Na manutenção, o erro que já vimos custar caro foi usar date_mod como "última ação". A coluna date_mod do pedido é atualizada por qualquer coisa: uma notificação enviada, um seguidor adicionado, o cron de SLA a recalcular o prazo, uma regra de negócio a disparar. Ou seja, dá a ilusão de movimento em pedidos que ninguém trabalhou de facto. A última ação humana real está no seguimento e na tarefa - glpi_itilfollowups e glpi_tickettasks. Quando trocámos date_mod pela data máxima dessas duas tabelas, a lista de estagnados de um cliente saltou de 3 para 17 pedidos: os outros 14 pareciam vivos só porque uma automação lhes tocava todos os dias.

-- Estagnação real: dias desde a última interação humana
-- date_mod não serve (notificações, seguidores e cron atualizam-no)
SELECT
  t.id,
  t.name,
  DATEDIFF(NOW(), t.date) AS dias_idade,
  DATEDIFF(NOW(), GREATEST(
      t.date,
      COALESCE(MAX(f.date), t.date),
      COALESCE(MAX(k.date), t.date)
  ))                       AS dias_parado
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)   -- fora Pendente, Resolvido, Fechado
  AND t.is_deleted = 0
GROUP BY t.id, t.name, t.date
HAVING dias_parado >= 7
ORDER BY dias_parado DESC;

Distribuição, não só a média

Antes de reagir a uma média que subiu, veja a forma da fila. A consulta abaixo divide o backlog em faixas de idade e revela a cauda longa que a média achata:

-- Distribuição do backlog por faixa de idade
SELECT
  CASE
    WHEN DATEDIFF(NOW(), date) <= 3  THEN '0-3 dias'
    WHEN DATEDIFF(NOW(), date) <= 7  THEN '3-7 dias'
    WHEN DATEDIFF(NOW(), date) <= 15 THEN '7-15 dias'
    WHEN DATEDIFF(NOW(), date) <= 30 THEN '15-30 dias'
    ELSE '30+ dias'
  END        AS faixa,
  COUNT(*)   AS pedidos
FROM glpi_tickets
WHERE status NOT IN (4, 5, 6)
  AND is_deleted = 0
GROUP BY faixa
ORDER BY MIN(DATEDIFF(NOW(), date));

Como referência honesta de faixa (dias de calendário, não dias úteis): abaixo de 3 dias é saudável, 3 a 7 dias é aceitável, 7 a 15 dias liga o alerta e acima de 15 dias pede revisão pedido a pedido. Não são metas universais - o número justo depende do contrato e do tipo de operação.

Do número à ação: matriz de decisão

Idade alta não é um problema; é um sintoma com várias causas. O que resolve é ler o sinal técnico e classificar antes de agir:

Um caso silencioso que vale a pena destacar: pedidos presos em Novo porque a regra de negócio de atribuição não correspondeu à categoria e nunca colocou um grupo. Envelhecem invisíveis - desaparecem dos painéis por grupo e só aparecem quando olha a idade média sem filtro de grupo.

Automatizar a revisão semanal

Correr a consulta à mão não escala. Guardamos a consulta de estagnação num ficheiro .sql e agendamos no cron do sistema, lendo as credenciais de um ficheiro .cnf (chmod 600) para nunca deixar a palavra-passe na linha de comandos. O resultado é um CSV semanal que se torna a agenda da revisão de backlog:

# /etc/cron.d/glpi-idade  ->  toda segunda 07:30, como www-data
# Gera a lista de pedidos estagnados (7+ dias) para a revisão do 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

Erros comuns de campo

• Olhar só para a média: ela achata a cauda. Acompanhe sempre a distribuição e, quando possível, a mediana.
• Misturar Pendente no saco: o estado 4 é uma espera legítima; sozinho levanta a média e gera alarme falso.
• Usar date_mod como última ação: as automações atualizam-no. Use as datas de seguimento e de tarefa.
• Comparar entidades com calendários diferentes: DATEDIFF conta dias de calendário; entidades com horários distintos não são comparáveis uma a uma.
• Esquecer is_deleted = 0: a reciclagem do GLPI não sai da tabela e contamina qualquer média.

Próximo passo

Combine a idade média com os restantes KPIs de Service Desk e monte tudo num painel no Metabase ou Grafana com filtro por entidade e grupo. Assim a idade deixa de ser um número no fim do mês e passa a ser um alerta que dispara enquanto ainda dá para agir.

Na NexTool, idade e estagnação do backlog entram no relatório mensal de manutenção que entregamos aos clientes, junto com a lista de pedidos a recuperar. Se quiser esse acompanhamento no seu GLPI, conheça o nosso serviço de suporte e manutenção.

Este conteúdo foi produzido com auxílio de inteligência artificial e revisto pela equipa Nextool Solutions.