Проблема случайного запуска регламентных заданий в копиях рабочих баз является одной из самых критичных для системных администраторов и разработчиков 1С. Забытая "галочка" в консоли кластера может привести к фатальным последствиям: отправке тестовых писем реальным клиентам, выгрузке некорректных данных в банк-клиент или обновлению статусов заказов на маркетплейсах. В данной статье мы разберем, как реализовать многоуровневую защиту на уровне кода и системных настроек, чтобы исключить человеческий фактор.
Самый простой и быстрый способ — это программная проверка текущего имени базы или сервера. Мы можем зашить в код условие, которое будет проверять, соответствует ли текущая строка соединения эталонной (рабочей) базе. Рассмотрим, как это реализовать. Нам поможет функция СтрокаСоединенияИнформационнойБазы().
Разберем пример кода, который можно разместить в начале процедуры каждого регламентного задания или в общем модуле:
Процедура ВыполнитьОбменДанными() Экспорт
НазваниеРабочейБазы = "PRODUCTION_BASE";
ТекущаяСтрокаСоединения = СтрокаСоединенияИнформационнойБазы();
// Проверяем, содержится ли имя рабочей базы в строке соединения
Если Найти(ВРег(ТекущаяСтрокаСоединения), ВРег(НазваниеРабочейБазы)) = 0 Тогда
ЗаписьЖурналаРегистрации("БлокировкаРЗ", УровеньЖурналаРегистрации.Предупреждение, , ,
"Попытка запуска регламентного задания в тестовой базе: " + ТекущаяСтрокаСоединения);
Возврат;
КонецЕсли;
// Основной код задания...
КонецПроцедуры
Важный нюанс: Проанализируем ситуацию, упомянутую опытными разработчиками. Иногда при запуске в фоновом задании строка соединения может возвращаться в ином формате (например, через IP-адрес вместо имени сервера). Поэтому рекомендуется использовать проверку не только по имени базы, но и по уникальному идентификатору (GUID) информационной базы, если это возможно в вашей архитектуре.
Если ваша конфигурация построена на БСП (что справедливо для большинства типовых решений, таких как ERP, УТ 11, БП 3.0), следует использовать штатные механизмы "Детекции копии". Рассмотрим подробнее, как это работает.
Система БСП при старте сравнивает параметры текущего сеанса с сохраненными ранее данными. Если база была перенесена на другой сервер или переименована, система выдает запрос: "Информационная база перемещена или является копией". При выборе варианта "Это копия" 1С автоматически блокирует все регламентные задания.
Для усиления этой защиты мы можем программно обращаться к методам БСП. Разберем по шагам, как настроить зависимости в модуле РегламентныеЗаданияПереопределяемый:
Процедура ПриОпределенииЗависимостейРегламентныхЗаданий(Зависимости) Экспорт
// Пример настройки зависимости задания от функциональной опции
Зависимость = Зависимости.Добавить();
Зависимость.РегламентноеЗадание = Метаданные.РегламентныеЗадания.СинхронизацияДанных;
Зависимость.ФункциональнаяОпция = Метаданные.ФункциональныеОпции.ИспользоватьСинхронизациюДанных;
КонецПроцедуры
Также полезно вызвать проверку в начале процедуры самого задания:
ОбщегоНазначения.ПриНачалеВыполненияРегламентногоЗадания();
Эта функция проверит, не установлена ли блокировка регламентных заданий на уровне параметров работы системы БСП, и корректно завершит выполнение, если база определена как копия.
Рассмотрим более продвинутый подход, который часто применяется в крупных компаниях. Вместо того чтобы просто блокировать задания, мы создаем "безопасную среду" в тестовой базе при первом входе администратора. Выясним причину, почему это надежнее: даже если задание будет запущено вручную, оно не сможет навредить.
Проанализируем алгоритм, который можно внедрить в процедуру ПередНачаломРаботыСистемы или специальную обработку:
Использование у всех объектов метаданных РегламентноеЗадание.test@mycompany.local).Пример кода для массового отключения заданий:
Для Каждого Задание Из РегламентныеЗадания.ПолучитьРегламентныеЗадания() Цикл
Задание.Использование = Ложь;
Попытка
Задание.Записать();
Исключение
// Обработка ошибок доступа
КонецПопытки;
КонецЦикла;
Этот метод считается одним из самых надежных, так как он не зависит от настроек внутри 1С или случайного изменения имени базы в кластере. Мы можем создать на рабочем сервере специальную переменную окружения, например 1C_ENVIRONMENT = PRODUCTION.
В коде 1С мы проверяем наличие этой переменной:
Шелл = Новый COMОбъект("WScript.Shell");
ПеремОкружения = Шелл.ExpandEnvironmentStrings("%1C_ENVIRONMENT%");
Если ПеремОкружения <> "PRODUCTION" Тогда
// Мы в тестовой среде, выполнение запрещено
Возврат;
КонецЕсли;
Прелесть этого метода в том, что при копировании базы на тестовый сервер переменная окружения там будет отсутствовать или иметь значение TEST, что автоматически заблокирует выполнение критичного кода без каких-либо ручных манипуляций в консоли администрирования.
Рассмотрим ситуацию с точки зрения системного администрирования. Если программные методы кажутся вам недостаточными, стоит применить изоляцию на уровне инфраструктуры:
rphost тестового кластера от имени специально созданного пользователя Windows/Linux, у которого нет прав доступа к сетевым папкам обмена рабочей базы.rac и устанавливает параметр --scheduled-jobs-deny=on для созданной базы.Мы проанализировали различные подходы к защите от нежелательного запуска регламентных заданий. Подведем итог: наиболее эффективным является сочетание нескольких методов. Во-первых, обязательно используйте механизмы БСП, так как они являются стандартом для современной платформы 1С. Во-вторых, добавьте проверку строки соединения или переменной окружения в критически важные узлы обмена данными. Это создаст "второй рубеж обороны", который спасет систему, даже если кто-то сознательно или случайно снимет блокировку в консоли кластера 1С.