NexTool Solutions

Die meisten Service Desks arbeiten reaktiv: Sie warten, bis das Ticket eintrifft, und eilen dann zur Lösung. Der Service-Desk-Trichter kehrt diese Logik um – jede Schicht filtert die Nachfrage, bevor sie beim Techniker ankommt. Im GLPI ist der Trichter kein Schalter, den man umlegt: Er ist ein Zusammenspiel aus Kategorien, Geschäftsregeln, Wissensdatenbank und Cron, das gemessen und justiert werden muss. Dieser Leitfaden zeigt, wie Sie jede Schicht mit den Bordmitteln des GLPI aufbauen, und welche Stolperfallen wir im Betriebssupport von Kundenumgebungen schon ganze Trichter zu Fall bringen sahen.

Bevor Sie den Trichter aufbauen: Messen Sie, woher das Volumen kommt

Der häufigste Fehler ist, den Trichter von hinten nach vorne aufzubauen: Dutzende generische Artikel und Formulare anlegen und hoffen, dass sie die Tickets reduzieren. Im Betriebssupport gehen wir umgekehrt vor – zuerst herausfinden, welche Kategorien das Volumen bündeln, denn dort bringt jede Schicht echten Nutzen. Die folgende Abfrage, ausgeführt mit einem Nur-Lese-Benutzer, listet die Kategorien mit der meisten Nachfrage in den letzten 90 Tagen und trennt Störung von Anfrage – die Unterscheidung, die entscheidet, ob die Nachfrage in den Self-Service oder an den 1st Level geht:

-- Top categorias por volume (últimos 90 dias): onde as camadas de
-- prevenção e autoatendimento têm o maior retorno. Usar usuário somente-leitura.
-- type: 1 = incidente, 2 = requisição
SELECT
    COALESCE(c.completename, '(sem categoria)') AS categoria,
    COUNT(*)        AS chamados,
    SUM(t.type = 1) AS incidentes,
    SUM(t.type = 2) AS requisicoes
FROM glpi_tickets t
LEFT JOIN glpi_itilcategories c ON c.id = t.itilcategories_id
WHERE t.is_deleted = 0
  AND t.date >= DATE_SUB(CURDATE(), INTERVAL 90 DAY)
GROUP BY t.itilcategories_id
ORDER BY chamados DESC
LIMIT 15;

Daraus ergeben sich zwei Erkenntnisse. Kategorien mit wiederkehrenden Anfragen (Passwort-Reset, Zugriffsfreigabe, Standardinstallation) sind Kandidaten für Self-Service und Automatisierung: Der Benutzer sollte dafür keinen Techniker brauchen. Störungskategorien mit hohem Volumen deuten auf wiederkehrende Fehler hin, die die Präventionsschicht abfangen sollte, bevor der Benutzer sie bemerkt. Und wenn „(sem categoria)“ ganz oben steht, liegt das Problem vor dem Trichter: Die Triage ist ungeregelt, und keine Regel kann routen, was nicht klassifiziert wurde.

Die Entscheidungsmatrix: jede Nachfrage in ihrer Schicht

Ein Trichter ist keine Personenhierarchie, sondern Routing der Nachfrage. Jede Art von Nachfrage hat die richtige Schicht und einen nativen GLPI-Mechanismus, der sie trägt. Die folgende Matrix ist der Ausgangspunkt, den wir beim Entwurf des Trichters eines Kunden verwenden:

Schicht 1 – Prävention: das Ticket, das aus dem Monitoring entsteht

Ziel dieser Schicht ist das Ticket, das das Team (oder das System selbst) erstellt, bevor der Benutzer das Problem bemerkt. In der Praxis:

