NexTool Solutions

Visibilidade não é ter mais relatórios - é ver o estado da fila enquanto ainda é possível agir. O GLPI já guarda tudo o que precisa; o problema é que o dado está espalhado e o painel nativo só mostra o passado. Este guia mostra onde vive a visibilidade real no GLPI, que consultas de diagnóstico corremos quando assumimos a manutenção de um ambiente, como antecipar o incumprimento de um SLA antes de acontecer e como transformar tudo isto num alerta automático.

A visibilidade que o GLPI já lhe dá - e onde ela para

O GLPI vem com painéis (dashboards) na Central e uma pesquisa com filtros poderosa. Para o dia a dia, isso resolve muita coisa: contagens por estado, por técnico, por categoria. O limite aparece em três pontos:

• É a pedido, não proativo. O painel só atualiza quando alguém abre o ecrã. Ninguém é avisado quando se forma um estrangulamento - tem de ir ver.
• Conta o que o seu perfil consegue ver. O número no painel depende da entidade e do perfil de quem tem a sessão iniciada. O coordenador de uma entidade e o administrador global veem totais diferentes da mesma fila.
• Mostra o agregado, não o chamado esquecido. "42 chamados abertos" não diz qual está parado há 20 dias.

Visibilidade a sério começa quando deixa de olhar para o total e passa a olhar para a forma da fila e para o que está prestes a correr mal.

Passo 1: para onde vai o backlog

Antes de qualquer painel bonito, a primeira radiografia é a distribuição do backlog por grupo e estado. Tudo vive em glpi_tickets; a atribuição a grupo, em glpi_groups_tickets (tipo 2 = atribuído). Os estados que importam: 1 Novo, 2/3 Em curso, 4 Pendente, 5 Resolvido, 6 Fechado.

-- Backlog aberto por grupo atribuído (type 2 = atribuído)
SELECT
  g.completename                    AS grupo,
  COUNT(*)                          AS abertos,
  SUM(t.status = 1)                 AS novos_sem_triagem,
  SUM(t.status = 4)                 AS pendentes
FROM glpi_tickets t
JOIN glpi_groups_tickets gt
     ON gt.tickets_id = t.id AND gt.type = 2
JOIN glpi_groups g ON g.id = gt.groups_id
WHERE t.status NOT IN (5, 6)
  AND t.is_deleted = 0
GROUP BY g.id
ORDER BY abertos DESC;

Em segundos vê qual grupo está sobrecarregado e quanto do backlog são chamados novos que ninguém triou - o número que o painel nativo esconde atrás do total.

Passo 2: o SLA que vai falhar antes de falhar

Aqui mora a diferença entre uma operação que reage e uma que antecipa. Quando um SLA corresponde ao chamado, o GLPI grava o prazo em colunas próprias de glpi_tickets: time_to_resolve (prazo de resolução) e time_to_own (prazo de atribuição). Isto é um relógio - dá para ver o que expira nas próximas horas, não só o que já expirou:

-- Chamados abertos com SLA de resolução a expirar nas próximas 4h
SELECT
  t.id,
  t.name,
  t.time_to_resolve,
  TIMESTAMPDIFF(MINUTE, NOW(), t.time_to_resolve) AS minutos_restantes
FROM glpi_tickets t
WHERE t.status NOT IN (4, 5, 6)        -- exceto Pendente, Resolvido, Fechado
  AND t.is_deleted = 0
  AND t.time_to_resolve IS NOT NULL
  AND t.time_to_resolve > NOW()
  AND t.time_to_resolve <= NOW() + INTERVAL 4 HOUR
ORDER BY t.time_to_resolve ASC;

A armadilha de campo está nesse IS NOT NULL. A coluna time_to_resolve só é preenchida quando uma regra de SLA correspondeu ao chamado na abertura. Um chamado que não bateu com nenhuma regra fica com o prazo NULL - e desaparece silenciosamente do painel de risco. Ou seja: os chamados sem SLA, justamente os que ninguém está a medir, são invisíveis para qualquer alerta baseado em prazo. Ao assumir um ambiente, a primeira contagem que corremos é quantos abertos têm time_to_resolve IS NULL. Já vimos um cliente com 60% do backlog sem qualquer SLA associado: o painel dizia "tudo dentro do prazo" porque metade da fila simplesmente não tinha prazo.

Passo 3: o responsável que não existe

