La conoscenza che vive nella testa di un tecnico muore quando lui se ne va - ma una base di conoscenza mal configurata è peggio: sembra documentazione e restituisce zero risultati. Nella manutenzione di parchi GLPI per i clienti, i due fallimenti che vediamo più spesso sono articoli che nessuno trova (problema di configurazione) e articoli che nessuno scrive (problema di coinvolgimento). Questa guida affronta entrambi, con le query e le regolazioni che eseguiamo sul campo.
Progetta la tassonomia prima del primo articolo
La base di conoscenza di GLPI è nativa (tabella glpi_knowbaseitems) e include già categorie, FAQ, ricerca full-text, controllo di visibilità, cronologia delle revisioni e collegamento ai ticket. L'errore comune è partire dagli articoli e lasciar crescere da solo l'albero delle categorie: dopo sei mesi hai dodici livelli e nessuno trova più nulla. Blocca prima la struttura:
- Al massimo due livelli di categoria. Se ne serve un terzo, probabilmente è un tag, non una categoria.
- Titoli orientati all'azione: "Come reimpostare la password AD" funziona meglio di "Active Directory". L'utente cerca per azione, non per sistema.
- Quattro famiglie coprono il 90% dei casi: Come fare (tutorial), Risoluzione dei problemi (errori noti), Politiche (regole) e FAQ (pubblica).
- Un articolo può stare in più categorie in GLPI 10/11 (tabella glpi_knowbaseitems_knowbaseitemcategories). Usalo con parsimonia: troppe categorie equivalgono a nessuna.
L'errore che fa "sparire" gli articoli: la visibilità
In manutenzione, il guasto numero 1 che troviamo non è la mancanza di articolo - è un articolo pubblicato che nessuno vede. Il tecnico lo scrive, lo salva, lo contrassegna come pubblicato e dà per scontato che sia online. Ma la visibilità di GLPI funziona per destinazione esplicita: se nessuno ha aggiunto un profilo, un gruppo, un'entità o un utente nella scheda dei destinatari, l'articolo è visibile solo al suo autore - e GLPI non emette alcun avviso. Abbiamo verificato basi con centinaia di articoli dove decine erano in quel limbo. Per questo, nell'onboarding di manutenzione, la prima cosa che eseguiamo è la query degli articoli orfani di visibilità, prima di parlare di tassonomia o coinvolgimento:
-- Articoli NON-FAQ senza alcuna destinazione di visibilita:
-- esistono, contano nel totale e sono invisibili a tutti, tranne l'autore.
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;Un dettaglio che morde solo chi scrive questa query: i nomi delle quattro tabelle di visibilità non sono simmetrici. Utenti e profili usano glpi_knowbaseitems_users e glpi_knowbaseitems_profiles, ma gruppi ed entità si invertono in glpi_groups_knowbaseitems e glpi_entities_knowbaseitems. Scambiare l'ordine significa passare ore a fare il debug di un LEFT JOIN che non combacia mai.
Perché "AD", "VM" e "PC" non restituiscono nulla nella ricerca
La ricerca della KB non è un LIKE: GLPI costruisce un MATCH(name, answer) AGAINST(... IN BOOLEAN MODE) sull'indice FULLTEXT della tabella. Su MariaDB/MySQL con InnoDB (predefinito in GLPI 10 e 11), innodb_ft_min_token_size definisce la lunghezza minima di parola indicizzata, e il valore predefinito è 3. Conseguenza: le sigle di due lettere - "AD", "VM", "PC", "IT", "DB" - non entrano nell'indice, e cercarle restituisce vuoto anche se ci sono decine di articoli che le citano. È il motivo numero 1 del "la ricerca della KB non serve a nulla" che sentiamo dai clienti. Diagnosi:
SHOW VARIABLES LIKE 'innodb_ft_min_token_size';Abbassa il limite a 2 nel file di configurazione di MariaDB e riavvia il servizio:
# /etc/mysql/mariadb.conf.d/50-server.cnf (MariaDB)
[mysqld]
innodb_ft_min_token_size = 2La parte che quasi tutti dimenticano: cambiare la variabile non reindicizzare gli articoli esistenti. Il token size viene scritto alla creazione dell'indice, quindi devi ricostruirlo. Il modo più diretto è forzare la ricostruzione della tabella:
-- Riavvia MariaDB e ricostruisci l'indice FULLTEXT
-- (il nuovo token size vale solo dopo aver ricreato l'indice):
ALTER TABLE glpi_knowbaseitems ENGINE=InnoDB;L'errore comune è abbassare il token a 2, riavviare e cantare vittoria - la variabile cambia, ma il vecchio indice continua a ignorare le sigle fino alla ricostruzione. Nelle installazioni legacy in MyISAM, il parametro equivalente è ft_min_word_len.
Finestra di validità: l'articolo che appare solo domani
Un'altra trappola silenziosa sono i campi begin_date ed end_date dell'articolo. GLPI esclude dalla ricerca qualsiasi articolo il cui begin_date è nel futuro o il cui end_date è già passato. È utile per pubblicare una procedura solo a partire da una data - ma è anche la causa classica di "ho creato l'articolo e non appare": qualcuno ha compilato una data di inizio per errore. Se un articolo appena creato non emerge nella ricerca e la visibilità è corretta, controlla la finestra di validità prima di ogni altra cosa.
FAQ pubblica per il self-service
Perché un articolo compaia nel portale dell'utente finale, contrassegnalo come FAQ (campo is_faq) e imposta la visibilità per entità con l'opzione ricorsiva attiva, per propagarla alle sotto-entità. Se vuoi la FAQ accessibile senza login, abilita la FAQ per gli utenti anonimi nelle impostazioni di Assistenza di GLPI. La matrice che usiamo per decidere dove vive ogni articolo:
| Obiettivo | is_faq | Destinazione di visibilità | Dove appare |
|---|---|---|---|
| FAQ pubblica (self-service) | 1 | Entità + ricorsivo | Portale dell'utente; senza login se la FAQ anonima è attiva |
| Base tecnica interna | 0 | Profilo (es. Tecnico) | Scheda Base di conoscenza, solo profili autorizzati |
| Procedura per cliente | 0 | Entità specifica | Solo i tecnici di quell'entità |
| Bozza / in revisione | 0 | Nessuna (solo l'autore) | Invisibile - usala di proposito, mai per dimenticanza |
Nota l'ultima riga: "nessuna destinazione" è uno stato valido per una bozza, ma dev'essere una scelta consapevole, mai il risultato di una visibilità dimenticata.
Coinvolgimento: il KPI che funziona (e quello che no)
Il KPI "X articoli per tecnico al mese" che la letteratura ITSM adora produce spazzatura: articoli scritti per raggiungere un numero che nessuno consulta. Ciò che funziona in pratica è legare la creazione al lavoro che già avviene - la chiusura di ticket di categorie ricorrenti. Invece di pretendere volume, individua il ripetitivo e trasformalo in articolo. Questa query elenca gli oggetti che si sono ripetuti di più negli ultimi 90 giorni, i candidati a maggior ritorno:
-- Oggetti di ticket ripetuti negli ultimi 90 giorni:
-- i candidati a maggior ritorno per diventare articoli della KB.
SELECT t.name AS oggetto, COUNT(*) AS totale
FROM glpi_tickets t
WHERE t.date >= DATE_SUB(NOW(), INTERVAL 90 DAY)
AND t.is_deleted = 0
GROUP BY t.name
HAVING totale >= 5
ORDER BY totale DESC
LIMIT 20;Documentare la cima di quell'elenco riduce le riaperture e il tempo di gestione in modo misurabile. E misura dal lato giusto: la colonna view di ogni articolo conta le consultazioni. Un articolo molto consultato sta ripagando l'investimento; un articolo con view vicino a zero e date_mod vecchio è candidato a revisione o archiviazione - non a un elemento in più nel totale.
Manutienila prima che invecchi
Una base di conoscenza non è un progetto, è una routine. GLPI conserva la cronologia in glpi_knowbaseitems_revisions, quindi puoi modificare senza timore di perdere la versione precedente. Fissa un ritmo di revisione (trimestrale di solito basta), dando priorità agli articoli più consultati - un passo-passo errato sul reset della password genera più ticket della sua assenza. Un articolo obsoleto non è neutro: costa credibilità e il tecnico torna a "chiedere al tale".
Ti serve una base di conoscenza che riduca davvero i ticket, con la ricerca affinata e la visibilità sotto controllo? Scopri il servizio di manutenzione GLPI di NexTool.
Revisionato dal team NexTool Solutions.
