При работе в большой команде разработчиков и тестировщиков неизбежно возникает ситуация, когда один общий сервер приложений 1С превращается в «зоопарк» из постоянно обновляемых, удаляемых и перезаписываемых информационных баз. Основные сложности здесь связаны с бесконтрольным запуском регламентных заданий в тестовых копиях и потерей прав администратора после загрузки выгрузок (.dt) из рабочих систем. Рассмотрим комплексный подход к решению этих проблем, сочетающий технические и организационные меры.
Один из самых надежных штатных механизмов платформы 1С для управления нагрузкой и регламентными заданиями — это требования назначения функциональности. Разберем по шагам, как это работает в контексте общего сервера разработки. Мы можем настроить кластер таким образом, чтобы регламентные задания выполнялись только на определенных рабочих серверах или не выполнялись вовсе для конкретных баз.
Проанализируем ситуацию: если у нас есть несколько рабочих серверов в кластере, мы можем создать правило, запрещающее сервис СервисРегламентныхЗаданий для всех баз, кроме списка исключений. Это гарантирует, что при создании новой тестовой базы «по умолчанию» в ней ничего не запустится, пока администратор явно не изменит настройки в консоли администрирования. Также существует возможность создать отдельный инстанс сервера 1С для каждого ведущего разработчика или группы тестирования, что обеспечит полную изоляцию процессов на уровне операционной системы.
Современный подход к управлению сервером подразумевает отказ от ручного создания баз в консоли. Рассмотрим внедрение пайплайнов (например, на базе GitLab CI, Jenkins или простых сценариев OneScript). Мы можем автоматизировать процесс «поднятия» базы следующим образом:
.dt.ScheduledJobsDeny (блокировка регламентных заданий).Пример пакетного запуска конфигуратора для установки блокировок может выглядеть так:
"C:\Program Files\1cv8\common\1cestart.exe" DESIGNER /S "Server\BaseName" /N "Admin" /P "Password" /UC "КодДоступа" /DumpResult "result.txt" /DisableStartupMessages /Execute "C:\Scripts\LockJobs.epf"
В самой обработке LockJobs.epf мы используем программный интерфейс:
ИнфоБаза = ИнформационныеБазы.НайтиПоИмени("BaseName");
Блокировка = ИнфоБаза.СоздатьБлокировкуУстановкиСоединений();
Блокировка.Установить();
// Установка блокировки регламентных заданий
ПараметрыБлокировки = Новый ПараметрыБлокировкиСеансов;
ПараметрыБлокировки.БлокировкаРегламентныхЗаданийУстановлена = Истина;
УстановитьБлокировкуСеансов(ПараметрыБлокировки);
Частая проблема: после загрузки клиентской базы администратор сервера теряет доступ, так как список пользователей полностью заменяется данными из .dt. Чтобы не тратить время на выяснение паролей, мы можем использовать метод прямого редактирования таблиц безопасности на уровне SQL. Проанализируем таблицу v8users.
Если нам нужно экстренно зайти в базу, где нет известных нам администраторов, мы можем временно переименовать или очистить таблицу пользователей в СУБД. При запуске 1С увидит, что список пользователей пуст, и позволит войти под любым именем с полными правами. После создания нужного нам пользователя, данные можно вернуть обратно.
Важно: Прямые запросы к СУБД нарушают лицензионное соглашение в части изменения структуры данных, однако для целей восстановления доступа в тестовых средах этот метод часто является единственно быстрым. Рассмотрим пример очистки списка пользователей (для MSSQL):
-- Очистка списка пользователей для входа без пароля
TRUNCATE TABLE v8users;
-- После этого заходим в 1С, создаем админа и работаем.
Более цивилизованный метод — использование серверных скриптов, которые добавляют служебного пользователя Admin_Service сразу после загрузки базы, используя пакетный режим запуска обработки, как было описано выше.
Выясним причину, по которой все разработчики стремятся на один сервер. Часто это связано с нежеланием настраивать окружение. Хорошей практикой является использование Microsoft SQL Server Developer Edition (который бесплатен для целей разработки) на локальных машинах. Это снимает нагрузку с общего сервера и устраняет конфликты прав.
Еще более современный способ — использование Docker-контейнеров для 1С. Мы можем подготовить образ, содержащий сервер 1С нужной версии и предустановленные инструменты. Разработчик запускает контейнер одной командой, получает чистую базу, и при этом он является «богом» в рамках своего контейнера, не мешая коллегам.
Для оперативного вмешательства и «лечения» баз на общем сервере рекомендуется использовать специализированные наборы обработок, такие как «Инструменты разработчика» (ИР). Они позволяют выполнять произвольный код на сервере, менять данные без контроля прав (при наличии административного доступа) и анализировать состояние регламентных заданий в удобном интерфейсе.
Рассмотрим полезную функцию ИР по массовой блокировке заданий: инструмент позволяет подключиться к кластеру и одной кнопкой «погасить» задания во всех выбранных базах. Это значительно экономит время системного администратора при проведении регламентных работ на сервере.
Помимо технических решений, необходимо внедрить регламент «жизни» базы на сервере. Посмотрим на эффективные правила:
Таким образом, управление общим сервером 1С — это не столько рутинный труд, сколько задача по автоматизации. Выстроив один раз цепочку «Скрипт создания базы -> Блокировка заданий -> Добавление админа», вы избавитесь от большинства проблем, описанных в теме.