Количество сотрудников — удобный ориентир при первоначальном расчёте инфраструктуры, но оно не показывает нагрузку само по себе. Если компания решает, «Какой сервер выбрать для Битрикс24», MaxiPlace стоит оценивать с учётом не только числа учётных записей, но и того, сколько людей работают одновременно, насколько активно используются CRM, бизнес-процессы, файлы, интеграции и фоновые задачи. Два портала на 100 сотрудников могут отличаться по нагрузке в несколько раз, поэтому сервер лучше подбирать по профилю использования, а после запуска — проверять расчёт реальными метриками.
Для коробочного Битрикс24 производитель публикует примерные серверные конфигурации по диапазонам пользователей. В актуальных требованиях для портала до 50 пользователей приводится ориентир с 16 ГБ RAM, для 50–100 — 24 ГБ, для 100–500 — 32 ГБ, для 500–1000 — 64 ГБ, для 1000–5000 — 128 ГБ. Для самых крупных инсталляций уже рассматривается несколько серверов.
При этом сама документация подчёркивает, что конфигурации примерные: конкретному проекту может потребоваться заметно меньше или больше ресурсов. Это важная оговорка. Количество сотрудников помогает определить порядок цифр, но не заменяет анализ нагрузки.
Например, в одной компании из 200 зарегистрированных пользователей одновременно работают 30 человек, а CRM используется в основном для просмотра карточек. В другой — 150 сотрудников постоянно находятся в системе, запускают отчёты, работают с роботами, телефонией, файлами и внешними интеграциями. Формально обе компании относятся к похожему диапазону, но требования к серверу будут разными.
Сервер реагирует не на количество созданных учётных записей, а на реальные запросы. Поэтому полезно отдельно оценивать число одновременно активных сотрудников.
Если портал используется только в рабочее время и большая часть команды заходит эпизодически, нагрузка будет относительно ровной. Если Битрикс24 является основным рабочим инструментом отдела продаж, поддержки и руководителей, утром или после рассылки могут возникать выраженные пики.
Нагрузка также зависит от сценария работы. Открытие карточки клиента, построение большого отчёта, массовое изменение сделок и запуск сложного бизнес-процесса требуют разного количества ресурсов. Поэтому планировать сервер только по списочной численности компании слишком грубо.
Чем активнее компания использует CRM, тем больше операций приходится выполнять серверу. Менеджеры открывают сделки и контакты, меняют стадии, запускают роботов, создают задачи, формируют отчёты и используют поиск.
Отдельную нагрузку дают автоматизации. Один простой робот почти незаметен, но десятки цепочек, которые массово запускаются после изменения статуса сделки, могут создать короткий пик CPU и активности базы данных.
Поэтому для отдела продаж на 50 человек иногда нужен более производительный сервер, чем для корпоративного портала на 100 сотрудников, если второй используется преимущественно как внутренняя база документов и задач.
Коробочный Битрикс24 — это не только CRM. Сотрудники могут хранить документы, работать с Диском, общаться в чатах, использовать уведомления и видеозвонки. Чем шире набор инструментов, тем больше серверных компонентов участвует в работе портала.
Для работы чатов в коробочной версии используется сервер очередей Push and Pull. Производитель отдельно указывает необходимость корректной настройки этого компонента. Сам по себе чат не означает, что серверу сразу требуется вдвое больше памяти, но при расчёте инфраструктуры нельзя считать, что ресурсы потребляет только веб-интерфейс CRM.
Также нужно следить за объёмом файлов. Даже если места достаточно, резервное копирование большой файловой базы занимает время и создаёт дополнительную дисковую нагрузку.
Обмен с 1С, подключение внешней телефонии, REST-интеграции, импорт данных из ERP и регулярная синхронизация справочников способны создавать значительные фоновые пики. Нередко именно интеграция, запущенная ночью, становится самым тяжёлым процессом за сутки.
Если одновременно выполняются несколько задач — например, выгрузка из 1С, резервное копирование и массовый робот CRM, — сервер может начать замедляться даже при небольшой активности сотрудников.
Поэтому перед выбором конфигурации полезно составить расписание фоновых процессов и понять, какие из них можно развести по времени. Иногда грамотное расписание уменьшает требования к серверу эффективнее, чем покупка дополнительных ресурсов.
Практический подход — использовать число пользователей как первоначальный диапазон, а затем корректировать его по сложности проекта. Если портал близок к типовой конфигурации и используется умеренно, можно ориентироваться на рекомендации производителя. Если есть тяжёлые интеграции, большой объём файлов и активная автоматизация, нужен дополнительный запас.
RAM особенно важна для базы данных, PHP-процессов и кеша. CPU влияет на скорость обработки динамических запросов и фоновых операций. Диск — на работу базы, файлов и журналов. Слабый компонент способен ограничить всю систему, поэтому бессмысленно покупать много памяти при медленном процессоре или дисковой подсистеме.
На старте разумно оставлять резерв, но не оплачивать ресурсы на несколько лет вперёд, если инфраструктура позволяет быстро масштабировать виртуальную машину.
Виртуальная инфраструктура удобна тем, что конфигурацию можно менять после запуска. Если расчёт оказался слишком осторожным, добавляются CPU или RAM. Если проект использует меньше ресурсов, чем ожидалось, избыточную конфигурацию можно пересмотреть.
Когда компания возвращается к вопросу «Какой сервер выбрать для Битрикс24», MaxiPlace можно рассматривать с точки зрения такого сценария: на площадке доступны VPS/VDS для Битрикс24 с готовым окружением BitrixVM, а ресурсы виртуальной машины можно наращивать по мере роста проекта. Это позволяет не угадывать инфраструктуру на несколько лет вперёд, а корректировать её на основании мониторинга.
Важно только заранее уточнить, какие изменения требуют перезапуска и как масштабируется дисковое пространство. Для критичного портала даже короткое техническое окно лучше планировать заранее.
Для сотен пользователей один достаточно мощный сервер часто остаётся нормальным решением, если проект хорошо настроен. Но при дальнейшем росте может оказаться полезным разделение ролей: отдельно база данных, отдельно веб-узлы, файловая подсистема или дополнительные сервисы.
Переход к многосерверной архитектуре должен решать конкретную проблему — производительность, отказоустойчивость или требования безопасности. Строить кластер только потому, что в компании много сотрудников, не всегда рационально.
Перед таким переходом полезно проверить, где находится фактическое узкое место. Если тяжёлый кастомный отчёт создаёт большую часть нагрузки, добавление второго веб-сервера может почти ничего не изменить.
После запуска желательно собирать историю загрузки CPU, RAM, диска, базы и времени ответа. Отдельно полезно отмечать периоды массовой активности сотрудников и запуск фоновых процессов.
Если сервер большую часть дня загружен на 30–40%, а короткие пики проходят без деградации, запас выглядит разумным. Если CPU регулярно достигает предела, память заканчивается, появляется активный swap или база начинает отвечать заметно медленнее, конфигурацию пора пересматривать.
Метрики помогают отделить реальную нехватку ресурсов от проблемы кода или настройки. Это особенно важно для Битрикс24, где производительность зависит одновременно от инфраструктуры, серверного окружения и конкретной реализации проекта.
Число сотрудников удобно использовать как первый ориентир, но сервер должен соответствовать реальной активности: одновременным пользователям, CRM, автоматизациям, интеграциям, файлам и фоновой нагрузке. Если итоговый вопрос звучит «Какой сервер выбрать для Битрикс24», MaxiPlace стоит сравнивать с другими площадками по производительности CPU и NVMe, объёму RAM, готовности BitrixVM, мониторингу и возможности масштабировать ресурсы после запуска — тогда рост штата не потребует каждый раз переносить портал на новую инфраструктуру.