Как правильно администрировать 1С:Предприятие 8.3 — практический гайд для сисадмина

Правильное администрирование 1С держится на пяти опорах: стабильный сервер 1С с одной версией платформы на сервере и клиентах, настроенная под 1С СУБД, ежедневный бэкап средствами СУБД с проверкой восстановления, мониторинг через технологический журнал и строгие права пользователей. Всё остальное — регламент: статистика, индексы, обновления по графику.

Файловую базу администрировать почти нечего: папка с файлом 1Cv8.1CD, копия файла и права на папку. Клиент-серверная база — другое дело: тут появляются кластер, СУБД, порты и службы, и большая часть сбоев рождается именно здесь. Поэтому гайд про клиент-серверный вариант на платформе 8.3; где файловая база отличается — сказано отдельно.

Как устроен кластер серверов 1С и где его настраивать

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

1. 🔌 Агент сервера (ragent) слушает порт 1540. Через него же работает консоль администрирования.
2. 🧭 Менеджер кластера (rmngr) — порт 1541. Он хранит список баз и раздаёт клиентов рабочим процессам.
3. ⚙️ Рабочие процессы (rphost) выполняют код и ходят в СУБД. Диапазон их портов задаётся в свойствах рабочего сервера, по умолчанию 1560:1591.

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

Настройки кластера хранятся в каталоге srvinfo (на Windows по умолчанию C:\Program Files\1cv8\srvinfo). Там же лежат реестр кластера reg_1541 и сеансовые данные.

Консоль администрирования и rac

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

regsvr32 "C:\Program Files\1cv8\8.3.XX.XXXX\bin\radmin.dll"

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

Для скриптов и Linux есть пара ras + rac. Сервер администрирования ras по умолчанию слушает порт 1545, утилита rac отправляет ему команды:

ras cluster --daemon
rac cluster list
rac infobase summary list --cluster=<UUID кластера>
rac session list --cluster=<UUID кластера>

UUID берите из вывода rac cluster list. Остальные ключи смотрите в rac help — у каждой команды свой набор.

Что настроить в свойствах рабочего сервера

• 🧮 Количество ИБ на процесс и соединений на процесс — влияют на то, сколько рабочих процессов поднимется.
• 💾 Безопасный расход памяти за один вызов — ограничивает «тяжёлый» вызов, чтобы он не съел память всего сервера.
• 🛡 Критический объём памяти процессов — порог, после которого кластер начинает обрывать вызовы.

Значения по умолчанию подходят для старта. Меняйте их, когда по журналу видна конкретная проблема, а не «для ускорения».

Какую СУБД выбрать для 1С и как её подготовить

1С 8.3 работает с MS SQL Server, PostgreSQL, IBM Db2 и Oracle. На практике выбор почти всегда между первыми двумя.

Настройка MS SQL Server под 1С

1. Задайте максимальный объём памяти сервера (max server memory). Без лимита SQL займёт почти всю память, и rphost на этой же машине начнёт голодать. Оставьте ОС и 1С хотя бы 4–8 ГБ.
2. Поставьте MAXDOP = 1 — так обычно рекомендуют для OLTP-нагрузки 1С, чтобы короткие запросы не дробились на потоки.
3. Выберите модель восстановления. Full — если нужен откат на любой момент дня. Simple — если устраивает потеря данных с последнего ночного бэкапа.
4. Вынесите файлы данных, журнал транзакций и tempdb на разные диски, лучше SSD.
5. Создайте для 1С отдельного SQL-пользователя с правами на свою базу, а не sa.

Настройка PostgreSQL под 1С

Ставьте PostgreSQL из дистрибутива с патчами для 1С (их выпускают фирма 1С и Postgres Professional). Базу под 1С создаёт сам кластер 1С при регистрации ИБ с флажком создания базы данных.

Параметры shared_buffers, work_mem, effective_cache_size подбирают под память сервера. Хорошая точка старта — shared_buffers около четверти ОЗУ. Дальше корректируйте по наблюдениям, а не по чужим конфигам.

Резервное копирование 1С: бэкап, который реально восстановится

Главный бэкап клиент-серверной базы делается средствами СУБД, а не выгрузкой .dt. Выгрузка долгая, ей нужен доступ к базе через 1С, и откатиться на конкретный час по ней нельзя.

Рабочая схема для MS SQL

• 🌙 Полный бэкап — каждую ночь.
• 🕐 Бэкап журнала транзакций — каждые 15–60 минут в рабочее время.
• 📅 Раз в неделю — копия за пределы сервера.

Без регулярного бэкапа журнала при модели Full файл журнала растёт до заполнения диска. Это частая причина внезапной остановки базы.

Рабочая схема для PostgreSQL

