Как подготовить 1С к большому количеству пользователей

архитектура, расчёт нагрузки и стратегия масштабирования

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

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

В этой статье рассматривается полный цикл такой работы — от модели бизнес-операций до критериев приёмки промышленной системы. Материал предназначен для руководителей предприятий, ИТ-директоров, архитекторов корпоративных систем и специалистов, отвечающих за эксплуатацию 1С.

Главный вопрос масштабирования: что именно должно вырасти?

Предположим, предприятие использует 1С для управления производством, складом, закупками и финансами. Сейчас системой пользуются 250 сотрудников. Через год планируется увеличить штат до 400 человек, открыть дополнительный склад и организовать вторую производственную смену.

На первый взгляд задача очевидна: нужно подготовить инфраструктуру к увеличению числа пользователей на 60%.

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

Рассмотрим два сценарию.

В первом случае новые сотрудники преимущественно просматривают справочники, проверяют статусы документов и формируют небольшое количество отчётов.

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

Число пользователей одинаково, но профиль нагрузки различается.

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

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

Четыре разных показателя, которые нельзя смешивать

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

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

Как построить модель нагрузки, пригодную для расчётов

Модель нагрузки должна описывать не абстрактные 400 пользователей, а конкретные операции, которые они выполняют.

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

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

Расчёт интенсивности операций

Для предварительной оценки можно использовать простую модель.

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

Это упрощённая модель. Она предполагает усреднённую активность и не учитывает автоматически пики, неравномерность работы, фоновые процессы и корреляцию действий пользователей. Для инженерного расчёта эти факторы добавляются отдельно.

Учебный пример

Предположим, сейчас в системе зарегистрировано 250 пользователей, из которых в среднем 60% активны в рассматриваемый период.

В этом учебном сценарии число активных пользователей увеличивается с 150 до 260, то есть примерно на 73%.

Это уже показывает, почему прирост нагрузки может отличаться от прироста общего числа сотрудников. Но даже 73% — не готовый коэффициент увеличения мощности серверов.

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

Принципиальное ограничение: нельзя считать, что увеличение интенсивности операций на 73% автоматически требует увеличить CPU, память или производительность дисков на те же 73%. Такая экстраполяция допустима лишь как предварительная гипотеза в условиях, где линейность подтверждена измерениями.

Архитектура 1С: где проходят границы масштабирования

В клиент-серверном варианте 1С взаимодействуют клиентское приложение, кластер серверов 1С и сервер системы управления базами данных.

Клиент инициирует действия пользователя. Кластер обслуживает соединения и выполняет серверную часть прикладной логики. СУБД обрабатывает запросы и транзакции, обеспечивая хранение и согласованность данных.

В реальной инфраструктуре присутствуют также сеть, операционная система, средства резервного копирования, мониторинг, терминальные серверы и интеграционные компоненты. Их роль зависит от конкретной конфигурации.

Главная особенность этой архитектуры — взаимозависимость уровней.

Если кластер способен обрабатывать больше запросов, это не означает, что СУБД сможет с той же скоростью обслужить возросший поток. Если СУБД обладает запасом мощности, но прикладная операция содержит последовательный алгоритм, время её выполнения может почти не измениться при добавлении серверов.

Официальная документация описывает эту архитектуру и механизмы масштабирования кластера: архитектура кластера 1С и масштабируемость кластера.

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

Кластер 1С: масштабируется не только количеством серверов

Эти возможности описаны в официальной документации 1С.

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

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

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

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

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

Как определить реальное ограничение системы

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

Для этого рассматриваются четыре группы ограничений.

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

Прикладные ограничения и конкуренция

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

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

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

Скводной расчётный пример: предприятие готовится к росту с 250 до 400 пользователей

Рассмотрим учебный проект. Все цифры в этом разделе иллюстративны и не относятся к реальному внедрению LOG-AI. Они нужны для демонстрации метода принятия решений.

Предприятие использует 1С для производственного и складского учёта. Планируется расширение склада, подключение второй смены и увеличение интенсивности регистрации операций.

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

Шаг 1. Зафиксировать критерии

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

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

Шаг 2. Определить базовую и целевую нагрузку

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

После расширения требуется обеспечить 35 операций в секунду.

Шаг 3. Проверить базовую конфигурацию под целевой нагрузкой

Команда воспроизводит целевой профиль на тестовом контуре с сопоставимыми версиями платформы и СУБД, конфигурацией приложения и репрезентативным набором данных.

Допустим, тест выявил следующую картину:

Такой результат не доказывает, что единственная причина — блокировки или СУБД. Он формирует набор гипотез, которые необходимо проверить дополнительными измерениями.

Шаг 4. Сравнить варианты

Для примера рассмотрим три архитектурных варианта.

Для каждого варианта выполняются одинаковые тестовые сценарии, а результаты сравниваются при сопоставимых условиях.

Шаг 5. Принять решение по измерениям

