NexTool Solutions

GLPI ohne Planung einzuführen heißt, vom ersten Tag an technische Schulden aufzubauen. Im Betrieb von Kundenumgebungen scheitert kaum ein GLPI-Projekt an der Software. Es scheitert an zu spät getroffenen Entscheidungen zum Umfang, an Daten, die importiert werden, bevor die Hierarchie festgelegt ist, und an einem Infrastrukturdetail, das erst nach dem Go-live schmerzt. Diese Checkliste umfasst die 12 Schritte, doch ihr Wert liegt in den Entscheidungen, die Sie vor jedem einzelnen treffen müssen.

Vor der Checkliste: Der Umfang ist eine Geschäftsentscheidung, keine IT-Entscheidung

Der stärkste Erfolgsindikator, den wir beobachten, ist nicht technisch: Es muss auf Kundenseite einen Prozessverantwortlichen geben, jemanden mit der Befugnis zu sagen: „Dieser Ablauf bleibt aus Phase 1 heraus.“ Ohne diese Person verlangt jeder Bereich eine Ausnahme, der Umfang bläht sich auf, und der Go-live verschiebt sich um drei Monate. Die erste Entscheidung einer Einführung ist nicht, welcher Server verwendet wird, sondern was am ersten Tag nicht live geht. Ein GLPI, das Tickets und Inventar gut abbildet und termingerecht startet, erzeugt mehr Akzeptanz als eine perfekte CMDB, die nie live geht.

Ehrliche Dimensionierung: drei Schichten, die gemeinsam wachsen

Eine GLPI-Umgebung besteht aus drei Schichten, die gemeinsam dimensioniert werden müssen: Anwendung (PHP/PHP-FPM), Datenbank (MariaDB/MySQL) und Dokumentenspeicher. Ohne erfundene Benchmarks: Für einige Hundert Benutzer und einige Tausend Assets laufen Umgebungen komfortabel im Bereich von 2 bis 4 vCPU und 4 bis 8 GB RAM. Die beiden Punkte, die am meisten Support verursachen, sind nicht die CPU:

• MariaDB - stellen Sie innodb_buffer_pool_size so ein, dass der heiße Datenbestand hineinpasst. Eine in einen kleinen Buffer gezwängte Datenbank lässt die Suche im GLPI langsam wirken, selbst wenn die CPU untätig ist.
• PHP - ein niedriges memory_limit lässt Berichte und große Importe mit einer generischen Fehlermeldung abbrechen; GLPI empfiehlt mindestens 128 MB, und Inventarimporte brauchen mehr Spielraum.
• Festplatte - am stärksten wachsen der Ordner mit angehängten Dokumenten und das Inventar. Planen Sie das Wachstum ein, nicht nur die Anfangsgröße.

Phasenplanung: die Matrix, die den Go-live-Zeitpunkt bestimmt

Die operative Frage lautet nicht „Was kann GLPI?“, sondern „Was kommt in welche Phase?“. Mit dieser Matrix trennen wir den Go-live (MVP) von späteren Ausbaustufen. Die Regel: Die nächste Phase beginnt erst, wenn die vorherige wirklich genutzt wird und Daten hereinkommen.

Die Konfiguration, die beim Go-live bricht: Cron im CLI-Modus

Dies ist der Fallstrick, der am häufigsten den Eindruck eines gelungenen Go-live zunichtemacht. Die automatischen Aktionen von GLPI (Versand von Benachrichtigungen, SLA-Berechnung, E-Mail-Abruf über Mailgate, Synchronisierung) können in zwei Modi laufen: GLPI (ausgelöst durch Webzugriffe) oder CLI (externe Ausführung per Crontab). Im GLPI-Modus kommen die Aktionen nur voran, wenn jemand eine Seite öffnet. Das klassische Ergebnis: Die Warteschlange staut sich die ganze Nacht, der erste Anwender am Morgen „zahlt die Rechnung“, indem Hunderte festhängender E-Mails verarbeitet werden, und alle glauben, „GLPI ist langsam“. Die Korrektur ist trivial, und kaum jemand richtet sie ein, bevor es wehtut: externer Cron jede Minute.

