NexTool Solutions

Uma mudança bem gerida no GLPI não é a que tem mais campos preenchidos, é a que você consegue reverter às 2h da manhã quando ela falha. Este guia percorre o ciclo de vida completo de mudanças no GLPI: de qual seção e coluna cada informação sai, como modelar tipos de mudança que o GLPI nativo não tem, e as armadilhas que já vimos derrubar janelas de manutenção em ambientes que sustentamos para clientes.

O modelo de dados por trás da mudança

Toda mudança vive na tabela glpi_changes. Além dos campos óbvios (nome, conteúdo, urgência, impacto, prioridade), o que diferencia uma mudança de um chamado comum são as colunas de texto que o GLPI expõe na seção de análise e planos do formulário:

• impactcontent - análise de impacto: o que quebra se der errado.
• controlistcontent - lista de controle: pontos de verificação.
• rolloutplancontent - plano de implantação (o core rotula "Deployment plan"): o passo-a-passo do deploy.
• backoutplancontent - plano de retrocesso/rollback (o core rotula "Backup plan"): como desfazer.
• checklistcontent - checklist de validação pós-implementação.

Saber que essas informações são colunas separadas, e não texto solto na descrição, é o que permite auditar a governança direto no banco, como mostramos mais abaixo.

"Tipo de mudança" no GLPI: o campo que não existe

O erro mais comum de quem vem de ferramentas como o ServiceNow é procurar um seletor "Tipo: Normal / Emergencial / Padrão". Ele não existe no GLPI nativo. A mudança tem categoria (itilcategories_id), urgência, impacto e prioridade, mas não um campo de tipo ITIL. Você modela a classificação usando Categorias ITIL dedicadas, o que ainda alimenta relatórios e regras de negócio.

O ciclo de vida, status por status

O GLPI move a mudança por uma máquina de estados própria, mais rica que a do chamado. O estado atual fica na coluna status de glpi_changes:

1. Novo (1) - registro em Assistência > Mudanças, com descrição, justificativa, impacto e risco.
2. Avaliação (4) - análise de impacto e risco; preenchimento das seções de análise e planos.
3. Aprovação (11) - rodada de validação com os aprovadores.
4. Aceito (12), Teste (13), Qualificação (14) - planejamento e execução das tarefas (glpi_changetasks), cada uma registrada na timeline.
5. Resolvido (5) - revisão pós-implementação; confirma sucesso e registra lições aprendidas.
6. Fechado (6) - documentação final e encerramento.

Cada tarefa de mudança carrega actiontime (tempo real) e state (a fazer/feito), o que permite comparar esforço planejado versus gasto - dado que usamos para calibrar as estimativas das próximas janelas.

Aprovação: validação nativa versus multinível

A aprovação nativa grava em glpi_changevalidations (status 2 = em espera, 3 = aprovado, 4 = recusado). O detalhe que pega quase todo mundo: a validação do GLPI é informativa, não é um portão. Nada impede mover a mudança de Aprovação para Teste com a validação ainda em espera; o GLPI não bloqueia a transição. Se a sua governança exige que ninguém implemente sem aprovação registrada, a validação nativa sozinha não resolve. É aí que entra o Approval Flow, com aprovação multinível e rotas condicionais que efetivamente travam o avanço.

Template de notificação do pedido de aprovação

Em Configurar > Notificações, o modelo do evento de validação de mudança usa as tags do GLPI. Um corpo enxuto reduz idas e vindas:

Assunto: [Mudança ##change.id##] Aprovação solicitada - ##change.title##

Olá,

Uma mudança aguarda a sua aprovação.

Título:     ##change.title##
Categoria:  ##change.category##
Urgência:   ##change.urgency##
Impacto:    ##change.impact##
Prioridade: ##change.priority##

Descrição:
##change.content##

Aprovar ou recusar em:
##change.url##

Manter urgência, impacto e prioridade no corpo evita que o aprovador precise abrir a mudança só para decidir. Isso reduz o tempo em status Aprovação, que é onde a maioria das janelas atrasa.

Diagnóstico: mudanças sem plano de rollback

Na sustentação, o campo que mais encontramos vazio é justamente o mais crítico: backoutplancontent. A seção de planos vem recolhida na interface, então o técnico preenche descrição e tarefas, mas nunca o plano de retrocesso, e a falha só aparece quando a mudança dá errado e ninguém sabe reverter. Rodamos este SELECT toda sexta, antes da janela de fim de semana:

SELECT c.id,
       c.name AS mudanca,
       c.status,
       IF(c.backoutplancontent = '' OR c.backoutplancontent IS NULL,
          'SEM ROLLBACK', 'ok') AS plano_retrocesso
FROM glpi_changes c
WHERE c.is_deleted = 0
  AND c.status NOT IN (5, 6)          -- exclui Resolvido e Fechado
ORDER BY c.date DESC;

Qualquer linha com SEM ROLLBACK é uma mudança que não deveria entrar em janela. Transformamos isso em regra de negócio: sem plano de retrocesso preenchido, a aprovação não sai.

Boas práticas de sustentação

• Documente o backoutplancontent antes de pedir aprovação, não depois de implementar.
• Vincule a mudança ao problema de origem (glpi_changes_problems) para manter a rastreabilidade causa raiz para ação corretiva.
• Crie modelos de mudança para as recorrentes (padrão) e dispense a validação nelas.
• Agende fora do horário de pico e registre o actiontime real para calibrar estimativas.
• Feche o ciclo com a revisão pós-implementação, mesmo quando deu tudo certo; é o que vira base de conhecimento.

Se a operação precisa de um portão de aprovação que realmente trave o avanço e de governança de mudanças auditável, a sustentação NexTool configura esse fluxo com o módulo Approval Flow sobre o GLPI que você já usa.

Revisado pela equipe NexTool Solutions.