• Das Monitoring erstellt das Ticket: Zabbix, GLPI Agent oder ein anderer Collector löst per E-Mail (Collector) oder API ein Ticket aus, wenn ein Schwellenwert überschritten wird – Festplatte bei 90 %, gestoppter Dienst, ablaufendes Zertifikat. Das Ticket kommt bereits kategorisiert in der Infrastrukturgruppe an.
• Angekündigte geplante Wartung: Vor einem Wartungsfenster verhindern eine Ankündigung im Portal und eine Benachrichtigung die Flut von „Ist das System down?“.
• Behebung der Ursache: Störungen, die sich wiederholen, werden im GLPI zu einem Problem (Problem), das einmal behandelt wird statt N gleicher Tickets.

Der Gewinn ist messbar: Die Präventionsrate ist der Anteil der Störungen, deren erste Erfassung vom Monitoring kam und nicht vom Benutzer. Die Integration von Zabbix mit dem GLPI ist der direkteste Weg zu dieser Schicht.

Schicht 2 – Self-Service: Veröffentlichen ist nicht dasselbe wie Erscheinen

Hier liegt die Stolperfalle, die wir die Self-Service-Schicht am häufigsten haben scheitern sehen: Das Team schreibt Dutzende Artikel, und trotzdem zeigt das Self-Service-Portal dem Benutzer nichts an. Im GLPI erscheint ein Artikel nur dann in der öffentlichen FAQ, wenn drei Bedingungen zusammentreffen:

1. Der Artikel ist veröffentlicht (mit Beginn des Gültigkeitszeitraums, kein Entwurf);
2. er ist als in der FAQ sichtbar markiert (das Feld is_faq);
3. er hat eine definierte Zielgruppe, die das Self-Service-Profil (oder „alle“) einschließt – ohne Zielgruppe ist der Artikel nur für seinen Ersteller sichtbar.

Fehlt eine der drei, existiert der Artikel in der Datenbank, ist aber für diejenigen unsichtbar, die ihn brauchen. Hinzu kommt die Sichtbarkeit der Kategorie: Eine Kategorie, die nicht als im Helpdesk sichtbar markiert ist, erscheint nicht im Formular zur Ticketerstellung, sodass der Benutzer sich dort gar nicht erst selbst helfen kann. Neben Artikeln umfasst diese Schicht geführte Formulare (Passwort-Reset, standardisierte Anfragen), die ohne Eingriff lösen oder routen. Beginnen Sie die Wissensdatenbank mit den Kategorien, die das SQL oben an der Spitze gezeigt hat, nicht mit dem Produkthandbuch von A bis Z.

Schicht 3 – Lösung: Routing per Regel, nicht per E-Mail

Was weder verhindert noch per Self-Service gelöst wurde, muss schnell bei dem ankommen, der es löst – und zwar beim Richtigen. Der Motor hier sind die Geschäftsregeln für Tickets (RuleTicket): Sie weisen Gruppe, Kategorie, Priorität und SLA anhand von Kriterien zu (Kategorie, Quelle, Wort im Titel, Anforderer). Routing per Regel ist nachvollziehbar und reproduzierbar; Routing nach dem Muster „leite die E-Mail an Herrn X weiter“ skaliert nicht und verschwindet, sobald Herr X in Urlaub geht. Die folgende Abfrage listet die aktiven Ticketregeln in der Reihenfolge, in der das GLPI sie ausführt:

-- Regras de negócio de chamado (RuleTicket) ativas, na ordem de execução.
-- O GLPI processa por `ranking`; uma ação "parar de processar" numa
-- regra anterior impede as seguintes de rodar. Usar usuário somente-leitura.
SELECT ranking, name, `match` AS operador_criterios, is_active
FROM glpi_rules
WHERE sub_type = 'RuleTicket'
  AND is_active = 1
ORDER BY ranking;

Die Reihenfolge (Spalte ranking) ist wichtig, weil eine Aktion „Verarbeitung beenden“ die nachfolgenden Regeln unterbricht. Der übliche Fehler ist, eine neue Regel am Ende der Warteschlange anzulegen, in der Erwartung, dass sie die Priorität anpasst, ohne zu bemerken, dass eine vorherige Regel mit aktiviertem „Verarbeitung beenden“ das Routing bereits abgeschlossen hat – die neue läuft nie. Die Stufen 1st/2nd/3rd Level sind Gruppen; die Eskalation zwischen ihnen ist Regel plus SLA nach Priorität, keine manuelle Einzelfallentscheidung.

