Зачем компании серверная 1С и когда она окупается

Сервер 1С даёт бизнесу три вещи, которых нет у файловой базы: стабильную работу при 15–20 и более одновременных пользователях, защиту данных средствами СУБД с резервным копированием «на любую минуту» и фоновые процессы — обмены, регламентные задания, веб-сервисы, — которые работают без запущенного у кого-то клиента. Возможности сервера 1С окупаются, когда база стала рабочим инструментом для нескольких отделов, а не только бухгалтерии.

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

Как устроена серверная 1С

В файловом варианте база — это один файл 1Cv8.1CD в общей папке. Каждый пользователь открывает его по сети и сам читает и пишет данные. Весь обмен идёт через файловый протокол, а целостность держится на блокировках файла.

В клиент-серверном варианте между пользователем и данными стоят две прослойки:

• 🖥 Кластер серверов 1С — служба на сервере. Она выполняет код конфигурации: проведение, отчёты, расчёты.
• 🗄 СУБД — хранит данные. Поддерживаются Microsoft SQL Server, PostgreSQL (в том числе сборки Postgres Pro и сборка от фирмы 1С), IBM Db2 и Oracle Database.
• 💻 Клиент — тонкий клиент или браузер. Он только показывает формы и передаёт команды.

Как идёт подключение. Клиент обращается к агенту сервера (порт 1540), агент направляет его к менеджеру кластера (1541), а дальше клиент работает с рабочими процессами. Их порты берутся из диапазона, который задаётся в свойствах рабочего сервера (по умолчанию 1560:1591).

Управляют всем этим через консоль администрирования серверов 1С или утилиту командной строки rac (через службу ras). Например, rac cluster list показывает кластеры, а rac session list --licenses — сеансы с выданными лицензиями.

Почему клиент-серверный вариант работает быстрее

Скорость — первое, ради чего обычно переходят на сервер. Но выигрыш есть не всегда, и важно понимать, откуда он берётся.

Откуда берётся ускорение:

• 📉 Меньше данных по сети. В файловом режиме для отчёта клиент тянет к себе страницы таблиц. В серверном запрос выполняет СУБД, а клиенту уходит готовый результат.
• 🔒 Блокировки на уровне записей. В файловой базе блокируется таблица целиком. Пока один пользователь проводит документ, другие ждут. В серверной базе с управляемым режимом блокировок конфликтуют только те, кто трогает одни и те же данные.
• 🧠 Кэш на сервере. Рабочие процессы и СУБД держат часто нужные данные в памяти. Повторный отчёт строится заметно быстрее.
• ⚙️ Тяжёлое — в фон. Закрытие месяца , перепроведение, загрузка банка запускаются фоновыми заданиями на сервере, а пользователь продолжает работать.

Когда файловая база окажется не хуже:

• 1–3 пользователя, база на локальном диске;
• слабый сервер с медленным диском и малым объёмом памяти;
• СУБД без настройки: нет регламентного обслуживания, не обновляется статистика.

Ориентиры по нагрузке для файловой базы:

Сохранность данных и защита от сбоев

Файловая база уязвима в трёх местах: обрыв сети при записи, сбой питания и прямой доступ к файлу. Серверная закрывает все три.

Целостность при сбоях

СУБД пишет изменения через журнал транзакций. Если сервер выключился посреди проведения, транзакция откатывается, база остаётся в согласованном состоянии. В файловом варианте после такого сбоя нередко приходится запускать «Тестирование и исправление» в конфигураторе — с монопольным доступом и остановкой работы всех пользователей.

Резервное копирование

Последняя строка — главный аргумент. Бухгалтер случайно удалил помеченные объекты в 14:20? Базу восстанавливают в копию на 14:15 и переносят нужные данные, а не откатывают весь день.

Доступ к данным

• 🔐 В файловом режиме у каждого пользователя должны быть права на чтение и запись в папку базы. Значит, любой может скопировать файл к себе на флешку или случайно удалить его.
• 🛡 В серверном режиме пользователи вообще не видят файлов. Доступ к СУБД есть только у службы 1С и администратора.
• 👤 Можно поставить пароль администратора кластера, ограничить доступ к консоли, запретить создание баз посторонним.
• 🧾 Журнал регистрации и технологический журнал хранятся на сервере, их нельзя «почистить» с рабочего места.

