NexTool Solutions

A gestão de problemas é o que separa uma operação que apaga o mesmo incêndio todas as semanas 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 ficar documentada. Este guia mostra onde vive cada informação do problema no GLPI, como classificar sem inventar um campo que não existe, e as armadilhas que fazem a investigação perder-se.

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 transforma-se em problema". No GLPI nem sequer partilham a mesma tabela: o incidente vive em glpi_tickets, o problema em glpi_problems, cada um com a sua própria máquina de estados. São objetos distintos com objetivos opostos:

• Incidente: repor o serviço o mais depressa possível. É curativo e tem um SLA de resolução.
• Problema: encontrar e eliminar a causa raiz para que o incidente não volte. É preventivo e segue outro ritmo.

Exemplo do terreno: o servidor de e-mail cai todas as segundas-feiras. Cada queda é um incidente resolvido reiniciando o serviço. A investigação que descobre que o backup semanal esgota a memória e deita o serviço abaixo é o problema. Fechar os incidentes sem abrir o problema garante que a segunda-feira seguinte traz o mesmo pedido.

A secção Análise: onde a causa raiz realmente vive

O que distingue o formulário do problema do de um pedido comum é a secção Análise, que grava em três colunas de texto dedicadas de glpi_problems (expostas como opções de pesquisa 60, 61 e 62):

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

A armadilha do terreno mais comum que encontramos: a secção Análise vem recolhida no formulário. O técnico preenche o título e a descrição, regista o contorno na cronologia e nunca abre a secção - por isso causecontent fica vazio. O resultado: seis meses depois, ninguém sabe porque é que aquele problema foi aberto nem o que se descobriu. Uma causa raiz que nunca chega a causecontent não se torna conhecimento, torna-se boato.

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

Antes de abrir qualquer registo, a equipa precisa de saber o que está a abrir. 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.

Ligar os incidentes: o separador Pedidos e o tipo de ligação

O que dá corpo a um problema são os incidentes ligados a ele. No formulário do problema, o separador Pedidos associa os pedidos relacionados, gravando na tabela glpi_problems_tickets. O detalhe que quase toda a gente ignora: a ligação tem tipo. Ligar como "Ligado a" é diferente de ligar como "Duplicado", e isso muda a leitura dos relatórios de recorrência. Padronize o tipo de ligação na equipa, senão a contagem de incidentes por problema deixa de fazer sentido - foi um dos primeiros ajustes que fizemos em ambientes que herdámos sem governação.

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

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

1. Novo (1) - registado, ainda sem investigação.
2. Aceite (7) - triado e assumido pela equipa.
3. Em processamento / atribuído (2) e planeado (3) - investigação em curso.
4. Em espera (4) - a aguardar um terceiro, fornecedor ou janela.
5. Sob observação (8) - contorno aplicado, a monitorizar se a causa foi mesmo eliminada.
6. Resolvido (5) e Fechado (6) - causa eliminada e ciclo encerrado.

Aqui está o erro comum que mais caro custa: 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 passámos a usar o estado Sob observação (8) exatamente para isto: o contorno está de pé, o problema continua vivo no painel, e só o movemos para Resolvido depois de a correção definitiva entrar e passar um período sem reincidência. Fechar cedo demais é como cantar vitória com o incêndio ainda a fumegar 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): repõe o serviço sem tocar na causa. Documente na cronologia ou como tarefa do problema (glpi_problemtasks) para uso imediato da primeira linha.
• Solução definitiva: elimina a causa raiz. É registada no separador Solução, gravando em glpi_itilsolutions (com itemtype = 'Problem'), e frequentemente exige uma mudança para ser implementada.

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

Modelo de notificação de encerramento de problema

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

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

Olá,

O problema abaixo foi encerrado.

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

Sintomas:
##problem.symptoms##

Causa raiz:
##problem.causes##

Detalhes: ##problem.url##

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

Diagnóstico: problemas com incidentes a mais e causa a menos

Na sustentação, executamos periodicamente um SELECT que cruza o que mais importa: problemas ainda abertos com muitos incidentes ligados mas sem causa raiz preenchida. É a fila do 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;

Cada linha com SEM CAUSA RAIZ e vários incidentes é um problema que consome esforço de contorno sem caminhar para a solução. Transformar esta consulta num painel semanal muda a conversa na reunião de operação: em vez de "quantos pedidos fechámos", passa a ser "que causas eliminámos".

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 se torna conhecimento.
• Use Sob observação enquanto o contorno corre; só marque Resolvido quando a causa estiver eliminada.
• Padronize o tipo de ligação dos incidentes para que a contagem de recorrência signifique algo.
• Ligue o problema à mudança (glpi_changes_problems) sempre que a correção mexer na infraestrutura.
• Reveja os problemas abertos semanalmente; um problema esquecido é um incidente garantido no futuro.

Se a operação precisa que os problemas recorrentes sejam detetados sozinhos - em vez de depender de alguém reparar no padrão - o módulo Problem Flow identifica incidentes repetidos por categoria e frequência e abre o problema já com os pedidos ligados. A equipa de suporte NexTool configura este fluxo sobre o GLPI que já utiliza, do gatilho de deteção ao painel de causas eliminadas.

Revisto pela equipa NexTool Solutions.