NexTool Solutions

Implantar o GLPI sem planejamento é criar dívida técnica desde o dia 1. Na sustentação de ambientes de clientes, quase nenhum projeto de GLPI fracassa por causa do software. Fracassa por decisões de escopo tomadas tarde demais, por dados importados antes da hierarquia estar definida e por um detalhe de infraestrutura que só dói depois do go-live. Este checklist cobre as 12 etapas, mas o valor está nas decisões que você precisa tomar antes de cada uma.

Antes do checklist: escopo é decisão de negócio, não de TI

O maior preditor de sucesso que observamos não é técnico: é existir um dono do processo do lado do cliente, alguém com autoridade para dizer "esse fluxo fica de fora da fase 1". Sem esse dono, cada área pede uma exceção, o escopo incha e o go-live escorrega três meses. A primeira decisão de uma implantação não é qual servidor usar, e sim o que não entra no ar no dia 1. Um GLPI que resolve bem chamados e inventário e sobe no prazo gera mais adoção do que um CMDB perfeito que nunca vai ao ar.

Dimensionamento honesto: três camadas que sobem juntas

Um ambiente GLPI são três camadas que precisam ser dimensionadas em conjunto: aplicação (PHP/PHP-FPM), banco (MariaDB/MySQL) e armazenamento de documentos. Sem inventar benchmark, para algumas centenas de usuários e alguns milhares de ativos, ambientes rodam confortáveis em faixa de 2 a 4 vCPU e 4 a 8 GB de RAM. Os dois pontos que mais causam suporte não são CPU:

• MariaDB - ajuste o innodb_buffer_pool_size para acomodar o conjunto de dados quente. Banco espremido em buffer pequeno faz a busca do GLPI parecer lenta mesmo com CPU ociosa.
• PHP - memory_limit baixo derruba relatórios e importações grandes com erro genérico; o GLPI recomenda pelo menos 128 MB, e importações de inventário pedem mais folga.
• Disco - o que mais cresce é a pasta de documentos anexados e o inventário. Planeje crescimento, não só o tamanho inicial.

Faseamento: a matriz que define quando ir ao ar

A pergunta operacional não é "o que o GLPI faz", é "o que entra em qual fase". Esta é a matriz que usamos para separar o go-live (MVP) das evoluções posteriores. A regra: só vai para a fase seguinte depois que a anterior estiver em uso real, com dado entrando.

A configuração que quebra no go-live: cron em modo CLI

Esta é a armadilha que mais vimos derrubar a percepção de um go-live bem-sucedido. As tarefas automáticas do GLPI (envio de notificação, cálculo de SLA, coleta de e-mail via mailgate, sincronização) podem rodar em dois modos: GLPI (disparadas pelo acesso web) ou CLI (execução externa por crontab). No modo GLPI, as tarefas só avançam quando alguém abre uma página. O resultado clássico: a fila acumula a noite inteira e o primeiro usuário da manhã "paga a conta", processando centenas de e-mails presos, e todo mundo acha que "o GLPI está lento". A correção é trivial e quase ninguém liga antes de doer: cron externo a cada minuto.

# /etc/cron.d/glpi -- fila, notificações, SLA e coleta de e-mail (mailgate)
# Rodar como o usuário do PHP (Debian/Ubuntu: www-data).
# Vale para GLPI 10 e 11: ambos executam front/cron.php via CLI.
* * * * * www-data /usr/bin/php /var/www/glpi/front/cron.php >/dev/null 2>&1

Depois de instalar o crontab, ajuste as tarefas automáticas para o modo CLI na interface de configuração. O GLPI passa a detectar a execução externa e drena a fila continuamente, sem depender do acesso web.

Validação pré-go-live: o diagnóstico que rodamos antes de liberar

Antes de liberar o acesso, roda-se um diagnóstico rápido no banco para pegar os quatro erros que mais aparecem: tarefa automática ainda em modo interno, notificação desligada, usuário sem perfil (não loga em entidade nenhuma) e árvore de entidades diferente do desenho aprovado.

-- 1) Ações automáticas ainda no modo interno (mode=1). No go-live devem ir para CLI (mode=2)
SELECT name, state, mode FROM glpi_crontasks WHERE mode = 1;

-- 2) Sistema de notificação ligado? (0 = desligado, e-mails nunca saem)
SELECT value FROM glpi_configs WHERE context = 'core' AND name = 'use_notifications';

-- 3) Usuários ativos sem perfil vinculado (não logam em nenhuma entidade)
SELECT u.id, u.name
FROM glpi_users u
LEFT JOIN glpi_profiles_users pu ON pu.users_id = u.id
WHERE pu.id IS NULL AND u.is_active = 1 AND u.is_deleted = 0;

-- 4) Árvore de entidades: confira se bate com o desenho aprovado
SELECT id, name, completename FROM glpi_entities ORDER BY completename;

Um bônus de campo: teste uma notificação real de ponta a ponta (abra um chamado de teste e confirme que o e-mail chega na caixa do solicitante). Notificação que "está configurada" mas não sai é o defeito silencioso número um da adoção.

O checklist das 12 etapas

1. Definir objetivos concretos e mensuráveis (chamados perdidos, falta de inventário, SLA sem controle).
2. Levantar requisitos entrevistando suporte, gestores e usuários; mapear fluxos e dores.
3. Dimensionar a infraestrutura (servidor, SO, banco, RAM, disco). Veja os guias de Docker ou Linux.
4. Instalar e configurar GLPI, SSL, SMTP, cron (CLI) e segurança básica.
5. Estruturar entidades e localizações antes de cadastrar qualquer dado. Veja o guia de hierarquia organizacional.
6. Configurar categorias e SLAs mínimos. Veja o guia de SLA e OLA.
7. Configurar perfis e permissões definindo quem pode fazer o quê.
8. Importar dados iniciais (usuários via LDAP/AD, ativos ativos, contratos vigentes) - o mínimo para operar.
9. Configurar integrações prioritárias (e-mail, LDAP/AD, monitoramento, GLPI Agent).
10. Treinar a equipe por papel: técnicos, gestores e usuários finais do portal.
11. Piloto (MVP) com um grupo pequeno, coletando feedback antes do go-live geral.
12. Go-live e monitoramento com acompanhamento de KPIs e ajuste nas primeiras semanas.

Armadilhas de campo que custaram caro

• Importar usuários antes de fechar a hierarquia de entidades. Mover itens de entidade depois toca tickets, contratos e permissões vinculados. Definimos a árvore de entidades e o campo de sincronização do LDAP antes do primeiro import, porque reimport sem campo-chave estável duplica usuários.
• Migrar cinco anos de histórico no dia 1. É a receita para atrasar o go-live. Carregue o mínimo operacional e deixe o histórico para uma carga posterior, com a estrutura já estável.
• Deixar o cron no modo GLPI. Detalhado acima: fila travada vira "lentidão" percebida.
• Não testar o SMTP com um e-mail real. Configuração salva não é notificação entregue. Teste ponta a ponta antes de liberar.

Precisa de um go-live sem surpresa? A NexTool planeja e executa implantações de GLPI para clientes B2B, do faseamento do escopo ao ambiente validado em produção. Conheça o serviço de Projetos e Implantação.

Revisado pela equipe NexTool Solutions.