Обновление высоконагруженных систем 1С на предприятиях с непрерывным циклом производства — это всегда сложная задача. Главная проблема заключается в том, что стандартное обновление через конфигуратор на «живой» базе может занимать длительное время, в течение которого пользователи не могут работать. Рассмотрим технологию обновления через тестовую базу с последующей выкладкой файла конфигурации (.cf), которая позволяет сократить время простоя «боевой» базы до минимума.
Прежде всего, разберем причины, по которым такой метод считается предпочтительным. Во-первых, это безопасность. Все ошибки, которые могут возникнуть в процессе реструктуризации таблиц или выполнения обработчиков, проявятся на копии, а не на рабочей системе. Во-вторых, это скорость. Основная часть работы по конвертации данных и подготовке метаданных происходит в стороне от пользователей. В-третьих, это тестирование. Вы можете проверить корректность работы нового релиза до того, как он попадет в промышленную эксплуатацию.
Первым делом проанализируем состояние нашей системы. Нам необходимо создать полную копию «боевой» базы. Важно помнить, что для корректности процесса копия должна быть максимально актуальной. Развернем ее в тестовом контуре, желательно на оборудовании, сопоставимом по мощности с серверным, чтобы реально оценить время выполнения операций.
Важный нюанс: Если в вашей базе используются расширения конфигурации, убедитесь, что они корректно перенеслись вместе с базой. На этом этапе мы должны гарантировать, что конфигурация поставщика и основная конфигурация в тестовой базе полностью идентичны рабочей.
Разберем процесс накатывания релизов. Если разрыв между текущей версией и целевой велик (пропущено несколько релизов), крайне не рекомендуется прыгать через них одним махом, даже если система это позволяет. Посмотрим на рекомендации фирмы «1С»: каждый промежуточный релиз может содержать критические изменения структуры данных.
Выполним следующие действия в конфигураторе тестовой базы:
.cfu) или полную конфигурацию (.cf).F7 для обновления конфигурации базы данных.После каждого шага обновления конфигурации обязательно запустим базу в режиме «Предприятие». Проанализируем ситуацию: современные конфигурации, построенные на Библиотеке стандартных подсистем (БСП), запускают процедуру «Результаты обновления программы». В этот момент выполняются обработчики обновления, которые переносят данные из старых реквизитов в новые, создают недостающие записи в регистрах и проверяют целостность.
Рассмотрим подробнее механизм работы обработчиков. В конфигурациях типа ERP 2.5, УТ 11 или БП 3.0 обработчики делятся на два типа:
При использовании метода с переносом .cf-файла, мы должны дождаться завершения всех обработчиков на тестовой базе. Выясним причину: если мы выгрузим конфигурацию и загрузим ее в боевую, а данные на боевой еще не прошли путь трансформации через промежуточные релизы, система может «запутаться» в очередности заданий. Для контроля используем форму Результаты обновления программы или стандартную обработку БСП.
После того как все этапы обновления на тестовой базе пройдены, обработчики завершены и проведено минимальное тестирование (проверка открытия форм, формирования основных отчетов), мы готовы к переносу. В конфигураторе тестовой базы выберем пункт меню: Конфигурация — Сохранить конфигурацию в файл... и сохраним ее под именем update.cf.
Этот файл теперь содержит в себе эталонную структуру метаданных, которую мы перенесем на «боевой» сервер.
Теперь наступил самый ответственный момент. Нам необходимо технологическое окно. Посмотрим на алгоритм действий в «боевой» базе:
Разберем, почему используется Загрузить конфигурацию. Этот метод делает основную конфигурацию полностью идентичной файлу. Поскольку наш файл update.cf был получен из копии этой же самой базы, идентификаторы объектов (UUID) совпадут, и реструктуризация пройдет корректно. Если же ваша тестовая база была создана не из копии, а «с нуля» из шаблона, использовать этот метод категорически нельзя, так как идентификаторы будут разными, что приведет к полной потере данных в таблицах.
После выбора файла нажмем F7. Система предложит выполнить обновление конфигурации базы данных. Проанализируем этот процесс: физически на SQL-сервере будут изменены таблицы (добавлены колонки, изменены типы данных). Время этого этапа зависит от объема данных. На тестовой базе вы могли заранее замерить этот интервал.
После успешного завершения запустим рабочую базу в режиме «Предприятие». Поскольку конфигурация уже содержит информацию о том, что релиз изменился, запустятся обработчики обновления. Однако теперь они будут работать с реальными данными «боевой» базы.
Рассмотрим специфические моменты, которые могут возникнуть при таком подходе:
1. Очистка серверного кэша. Часто после загрузки .cf возникают ошибки вида «Объект не найден» или «Ошибка формата потока». Это связано с тем, что сервер приложений 1С хранит кэш метаданных. В случае серьезных обновлений рекомендуется перезапустить службу Агент сервера 1С:Предприятия или вручную очистить папку snccntx.
2. Режим совместимости и платформа. Если новый релиз требует повышения версии платформы, это необходимо сделать до того, как вы начнете загружать .cf в рабочую базу. В противном случае конфигуратор может просто не открыться или выдать ошибку при попытке обновления базы данных.
3. Расширения. Проанализируем влияние расширений. При обновлении метаданных расширения могут стать «неактивными», если изменились типы данных или удалены объекты, к которым они обращаются. Обязательно зайдите в раздел Администрирование — Печатные формы, отчеты и обработки — Расширения и проверьте отсутствие красных восклицательных знаков.
Если вы хотите автоматизировать контроль завершения обработчиков, можно использовать функции БСП. Посмотрим на пример кода, который позволяет узнать, завершено ли полнотекстовое индексирование или другие фоновые процессы:
// Проверка статуса выполнения обработчиков обновления в БСП
Результат = ОбновлениеИнформационнойБазы.ВсеОбработчикиОбновленияЗавершены();
Если Не Результат Тогда
Сообщить("Внимание! Еще выполняются фоновые процедуры обновления данных.");
Иначе
Сообщить("Обновление данных успешно завершено.");
КонецЕсли;
Метод «Обновление через копию + Загрузка CF» является стандартом де-факто для крупных баз 1С. Мы рассмотрели, как минимизировать риски и время простоя. Помните, что ключевой успех этой операции зависит от двух факторов: полная идентичность UUID (тестовая база должна быть копией рабочей) и последовательный запуск обработчиков на всех промежуточных этапах.
Соблюдение этой инструкции позволит вам проводить обновления даже самых сложных систем с минимальным стрессом для пользователей и бизнеса.