Настройка сервера 1С: пошаговый чек-лист для системного администратора

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

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

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

Сервер 1С стартует с ОС, и многие узкие места живут именно здесь. Выбор зависит от связки: под MS SQL — Windows Server, под PostgreSQL для 1С - Linux (Astra, РЕД ОС, Debian или Ubuntu LTS). Сравнение ниже.

Сетевые настройки. Статический IP, корректный DNS, имя хоста по политике. Проверьте прямую и обратную DNS-запись, без них кластер 1С и AD будут «капризничать». Включите NTP-синхронизацию с контроллером домена или внешним пулом.

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

Питание и BIOS. Поставьте режим «Высокая производительность» в Windows или performance governor в Linux, отключите агрессивные C-states - 1С чувствительна к латентности процессора. После накатывания актуальных обновлений отключите автоустановку с принудительной перезагрузкой.

Установка сервера 1С на связке с MS SQL начинается с самой СУБД. Запустите установщик MS SQL, выберите режим Default Instance и смешанную аутентификацию, иначе администратору 1С придётся каждый раз входить под доменной учёткой.

Включите TCP/IP в SQL Server Configuration Manager, откройте порт 1433. Ограничьте Maximum server memory, оставив ОС хотя бы пару гигабайт. MAXDOP выставьте в 1 согласно рекомендациям 1С:Предприятия. Системную базу model переведите в Simple recovery - новые базы наследуют эту модель.

Разнесите по томам data-файлы, log-файлы и tempdb. Tempdb - на самый быстрый NVMe, это горячая зона 1С. Создайте пустую базу под проект: recovery model Full для прода, Simple для тестов.

Используйте только сборки от Postgres Pro или официальные сборки 1С. Обычный community PostgreSQL не подойдёт - слишком много специфичных патчей.

В postgresql.conf настройте shared_buffers, work_mem, effective_cache_size по рекомендациям 1С. В pg_hba.conf разрешите подключения с сервера 1С и закройте остальное. Локаль и кодировка - UTF-8, иначе будут сюрпризы с кириллицей.

Администрирование сервера 1С начинается с установки самой платформы. Запустите установщик технологической платформы 1С, в списке компонентов выберите «Сервер 1С:Предприятие» и «Администрирование сервера». Остальное, по необходимости.

Создайте локальную учётную запись USR1CV8 (или доменную) - от её имени работает служба сервера 1С. У учётки не должно быть прав на интерактивный вход, но должны быть права на каталог srvinfo. Запустите службу «Агент сервера 1С:Предприятия» от имени этой учётки.

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

Настройте рабочие процессы (rphost) по числу одновременных пользователей и включите безопасное расходование памяти, иначе один «сошедший с ума» сеанс уронит всем рабочий день. В консоли пропишите регламентные операции: профилактика, тестирование и исправление, переиндексация - раз в неделю в выходные. Финальная проверка - подключение из тонкого клиента: создайте базу в списке, войдите. Если форма открывается и справочники грузятся, платформа поднята.

Кластер 1С нужен при росте числа пользователей за полсотни и при требовании отказоустойчивости. Возьмите минимум два сервера 1С, общий srvinfo держите на отказоустойчивом хранилище. Настройте уровень отказоустойчивости в свойствах кластера, в назначениях функциональности распределите rphost по узлам. Лицензии - на каждый узел; конфигурацию между узлами держите синхронной.

Откройте на брандмауэре порты 1С: 1540 (агент), 1541 (главный менеджер кластера), 1560–1591 (рабочие процессы). Плюс порт СУБД: 1433 для MS SQL или 5432 для PostgreSQL.

Служба 1С работает под доменной учётной записью с минимальными правами. Права на каталог srvinfo - только эта учётка и админы. Админы СУБД и админы 1С - разные группы AD, и каждая видит только своё. Веб-доступ через IIS или Apache с модулем 1С - отдельная задача с публикацией через утилиты администрирования. Журнал регистрации по умолчанию идёт в SQLite, для крупных баз переключите формат на SQL.

Резервное копирование 1С делается на уровне СУБД, а не на уровне платформы - это самая частая ошибка при первой настройке.

В MS SQL поставьте полные бэкапы по ночам, разностные днём и Transaction Log каждые 15–30 минут для прода. Храните бэкапы на отдельной СХД или сервере резервного копирования, не на том же томе, где живут данные. В PostgreSQL для разовых выгрузок - pg_dump, для непрерывной защиты - pg_basebackup плюс архивирование WAL, для крупных баз - Barman или pgBackRest.

Раз в месяц разворачивайте свежий бэкап на тестовом сервере и убеждайтесь, что база открывается и пользователи могут войти. Неработающий бэкап равен отсутствию бэкапа. Файловые бэкапы srvinfo делайте только при остановленной службе 1С через теневую копию или snapshot СХД.

Мониторинг подключайте сразу: Zabbix, PRTG или Prometheus, что у вас уже есть. Минимум: счётчики rphost (память, CPU), журнал ошибок 1С, занятое место в БД и журнале транзакций, доступность портов 1540, 1541 и порта СУБД. Алёрты на рост базы, рост журнала транзакций, обрыв подключений к СУБД и рестарты rphost должны прилетать инженеру раньше, чем пользователи с «1С снова не работает».

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

Прогоните типовой тест Гилёва для оценки скорости - не гонитесь за «зелёными» цифрами, смотрите на нагрузку, типичную для вашего бизнеса. Запустите тестирование и исправление в консоли. Сделайте бэкап вручную, восстановите его на тестовом контуре, откройте базу - это финальная проверка.

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

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