Создание тестовой копии для таких комплексных решений, как 1С:Комплексная автоматизация 2 (КА 2) или 1С:ERP, — это ответственная задача, требующая от системного администратора и программиста четкого понимания внутренних механизмов платформы. Ошибки на этом этапе могут привести к крайне неприятным последствиям: от случайной отправки тестовых писем контрагентам до затирания реальных данных в рабочей базе через механизмы РИБ (распределенных информационных баз) или отправки некорректной отчетности в контролирующие органы (СКО).
В данной статье мы подробно разберем, какой способ копирования базы выбрать, как ведут себя расширения конфигурации при переносе, а также рассмотрим пошаговый алгоритм безопасного запуска копии и изоляции её внешних связей.
Выясним, какой инструмент создания копии является наиболее надежным и быстрым для баз уровня КА 2. Традиционно в среде «1С» используются два подхода: выгрузка в файл .dt и создание резервной копии средствами СУБД (например, Microsoft SQL Server).
Для крупных баз данных (от нескольких десятков гигабайт) выгрузка в формат .dt крайне не рекомендуется разработчиками фирмы «1С». Процесс загрузки и выгрузки файлов .dt очень требователен к оперативной памяти сервера приложений. При нехватке ресурсов процесс часто аварийно завершается с ошибками класса «Out of Memory». Кроме того, для выгрузки .dt требуется монопольный доступ к базе, что вынуждает администратора выгонять всех пользователей из рабочей системы.
Копирование средствами СУБД MSSQL лишено этих недостатков. Рассмотрим его ключевые преимущества:
.bak) на SQL-сервере выполняется «на лету» без блокировки работы пользователей.Проанализируем теперь поведение расширений конфигурации (файлов .cfe). Часто возникает вопрос: переносятся ли расширения и созданные в них объекты данных при копировании через MSSQL?
Ответ однозначный: да, расширения и все их данные переносятся полностью и автоматически. В СУБД MSSQL конфигурация базы данных, включая все подключенные расширения, их собственные справочники, документы, реквизиты и табличные части, физически хранится в тех же таблицах SQL. Платформа «1С:Предприятие» создает для таблиц расширений специальные структуры (с префиксами имен таблиц СУБД), которые беспрепятственно копируются вместе со всей базой данных. Никаких дополнительных действий по повторному подключению файлов .cfe в тестовой копии выполнять не нужно.
Одной из главных опасностей при развертывании тестовой копии является автоматический запуск фоновых процессов. Как только копия базы будет запущена, регламентные задания начнут отправлять почту, синхронизироваться с сайтами, банками и другими внешними сервисами, считая, что они работают в «живой» базе.
Чтобы исключить этот риск, разберем по шагам схему блокировки регламентных заданий до первого входа пользователей.
Шаг 1. Блокировка на уровне кластера серверов 1С
При регистрации восстановленной базы на сервере приложений «1С:Предприятие» в консоли администрирования необходимо **сразу же** установить признак блокировки регламентных заданий. Для этого в свойствах созданной информационной базы установите флаг «Блокировка регламентных заданий включена» (в коде и утилитах администрирования этот параметр называется ScheduledJobsDenied). Сделайте это строго до того, как запустите хотя бы один клиентский сеанс.
Вы можете выполнить эту операцию скриптом через утилиту администрирования rac или программно через COM/агент администрирования.
Шаг 2. Локальный запуск (для файловых вариантов)
Если копия разворачивается локально или в файловом варианте, где нет консоли кластера, используйте специальный ключ командной строки при первом запуске:
"C:\Program Files\1cv8\8.3.22.1709\bin\1cv8.exe" ENTERPRISE /F"C:\1C_Bases\KA2_Test" /N"Администратор" /P"Пароль" /AllowExecuteScheduledJobs -off
Параметр /AllowExecuteScheduledJobs -off временно отключает выполнение любых фоновых и регламентных задач для запускаемой информационной базы.
Шаг 3. Использование механизмов БСП (Библиотеки Стандартных Подсистем)
Современные версии КА 2 построены на БСП. При первом запуске базы после копирования система определяет изменение её расположения (уникального идентификатора ИБ) и выводит интерактивный диалог: «Информационная база перемещена или восстановлена из копии?».
Если пользователь выбирает вариант «Это копия информационной базы», БСП автоматически запускает процедуру БлокировкаРаботыСВнешнимиРесурсами(). При этом блокируются все исходящие соединения: рассылка отчетов, синхронизация данных, обмен с банками, интеграция с ГИС и СКО. В коде кастомных обработчиков обмена всегда следует проверять этот флаг с помощью обращения к функции БСП:
Если РегламентныеЗаданияСервер.РаботаСВнешнимиРесурсамиЗаблокирована() Тогда
ЗаписьЖурналаРегистрации("ТестоваяКопия.Обмен",
УровеньЖурналаРегистрации.Предупреждение, , ,
"Выполнение обмена отменено: работа с внешними ресурсами заблокирована.");
Возврат;
EndIf;
Посмотрим на важный нюанс: полагаться только на интерактивный выбор пользователя при первом входе опасно. Если первый вошедший пользователь случайно нажмет кнопку «Информационная база перемещена» (а не «Это копия»), блокировка внешних ресурсов не включится, и база начнет отправлять данные во внешние системы. Именно поэтому предварительная жесткая блокировка регламентных заданий на уровне кластера (Шаг 1) является обязательной.
Сервис «1С-Отчетность» (обмен со СКО через Калугу-Астрал) имеет жесткие механизмы синхронизации и контроля транзакций. Если запустить тестовую копию базы с активными регламентными заданиями СКО, она может автоматически забрать новые требования от ФНС с сервера оператора. Это сделает невозможным их получение в основной рабочей базе, что приведет к пропуску сроков ответов на требования контролирующих органов.
Проанализируем, как полностью обезопасить тестовый контур от взаимодействия со СКО.
Во-первых, выполним интерактивное отключение обмена непосредственно в режиме «1С:Предприятие». Для этого необходимо перейти в раздел: 1С-Отчетность -> Настройки -> Настройки обмена с контролирующими органами -> Расширенные настройки. В открывшейся форме перейдите по ссылкам настроек обмена с ФНС, СФР и Росстатом и установите для каждого направления признак «Документооборот отключен».
Во-вторых, разберемся, как программно найти и отключить автоматические обработчики ожидания, которые могут инициировать фоновые запросы к СКО на клиентских рабочих местах. Часто вызовы функций документооборота с контролирующими органами зашиты на уровне модулей управляемого приложения и привязаны к обработчикам ожидания. Для их поиска в конфигураторе запустите глобальный поиск по конфигурации со следующими ключевыми фразами:
ДокументооборотСКО — для локализации всех модулей, отвечающих за интеграцию;ПодключениеОбработчикаОжидания — для поиска процедур, запускающих периодический опрос серверов;ПроверитьНовыеСообщения — стандартное имя процедур получения обновлений документооборота;ПолучитьОбновленияСКО — ключевой метод обновления статусов регламентированной отчетности.Выявленные вызовы в тестовой базе рекомендуется программно перехватывать (например, через расширение конфигурации с директивой &Вместо) и блокировать их выполнение, если база определена как копия.
Наиболее надежный метод (Сетевая изоляция): Самый надежный способ защитить рабочий контур — настроить сетевую изоляцию тестового сервера. Заблокируйте на уровне сетевого экрана (брандмауэра ОС или прокси-сервера) исходящий трафик для тестового сервера приложений «1С». Закрытие портов и блокировка адресов (в частности, серверов *.1c.ru, *.keydisk.ru и шлюзов операторов отчетности) гарантирует, что тестовая база физически не сможет отправить или принять внешние данные, даже если администратор забыл отключить регламентные задания.
Если ваша система использует распределенную информационную базу (РИБ) и вам необходимо протестировать механизмы обмена между копиями баз (например, «Тест_Центр» и «Тест_Узел»), изменения одной лишь папки обмена в настройках транспорта недостаточно. Посмотрим на важные скрытые параметры, которые необходимо скорректировать.
1. Очистка регистрации изменений
При создании копии базы из рабочей базы переносятся таблицы регистрации изменений (номера сообщений и измененные объекты, подготовленные к отправке). Если запустить обмен между тестовыми копиями без предварительной очистки, базы попытаются выгрузить друг другу колоссальный объем накопленных рабочих данных. Это приведет к зависанию обмена и переполнению диска.
Для решения этой проблемы очистите регистрацию изменений программно. Рассмотрим пример кода, который можно запустить в тестовой базе перед стартом обменов:
Процедура ОчиститьРегистрациюИзмененийДляТеста() Экспорт
Для Каждого ПланОбмена Из Метаданные.ПланыОбмена Цикл
ВыборкаУзлов = ПланыОбмена[ПланОбмена.Имя].Выбрать();
Пока ВыборкаУзлов.Следующий() Цикл
Если ВыборкаУзлов.Ссылка = ПланыОбмена[ПланОбмена.Имя].ЭтотУзел() Тогда
Продолжить;
КонецЕсли;
// Полное удаление регистрации изменений для узла
ПланыОбмена.УдалитьРегистрациюИзменений(ВыборкаУзлов.Ссылка);
КонецЦикла;
КонецЦикла;
ЗаписьЖурналаРегистрации("ТестоваяКопия.ОчисткаРИБ",
УровеньЖурналаРегистрации.Информация, , ,
"Регистрация изменений успешно очищена для всех планов обмена.");
КонецПроцедуры
2. Изменение кодов и наименований узлов планов обмена
Чтобы тестовые базы обменивались исключительно между собой, необходимо переименовать коды узлов (например, добавить префикс или суффикс _TEST к реквизиту Код узла плана обмена). Если оставить коды прежними, базы по ошибке могут идентифицировать себя как рабочие узлы, что приведет к путанице, если файлы обмена случайно пересекутся.
3. Префиксы информационной базы и номеров документов
Обязательно измените префикс информационной базы в настройках тестовой копии (в КА 2 это делается в разделе администрирования). Если префиксы тестовой и рабочей баз совпадут, автонумерация документов в тестовой базе начнет генерировать номера, идентичные рабочим. В случае сбоя или случайной ручной загрузки данных из теста в рабочую базу это приведет к критическому затиранию документов с совпадающими номерами.
4. Проверка параметров авторизации веб-сервисов
Если ваш самописный РИБ или интеграционные шлюзы используют для передачи данных не файловый каталог, а Web-сервисы или HTTP-сервисы, проверьте настройки адресов подключений (URL), логины и пароли. Убедитесь, что тестовая база обращается к тестовым веб-сервисам, а не стучится на рабочий IIS/Apache сервер.
Резюмируя все вышесказанное, составим итоговый пошаговый план развертывания безопасной тестовой среды:
.bak файла).Соблюдение данного регламента гарантирует стабильную работу тестового контура без рисков нарушить бизнес-процессы в рабочей информационной базе «1С:Комплексная автоматизация 2».