Знания, которые живут в голове одного специалиста, умирают, когда он уходит, - но плохо настроенная база знаний ещё хуже: она выглядит как документация и возвращает ноль результатов. При сопровождении парков GLPI клиентов мы чаще всего видим два провала: статьи, которые никто не может найти (проблема конфигурации), и статьи, которые никто не пишет (проблема вовлечённости). Это руководство разбирает оба - с запросами и настройками, которые мы применяем на практике.
Выстройте таксономию до первой статьи
База знаний GLPI встроенная (таблица glpi_knowbaseitems) и уже включает категории, FAQ, полнотекстовый поиск, управление видимостью, историю ревизий и привязку к заявкам. Типичная ошибка - начать со статей и позволить дереву категорий расти самому: через полгода у вас двенадцать уровней, и никто ничего не находит. Сначала зафиксируйте структуру:
- Не более двух уровней категорий. Если нужен третий, скорее всего, это тег, а не категория.
- Заголовки, описывающие действие: «Как сбросить пароль в AD» работает лучше, чем «Active Directory». Пользователь ищет по действию, а не по системе.
- Четыре семейства покрывают 90% случаев: Как сделать (инструкции), Устранение неполадок (известные ошибки), Политики (правила) и FAQ (публичный).
- Статья может находиться в нескольких категориях в GLPI 10/11 (таблица glpi_knowbaseitems_knowbaseitemcategories). Пользуйтесь этим умеренно: слишком много категорий - то же, что ни одной.
Ошибка, из-за которой статьи «исчезают»: видимость
При сопровождении сбой номер 1, который мы находим, - не отсутствие статей, а опубликованные статьи, которые никто не видит. Специалист пишет, сохраняет, отмечает как опубликованную и считает, что она доступна. Но видимость в GLPI задаётся явными целями: если никто не добавил профиль, группу, организацию или пользователя на вкладке получателей, статья видна только автору - и GLPI не выдаёт никакого предупреждения. Мы проверяли базы с сотнями статей, где десятки находились в таком подвешенном состоянии. Поэтому при подключении к сопровождению первым делом мы запускаем запрос статей без целей видимости - ещё до обсуждения таксономии или вовлечённости:
-- 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;Деталь, на которой спотыкаются только те, кто пишет этот запрос: имена четырёх таблиц видимости несимметричны. Пользователи и профили используют glpi_knowbaseitems_users и glpi_knowbaseitems_profiles, а у групп и организаций порядок обратный: glpi_groups_knowbaseitems и glpi_entities_knowbaseitems. Перепутаете порядок - и часами будете отлаживать LEFT JOIN, который никогда не совпадает.
Почему «AD», «VM» и «PC» ничего не находят в поиске
Поиск по базе знаний - это не LIKE: GLPI строит MATCH(name, answer) AGAINST(... IN BOOLEAN MODE) по индексу FULLTEXT таблицы. В MariaDB/MySQL с InnoDB (по умолчанию в GLPI 10 и 11) параметр innodb_ft_min_token_size задаёт минимальную длину индексируемого слова, и значение по умолчанию - 3. Следствие: двухбуквенные аббревиатуры - «AD», «VM», «PC», «TI», «BD» - в индекс не попадают, и поиск по ним возвращается пустым, даже если их упоминают десятки статей. Это причина номер 1 жалоб «поиск по базе знаний никуда не годится», которые мы слышим от клиентов. Диагностика:
SHOW VARIABLES LIKE 'innodb_ft_min_token_size';Понизьте предел до 2 в конфигурационном файле MariaDB и перезапустите службу:
# /etc/mysql/mariadb.conf.d/50-server.cnf (MariaDB)
[mysqld]
innodb_ft_min_token_size = 2Часть, о которой забывают почти все: изменение переменной не переиндексирует существующие статьи. Размер токена фиксируется при создании индекса, поэтому индекс нужно перестроить. Самый прямой способ - принудительно перестроить таблицу:
-- Reinicie o MariaDB e reconstrua o indice FULLTEXT
-- (o novo token size so vale apos recriar o indice):
ALTER TABLE glpi_knowbaseitems ENGINE=InnoDB;Типичная ошибка - понизить токен до 2, перезапустить и объявить победу: переменная меняется, но старый индекс продолжает игнорировать аббревиатуры до перестроения. В устаревших установках на MyISAM аналогичный параметр - ft_min_word_len.
Окно действия: статья, которая появится только завтра
Другая тихая ловушка - поля статьи begin_date и end_date. GLPI исключает из поиска любую статью, у которой begin_date в будущем или end_date уже прошла. Это полезно, чтобы опубликовать процедуру начиная с определённой даты, - но это и классическая причина ситуации «создал статью, а она не появляется»: кто-то случайно заполнил дату начала. Если только что созданная статья не находится поиском, а видимость настроена верно, прежде всего проверьте окно действия.
Публичный FAQ для self-service
Чтобы статья появилась на портале конечного пользователя, отметьте её как FAQ (поле is_faq) и задайте видимость по организации с включённой рекурсивной опцией, чтобы она распространялась на дочерние организации. Если нужен FAQ без входа в систему, включите FAQ для анонимных пользователей в настройках раздела Поддержка GLPI. Матрица, по которой мы решаем, где живёт каждая статья:
| Цель | is_faq | Цель видимости | Где отображается |
|---|---|---|---|
| Публичный FAQ (self-service) | 1 | Организация + рекурсивно | Портал пользователя; без входа, если включён анонимный FAQ |
| Внутренняя техническая база | 0 | Профиль (напр., Технический специалист) | Вкладка База знаний, только профили с правом доступа |
| Процедура для конкретного клиента | 0 | Конкретная организация | Только специалисты этой организации |
| Черновик / на ревизии | 0 | Нет (только автор) | Невидима - используйте намеренно, а не по забывчивости |
Обратите внимание на последнюю строку: «нет целей» - допустимое состояние для черновика, но это должен быть осознанный выбор, а не результат того, что видимость забыли заполнить.
Вовлечённость: KPI, который работает (и который нет)
KPI «X статей на специалиста в месяц», который так любит литература по ITSM, порождает мусор: статьи, написанные ради выполнения плана, которые никто не читает. На практике работает привязка создания статей к уже идущей работе - закрытию заявок повторяющихся категорий. Вместо того чтобы требовать объём, выявляйте повторяющееся и превращайте его в статью. Этот запрос выводит темы, которые чаще всего повторялись за последние 90 дней, - кандидатов с наибольшей отдачей:
-- 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;Документирование верхушки этого списка измеримо снижает число повторных открытий и время обработки. И измеряйте с правильной стороны: столбец view каждой статьи считает просмотры. Статья с большим числом просмотров окупает вложения; статья с view около нуля и давней date_mod - кандидат на ревизию или архивирование, а не ещё одна единица в общем счёте.
Поддерживайте актуальность до того, как статьи устареют
База знаний - не проект, а рутина. GLPI хранит историю в glpi_knowbaseitems_revisions, так что редактировать можно без страха потерять предыдущую версию. Задайте ритм ревизий (обычно достаточно ежеквартального), начиная с самых просматриваемых статей: неверная пошаговая инструкция по сбросу пароля порождает больше заявок, чем её отсутствие. Устаревшая статья не нейтральна: она стоит доверия, и специалист снова начинает «спрашивать у коллеги».
Нужна база знаний, которая действительно сокращает число заявок, с настроенным поиском и видимостью под контролем? Узнайте о сопровождении GLPI от NexTool.
Проверено командой NexTool Solutions.