Ночной дамп в собственном формате:

pg_dump -U postgres -Fc -f /backup/buh.dump buh

Для восстановления на момент времени — pg_basebackup плюс непрерывная архивация WAL (archive_mode = on и archive_command).

Правило 3-2-1 и тест восстановления

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

Мониторинг производительности и разбор блокировок в 1С

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

С чего начать диагностику

1. Откройте диспетчер задач или top: процессор, память, очередь диска. Если rphost упирается в память — смотрите свойства рабочего сервера.
2. В консоли кластера посмотрите сеансы и соединения: кто держит долгий вызов, в какой базе.
3. Если ресурсы свободны, а пользователи ждут — это блокировки. Включайте технологический журнал.

Технологический журнал: файл logcfg.xml

Журнал включается файлом logcfg.xml в каталоге conf платформы на сервере (например, C:\Program Files\1cv8\conf). Платформа подхватывает его без перезапуска службы. Пример для блокировок:

<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\techlog" history="24">
    <event><eq property="name" value="TLOCK"/></event>
    <event><eq property="name" value="TTIMEOUT"/></event>
    <event><eq property="name" value="TDEADLOCK"/></event>
    <property name="all"/>
  </log>
</config>

history — сколько часов хранить логи. События:

• ⏳ TTIMEOUT — пользователь не дождался блокировки. Это и есть ошибка Конфликт блокировок при выполнении транзакции: Превышено максимальное время ожидания предоставления блокировки.
• 🔁 TDEADLOCK — взаимоблокировка: две транзакции ждут друг друга.
• 🔒 TLOCK — все управляемые блокировки. По нему видно, кто держал ресурс.

Для поиска медленных запросов добавьте событие DBMSSQL (MS SQL) или DBPOSTGRS (PostgreSQL) с фильтром по длительности.

Что обычно находят

• 📦 Закрытие месяца или перепроведение запущено днём — переносите на вечер или ночь.
• 🔄 Обмен держит долгую транзакцию — дробите выгрузку на порции.
• 🧱 Доработка конфигурации работает в автоматическом режиме блокировок — переводите на управляемый режим (это работа программиста, не администратора).
• 📉 Устаревшая статистика СУБД — запрос выбирает плохой план (лечится регламентом, см. ниже).

Права пользователей и безопасность базы 1С

Безопасность в 1С — это три уровня: доступ к серверу, к кластеру и к данным внутри базы.

Сервер и кластер

1. Служба агента работает от отдельной учётной записи (при установке создаётся USR1CV8), а не от администратора домена.
2. В консоли кластера задайте администраторов кластера. Пока их нет, любой пользователь сети с консолью может удалить базу из кластера.
3. При регистрации базы укажите, разрешено ли выдавать лицензии сервером и разрешено ли регламентным заданиям работать.
4. Пароль пользователя СУБД в карточке базы хранит кластер — не давайте его пользователям.

Пользователи внутри базы

• 👤 Каждому человеку — своя учётная запись. Общий логин «Бухгалтер» убивает аудит: в журнале регистрации не понять, кто удалил документ.
• 🔑 Аутентификация ОС удобнее паролей: человек входит под доменной учёткой, пароль от 1С не нужен.
• 🧩 Права выдавайте через профили и группы доступа в типовых конфигурациях, а не ролью «Полные права».
• 🛑 Включите в карточке пользователя защиту от опасных действий — 1С будет спрашивать подтверждение при запуске внешних обработок.

Регламентное обслуживание и обновление платформы 1С

Без регламента база постепенно замедляется даже при хорошем железе.

Регламент СУБД

Для MS SQL удобен план обслуживания в Management Studio — настраивается мышкой и пишет отчёт о выполнении.

Регламент на стороне 1С

• 🧰 Тестирование и исправление в Конфигураторе — при подозрении на повреждение базы. Требует монопольного доступа, только после бэкапа.
• 🧹 Очистка кэша клиента — при странных ошибках интерфейса у одного пользователя: запуск с ключом /ClearCache или удаление папок кэша в профиле.
• 🗂 Очистка сеансовых данных сервера — крайняя мера при «зависших» сеансах: остановка службы и удаление папок snccntx* из каталога reg_1541.

Обновление платформы

Версия клиента и сервера должна совпадать полностью, до номера сборки. Порядок:

1. Сделайте бэкап всех баз средствами СУБД.
2. Поставьте новую версию на сервер рядом со старой.
3. Остановите службу агента, переключите её на ragent.exe из каталога новой версии, запустите.
4. Перерегистрируйте radmin.dll новой версии для консоли.
5. Обновите клиентов. Удобно через общий каталог дистрибутива и 1cestart: клиенты подтянут нужную версию сами.

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

Частые вопросы администратора 1С