NexTool Solutions

Gestão de problemas é o que separa uma operação que apaga o mesmo incêndio toda semana de uma que o elimina de vez. Na sustentação de ambientes GLPI de clientes, o padrão que mais vemos não é falta de processo, é o problema aberto, contornado e marcado como Resolvido no mesmo dia - fechando o ciclo antes de a causa raiz ser documentada. Este guia mostra onde cada informação do problema mora no GLPI, como classificar sem inventar um campo que não existe, e as armadilhas que fazem a investigação se perder.

Incidente vs problema: a diferença está no dado, não só no discurso

A confusão clássica do ITSM é achar que "o incidente vira problema". No GLPI eles nem compartilham a mesma tabela: o incidente vive em glpi_tickets, o problema em glpi_problems, cada um com sua própria máquina de estados. São objetos distintos com objetivos opostos:

• Incidente: restaurar o serviço o mais rápido possível. É curativo e tem SLA de resolução.
• Problema: encontrar e eliminar a causa raiz para que o incidente não volte. É preventivo e vive em outro ritmo.

Exemplo de campo: o servidor de e-mail cai toda segunda. Cada queda é um incidente resolvido reiniciando o serviço. A investigação que descobre que o backup semanal esgota a memória e derruba o serviço é o problema. Fechar os incidentes sem abrir o problema garante que a segunda-feira seguinte terá o mesmo chamado.

A seção Análise: onde a causa raiz realmente mora

O que diferencia o formulário de problema do de um chamado comum é a seção Análise, que grava em três colunas de texto dedicadas de glpi_problems (expostas nas opções de busca 60, 61 e 62):

• impactcontent - Impactos: o que o problema afeta enquanto não for resolvido.
• causecontent - Causas: aqui mora a causa raiz. É o campo mais importante do processo inteiro.
• symptomcontent - Sintomas: como o problema se manifesta para quem abre incidente.

A armadilha de campo mais comum que encontramos: a seção Análise vem recolhida no formulário. O técnico preenche título e descrição, registra o contorno na timeline e nunca abre a seção - então causecontent fica vazio. Resultado: seis meses depois, ninguém sabe por que aquele problema foi aberto nem o que se descobriu. A causa raiz que não vai para causecontent não vira base de conhecimento, vira boato.

Incidente, problema ou mudança: matriz de decisão

Antes de abrir qualquer registro, o time precisa saber o que está abrindo. Esta é a matriz que usamos na triagem:

Repare que problema e mudança não competem: o fluxo maduro é problema (descobre a causa) - mudança (implementa a correção) - base de conhecimento (documenta), tudo encadeado.

Vinculando os incidentes: a aba Tickets e o tipo de vínculo

O que dá corpo a um problema são os incidentes ligados a ele. No formulário do problema, a aba Tickets associa os chamados relacionados, gravando na tabela glpi_problems_tickets. O detalhe que quase todo mundo ignora: o vínculo tem tipo. Ligar como "Vinculado a" é diferente de ligar como "Duplicado", e isso muda a leitura dos relatórios de recorrência. Padronize o tipo de vínculo no time, senão a contagem de incidentes por problema fica sem sentido - foi um dos primeiros ajustes que fizemos em ambientes que herdamos sem governança.

O ciclo de vida e a armadilha do "Resolvido" cedo demais

O problema tem sua própria máquina de estados na coluna status de glpi_problems, e ela não é igual à da mudança. Os estados que o problema realmente usa são:

1. Novo (1) - registrado, ainda sem investigação.
2. Aceito (7) - triado e assumido pela equipe.
3. Em processamento / atribuído (2) e planejado (3) - investigação em andamento.
4. Em espera (4) - aguardando terceiro, fornecedor ou janela.
5. Em observação (8) - contorno aplicado, monitorando se a causa foi mesmo eliminada.
6. Resolvido (5) e Fechado (6) - causa eliminada e ciclo encerrado.

Aqui está o erro comum que mais custa caro: aplicar o contorno e marcar o problema como Resolvido no mesmo dia. Resolvido significa "a causa raiz acabou", mas um contorno não elimina causa nenhuma - só esconde o sintoma. Na sustentação passamos a usar o status Em observação (8) exatamente para isso: o contorno está de pé, o problema continua vivo no painel, e só movemos para Resolvido depois de a correção definitiva entrar e passar um período sem reincidência. Fechar cedo demais é como declarar vitória com o incêndio ainda fumegando atrás da parede.