Der Fehler, der jeden Trichter zu Fall bringt: die Automatisierung, die nie auslöst

Sie können alle drei Schichten sorgfältig aufbauen, und trotzdem passiert nichts von selbst. SLA-Eskalation, Versand von Benachrichtigungen, automatisches Schließen gelöster Tickets, Warnungen – all das hängt im GLPI von den Automatischen Aktionen (CronTask) ab, und diese laufen nur zuverlässig, wenn ein externer Cron des Betriebssystems das GLPI aufruft. Im Standardmodus „GLPI“ (Auslösung durch Webnavigation) laufen die Aktionen unregelmäßig, hängen davon ab, dass jemand die Oberfläche aufruft, und blockieren unter Last. Das klassische Symptom, das wir betreuen: „Das SLA eskaliert nicht“, „die Benachrichtigung kommt nicht an“, „das Ticket schließt sich nicht von selbst“ – und die Ursache ist fast immer dieselbe. Die folgende Zeile löst das (passen Sie den Pfad an das Stammverzeichnis Ihres GLPI und den PHP-Benutzer an):

# GLPI - ação automática EXTERNA, a cada 1 minuto, como usuário do PHP.
# Sem isto, SLA/escalonamento, notificações e fechamento automático NÃO rodam.
# Ajuste o caminho para a raiz do seu GLPI (GLPI 10 e 11 usam front/cron.php).
* * * * * www-data /usr/bin/php /var/www/html/glpi/front/cron.php >/dev/null 2>&1

Stellen Sie anschließend unter Einrichten > Automatische Aktionen den Modus der Aufgaben von „GLPI“ auf „CLI“ um. Ohne diesen Schritt bleibt ein Großteil des Trichters reine Dekoration.

Aus dem Betriebssupport: der Trichter, der nur auf dem Papier existierte

Bei der Übernahme des Betriebssupports einer bereits laufenden Umgebung fanden wir das häufigste Szenario überhaupt vor: Der Trichter war auf der Folie entworfen, aber nicht im System. Die Wissensdatenbank hatte über hundert Artikel – alle als Entwurf gespeichert, keiner als FAQ markiert oder mit Zielgruppe versehen, sodass das Self-Service-Portal für den Benutzer leer erschien. Die Zuweisungsregeln existierten, aber bei der dritten war „Verarbeitung beenden“ aktiviert, und sie schluckte die Hälfte der Tickets in die falsche Gruppe. Und der externe Cron war nie eingerichtet worden, also eskalierte das SLA nicht und das automatische Schließen stand still – der Rückstau wuchs mit gelösten Tickets, die niemand bestätigte. Wir haben das SQL zum Volumen pro Kategorie ausgeführt, bevor wir irgendetwas anfassten: Passwort-Reset und VPN machten einen Großteil des Gesamtvolumens aus. Wir haben ein halbes Dutzend Artikel dieser beiden Kategorien veröffentlicht und als FAQ markiert, die Reihenfolge der Regeln korrigiert und den externen Cron aktiviert. Innerhalb weniger Wochen sank das Volumen dieser Kategorien im selben Bericht sichtbar – nicht weil das Problem verschwunden war, sondern weil es nicht mehr zum Ticket wurde. Der Trichter war nicht neu; er hatte nur nie das Papier verlassen.

Beim Aufbau des Trichters im GLPI geht es weniger um Plugins als um Reihenfolge: das Volumen messen, per Regel routen, den Self-Service wirklich veröffentlichen und sicherstellen, dass die Automatisierung auslöst. Der GLPI-Betriebssupport von NexTool umfasst genau diesen Entwurf – von der Kategorienmatrix über die Regeln bis zum Cron – und die monatliche Begleitung, die zeigt, wie jede Schicht die Nachfrage reduziert, die beim Techniker ankommt.

Geprüft vom Team der NexTool Solutions.