Рост компании без переделки учёта

Масштабируемость — это когда новые сотрудники, склады и филиалы добавляются без смены программы. Серверная 1С растёт в нескольких направлениях.

Вертикально. Добавили памяти и ядер — сервер сам запустит больше соединений в рабочих процессах. Для типовых конфигураций ориентир по памяти: 4–8 ГБ на сервер 1С плюс память под СУБД, далее примерно 150–300 МБ на активного пользователя тонкого клиента . Точные цифры зависят от конфигурации и сценариев.

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

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

Возможности кластера зависят от лицензии на сервер:

Для большинства компаний с одним сервером 1С хватает ПРОФ. КОРП нужен, когда простой базы на час стоит дороже лицензии — тогда собирают кластер из двух серверов с резервированием.

Обмены, интеграции и фоновые процессы

Здесь сервер 1С даёт то, что сложно получить в файловом режиме даже на одном рабочем месте.

Регламентные задания

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

На сервере задания идут по расписанию сами, круглосуточно. Включаются они в свойствах информационной базы в кластере: флажок «Блокировка регламентных заданий включена» должен быть снят. Управлять расписанием можно в самой конфигурации: в БП 3.0 и ЗУП 3.1 это Администрирование → Обслуживание → Регламентные операции → Регламентные и фоновые задания.

Внешние системы

• 🌐 HTTP-сервисы и веб-сервисы — сайт, маркетплейс или мобильное приложение получают остатки и создают заказы прямо в базе.
• 🔗 Стандартный интерфейс OData — выгрузка данных в BI-системы без программирования запросов.
• 🔄 Обмены через планы обмена — с другими базами 1С, филиалами, кассами.
• 🏦 Прямой обмен с банком, ЭДО, маркировка — фоновые проверки статусов идут без участия пользователя.

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

Деньги: из чего складывается стоимость и где экономия

Ниже — ориентировочные цены, чтобы прикинуть бюджет. Фактические цены смотрите у партнёра на дату покупки.

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

Где возникает экономия

• ⏱ Время сотрудников. Пример: 20 человек ждут блокировок по 15 минут в день. Это 5 часов в день, около 100 часов в месяц. При стоимости часа 600 ₽ — 60 000 ₽ в месяц, или 720 000 ₽ в год. Лицензия ПРОФ окупается за два месяца.
• 🧯 Простои после сбоев. Час неработающей базы в разгар отгрузок стоит дороже часа администратора.
• 🧾 Отказ от ручных обменов. Выгрузки «по кнопке», которые кто-то делает каждое утро, превращаются в регламентные задания.
• 🗄 Выбор СУБД. PostgreSQL снимает расходы на лицензии MS SQL. Для типовых конфигураций до нескольких десятков пользователей разница в скорости на практике небольшая, если СУБД правильно настроена.

Как перейти с файловой базы на серверную

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

1. Установите на сервер СУБД и платформу 1С той же версии, что у клиентов. Для PostgreSQL используйте сборку, рассчитанную на работу с 1С.
2. Установите компонент «Сервер 1С:Предприятия» и запустите его как службу. Активируйте серверную лицензию.
3. В консоли администрирования создайте информационную базу в кластере: укажите тип СУБД, адрес сервера, имя базы данных, пользователя СУБД и включите создание базы данных в СУБД.
4. Перед выгрузкой предупредите пользователей: для неё нужен монопольный доступ, все сеансы надо завершить. В файловой базе откройте конфигуратор и выполните Администрирование → Выгрузить информационную базу.
5. Подключитесь конфигуратором к новой серверной базе и выполните Администрирование → Загрузить информационную базу, выбрав файл .dt.
6. В списке баз у пользователей замените путь к файлу на адрес сервера и имя базы.
7. Проверьте работу, затем настройте резервное копирование и регламентное обслуживание в СУБД: обновление статистики и обслуживание индексов.

Частые вопросы