Contorno, solução definitiva e a ponte para a mudança

Um problema carrega dois desfechos que não podem ser confundidos:

• Contorno (workaround): restaura o serviço sem tocar na causa. Documente na timeline ou como tarefa do problema (glpi_problemtasks) para uso imediato do time de linha de frente.
• Solução definitiva: elimina a causa raiz. É registrada na aba Solução, gravando em glpi_itilsolutions (com itemtype = 'Problem'), e frequentemente exige uma mudança para ser implementada.

Quando a correção mexe em infraestrutura, abra a mudança direto do problema: o vínculo grava em glpi_changes_problems e mantém a rastreabilidade causa raiz - ação corretiva. É essa linha que permite provar, depois, que o problema foi de fato resolvido e não apenas fechado.

Template de notificação de encerramento de problema

Em Configurar > Notificações, o modelo do evento de problema usa as tags do GLPI. Um corpo de encerramento que force o registro da causa raiz reduz problema fechado sem lição aprendida:

Assunto: [Problema ##problem.id##] Encerrado - ##problem.title##

Olá,

O problema abaixo foi encerrado.

Título:      ##problem.title##
Categoria:   ##problem.category##
Status:      ##problem.status##
Incidentes:  ##problem.numberoftickets##

Sintomas:
##problem.symptoms##

Causa raiz:
##problem.causes##

Detalhes: ##problem.url##

As tags ##problem.causes## e ##problem.symptoms## puxam direto de causecontent e symptomcontent. Se a notificação de encerramento chega com esses blocos vazios, isso é sinal claro de que o problema foi fechado sem causa raiz documentada - e o próprio e-mail vira o auditor do processo.

Diagnóstico: problemas com incidentes de sobra e causa de menos

Na sustentação, rodamos periodicamente um SELECT que cruza o que mais importa: problemas ainda abertos com muitos incidentes vinculados, mas sem causa raiz preenchida. É a fila de retrabalho iminente:

SELECT p.id,
       p.name AS problema,
       p.status,
       COUNT(pt.tickets_id) AS incidentes,
       IF(p.causecontent = '' OR p.causecontent IS NULL,
          'SEM CAUSA RAIZ', 'ok') AS causa
FROM glpi_problems p
LEFT JOIN glpi_problems_tickets pt ON pt.problems_id = p.id
WHERE p.is_deleted = 0
  AND p.status NOT IN (5, 6)          -- exclui Resolvido e Fechado
GROUP BY p.id
HAVING causa = 'SEM CAUSA RAIZ'
    OR incidentes >= 3
ORDER BY incidentes DESC;

Toda linha com SEM CAUSA RAIZ e vários incidentes é um problema que está consumindo esforço de contorno sem caminhar para a solução. Transformar essa consulta em um painel semanal muda a conversa da reunião de operação: em vez de "quantos chamados fechamos", passa a ser "quais causas eliminamos".

Boas práticas de sustentação

• Não espere dezenas de incidentes: 3 ocorrências com o mesmo sintoma já justificam um problema.
• Preencha causecontent antes de encerrar, mesmo que a causa pareça óbvia; é o que vira base de conhecimento.
• Use Em observação enquanto o contorno roda; só marque Resolvido quando a causa foi eliminada.
• Padronize o tipo de vínculo dos incidentes para que a contagem de recorrência signifique algo.
• Vincule o problema à mudança (glpi_changes_problems) sempre que a correção mexer em infraestrutura.
• Revise os problemas abertos semanalmente; problema esquecido é incidente garantido no futuro.

Se a operação precisa que problemas recorrentes sejam detectados sozinhos - em vez de depender de alguém perceber o padrão - o módulo Problem Flow identifica incidentes repetidos por categoria e frequência e abre o problema já com os chamados vinculados. A sustentação NexTool configura esse fluxo sobre o GLPI que você já usa, do gatilho de detecção ao painel de causas eliminadas.

Revisado pela equipe NexTool Solutions.