NexTool Solutions

Uma alteração bem gerida no GLPI não é a que tem mais campos preenchidos, é a que consegue reverter às 2h da manhã quando falha. Este guia percorre o ciclo de vida completo das alterações no GLPI: de que secção e coluna sai cada informação, como modelar tipos de alteração que o GLPI nativo não tem, e as armadilhas que já vimos deitar abaixo janelas de manutenção em ambientes que mantemos para clientes.

O modelo de dados por trás da alteração

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

• impactcontent - análise de impacto: o que parte se correr mal.
• controlistcontent - lista de controlo: pontos de verificação.
• rolloutplancontent - plano de implementação (o núcleo rotula "Deployment plan"): o passo a passo do deploy.
• backoutplancontent - plano de retrocesso/rollback (o núcleo rotula "Backup plan"): como desfazer.
• checklistcontent - lista de verificação de validação após a implementação.

Saber que estas informações são colunas separadas, e não texto solto na descrição, é o que permite auditar a governação diretamente na base de dados, como mostramos mais abaixo.

"Tipo de alteração" 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 / Emergência / Padrão". Ele não existe no GLPI nativo. A alteração tem categoria (itilcategories_id), urgência, impacto e prioridade, mas não um campo de tipo ITIL. A classificação modela-se com categorias ITIL dedicadas, o que também alimenta relatórios e regras de negócio.

O ciclo de vida, estado a estado

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

1. Novo (1) - registado em Assistência > Alterações, com descrição, justificação, impacto e risco.
2. Avaliação (4) - análise de impacto e risco; preenchimento das secções de análise e planos.
3. Aprovação (11) - ronda de validação com os aprovadores.
4. Aceite (12), Teste (13), Qualificação (14) - planeamento e execução das tarefas (glpi_changetasks), cada uma registada na cronologia.
5. Resolvido (5) - revisão após a implementação; confirma o sucesso e regista lições aprendidas.
6. Fechado (6) - documentação final e encerramento.

Cada tarefa de alteração transporta actiontime (tempo real) e state (a fazer/feito), o que permite comparar o esforço planeado com o 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 (estado 2 = em espera, 3 = aprovado, 4 = recusado). O detalhe que apanha quase toda a gente: a validação do GLPI é informativa, não é um portão. Nada impede mover a alteração de Aprovação para Teste com a validação ainda em espera; o GLPI não bloqueia a transição. Se a sua governação exige que ninguém implemente sem aprovação registada, a validação nativa por si só não resolve. É aí que entra o Approval Flow, com aprovação multinível e rotas condicionais que travam de facto o avanço.

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

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

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

Olá,

Uma alteração 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 tenha de abrir a alteração só para decidir. Isto reduz o tempo no estado Aprovação, que é onde a maioria das janelas atrasa.

Diagnóstico: alterações sem plano de rollback

Na manutenção, o campo que mais encontramos vazio é justamente o mais crítico: backoutplancontent. A secção de planos vem recolhida na interface, por isso o técnico preenche a descrição e as tarefas, mas nunca o plano de retrocesso, e a falha só aparece quando a alteração corre mal e ninguém sabe reverter. Corremos este SELECT todas as sextas, antes da janela de fim de semana:

SELECT c.id,
       c.name AS alteracao,
       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 alteração que não devia entrar em janela. Transformamos isto em regra de negócio: sem plano de retrocesso preenchido, a aprovação não sai.

Boas práticas de manutenção

• Documente o backoutplancontent antes de pedir a aprovação, não depois de implementar.
• Associe a alteração ao problema de origem (glpi_changes_problems) para manter a rastreabilidade da causa raiz para a ação corretiva.
• Crie modelos de alteração para as recorrentes (padrão) e dispense a validação nelas.
• Agende fora das horas de pico e registe o actiontime real para calibrar estimativas.
• Feche o ciclo com a revisão após a implementação, mesmo quando correu tudo bem; é o que se torna base de conhecimento.

Se a operação precisa de um portão de aprovação que trave mesmo o avanço e de governação de alterações auditável, a equipa de suporte NexTool configura esse fluxo com o módulo Approval Flow sobre o GLPI que já utiliza.

Revisto pela equipa NexTool Solutions.