Implantar GLPI sin planificación es crear deuda técnica desde el día 1. En el mantenimiento de entornos de clientes, casi ningún proyecto de GLPI fracasa por el software. Fracasa por decisiones de alcance tomadas demasiado tarde, por datos importados antes de definir la jerarquía y por un detalle de infraestructura que solo duele después del go-live. Este checklist cubre las 12 etapas, pero el valor está en las decisiones que debes tomar antes de cada una.
Antes del checklist: el alcance es una decisión de negocio, no de TI
El mayor predictor de éxito que observamos no es técnico: es que exista un dueño del proceso del lado del cliente, alguien con autoridad para decir "ese flujo queda fuera de la fase 1". Sin ese dueño, cada área pide una excepción, el alcance se infla y el go-live se retrasa tres meses. La primera decisión de una implantación no es qué servidor usar, sino qué no entra en producción el día 1. Un GLPI que resuelve bien tickets e inventario y sale a tiempo genera más adopción que un CMDB perfecto que nunca entra en producción.
Dimensionamiento honesto: tres capas que escalan juntas
Un entorno GLPI son tres capas que deben dimensionarse en conjunto: aplicación (PHP/PHP-FPM), base de datos (MariaDB/MySQL) y almacenamiento de documentos. Sin inventar benchmarks, para algunos cientos de usuarios y algunos miles de activos, los entornos funcionan cómodos en el rango de 2 a 4 vCPU y 4 a 8 GB de RAM. Los dos puntos que más generan soporte no son la CPU:
- MariaDB - ajusta
innodb_buffer_pool_sizepara acomodar el conjunto de datos caliente. Una base apretada en un buffer pequeño hace que la búsqueda de GLPI parezca lenta aun con CPU ociosa. - PHP - un
memory_limitbajo tumba informes e importaciones grandes con un error genérico; GLPI recomienda al menos 128 MB, y las importaciones de inventario piden más margen. - Disco - lo que más crece es la carpeta de documentos adjuntos y el inventario. Planifica el crecimiento, no solo el tamaño inicial.
Fases: la matriz que decide cuándo salir a producción
La pregunta operativa no es "qué hace GLPI", es "qué entra en cada fase". Esta es la matriz que usamos para separar el go-live (MVP) de las evoluciones posteriores. La regla: solo se pasa a la fase siguiente cuando la anterior está en uso real, con datos entrando.
| Capacidad | Fase 1 - Go-live (MVP) | Fase 2 - 30 a 60 días | Fase 3 - Madurez |
|---|---|---|---|
| Tickets + categorías | Obligatorio (alcance mínimo) | Refinar con datos reales | Automatización de triaje |
| Grupos + asignación | Obligatorio | Reglas de asignación | Balanceo de carga |
| SLA / OLA | Básico (1 a 2 SLAs) | SLAs por categoría | Escalado |
| Inventario (GLPI Agent) | Piloto de activos | Despliegue total | CMDB y relaciones |
| Autenticación LDAP / AD | Obligatorio | Reglas de perfil | Aprovisionamiento fino |
| Catálogo de servicios | Fuera | Introducir | Formularios y aprobaciones |
| Base de conocimiento | Semillas iniciales | Ampliar | KB pública / autoservicio |
| Integraciones (monitorización, etc.) | Fuera | Las prioritarias | El resto |
La configuración que se rompe en el go-live: cron en modo CLI
Esta es la trampa que más vemos hundir la percepción de un go-live exitoso. Las tareas automáticas de GLPI (envío de notificaciones, cálculo de SLA, recogida de correo vía mailgate, sincronización) pueden ejecutarse en dos modos: GLPI (disparadas por el acceso web) o CLI (ejecución externa por crontab). En modo GLPI, las tareas solo avanzan cuando alguien abre una página. El resultado clásico: la cola se acumula toda la noche y el primer usuario de la mañana "paga la cuenta", procesando cientos de correos atascados, y todos creen que "GLPI está lento". La solución es trivial y casi nadie la configura antes de que duela: un cron externo cada minuto.
# /etc/cron.d/glpi -- cola, notificaciones, SLA y recogida de correo (mailgate)
# Ejecutar como el usuario de PHP (Debian/Ubuntu: www-data).
# Válido para GLPI 10 y 11: ambos ejecutan front/cron.php vía CLI.
* * * * * www-data /usr/bin/php /var/www/glpi/front/cron.php >/dev/null 2>&1Tras instalar el crontab, cambia las tareas automáticas al modo CLI en la interfaz de configuración. GLPI pasa a detectar la ejecución externa y drena la cola de forma continua, sin depender del acceso web.
Validación previa al go-live: el diagnóstico que ejecutamos antes de abrir el acceso
Antes de abrir el acceso se ejecuta un diagnóstico rápido en la base de datos para atrapar los cuatro errores más frecuentes: tarea automática todavía en modo interno, notificaciones apagadas, usuario sin perfil (no inicia sesión en ninguna entidad) y árbol de entidades distinto del diseño aprobado.
-- 1) Acciones automáticas todavía en modo interno (mode=1). En el go-live deben pasar a CLI (mode=2)
SELECT name, state, mode FROM glpi_crontasks WHERE mode = 1;
-- 2) ¿Sistema de notificaciones activo? (0 = apagado, los correos nunca salen)
SELECT value FROM glpi_configs WHERE context = 'core' AND name = 'use_notifications';
-- 3) Usuarios activos sin perfil asignado (no inician sesión en ninguna entidad)
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) Árbol de entidades: comprueba que coincide con el diseño aprobado
SELECT id, name, completename FROM glpi_entities ORDER BY completename;Un extra de campo: prueba una notificación real de extremo a extremo (abre un ticket de prueba y confirma que el correo llega a la bandeja del solicitante). Una notificación que "está configurada" pero nunca sale es el defecto silencioso número uno de la adopción.
El checklist de 12 etapas
- Definir objetivos concretos y medibles (tickets perdidos, falta de inventario, SLA sin control).
- Levantar requisitos entrevistando a soporte, gestores y usuarios; mapear flujos y dolores.
- Dimensionar la infraestructura (servidor, SO, base de datos, RAM, disco). Consulta las guías de Docker o Linux.
- Instalar y configurar GLPI, SSL, SMTP, cron (CLI) y seguridad básica.
- Estructurar entidades y ubicaciones antes de registrar cualquier dato. Consulta la guía de jerarquía organizativa.
- Configurar categorías y SLAs mínimos. Consulta la guía de SLA y OLA.
- Configurar perfiles y permisos definiendo quién puede hacer qué.
- Importar datos iniciales (usuarios vía LDAP/AD, activos activos, contratos vigentes) - lo mínimo para operar.
- Configurar integraciones prioritarias (correo, LDAP/AD, monitorización, GLPI Agent).
- Formar al equipo por rol: técnicos, gestores y usuarios finales del portal.
- Piloto (MVP) con un grupo pequeño, recogiendo feedback antes del go-live general.
- Go-live y monitorización con seguimiento de KPIs y ajuste en las primeras semanas.
Trampas de campo que costaron caro
- Importar usuarios antes de cerrar la jerarquía de entidades. Mover ítems entre entidades después toca tickets, contratos y permisos vinculados. Definimos el árbol de entidades y el campo de sincronización de LDAP antes de la primera importación, porque una reimportación sin campo clave estable duplica usuarios.
- Migrar cinco años de histórico el día 1. Es la receta para retrasar el go-live. Carga el mínimo operativo y deja el histórico para una carga posterior, con la estructura ya estable.
- Dejar el cron en modo GLPI. Detallado arriba: notificaciones y SLA atascados en la cola se convierten en "lentitud" percibida.
- No probar el SMTP con un correo real. Una configuración guardada no es una notificación entregada. Prueba de extremo a extremo antes de abrir el acceso.
¿Necesitas un go-live sin sorpresas? NexTool planifica y ejecuta implantaciones de GLPI para clientes B2B, desde la definición de fases del alcance hasta el entorno validado en producción. Conoce el servicio de Proyectos e Implantación.
Revisado por el equipo de NexTool Solutions.