Допустим, вариант A снижает загрузку CPU, но почти не меняет p95 операций записи. Вариант B увеличивает количество обрабатываемых операций, но не устраняет нарушение требований к отдельным транзакциям. Вариант C улучшает время отклика, однако требует дополнительных изменений прикладной логики.

В таком случае рациональным решением может оказаться сочетание вариантов B и C — если тесты подтвердят, что они обеспечивают необходимые показатели и экономически оправданны.

Но это не универсальная рекомендация. В реальном проекте иной результат измерений приведёт к иному решению.

Визуал: логика архитектурного выбора

Ценность модели не в том, что она заранее указывает правильный сервер. Она позволяет проверить, какое изменение действительно обеспечивает целевые показатели.

Обоснованный выбор архитектуры исключает траты на избыточную, но неэффективную инфраструктуру.

Нагрузочное тестирование: почему одного успешного прогона недостаточно

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

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

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

Полноценный профиль испытаний — единственный способ гарантировать стабильность системы после ввода в промышленную эксплуатацию.

Какие метрики действительно важны

Среднее время отклика недостаточно: оно может скрывать редкие длительные операции, которые критичны для производственного процесса.

Например, если 95% операций выполняются быстро, но 5% документов регулярно задерживаются, среднее значение может выглядеть приемлемо, хотя пользователи будут сталкиваться с заметными проблемами.

Что считать успешным результатом

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

СУБД и транзакционная конкуренция: ограничения, которые не устраняются добавлением серверов

В корпоративной 1С важно учитывать не только количество запросов, но и то, как операции взаимодействуют с данными.

Два пользователя могут работать с разными документами и не мешать друг другу. Но они также могут обращаться к одним и тем же остаткам, регистрам или объектам, для которых требуется согласованное изменение состояния.

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

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

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

Дополнительная параллельность может даже увеличить число одновременно ожидающих операций.

Эти показатели связаны, но описывают разные свойства системы.

Что исследовать в SQL Server

Документация: Microsoft Learn — мониторинг производительности через Query Store.

Конкретный набор инструментов зависит от СУБД и её версии. Для других поддерживаемых систем применяются соответствующие средства диагностики.

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

Вертикальное и горизонтальное масштабирование: сравнивать нужно не серверы, а результаты

Вертикальное масштабирование означает увеличение ресурсов существующего узла. Горизонтальное — добавление узлов и распределение нагрузки между ними там, где это допускает архитектура.

Вертикальное масштабирование

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

Однако у него есть предел: дальнейшее увеличение мощности может становиться всё дороже, а ограничения других компонентов сохраняются.

Горизонтальное масштабирование

Добавление рабочих серверов расширяет вычислительные возможности кластера. Но общая СУБД остаётся отдельным компонентом, который должен справляться с возросшей интенсивностью обращений.

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

Как выбрать вариант

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

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

Отказоустойчивость: производительность должна сохраняться и при аварийном сценарии

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

Необходимо определить, что произойдёт при отказе рабочего сервера, проблеме с СУБД, потере сетевого соединения или необходимости восстановить базу из резервной копии.

При этом важно разделять три разных требования.

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

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

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

Экономика масштабирования: сколько стоит готовность к росту

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

Варианты должны сравниваться на одинаковом горизонте планирования, например трёхлетнем, если он соответствует инвестиционному циклу предприятия.

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

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

Экономический расчет на трехлетнем горизонте защищает ИТ-бюджет от неэффективного освоения.

Когда пора масштабировать систему

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

Более зрелый подход — определить заранее наблюдаемые условия, при которых необходим повторный архитектурный анализ.

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

Превентивный мониторинг метрик — единственная альтернатива реактивному устранению инцидентов.

Как построить план развития архитектуры на несколько лет

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

Для этого формируются три сценария:

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

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

Повторная оценка необходима при расширении производства, изменении конфигурации, переходе на новую версию платформы или СУБД, добавлении интеграций и изменении требований к доступности.

Критерии готовности 1С к масштабированию

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

Чек-лист не заменяет нагрузочные испытания. Его задача — обеспечить полноту проектной работы и не допустить, чтобы критичные риски остались за пределами оценки.

Готовность ИС проверяется системным выполнением каждого шага модели, а не субъективным ощущением стабильности.

Заключение

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

Для этого необходимо моделировать не численность сотрудников, а бизнес-операции, их интенсивность, одновременность, объём данных и временные пики. Затем требуется установить ограничения действующей системы, сравнить варианты масштабирования и проверить их в контролируемых испытаниях.

Сильная архитектура 1С — это не система с максимальным количеством серверов. Это система, для которой заранее определены целевые показатели, измерены пределы, проверены сценарии роста и обоснована стоимость следующего шага масштабирования.

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

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

Сайт носит исключительно информационный характер и не является публичной офертой в соответствии со статьёй 437 Гражданского кодекса РФ. Цены, состав и условия предоставления услуг уточняются при проектировании решения и фиксируются в договоре. Условия технического сопровождения и уровень сервиса могут дополнительно определяться отдельным соглашением (SLA).