Outro ponto cego clássico: chamado atribuído só a um grupo, sem técnico nomeado. No ecrã parece atribuído; na prática, ninguém se sente responsável. Esses chamados desaparecem dos painéis pessoais ("os meus chamados") e envelhecem invisíveis. A atribuição a pessoa vive em glpi_tickets_users com type = 2:

-- Abertos atribuídos a grupo mas SEM técnico responsável nomeado
SELECT COUNT(*) AS sem_responsavel
FROM glpi_tickets t
WHERE t.status NOT IN (5, 6)
  AND t.is_deleted = 0
  AND NOT EXISTS (
    SELECT 1 FROM glpi_tickets_users tu
    WHERE tu.tickets_id = t.id AND tu.type = 2
  );

As camadas de visibilidade: o que usar para quê

Não existe uma ferramenta única. Cada camada resolve um problema e tem um limite. É assim que decidimos onde colocar cada indicador:

Passo 4: transformar o diagnóstico em alerta automático

Correr a consulta à mão não escala e, pior, depende de alguém se lembrar de olhar. Duas formas de fechar esse ciclo no GLPI:

1. Nativo, sem infraestrutura extra: guarde a pesquisa de "SLA a expirar" ou "pendentes há mais de 7 dias" e crie um alerta de pesquisa guardada. O cron do GLPI corre a pesquisa periodicamente e dispara um e-mail quando a contagem cruza o limite que definir.
2. Fora do GLPI, para ecrã de parede e histórico: agende a consulta de diagnóstico no cron do sistema, lendo a credencial de um ficheiro .cnf (chmod 600) para nunca deixar a palavra-passe na linha de comandos.

# /etc/cron.d/glpi-visibilidade  ->  a cada hora útil, como www-data
# Lista chamados com SLA a expirar nas próximas 4h para o turno de piquete
0 8-18 * * 1-5 www-data /usr/bin/mysql --defaults-file=/etc/glpi/kpi-ro.cnf glpi \
  < /opt/glpi-kpi/sla-a-expirar.sql \
  > /var/log/glpi-kpi/sla-risco-$(date +\%Y-\%m-\%d-\%H).csv 2>&1

Antes de agendar, garanta que o próprio cron do GLPI está mesmo a correr em modo externo (o cron do sistema a chamar front/cron.php) - senão os prazos de SLA e os alertas nativos nem sequer são recalculados, e estaria a ler um relógio parado.

A viragem, na prática da manutenção

Quando assumimos o GLPI de um cliente, a primeira radiografia nunca é o painel nativo - é a contagem de chamados atribuídos só a grupo (sem responsável) e de chamados com time_to_resolve nulo. Num caso, 40% do backlog estava "atribuído" a um grupo de oito pessoas e ninguém se sentia responsável; nenhum desses chamados aparecia num painel pessoal e o mais antigo tinha 90 dias. A correção não foi um painel novo - foi uma regra de negócio a forçar um técnico nomeado na atribuição, mais um alerta de SLA a 4 horas de expirar. A visibilidade não veio de comprar uma ferramenta; veio de olhar para os campos certos.

Erros comuns de campo

• Confiar no total do painel: agrega e esconde o chamado parado; olhe para a distribuição por grupo e por antiguidade.
• Achar que todo o chamado tem SLA: time_to_resolve NULL = fora de qualquer alerta de prazo. Conte primeiro os que não têm SLA.
• Tratar "atribuído a grupo" como "tem responsável": sem um registo em glpi_tickets_users com type = 2, ninguém é responsável.
• Comparar entidades pelo mesmo número: o painel nativo já filtra por perfil e entidade; o total muda consoante quem tem a sessão iniciada.
• Esquecer is_deleted = 0: a reciclagem do GLPI não sai da tabela e contamina qualquer contagem.
• Medir com o cron parado: sem o cron externo a correr, o SLA e os alertas nativos não atualizam.

Próximo passo

Comece pelas três contagens deste guia (sem responsável, sem SLA, SLA a expirar), leve esses recortes para um painel no Metabase ou Grafana e ligue os seus KPIs de Service Desk a alertas. Assim a fila deixa de ser um número no fim do mês e passa a ser um sinal que dispara enquanto ainda há tempo de agir.

Na NexTool, esta radiografia de visibilidade é o primeiro entregável quando assumimos a manutenção de um GLPI: mapeamos os pontos cegos, ligamos os alertas e entregamos o painel. Se quiser este acompanhamento no seu ambiente, conheça o nosso serviço de suporte e manutenção.

Este conteúdo foi produzido com o apoio de inteligência artificial e revisto pela equipa Nextool Solutions.