Жалобы на поиск в коробочном Битрикс24 обычно звучат двумя фразами. Первая: «ищет по десять секунд». Вторая: «клиент точно есть, а поиск его не находит». Пока в CRM несколько тысяч контактов, никто об этом не думает. Проблемы начинаются, когда база переваливает за сотни тысяч записей, к порталу подключены склад, документы и несколько лет переписки, а на сервере параллельно работают интеграции с 1С и телефонией. Руководитель видит одно: менеджер ищет клиента дольше, чем с ним разговаривает.
У коробочной версии для этой проблемы есть инструменты, которых нет в облаке: доступ к настройкам модуля поиска, выбор поискового движка, монитор производительности базы данных. На практике эти настройки редко открывают после установки, и портал годами работает на параметрах по умолчанию, хотя данных за это время стало в десятки раз больше.
В коробочном Битрикс24 работают два разных поиска
Первое, что стоит понять администратору: строка поиска в шапке портала и поиск в списке сделок устроены по-разному, и чинить их приходится разными способами.
Общий поиск портала вызывается лупой в верхней части интерфейса. По описанию в справке Битрикс24, он работает по основным инструментам: CRM, диску, бизнес-процессам и другим разделам, а также находит сотрудников и пункты меню. В коробке за индексируемый контент отвечает модуль «Поиск» платформы, и его настройки доступны администратору.
Поиск и фильтр внутри CRM работают со списками сделок, контактов, компаний и других элементов. Справка Битрикс24 прямо говорит, что этот поиск идёт только по полям карточки CRM. Дела и комментарии в таймлайне туда не попадают. И второе важное ограничение из той же справки: поиск учитывает только начало слова или полное совпадение. Запрос «ван» не найдёт контакт «Иван».
Отсюда половина жалоб «поиск не работает». Менеджер помнит, что обсуждал с клиентом доставку в Шымкент, вводит «Шымкент» в строку поиска по сделкам, но город был упомянут только в комментарии таймлайна. Система отработала ровно так, как описано в справке, а сотрудник уходит с ощущением, что поиск сломан, и в следующий раз пишет администратору.
Почему поиск не находит то, что точно есть в базе
Прежде чем трогать сервер, стоит проверить причины, которые не связаны с производительностью. Они встречаются чаще, и исправить их можно быстрее.
Первая причина: сотрудник ищет по середине слова или по фрагменту телефона не с начала. Лечится обучением и договорённостью, как в компании записывают данные. Если номера хранятся то с «+7», то с восьмёркой, то с пробелами, поиск по телефону будет вести себя непредсказуемо.
Вторая причина: нужная информация лежит в таймлайне, а не в полях. Если по клиенту постоянно ищут город, номер договора или модель оборудования, эти данные нужно вынести в поля карточки. Иначе поиск их не увидит.
Третья причина: данные попали в систему в обход штатных механизмов. Курс администратора 1С-Битрикс отдельно оговаривает, что автоматическая индексация срабатывает, когда контент добавляют через интерфейс системы, а при загрузке файлов по FTP нужна ручная переиндексация. Тот же принцип касается любых данных, которые залили напрямую, минуя штатные механизмы платформы: индекс о них может просто не знать.
Четвёртая причина: права доступа. Сотрудник видит в результатах только те элементы, к которым у него есть доступ. Когда менеджер филиала не находит клиента головного офиса, стоит сначала проверить роли, а уже потом индекс.
Пятая причина проявляется после переноса портала на новый сервер или восстановления из резервной копии. Если индекс не пересобрали, часть материалов в общем поиске не находится или находится со старыми ссылками.
Почему поиск стал медленным на большой базе
Когда с «не находит» разобрались, остаётся скорость. Здесь причины обычно лежат в трёх местах: в настройках модуля «Поиск», в выбранном поисковом движке и в базе данных.
По умолчанию модуль поиска использует встроенный механизм платформы. Для небольшого портала его хватает. На больших объёмах встроенный индекс сам становится тяжёлой таблицей, и каждый запрос нагружает ту же базу данных, в которой параллельно работают CRM, задачи и интеграции.
Вторая типичная причина связана с тем, как люди ищут в CRM. Фильтр по пользовательскому полю на базе в полмиллиона сделок может выполняться заметно дольше, чем фильтр по ответственному или стадии. Если такой фильтр сохранён как шаблон и открывается у двадцати менеджеров каждое утро, нагрузка складывается.
Третья причина касается ресурсов сервера и настроек MySQL. Если сервер собирали под двадцать пользователей, а сейчас их двести, никакая настройка поиска не компенсирует нехватку памяти под кэш базы данных.
Настройки модуля «Поиск»: что проверить в первую очередь
Настройки модуля открываются по пути Настройки → Настройки продукта → Настройки модулей → Поиск. В учебном курсе 1С-Битрикс описаны четыре вкладки: «Индексация», «Морфология», «Поиск» и «Статистика».
На вкладке «Индексация» задаются ограничения на то, что вообще попадает в индекс. Здесь есть параметр «Максимальный размер индексируемого документа в килобайтах», а также «Маска включения» и «Маска исключения». Если на портале лежат гигабайты служебных файлов, выгрузок и архивов, которые никто не ищет, их разумно исключить из индексации. Индекс станет меньше, переиндексация быстрее.
На вкладке «Морфология» находится ключевой для больших порталов параметр «Полнотекстовый поиск с помощью». По описанию в курсе, в нём доступны варианты Bitrix, Sphinx, OpenSearch и MySQL. Выбор движка определяет, где физически хранится индекс и какой сервер обрабатывает поисковые запросы.
На вкладке «Поиск» есть опция «Использовать быстрый поиск (с ухудшенным ранжированием)» и ограничение «Максимальное количество документов в результатах поиска». Быстрый режим жертвует точностью сортировки результатов ради скорости. Для корпоративного портала, где сотрудник обычно знает, что ищет, это часто разумный компромисс, но решение лучше принимать после теста на реальных запросах.
Вкладка «Статистика» отвечает за хранение поисковых фраз. На активном портале эта статистика со временем тоже разрастается, поэтому срок хранения стоит выставить осмысленно.
Переиндексация без остановки работы портала
Переиндексация запускается на странице Настройки → Поиск → Переиндексация сайта. В форме есть флаг «Переиндексировать только измененные», поле «Шаг» с длительностью одного этапа, а также выбор сайта и модуля, данные которых участвуют в переиндексации.
Полная переиндексация большой базы идёт долго и нагружает сервер, поэтому несколько практических правил:
- Запускайте полную переиндексацию вне рабочего времени, особенно если портал обслуживает круглосуточную поддержку или склад.
- Если проблема касается одного раздела, выбирайте конкретный модуль, а не весь портал.
- Для регулярного поддержания индекса используйте режим «только измененные», он заметно быстрее.
- Не ставьте слишком длинный шаг на слабом сервере: один этап будет надолго занимать ресурсы, и пользователи это почувствуют.
Курс администратора упоминает ещё один приём для очень больших объёмов данных: иногда эффективнее удалить и заново установить модуль «Поиск», чем обновлять существующий индекс. Это радикальный шаг, и выполнять его стоит только после резервной копии и проверки на тестовой копии портала. Как организовать такую копию, мы описывали в статье про тестовый контур для коробочного Битрикс24.
Sphinx: когда пора выносить поиск на отдельный движок
Sphinx это внешний сервер полнотекстового поиска, поддержка которого встроена в модуль «Поиск». В учебном курсе по виртуальной машине BitrixVM его назначение сформулировано так: использование Sphinx позволяет значительно увеличить скорость поиска и снижает нагрузку на сервер. Индекс при этом живёт отдельно от основной базы, и поисковые запросы перестают конкурировать с CRM за ресурсы MySQL.
Подключение состоит из двух частей. На сервере должен быть установлен и запущен Sphinx. В самом портале на вкладке «Морфология» выбирается Sphinx как движок полнотекстового поиска, указывается строка подключения к серверу с адресом и портом и задаётся идентификатор индекса. После этого портал нужно переиндексировать.
В BitrixVM для этого есть готовый пункт меню управления сервером. В архивной версии курса по BitrixVM это пункт «Sphinx search server», через который запускается сервис и добавляется индекс. В актуальных версиях виртуальной машины меню устроено иначе, поэтому перед работой сверяйтесь с документацией именно своей версии.
Одно ограничение стоит проверить заранее. В курсе 1С-Битрикс указано, что начиная с версии Sphinx 2.2.2 поддерживается только кодировка UTF-8, и на сайтах в кодировке Windows-1251 поиск через Sphinx работать не будет. Старые порталы, которые начинали жизнь в Windows-1251, сначала придётся перевести на UTF-8, а это отдельный проект.
Переходить на внешний движок имеет смысл, когда поиск заметно тормозит, в мониторе производительности видно, что поисковые запросы занимают значимую долю нагрузки на базу, а исключение лишнего из индекса и настройка модуля уже не помогли. Если портал небольшой, а тормозит всё подряд, дело скорее в сервере, и Sphinx проблему не решит.
База данных: монитор производительности и анализ индексов
Медленный поиск по CRM часто оказывается медленной базой данных. В коробочной версии для диагностики есть модуль «Монитор производительности».
Страница «Сервер БД» в мониторе показывает состояние сервера базы данных. С неё стоит начинать, если тормозит всё: и поиск, и открытие карточек, и отчёты.
Вторая полезная страница того же модуля называется «Анализ индексов». Согласно документации модуля, перед анализом нужно собрать статистику по медленным запросам и провести тестирование конфигурации. После этого на странице можно выполнить анализ собранных SQL-запросов, открыть детальный анализ и посмотреть план выполнения запроса. Индикатор показывает, создан ли для запроса индекс.
Здесь важна последовательность. Сначала собирается статистика в рабочее время, когда пользователи реально ищут и фильтруют. Потом анализируются самые медленные и самые частые запросы. Только после этого принимаются решения о новых индексах. Добавлять индексы вслепую на всё подряд не стоит: каждый индекс ускоряет чтение, но замедляет запись и увеличивает размер базы, а на CRM с активным импортом и интеграциями запись идёт постоянно.
Как отличить медленный поиск от медленного портала
Прежде чем менять движок или добавлять индексы, полезно убедиться, что тормозит именно поиск. Простая проверка: засеките, сколько открывается карточка сделки, список задач и отчёт, а потом сколько выполняется поиск. Повторите то же самое утром, в обед и вечером. Если медленно всё и в одни и те же часы, проблема общая, и поиск просто первым попадается пользователям на глаза.
Для более объективной оценки в мониторе производительности есть «Панель производительности», в документации она находится по пути Настройки → Производительность → Панель производительности. Там доступно тестирование конфигурации: общая оценка, время отклика, операции процессора, файловая система, старт сессии, конфигурация PHP и запросы к базе данных на запись, чтение и изменение. Результаты сравниваются с эталонной виртуальной машиной. Если оценка по запросам к БД заметно ниже эталона, разбираться нужно с базой, а не с поиском.
Ещё одна частая причина общей медлительности связана с агентами, периодическими фоновыми задачами платформы. По умолчанию агенты могут выполняться на хитах, то есть во время обращений пользователей к порталу. Курс администратора 1С-Битрикс описывает перевод выполнения всех агентов на cron: тогда фоновые задачи запускаются по расписанию на сервере и не отнимают время у запросов пользователей. Для большого коробочного портала это одна из первых настроек, которые стоит проверить.
Как сотрудникам искать быстрее уже сегодня
Часть проблем решается без администратора, привычками пользователей.
Используйте фильтры вместо общего поиска, когда известен хотя бы один параметр: ответственный, стадия, период. Справка Битрикс24 описывает, что фильтр позволяет уточнять поиск сразу по нескольким параметрам, а часто используемые фильтры можно сохранять как шаблоны.
Ищите по началу слова: фамилии, названию компании, первым цифрам телефона. Поиск в CRM не находит фрагменты из середины.
Договоритесь о формате данных. Единый формат телефонов, названий компаний без кавычек и организационно-правовой формы в начале, обязательное поле города. Это скучная работа, но она убирает большую часть ситуаций «клиент есть, а поиск не находит».
Выносите в поля то, по чему ищут. Если отдел сервиса постоянно ищет по серийному номеру, серийный номер должен быть полем карточки, а не строкой в комментарии.
Условный пример: дистрибьютор после объединения баз
Пример иллюстративный, объёмы и сроки взяты для наглядности. Торговая компания в Алматы объединила в одном коробочном портале базы трёх филиалов. Контактов стало больше трёхсот тысяч, данные залили скриптом напрямую, чтобы уложиться в выходные. В понедельник менеджеры начали жаловаться, что половина клиентов не ищется, а то, что ищется, открывается долго.
Разбор показал сразу несколько причин. Часть данных не попала в поисковый индекс, потому что загрузка шла в обход штатных механизмов. Телефоны в трёх базах были записаны в трёх разных форматах. Модуль поиска работал на встроенном движке, в индекс попадали архивы выгрузок из старой CRM. На сервере не хватало памяти под кэш базы данных.
Работы шли в таком порядке: резервная копия и тестовая копия портала, исключение архивов из индексации, нормализация телефонов, полная ночная переиндексация, сбор статистики медленных запросов в течение рабочей недели и анализ индексов по её итогам. Вопрос о переходе на Sphinx решали уже после этого, по фактической нагрузке, а не заранее.
Регламент, чтобы поиск не деградировал снова
Разовая настройка даёт эффект на полгода-год, а потом база снова растёт. Чтобы не возвращаться к проблеме в авральном режиме, администратору стоит завести простой регламент.
Раз в месяц просматривать настройки индексации и проверять, не появились ли на портале новые папки с выгрузками и архивами, которые стоит исключить. После каждой массовой загрузки данных, миграции или восстановления из копии запускать переиндексацию. Раз в квартал собирать статистику медленных запросов в мониторе производительности и сравнивать её с прошлым замером. После крупных обновлений платформы проверять поиск на наборе типовых запросов, которые заранее собраны у пользователей: пять-десять фамилий, названий компаний и телефонов, по которым точно известен правильный результат.
Такой набор контрольных запросов заодно решает спор «раньше искало быстрее»: время можно сравнить с прошлым замером, а не с ощущениями.
Порядок работ, если поиск тормозит прямо сейчас
- Соберите от пользователей конкретные примеры: что искали, где, сколько ждали, что ожидали найти.
- Отделите «не находит» от «медленно». Первое чаще решается правами, форматом данных и полями карточки.
- Сделайте резервную копию и, если есть возможность, тестовую копию портала.
- Проверьте настройки модуля «Поиск»: маски исключения, размер индексируемых документов, выбранный движок.
- Запустите переиндексацию вне рабочего времени.
- Соберите статистику медленных запросов в мониторе производительности и проанализируйте индексы.
- Оцените ресурсы сервера и настройки базы данных.
- Только после этого решайте, нужен ли внешний поисковый движок.
Если своего администратора с опытом эксплуатации коробочной версии нет, эту работу удобнее отдать подрядчику. Мы проводим аудит производительности и берём на себя внедрение, настройку и сопровождение Битрикс24, в том числе больших коробочных порталов: от переиндексации и настройки поиска до переноса на более мощный сервер.
Частые вопросы
Почему поиск в CRM не находит клиента по части имени?
По справке Битрикс24, поиск в CRM учитывает только начало слова или полное совпадение. Запрос «ван» не найдёт контакт «Иван». Ищите по началу фамилии, имени, названия компании или номера телефона.
Ищет ли CRM по комментариям и делам в таймлайне?
Нет. Поиск в CRM работает только по полям карточки, данные в делах и комментариях таймлайна не находятся. Если по какой-то информации регулярно ищут, её стоит вынести в отдельное поле.
Когда нужна ручная переиндексация в коробочном Битрикс24?
Когда данные попали на портал в обход интерфейса системы, например файлы загрузили по FTP, а также после переноса на новый сервер или восстановления из копии. Переиндексация запускается в разделе «Настройки → Поиск → Переиндексация сайта», для больших баз лучше ночью.
Поможет ли Sphinx, если тормозит весь портал, а не только поиск?
Скорее нет. Sphinx разгружает базу данных от поисковых запросов и ускоряет сам поиск. Если медленно открываются карточки, отчёты и задачи, причину нужно искать в ресурсах сервера и базе данных, начиная со страницы «Сервер БД» в мониторе производительности.