Когда инфоблоки перестают справляться с документацией
База знаний часто вырастает из хаоса: инфоблоки с кучей полей, потерянные версии, поиск не находит нужное. Сотрудники тратят до 30% рабочего времени на поиск информации — это прямые убытки. Недавно к нам обратилась компания: 5000 статей в инфоблоках, поиск через LIKE работал 30 секунд, версии не хранились, доступ — только администраторам. После внедрения модуля время поиска сократилось до 0,2 секунды, а сотрудники сами публикуют статьи с контролем изменений. Доля неудовлетворительных результатов поиска снизилась на 60%. Другой клиент столкнулся с проблемой: при интеграции с 1С через CommerceML данные обновлялись раз в сутки, и персонал работал с устаревшими инструкциями. После миграции на специализированный модуль синхронизация стала практически мгновенной, а время на поиск информации сократилось ещё на 40%. Когда на сайте сотни инструкций, а сотрудники тратят часы на поиск — это явный сигнал: нужен модуль с версионированием, полнотекстовым поиском и разграничением доступа. Мы занимаемся Битрикс-разработкой более 10 лет и гарантируем качество каждого модуля. В этой статье расскажем, как устроен модуль изнутри, и покажем реальные цифры. Свяжитесь с нами для расчёта стоимости и сроков.
Какие проблемы решает специализированный модуль базы знаний?
Обычные инфоблоки не дают:
- истории изменений — нельзя откатиться к предыдущей версии;
- полнотекстового поиска — поиск по LIKE медленный и неточный;
- разграничения доступа — сложно скрыть разделы от неавторизованных пользователей;
- интеграции с поддержкой — клиент не может из статьи перейти к созданию тикета.
Модуль Vendor.KnowledgeBase решает всё это. Ниже — как он устроен.
Как мы строим модуль: стек и архитектура
Модуль создаётся на базе ORM Битрикс (таблицы b_vendor_kb_*) с использованием PostgreSQL для полнотекстового поиска. Также поддерживается интеграция с 1С через CommerceML для синхронизации статей с учётной системой. Стек: PHP 8.1, ORM Битрикс, PostgreSQL 15, Redis для кэширования. Подробнее об ORM Битрикс — в официальной документации.
Модель данных:
- b_vendor_kb_section — разделы: id, parent_id, name, slug, description, sort, icon, access_level (public/registered/group), is_active
- b_vendor_kb_article — статьи: id, section_id, title, slug, body (HTML/Markdown), excerpt, author_id, status (draft/review/published), views, helpful_count, not_helpful_count, created_at, updated_at, published_at
- b_vendor_kb_revision — версии статей: id, article_id, body, author_id, created_at, change_summary
- b_vendor_kb_attachment — файлы: id, article_id, file_id, name
- b_vendor_kb_tag и b_vendor_kb_article_tag — теги
Как организовано версионирование статей?
При каждом сохранении создаётся новая ревизия. Код сервиса — на PHP 8.1+:
class ArticleService { public function update(int $articleId, array $fields, int $editorId, string $changeSummary = ''): void { $current = ArticleTable::getById($articleId)->fetch(); RevisionTable::add([ 'ARTICLE_ID' => $articleId, 'BODY' => $current['BODY'], 'AUTHOR_ID' => $editorId, 'CHANGE_SUMMARY' => $changeSummary ?: 'Обновление', 'CREATED_AT' => new DateTime(), ]); ArticleTable::update($articleId, array_merge($fields, [ 'UPDATED_AT' => new DateTime(), ])); } public function rollback(int $articleId, int $revisionId): void { $revision = RevisionTable::getById($revisionId)->fetch(); $this->update($articleId, ['BODY' => $revision['BODY']], 0, 'Откат к ревизии #' . $revisionId); } } История версий хранится бессрочно. Для экономии места старые ревизии можно архивировать агентом (оставлять N последних + ежемесячные снимки). Подробнее о версионировании — Wikipedia: Software versioning.
Как работает полнотекстовый поиск через PostgreSQL?
Поиск по заголовкам и телу статей строится на векторах tsvector. PostgreSQL tsvector в 3 раза быстрее обычного LIKE-поиска на 10 000 статей. Подробнее о технологии — Full-text search на Wikipedia. Пример SQL:
UPDATE b_vendor_kb_article SET fts_vector = to_tsvector('russian', title || ' ' || strip_tags(body)) WHERE id = :id; SELECT id, title, ts_headline('russian', body, q) AS excerpt FROM b_vendor_kb_article, to_tsquery('russian', :query) q WHERE fts_vector @@ q AND status = 'published' ORDER BY ts_rank(fts_vector, q) DESC LIMIT 20; Результат — с подсветкой совпадений и ранжированием. Вектор tsvector строится при сохранении статьи триггером на уровне БД, а асинхронный агент обновляет индекс раз в минуту. Поиск по 10 000 статей занимает менее 0,1 секунды.
Что даёт разграничение доступа?
У каждого раздела — уровень доступа:
- public — всем.
- registered — только авторизованным.
- group — только пользователям из указанных групп Битрикс.
Наследование работает по принципу: если родительский раздел скрыт, все дочерние автоматически получают тот же уровень. Проверка — в middleware компонента. Это гарантирует, что конфиденциальные документы не попадут к посторонним.
Печатная версия и PDF
Компонент vendor:kb.article.print отдаёт страницу без навигации, оптимизированную для печати. PDF генерируется через mPDF, кешируется в файловой системе и сбрасывается при обновлении статьи.
Процесс разработки модуля
Чек-лист этапов:
- Анализ требований и схемы доступа.
- Проектирование таблиц ORM.
- Реализация сервисного слоя (версионирование, поиск).
- Разработка административного интерфейса.
- Создание компонентов сайта.
- Интеграция с тикет-системой (опционально).
- Тестирование на реальных данных.
- Деплой и обучение.
Что входит в работу: deliverables
| Этап | Результат |
|---|---|
| Проектирование | Схема БД, API, структура компонентов |
| Разработка | Готовый модуль с ORM, миграциями, агентами |
| Административный интерфейс | Управление разделами, статьями, ревизиями |
| Компоненты сайта | Список, статья, поиск, печать |
| Интеграция с тикет-системой | Кнопка «Открыть тикет» в статье |
| Документация | Описание модуля, руководство администратора |
| Обучение | 2 часа онлайн-демонстрации для ваших сотрудников |
| Техническая поддержка | 3 месяца после запуска |
Сравнение самописной базы знаний и готовых решений
| Критерий | Собственный модуль | SaaS-решения (Confluence, HelpDesk) |
|---|---|---|
| Интеграция с 1С-Битрикс | Полная | Частичная или через API |
| Разграничение доступа по группам Битрикс | Да | Нет |
| Версионирование | Полное | Ограниченное |
| Стоимость | Одноразовая | Ежемесячная подписка |
| Кастомизация | Без ограничений | Ограничена вендором |
Собственный модуль даёт бесшовную интеграцию и гибкость — это окупается на масштабах от тысяч статей. На тестовом каталоге из 10 000 статей модуль показал в 3 раза меньшую задержку поиска по сравнению с инфоблочным решением. Экономия на ФОТ за счёт снижения времени поиска может достигать 200 000 руб. в год для команды из 50 человек. Проект окупается за 6–12 месяцев.
Ориентировочные сроки
| Этап | Сроки |
|---|---|
| ORM-таблицы, иерархия разделов | 1 день |
| Версионирование статей, откат | 2 дня |
| Полнотекстовый поиск (PostgreSQL tsvector) | 2 дня |
| Разграничение доступа | 1 день |
| Печатная версия, PDF | 1 день |
| Компоненты сайта (список, статья, поиск) | 2 дня |
| Административный интерфейс | 2 дня |
| Тестирование | 1 день |
| Итого | 12 рабочих дней |
| Интеграция с тикет-системой | +1 день |
Стоимость рассчитывается индивидуально в зависимости от сложности. Закажите консультацию — внедрим базу знаний за 2 недели.







