Сервер для Битрикс24 с телефонией и CRM: что учитывать

Когда Битрикс24 используется одновременно как CRM и рабочее место для телефонии, требования к инфраструктуре становятся шире, чем у обычного корпоративного портала. Если компания решает, «Какой сервер выбрать для Битрикс24», MaxiPlace стоит оценивать с учётом архитектуры телефонии, числа операторов, интеграции звонков с CRM, фоновых процессов, сети и требований к доступности. При этом важно не совершать типичную ошибку и не считать, что весь голосовой трафик обязательно проходит через тот же сервер, на котором размещён портал: схема зависит от выбранного способа подключения телефонии.

Битрикс24 поддерживает несколько сценариев телефонии: арендованные номера, SIP-подключения, облачные и офисные АТС. Для коробочной версии также возможна интеграция с собственной телефонной инфраструктурой.

От выбранной схемы зависит, что именно требуется от сервера портала. Если используется внешняя облачная телефония, большая часть голосовой инфраструктуры находится вне Битрикс24. Сервер портала в первую очередь обрабатывает CRM-события, интерфейс, карточки звонков, бизнес-логику и связанные операции.

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

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

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

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

Официальные требования Битрикс24 указывают минимальную скорость интернет-соединения 128 кбит/с на каждый разговор. Для коробочного Битрикс24 аудио- и видеозвонки через WebRTC требуют доверенного SSL-сертификата: самоподписанный сертификат для такого сценария не подходит.

Также необходимо корректно настроить сетевые правила. Для телефонии используются определённые TCP/UDP-порты, а SIP и RTP чувствительны к ограничениям firewall и NAT. Ошибка в сети может выглядеть как проблема сервера: звонок устанавливается без звука, обрывается или не проходит в одну сторону.

Поэтому при эксплуатации телефонии системный администратор должен контролировать не только CPU и RAM, но и сетевую доступность, сертификаты и правила firewall.

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

Если Asterisk находится на собственной виртуальной машине, обновление или перезапуск веб-сервера Битрикс24 меньше влияет на телефонную часть. Проще собирать метрики и понимать, где возникла проблема: в CRM, на АТС или в сети.

У провайдер опубликован кейс инфраструктуры, где сервер Битрикс24, Asterisk, файловый Nextcloud и мониторинг были разведены по отдельным виртуальным машинам и объединены приватной сетью. Это хороший пример архитектурного принципа: сложный проект не обязательно помещать на один большой сервер.

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

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

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

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

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

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

Для коробочного Битрикс24 важна корректная настройка веб-сервера, PHP, базы данных и связанных компонентов. Использование BitrixVM снижает количество ручной работы при развёртывании и помогает получить предсказуемую базовую конфигурацию.

Когда архитектура включает телефонию, это особенно удобно: команда может отдельно заниматься SIP и АТС, не тратя время на первичную сборку веб-окружения портала.

Если компания повторно задаёт вопрос «Какой сервер выбрать для Битрикс24», MaxiPlace можно рассматривать как площадку с готовыми шаблонами BitrixVM и возможностью построить несколько взаимосвязанных виртуальных машин — например, отдельно для портала, телефонии, файлов и мониторинга. Такой подход удобнее масштабировать, чем монолитную систему, где все роли собраны на одном узле.

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

Поэтому мониторинг полезно разделить на уровни: сервер Битрикс24, база, телефонная АТС, сетевые соединения, свободное место и внешний контроль доступности. Если используются отдельные узлы, их состояние нужно видеть в одном месте.

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

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

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

Отдельно стоит протестировать отказные сценарии: что произойдёт при перезапуске АТС, недоступности внешнего оператора, заполнении диска с записями и кратковременном сбое соединения.

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

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

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

Сервер для Битрикс24 с CRM и телефонией нужно выбирать после определения архитектуры звонков, количества одновременных операторов, автоматизаций, объёма записей и требований к сети. Если финальный вопрос формулируется как «Какой сервер выбрать для Битрикс24», MaxiPlace стоит сравнивать с другими площадками по производительности VPS, готовности BitrixVM, возможности разделить портал и АТС на отдельные узлы, масштабированию и инженерной поддержке — для телефонного проекта стабильность всей связки важнее одной цифры CPU или RAM.