Высоконагруженная 1С: как построить стабильную и масштабируемую ИТ-архитектуру

Когда сотрудники жалуются, что 1С тормозит, первая реакция руководителя обычно одна: «надо купить сервер помощнее». Иногда это действительно помогает. Но чаще новый сервер снимает проблему на несколько месяцев, а потом тормоза возвращаются, потому что причина сидела не в железе, а в том, как настроена и организована вся система целиком.

1С, особенно при большом числе пользователей и объеме данных, представляет собой не одну программу, а связку из нескольких слоев: оборудование, база данных, сам сервер 1С и код, которым пользуется компания.

Проблема может прятаться на любом из этих уровней, а выглядит для сотрудника всегда одинаково: «все зависает».

Разберем, что стоит проверить на каждом уровне и почему это в итоге влияет на работу всей компании, а не только на ИТ-отдел.

Сначала диагностика, потом покупка

Прежде чем тратить деньги на оборудование, стоит понять, где именно теряется время.

Хороший специалист может замерить, сколько сейчас занимают ключевые операции: открытие карточки клиента, проведение документа, формирование основного отчета.

Эти цифры до изменений и после позволяют объективно увидеть, сработало ли решение, вместо того чтобы полагаться на общее ощущение «вроде побыстрее стало».

Дополнительно помогает анализ технического журнала системы: он показывает, какие именно операции занимают больше всего времени, а не просто фиксирует общее недовольство пользователей.

Отсюда следует простое практическое правило: любое серьезное вложение в 1С должно начинаться с диагностики. Иначе компания рискует заплатить за оборудование, которое не решит реальную проблему, потому что причина была в другом месте.

Не любое оборудование важно

Часть проблем с быстродействием решается на уровне «железа» и базовых настроек операционной системы, еще до работы с самой 1С.

Здесь важны не мощные компоненты сами по себе, а правильное распределение нагрузки между ними: быстрые диски именно под данные, которыми активно пользуются сотрудники, отдельные диски под служебные и временные файлы базы, чтобы они не мешали друг другу, стабильный и быстрый канал связи между сервером 1С и сервером базы данных, потому что для 1С критична именно задержка сети, а не только ее пропускная способность.

Покупка самого мощного сервера не гарантирует результата. Гораздо важнее, чтобы специалист правильно распределил имеющиеся ресурсы под конкретную нагрузку компании.

Настройки базы данных

База данных, в которой физически хранится вся информация компании, после установки почти всегда настроена на усредненный сценарий, а не под конкретный бизнес.

Большинство компаний годами работают на этих настройках, даже не подозревая, что теряют значительную часть производительности буквально бесплатно, без покупки нового оборудования.

Речь идет о десятках параметров: сколько памяти база выделяет под кэш и промежуточные вычисления, как активно она чистит за собой устаревшие данные, стоит ли использовать параллельную обработку запросов или, наоборот, отключить ее, чтобы избежать нестабильности при высокой нагрузке.

Проверить и настроить эти параметры под реальную нагрузку компании стоит одним из первых шагов, потому что это часто дает заметный прирост скорости без единого рубля вложений в оборудование.

Кластер серверов 1С

Когда в компании много пользователей, обычно ставят не один сервер 1С, а кластер из нескольких серверов, которые работают вместе.

Проблема в том, что сам факт наличия кластера ничего не гарантирует: если он настроен «из коробки», без учета реальной нагрузки, разница с одним сервером может оказаться минимальной.

Правильная настройка предполагает несколько рабочих процессов с ограничением по памяти вместо одного огромного процесса, вынос тяжелых фоновых операций на отдельный сервер, чтобы они не мешали работе сотрудников, и разделение служебных функций вроде журнала событий и поиска по базе так, чтобы они не боролись за ресурсы с обычными пользователями.

Здесь важно понимать: покупка второго или третьего сервера имеет смысл только вместе с грамотной настройкой их совместной работы. Иначе компания просто платит за железо, которое не используется эффективно.

Порядок в самой базе данных

Со временем в любой базе накапливается «мусор»: устаревшие версии документов, разросшиеся служебные журналы, старые архивные периоды, которые компании давно не нужны, но которые база все равно просматривает при каждом отчете.

Это похоже на шкаф, который годами не разбирали: формально в нем можно найти нужную вещь, но на это уходит все больше времени.

Регулярное наведение порядка включает добавление нужных индексов там, где их не хватает, удаление лишних индексов, которые только замедляют запись новых данных, регулярный пересчет накопленных итогов и, при большом объеме устаревших данных, их архивирование или свертку.

Такая уборка часто дает ощутимый эффект без всяких вложений в оборудование, просто за счет наведения порядка в том, что уже есть.

Качество кода: где чаще всего теряется скорость

Многие компании со временем дорабатывают типовую 1С под себя: добавляют отчеты, автоматизации, интеграции с другими системами.

Если это делается быстро и без должного контроля качества, именно доработки чаще всего становятся главным источником тормозов, и никакая настройка сервера эту проблему не решит.

Типичная ошибка выглядит так: программист пишет код, который для каждой строки документа отдельно обращается к базе данных, вместо того чтобы запросить все нужные данные один раз.

Внешне доработка работает и проходит тестирование на небольшом объеме данных, но на реальных объемах компании начинает работать в разы медленнее, чем должна.

Если компания регулярно заказывает доработки 1С, разумно закладывать в этот же бюджет проверку качества написанного кода независимым специалистом. Это дешевле, чем потом разбираться, почему «быстро сделанная» доработка тормозит всю систему.

Архитектура: как разделить разные типы нагрузки

В любой компании есть два разных вида работы с 1С: оперативная работа сотрудников с документами и тяжелая аналитика вроде больших отчетов и выгрузок.

Если и то и другое выполняется на одном и том же сервере одновременно, тяжелый отчет одного сотрудника может заметно замедлить работу всех остальных в этот момент.

Решается это разделением: тяжелую отчетность выносят на отдельную копию базы, которая обновляется по расписанию, а фоновые операции вроде синхронизации с другими системами переносят на нерабочее время, чтобы они не конкурировали с сотрудниками за ресурсы в течение дня.

Для бизнеса это означает, что грамотное разделение нагрузки часто снимает проблему без покупки дополнительного оборудования, просто за счет того, что разные задачи перестают мешать друг другу.

Масштабирование

Компании, которые начинают задумываться о запасе мощности только тогда, когда система уже не справляется, почти всегда сталкиваются с более дорогой и сложной доработкой, чем те, кто заранее закладывает возможность роста в два-три раза.

Устойчивая архитектура сразу учитывает возможность добавить сервер в кластер без переделки всей схемы, продуманную структуру базы и регулярный контроль производительности по мере роста компании.
При планировании ИТ-бюджета имеет смысл спросить у специалиста не только «как ускорить систему сейчас», но и «что будет с производительностью, если компания вырастет в два раза за год».

Итог

Заниматься только одним уровнем, будь то покупка нового сервера, настройка базы данных или доработка кода, почти никогда не дает устойчивого результата, потому что проблема редко лежит в одном месте.

Рабочий подход выглядит так: сначала диагностика, чтобы понять, где реально теряется скорость, затем точечные изменения с измеримым результатом на каждом шаге, и архитектура, изначально рассчитанная на рост компании, а не донастраиваемая в аварийном режиме, когда система уже перестала справляться.