# /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

Stellen Sie nach dem Einrichten der Crontab die automatischen Aktionen in der Konfigurationsoberfläche auf den CLI-Modus um. GLPI erkennt dann die externe Ausführung und arbeitet die Warteschlange kontinuierlich ab, ohne von Webzugriffen abhängig zu sein.

Prüfung vor dem Go-live: die Diagnose, die wir vor der Freigabe ausführen

Vor der Freigabe des Zugangs läuft eine schnelle Diagnose auf der Datenbank, um die vier häufigsten Fehler zu finden: automatische Aktion noch im internen Modus, Benachrichtigungen deaktiviert, Benutzer ohne Profil (meldet sich in keiner Einheit an) und eine Einheitenstruktur, die vom freigegebenen Entwurf abweicht.

-- 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;

Ein Bonus aus der Praxis: Testen Sie eine echte Benachrichtigung durchgängig (erstellen Sie ein Testticket und prüfen Sie, ob die E-Mail im Postfach des Anforderers ankommt). Eine Benachrichtigung, die „konfiguriert ist“, aber nicht versendet wird, ist der stille Akzeptanzkiller Nummer eins.

Die Checkliste mit 12 Schritten

1. Ziele definieren, konkret und messbar (verlorene Tickets, fehlendes Inventar, unkontrollierte SLAs).
2. Anforderungen erheben durch Interviews mit Support, Führungskräften und Anwendern; Abläufe und Schmerzpunkte erfassen.
3. Infrastruktur dimensionieren (Server, Betriebssystem, Datenbank, RAM, Festplatte). Siehe die Leitfäden zu Docker oder Linux.
4. Installieren und konfigurieren: GLPI, SSL, SMTP, Cron (CLI) und grundlegende Sicherheit.
5. Einheiten und Standorte strukturieren, bevor irgendwelche Daten erfasst werden. Siehe den Leitfaden zur Organisationshierarchie.
6. Kategorien und SLAs im Mindestumfang einrichten. Siehe den Leitfaden zu SLA und OLA.
7. Profile und Berechtigungen einrichten und festlegen, wer was tun darf.
8. Anfangsdaten importieren (Benutzer über LDAP/AD, aktive Assets, laufende Verträge) - das Minimum für den Betrieb.
9. Integrationen einrichten, die vorrangig sind (E-Mail, LDAP/AD, Monitoring, GLPI Agent).
10. Team schulen, nach Rolle: Techniker, Führungskräfte und Endanwender des Portals.
11. Pilot (MVP) mit einer kleinen Gruppe, Feedback sammeln vor dem allgemeinen Go-live.
12. Go-live und Monitoring mit Verfolgung der KPIs und Anpassungen in den ersten Wochen.

Fallstricke aus der Praxis, die teuer wurden

• Benutzer importieren, bevor die Einheitenhierarchie feststeht. Elemente nachträglich zwischen Einheiten zu verschieben, betrifft verknüpfte Tickets, Verträge und Berechtigungen. Wir legen die Einheitenstruktur und das Synchronisierungsfeld des LDAP vor dem ersten Import fest, weil ein erneuter Import ohne stabiles Schlüsselfeld Benutzer dupliziert.
• Fünf Jahre Historie am ersten Tag migrieren. Das ist das Rezept, um den Go-live zu verzögern. Laden Sie das operative Minimum und verschieben Sie die Historie auf einen späteren Import, wenn die Struktur bereits stabil ist.
• Den Cron im GLPI-Modus belassen. Oben ausführlich beschrieben: Eine blockierte Warteschlange wird als „Langsamkeit“ wahrgenommen.
• SMTP nicht mit einer echten E-Mail testen. Eine gespeicherte Konfiguration ist keine zugestellte Benachrichtigung. Testen Sie durchgängig vor der Freigabe.

Sie brauchen einen Go-live ohne Überraschungen? NexTool plant und führt GLPI-Einführungen für B2B-Kunden durch, von der Phasenplanung des Umfangs bis zur validierten Umgebung in Produktion. Lernen Sie den Service Projekte und Einführung kennen.

Geprüft vom Team der NexTool Solutions.