NexTool Solutions

Implementar o GLPI sem planeamento é 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 âmbito tomadas tarde demais, por dados importados antes de a hierarquia estar definida e por um detalhe de infraestrutura que só dói depois do go-live. Esta checklist cobre as 12 etapas, mas o valor está nas decisões que precisa de tomar antes de cada uma.

Antes da checklist: o âmbito é uma 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 âmbito incha e o go-live escorrega três meses. A primeira decisão de uma implementação não é qual servidor usar, mas o que não entra em produção no dia 1. Um GLPI que resolve bem pedidos e inventário e vai ao ar a tempo gera mais adoção do que uma CMDB perfeita que nunca entra em produção.

Dimensionamento honesto: três camadas que sobem juntas

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

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

Faseamento: a matriz que decide quando ir a produção

A pergunta operacional não é "o que o GLPI faz", é "o que entra em cada fase". Esta é a matriz que usamos para separar o go-live (MVP) das evoluções posteriores. A regra: só se passa à fase seguinte depois de a anterior estar em uso real, com dados a entrar.

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

Esta é a armadilha que mais vemos derrubar a perceção de um go-live bem-sucedido. As tarefas automáticas do GLPI (envio de notificação, cálculo de SLA, recolha de e-mail via mailgate, sincronização) podem correr 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 utilizador da manhã "paga a conta", processando centenas de e-mails presos, e toda a gente 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 recolha de e-mail (mailgate)
# Correr como o utilizador 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 detetar a execução externa e drena a fila continuamente, sem depender do acesso web.

Validação pré-go-live: o diagnóstico que corremos antes de abrir o acesso

Antes de abrir o acesso, corre-se um diagnóstico rápido na base de dados para apanhar os quatro erros que mais aparecem: tarefa automática ainda em modo interno, notificação desligada, utilizador sem perfil (não entra em nenhuma entidade) e árvore de entidades diferente do desenho aprovado.

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

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

-- 3) Utilizadores ativos sem perfil associado (não entram 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: confirme que bate certo 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 pedido de teste e confirme que o e-mail chega à caixa do requerente). Uma notificação que "está configurada" mas nunca sai é o defeito silencioso número um da adoção.

A checklist das 12 etapas

1. Definir objetivos concretos e mensuráveis (pedidos perdidos, falta de inventário, SLA sem controlo).
2. Levantar requisitos entrevistando suporte, gestores e utilizadores; mapear fluxos e dores.
3. Dimensionar a infraestrutura (servidor, SO, base de dados, 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 registar 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 (utilizadores via LDAP/AD, ativos ativos, contratos vigentes) - o mínimo para operar.
9. Configurar integrações prioritárias (e-mail, LDAP/AD, monitorização, GLPI Agent).
10. Formar a equipa por papel: técnicos, gestores e utilizadores finais do portal.
11. Piloto (MVP) com um grupo pequeno, recolhendo feedback antes do go-live geral.
12. Go-live e monitorização com acompanhamento de KPIs e ajuste nas primeiras semanas.

Armadilhas de campo que custaram caro

• Importar utilizadores antes de fechar a hierarquia de entidades. Mover itens entre entidades depois toca em pedidos, contratos e permissões associados. Definimos a árvore de entidades e o campo de sincronização do LDAP antes da primeira importação, porque uma reimportação sem campo-chave estável duplica utilizadores.
• 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 em modo GLPI. Detalhado acima: notificações e SLA presos na fila viram "lentidão" percebida.
• Não testar o SMTP com um e-mail real. Uma configuração guardada não é uma notificação entregue. Teste de ponta a ponta antes de abrir o acesso.

Precisa de um go-live sem surpresa? A NexTool planeia e executa implementações de GLPI para clientes B2B, do faseamento do âmbito ao ambiente validado em produção. Conheça o serviço de Projetos e Implementação.

Revisto pela equipa NexTool Solutions.