Implementare GLPI senza pianificazione significa creare debito tecnico dal giorno 1. Nella manutenzione di ambienti dei clienti, quasi nessun progetto GLPI fallisce per colpa del software. Fallisce per decisioni di ambito prese troppo tardi, per dati importati prima che la gerarchia sia definita e per un dettaglio di infrastruttura che fa male solo dopo il go-live. Questa checklist copre le 12 fasi, ma il valore sta nelle decisioni da prendere prima di ognuna.
Prima della checklist: l'ambito è una decisione di business, non IT
Il maggior predittore di successo che osserviamo non è tecnico: è l'esistenza di un responsabile del processo lato cliente, qualcuno con l'autorità di dire "quel flusso resta fuori dalla fase 1". Senza questo responsabile, ogni reparto chiede un'eccezione, l'ambito si gonfia e il go-live slitta di tre mesi. La prima decisione di un'implementazione non è quale server usare, ma cosa non va in produzione il giorno 1. Un GLPI che gestisce bene ticket e inventario e va online nei tempi genera più adozione di una CMDB perfetta che non va mai in produzione.
Dimensionamento onesto: tre strati che crescono insieme
Un ambiente GLPI è composto da tre strati da dimensionare insieme: applicazione (PHP/PHP-FPM), database (MariaDB/MySQL) e archiviazione documenti. Senza inventare benchmark, per qualche centinaio di utenti e qualche migliaio di asset, gli ambienti girano comodi nella fascia di 2 a 4 vCPU e 4 a 8 GB di RAM. I due punti che generano più supporto non sono la CPU:
- MariaDB - regoli
innodb_buffer_pool_sizeper contenere il set di dati caldo. Un database compresso in un buffer piccolo fa sembrare lenta la ricerca di GLPI anche con CPU inattiva. - PHP - un
memory_limitbasso fa fallire report e import grandi con un errore generico; GLPI raccomanda almeno 128 MB, e gli import di inventario chiedono più margine. - Disco - ciò che cresce di più è la cartella dei documenti allegati e l'inventario. Pianifichi la crescita, non solo la dimensione iniziale.
Suddivisione in fasi: la matrice che decide quando andare in produzione
La domanda operativa non è "cosa fa GLPI", è "cosa appartiene a quale fase". Questa è la matrice che usiamo per separare il go-live (MVP) dalle evoluzioni successive. La regola: si passa alla fase seguente solo dopo che la precedente è in uso reale, con dati che entrano.
| Funzionalità | Fase 1 - Go-live (MVP) | Fase 2 - 30 a 60 giorni | Fase 3 - Maturità |
|---|---|---|---|
| Ticket + categorie | Obbligatorio (ambito minimo) | Affinare con dati reali | Automazione del triage |
| Gruppi + assegnazione | Obbligatorio | Regole di assegnazione | Bilanciamento del carico |
| SLA / OLA | Base (1 a 2 SLA) | SLA per categoria | Escalation |
| Inventario (GLPI Agent) | Pilota di asset | Rollout totale | CMDB e relazioni |
| Autenticazione LDAP / AD | Obbligatorio | Regole di profilo | Provisioning fine |
| Catalogo servizi | Fuori ambito | Introdurre | Moduli e approvazioni |
| Base di conoscenza | Semi iniziali | Espandere | KB pubblica / self-service |
| Integrazioni (monitoraggio, ecc.) | Fuori ambito | Le prioritarie | Le altre |
L'impostazione che si rompe al go-live: cron in modalità CLI
È la trappola che più spesso vediamo minare la percezione di un go-live riuscito. I task automatici di GLPI (invio notifiche, calcolo SLA, raccolta e-mail via mailgate, sincronizzazione) possono girare in due modalità: GLPI (attivati dall'accesso web) o CLI (esecuzione esterna via crontab). In modalità GLPI, i task avanzano solo quando qualcuno apre una pagina. Il risultato classico: la coda si accumula tutta la notte e il primo utente del mattino "paga il conto", elaborando centinaia di e-mail bloccate, e tutti pensano che "GLPI è lento". La correzione è banale e quasi nessuno la imposta prima che faccia male: un cron esterno ogni minuto.
# /etc/cron.d/glpi -- coda, notifiche, SLA e raccolta e-mail (mailgate)
# Eseguire come utente PHP (Debian/Ubuntu: www-data).
# Valido per GLPI 10 e 11: entrambi eseguono front/cron.php via CLI.
* * * * * www-data /usr/bin/php /var/www/glpi/front/cron.php >/dev/null 2>&1Dopo aver installato il crontab, imposti i task automatici in modalità CLI nell'interfaccia di configurazione. GLPI rileva l'esecuzione esterna e svuota la coda in modo continuo, senza dipendere dall'accesso web.
Validazione pre-go-live: la diagnostica che eseguiamo prima di aprire l'accesso
Prima di aprire l'accesso si esegue una diagnostica rapida sul database per intercettare i quattro errori più frequenti: task automatico ancora in modalità interna, notifiche spente, utente senza profilo (non accede ad alcuna entità) e albero delle entità diverso dal disegno approvato.
-- 1) Azioni automatiche ancora in modalità interna (mode=1). Al go-live devono passare a CLI (mode=2)
SELECT name, state, mode FROM glpi_crontasks WHERE mode = 1;
-- 2) Sistema di notifica attivo? (0 = spento, le e-mail non partono mai)
SELECT value FROM glpi_configs WHERE context = 'core' AND name = 'use_notifications';
-- 3) Utenti attivi senza profilo assegnato (non accedono ad alcuna entità)
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) Albero delle entità: verifica che corrisponda al disegno approvato
SELECT id, name, completename FROM glpi_entities ORDER BY completename;Un bonus dal campo: provi una notifica reale end-to-end (apra un ticket di prova e confermi che l'e-mail arriva nella casella del richiedente). Una notifica "configurata" che non parte mai è il difetto silenzioso numero uno dell'adozione.
La checklist delle 12 fasi
- Definire obiettivi concreti e misurabili (ticket persi, inventario mancante, SLA senza controllo).
- Raccogliere i requisiti intervistando supporto, manager e utenti; mappare flussi e criticità.
- Dimensionare l'infrastruttura (server, SO, database, RAM, disco). Veda le guide Docker o Linux.
- Installare e configurare GLPI, SSL, SMTP, cron (CLI) e sicurezza di base.
- Strutturare entità e sedi prima di registrare qualsiasi dato. Veda la guida sulla gerarchia organizzativa.
- Configurare categorie e SLA minimi. Veda la guida SLA e OLA.
- Configurare profili e permessi definendo chi può fare cosa.
- Importare i dati iniziali (utenti via LDAP/AD, asset attivi, contratti in corso) - il minimo per operare.
- Configurare le integrazioni prioritarie (e-mail, LDAP/AD, monitoraggio, GLPI Agent).
- Formare il team per ruolo: tecnici, manager e utenti finali del portale.
- Pilota (MVP) con un piccolo gruppo, raccogliendo feedback prima del go-live generale.
- Go-live e monitoraggio con controllo dei KPI e aggiustamenti nelle prime settimane.
Trappole dal campo che sono costate care
- Importare gli utenti prima di chiudere la gerarchia delle entità. Spostare elementi tra entità in seguito tocca ticket, contratti e permessi collegati. Definiamo l'albero delle entità e il campo di sincronizzazione LDAP prima del primo import, perché un reimport senza campo chiave stabile duplica gli utenti.
- Migrare cinque anni di storico il giorno 1. È la ricetta per un go-live in ritardo. Carichi il minimo operativo e lasci lo storico per un caricamento successivo, con la struttura già stabile.
- Lasciare il cron in modalità GLPI. Dettagliato sopra: notifiche e SLA bloccati in coda diventano "lentezza" percepita.
- Non testare l'SMTP con una e-mail reale. Una configurazione salvata non è una notifica consegnata. Testi end-to-end prima di aprire l'accesso.
Le serve un go-live senza sorprese? NexTool pianifica ed esegue implementazioni di GLPI per clienti B2B, dalla suddivisione in fasi dell'ambito all'ambiente validato in produzione. Scopra il servizio di Progetti e Implementazione.
Revisionato dal team NexTool Solutions.
