Conhecimento que vive na cabeça de um técnico morre quando ele sai - mas uma base de conhecimento mal configurada é pior: parece documentação e devolve zero resultado. Na sustentação de parques GLPI para clientes, os dois fracassos que mais vemos são artigos que ninguém encontra (problema de configuração) e artigos que ninguém escreve (problema de engajamento). Este guia trata os dois, com as queries e os ajustes que rodamos em campo.
Estruture a taxonomia antes do primeiro artigo
A base de conhecimento do GLPI é nativa (tabela glpi_knowbaseitems) e já traz categorias, FAQ, busca full-text, controle de visibilidade, histórico de revisões e vínculo a chamados. O erro comum é começar pelos artigos e deixar a árvore de categorias crescer sozinha: em seis meses você tem doze níveis e ninguém acha nada. Trave a estrutura primeiro:
- No máximo dois níveis de categoria. Se precisa de um terceiro, provavelmente é uma tag, não uma categoria.
- Títulos acionáveis: "Como resetar senha no AD" funciona melhor que "Active Directory". O usuário busca pela ação, não pelo sistema.
- Quatro famílias cobrem 90% dos casos: Como fazer (tutoriais), Solução de problemas (erros conhecidos), Políticas (regras) e FAQ (pública).
- Um artigo pode ficar em várias categorias no GLPI 10/11 (tabela glpi_knowbaseitems_knowbaseitemcategories). Use com parcimônia: categoria demais é o mesmo que categoria nenhuma.
O erro que faz artigos "sumirem": visibilidade
Na sustentação, a falha número 1 que encontramos não é falta de artigo - é artigo publicado que ninguém enxerga. O técnico escreve, salva, marca como publicado e assume que está no ar. Só que a visibilidade do GLPI é por alvo explícito: se ninguém adicionou um perfil, grupo, entidade ou usuário na aba de destinatários, o artigo fica visível apenas para o autor - e o GLPI não emite aviso nenhum. Já auditamos bases com centenas de artigos onde dezenas estavam nesse limbo. Por isso, no onboarding de sustentação, a primeira coisa que rodamos é a query de artigos órfãos de visibilidade, antes de discutir taxonomia ou engajamento:
-- 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;Um detalhe que só morde quem escreve essa query: os nomes das quatro tabelas de visibilidade não são simétricos. Usuários e perfis usam glpi_knowbaseitems_users e glpi_knowbaseitems_profiles, mas grupos e entidades invertem para glpi_groups_knowbaseitems e glpi_entities_knowbaseitems. Trocar a ordem é passar horas depurando um LEFT JOIN que nunca casa.
Por que "AD", "VM" e "PC" não retornam nada na busca
A busca da KB não é LIKE: o GLPI monta um MATCH(name, answer) AGAINST(... IN BOOLEAN MODE) sobre o índice FULLTEXT da tabela. No MariaDB/MySQL com InnoDB (padrão no GLPI 10 e 11), o parâmetro innodb_ft_min_token_size define o tamanho mínimo de palavra indexada, e o default é 3. Consequência: siglas de duas letras - "AD", "VM", "PC", "TI", "BD" - não entram no índice, e a busca por elas volta vazia mesmo havendo dezenas de artigos que as citam. Esse é o motivo número 1 do "a busca da KB não presta" que ouvimos de clientes. Diagnóstico:
SHOW VARIABLES LIKE 'innodb_ft_min_token_size';Baixe o limite para 2 no arquivo de configuração do MariaDB e reinicie o serviço:
# /etc/mysql/mariadb.conf.d/50-server.cnf (MariaDB)
[mysqld]
innodb_ft_min_token_size = 2A parte que quase todo mundo esquece: mudar a variável não reindexar os artigos existentes. O token size é gravado na criação do índice, então você precisa reconstruí-lo. A forma mais direta é forçar o rebuild da tabela:
-- Reinicie o MariaDB e reconstrua o indice FULLTEXT
-- (o novo token size so vale apos recriar o indice):
ALTER TABLE glpi_knowbaseitems ENGINE=InnoDB;O erro comum é baixar o token para 2, reiniciar e declarar vitória - a variável muda, mas o índice antigo continua ignorando as siglas até a reconstrução. Em instalações legadas em MyISAM, o parâmetro equivalente é ft_min_word_len.
Janela de validade: o artigo que só aparece amanhã
Outra armadilha silenciosa são os campos begin_date e end_date do artigo. O GLPI filtra da busca qualquer artigo cujo begin_date seja futuro ou cujo end_date já tenha passado. É útil para publicar um procedimento só a partir de uma data - mas também é a causa clássica de "criei o artigo e ele não aparece": alguém preencheu a data de início sem querer. Se um artigo recém-criado não surge na busca e a visibilidade está correta, confira a janela de validade antes de qualquer outra coisa.
FAQ pública para self-service
Para um artigo aparecer no portal do usuário final, marque-o como FAQ (campo is_faq) e defina a visibilidade por entidade com a opção recursiva ligada, para propagar às sub-entidades. Se você quer a FAQ acessível sem login, habilite a FAQ para usuários anônimos na configuração de Assistência do GLPI. A matriz que usamos para decidir onde cada artigo mora:
| Objetivo | is_faq | Alvo de visibilidade | Onde aparece |
|---|---|---|---|
| FAQ pública (self-service) | 1 | Entidade + recursivo | Portal do usuário; sem login se a FAQ anônima estiver ligada |
| Base técnica interna | 0 | Perfil (ex.: Técnico) | Aba Base de conhecimento, só perfis com direito |
| Procedimento por cliente | 0 | Entidade específica | Só técnicos daquela entidade |
| Rascunho / em revisão | 0 | Nenhum (só o autor) | Invisível - use por intenção, nunca por esquecimento |
Repare na última linha: "nenhum alvo" é um estado válido para rascunho, mas deve ser uma escolha consciente, nunca o resultado de esquecer de preencher a visibilidade.
Engajamento: o KPI que funciona (e o que não funciona)
O KPI de "X artigos por técnico por mês" que a literatura de ITSM adora produz lixo: artigo escrito para bater meta, que ninguém consulta. O que funciona na prática é amarrar a criação ao trabalho que já acontece - o fechamento de chamado de categoria recorrente. Em vez de pedir volume, identifique o repetitivo e transforme-o em artigo. Esta query lista os assuntos que mais se repetiram nos últimos 90 dias, os candidatos de maior retorno:
-- 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;Documentar o topo dessa lista derruba reabertura e tempo de atendimento de forma mensurável. E meça pelo lado certo: a coluna view de cada artigo conta as consultas. Artigo com muitas visualizações está pagando o investimento; artigo com view perto de zero e date_mod antigo é candidato a revisão ou arquivamento - não a mais um item no total.
Mantenha antes de envelhecer
Base de conhecimento não é projeto, é rotina. O GLPI guarda o histórico em glpi_knowbaseitems_revisions, então dá para editar sem medo de perder a versão anterior. Defina um ritmo de revisão (trimestral costuma bastar), priorizando os artigos mais consultados - um passo a passo errado sobre reset de senha gera mais chamado do que a ausência dele. Artigo desatualizado não é neutro: custa credibilidade e o técnico volta a "perguntar pro fulano".
Precisa de uma base de conhecimento que realmente reduza chamados, com a busca afinada e a visibilidade sob controle? Conheça a sustentação de GLPI da NexTool.
Revisado pela equipe NexTool Solutions.
