Wissen, welches nur im Kopf eines Technikers existiert, geht verloren, wenn er geht - doch eine schlecht konfigurierte Wissensdatenbank ist schlimmer: Sie sieht aus wie Dokumentation und liefert null Treffer. Im Betrieb von GLPI-Landschaften für Kunden sehen wir am häufigsten zwei Arten des Scheiterns: Artikel, die niemand findet (ein Konfigurationsproblem), und Artikel, die niemand schreibt (ein Engagement-Problem). Dieser Leitfaden behandelt beide, mit den Queries und Anpassungen, die wir in der Praxis einsetzen.
Strukturieren Sie die Taxonomie vor dem ersten Artikel
Die Wissensdatenbank von GLPI ist nativ (Tabelle glpi_knowbaseitems) und bringt bereits Kategorien, FAQ, Volltextsuche, Sichtbarkeitssteuerung, Revisionshistorie und Verknüpfung mit Tickets mit. Der häufige Fehler ist, mit den Artikeln zu beginnen und den Kategorienbaum von selbst wachsen zu lassen: Nach sechs Monaten haben Sie zwölf Ebenen, und niemand findet etwas. Legen Sie zuerst die Struktur fest:
- Höchstens zwei Ebenen an Kategorien. Wenn Sie eine dritte brauchen, ist es wahrscheinlich ein Tag, keine Kategorie.
- Handlungsorientierte Titel: "Passwort im AD zurücksetzen" funktioniert besser als "Active Directory". Benutzer suchen nach einer Aktion, nicht nach einem System.
- Vier Familien decken 90 % der Fälle ab: Anleitungen (Tutorials), Fehlerbehebung (bekannte Fehler), Richtlinien (Regeln) und FAQ (öffentlich).
- Ein Artikel kann in GLPI 10/11 in mehreren Kategorien stehen (Tabelle glpi_knowbaseitems_knowbaseitemcategories). Nutzen Sie dies sparsam: Zu viele Kategorien sind genauso schlecht wie gar keine.
Der Fehler, durch den Artikel "verschwinden": Sichtbarkeit
Im Betrieb ist der Fehler Nummer 1, auf den wir stoßen, nicht fehlende Artikel - sondern veröffentlichte Artikel, die niemand sieht. Ein Techniker schreibt, speichert, markiert als veröffentlicht und geht davon aus, dass sie online sind. Doch die Sichtbarkeit in GLPI erfolgt über explizite Ziele: Hat niemand ein Profil, eine Gruppe, eine Einheit oder einen Benutzer im Reiter der Empfänger hinzugefügt, ist ein Artikel nur für seinen Autor sichtbar - und GLPI gibt keinerlei Warnung aus. Wir haben bereits Datenbanken mit Hunderten von Artikeln geprüft, in denen Dutzende in diesem Schwebezustand waren. Deshalb führen wir beim Onboarding in den Betrieb als Erstes die Query für Artikel ohne Sichtbarkeitsziel aus, noch bevor wir über Taxonomie oder Engagement sprechen:
-- Artigos NAO-FAQ sem nenhum alvo de visibilidade:
-- existem, contam no total e sao invisiveis para todos, menos o autor.
SELECT k.id, k.name
FROM glpi_knowbaseitems k
LEFT JOIN glpi_knowbaseitems_profiles p ON p.knowbaseitems_id = k.id
LEFT JOIN glpi_knowbaseitems_users u ON u.knowbaseitems_id = k.id
LEFT JOIN glpi_groups_knowbaseitems g ON g.knowbaseitems_id = k.id
LEFT JOIN glpi_entities_knowbaseitems e ON e.knowbaseitems_id = k.id
WHERE k.is_faq = 0
AND p.knowbaseitems_id IS NULL
AND u.knowbaseitems_id IS NULL
AND g.knowbaseitems_id IS NULL
AND e.knowbaseitems_id IS NULL;Ein Detail, über welches nur stolpert, wer diese Query schreibt: Die Namen der vier Sichtbarkeitstabellen sind nicht symmetrisch. Benutzer und Profile verwenden glpi_knowbaseitems_users und glpi_knowbaseitems_profiles, Gruppen und Einheiten kehren die Reihenfolge jedoch um: glpi_groups_knowbaseitems und glpi_entities_knowbaseitems. Wer die Reihenfolge vertauscht, verbringt Stunden mit dem Debuggen eines LEFT JOIN, der nie greift.
Warum "AD", "VM" und "PC" in der Suche nichts liefern
Die Suche der Wissensdatenbank ist kein LIKE: GLPI baut ein MATCH(name, answer) AGAINST(... IN BOOLEAN MODE) auf dem FULLTEXT-Index der Tabelle. In MariaDB/MySQL mit InnoDB (Standard in GLPI 10 und 11) legt der Parameter innodb_ft_min_token_size die minimale Länge indexierter Wörter fest, und der Standardwert ist 3. Folge: Abkürzungen aus zwei Buchstaben - "AD", "VM", "PC", "IT", "DB" - kommen nicht in den Index, und die Suche danach bleibt leer, selbst wenn Dutzende Artikel sie erwähnen. Dies ist der Grund Nummer 1 für das "die Suche der Wissensdatenbank taugt nichts", welches wir von Kunden hören. Diagnose:
SHOW VARIABLES LIKE 'innodb_ft_min_token_size';Senken Sie den Grenzwert in der Konfigurationsdatei von MariaDB auf 2 und starten Sie den Dienst neu:
# /etc/mysql/mariadb.conf.d/50-server.cnf (MariaDB)
[mysqld]
innodb_ft_min_token_size = 2Was fast alle vergessen: Eine Änderung der Variable indexiert die bestehenden Artikel nicht neu. Die Token-Größe wird bei der Erstellung des Index festgeschrieben, also müssen Sie ihn neu aufbauen. Am direktesten erzwingen Sie einen Rebuild der Tabelle:
-- Reinicie o MariaDB e reconstrua o indice FULLTEXT
-- (o novo token size so vale apos recriar o indice):
ALTER TABLE glpi_knowbaseitems ENGINE=InnoDB;Der häufige Fehler ist, das Token auf 2 zu senken, neu zu starten und den Sieg zu verkünden - die Variable ändert sich, aber der alte Index ignoriert die Abkürzungen bis zum Neuaufbau weiter. In Legacy-Installationen mit MyISAM heißt der entsprechende Parameter ft_min_word_len.
Gültigkeitszeitraum: der Artikel, der erst morgen erscheint
Eine weitere stille Falle sind die Felder begin_date und end_date eines Artikels. GLPI filtert jeden Artikel aus der Suche, dessen begin_date in der Zukunft liegt oder dessen end_date bereits vergangen ist. Dies ist nützlich, um ein Verfahren erst ab einem bestimmten Datum zu veröffentlichen - aber auch die klassische Ursache für "ich habe einen Artikel erstellt und er erscheint nicht": Jemand hat versehentlich ein Startdatum eingetragen. Wenn ein neu erstellter Artikel nicht in der Suche auftaucht und die Sichtbarkeit korrekt ist, prüfen Sie vor allem anderen den Gültigkeitszeitraum.
Öffentliche FAQ für Self-Service
Damit ein Artikel im Portal der Endbenutzer erscheint, markieren Sie ihn als FAQ (Feld is_faq) und legen Sie die Sichtbarkeit nach Einheit mit aktivierter rekursiver Option fest, damit sie an Untereinheiten weitergegeben wird. Wenn die FAQ ohne Anmeldung zugänglich sein soll, aktivieren Sie die FAQ für anonyme Benutzer in der Support-Konfiguration (Assistance) von GLPI. Die Matrix, mit der wir entscheiden, wo jeder Artikel liegt:
| Ziel | is_faq | Sichtbarkeitsziel | Wo er erscheint |
|---|---|---|---|
| Öffentliche FAQ (Self-Service) | 1 | Einheit + rekursiv | Benutzerportal; ohne Anmeldung, wenn die anonyme FAQ aktiviert ist |
| Interne technische Wissensbasis | 0 | Profil (z. B. Techniker) | Reiter Wissensdatenbank, nur Profile mit Berechtigung |
| Verfahren je Kunde | 0 | Bestimmte Einheit | Nur Techniker dieser Einheit |
| Entwurf / in Prüfung | 0 | Keines (nur der Autor) | Unsichtbar - bewusst einsetzen, nie aus Vergesslichkeit |
Beachten Sie die letzte Zeile: "Kein Ziel" ist ein gültiger Zustand für einen Entwurf, muss aber eine bewusste Entscheidung sein, nie die Folge davon, dass die Sichtbarkeit vergessen wurde.
Engagement: die KPI, die funktioniert (und die, die es nicht tut)
Die KPI "X Artikel pro Techniker pro Monat", welche die ITSM-Literatur so liebt, produziert Müll: Artikel, die geschrieben werden, um ein Ziel zu erreichen, und die niemand liest. In der Praxis funktioniert es, die Erstellung an Arbeit zu koppeln, die ohnehin anfällt - den Abschluss von Tickets wiederkehrender Kategorien. Statt Menge zu verlangen, identifizieren Sie Wiederkehrendes und machen Sie daraus einen Artikel. Diese Query listet die Themen, die sich in den letzten 90 Tagen am häufigsten wiederholt haben, also die Kandidaten mit dem größten Nutzen:
-- Assuntos de chamado repetidos nos ultimos 90 dias:
-- os candidatos de maior retorno para virar artigo de KB.
SELECT t.name AS assunto, COUNT(*) AS total
FROM glpi_tickets t
WHERE t.date >= DATE_SUB(NOW(), INTERVAL 90 DAY)
AND t.is_deleted = 0
GROUP BY t.name
HAVING total >= 5
ORDER BY total DESC
LIMIT 20;Wer die Spitze dieser Liste dokumentiert, senkt Wiedereröffnungen und Bearbeitungszeit messbar. Und messen Sie auf der richtigen Seite: Die Spalte view jedes Artikels zählt die Aufrufe. Ein Artikel mit vielen Aufrufen zahlt die Investition zurück; ein Artikel mit view nahe null und altem date_mod ist ein Kandidat für Überarbeitung oder Archivierung - nicht für einen weiteren Eintrag in der Gesamtzahl.
Pflegen Sie, bevor es veraltet
Eine Wissensdatenbank ist kein Projekt, sondern Routine. GLPI speichert die Historie in glpi_knowbaseitems_revisions, Sie können also bearbeiten, ohne Angst zu haben, die vorherige Version zu verlieren. Legen Sie einen Prüfrhythmus fest (vierteljährlich genügt meist) und priorisieren Sie die meistgelesenen Artikel - eine falsche Schritt-für-Schritt-Anleitung zum Zurücksetzen von Passwörtern erzeugt mehr Tickets als gar keine. Ein veralteter Artikel ist nicht neutral: Er kostet Glaubwürdigkeit, und Techniker fangen wieder an, "den Kollegen zu fragen".
Sie brauchen eine Wissensdatenbank, die Tickets wirklich reduziert, mit fein abgestimmter Suche und kontrollierter Sichtbarkeit? Lernen Sie den GLPI-Betrieb von NexTool kennen.
Geprüft vom Team der NexTool Solutions.
