При обслуживании систем на базе 1С:Предприятие мы часто сталкиваемся с ситуацией, когда для установки свежего релиза конфигурации (например, «Управление Торговлей» или ERP) требуется более новая версия технологической платформы. У администраторов и программистов возникает закономерный страх: если обновить платформу на сервере, запустится ли текущая рабочая база, которая еще не обновлена? И как правильно организовать процесс, чтобы не потерять данные?
В этой статье мы подробно разберем механику взаимодействия платформы и конфигурации, обсудим, почему нельзя игнорировать системные требования, и выработаем стратегию безопасного обновления с учетом "подводных камней", таких как расширения и отложенные обработчики.
Первый вопрос, который мы должны прояснить: не перестанет ли работать старая база на новой платформе?
Ответ лежит в архитектуре 1С. Платформа 1С обладает свойством обратной совместимости. Это означает, что новая версия платформы (например, 8.3.27) умеет работать с конфигурациями, разработанными под старые версии (например, 8.3.18). Ключевым механизмом здесь является свойство конфигурации РежимСовместимости.
Даже если мы обновим платформу на сервере и на клиентских машинах, в свойствах самой конфигурации (в метаданных) режим совместимости останется прежним до тех пор, пока вы не накатите обновление конфигурации. Платформа будет эмулировать поведение старой версии, поэтому риск того, что рабочая база просто "не запустится", минимален.
Однако есть важный нюанс для клиент-серверного варианта работы:
Иногда возникает соблазн обойти требование обновления платформы, изменив код проверки или понизив РежимСовместимости вручную. Разберем, почему это категорически запрещено.
Когда конфигурация требует новую платформу, это не просто прихоть разработчиков. Это означает, что в коде конфигурации используются новые инструкции встроенного языка или новые объекты метаданных, которые физически отсутствуют в старой версии платформы.
Если мы попытаемся "обмануть" систему (например, закомментировав проверку в модуле приложения), произойдет следующее:
Более того, обновление платформы часто несет изменение структуры системных таблиц, таких как v8users (список пользователей) или таблиц полнотекстового поиска. Работа старого движка с базой, конвертированной под новый формат, невозможна.
В рассматриваемой ситуации обновление происходит сразу на 5 релизов. Для современных конфигураций, таких как УТ 11, КА 2 или ERP, это серьезный вызов. Проанализируем риски, связанные с данными.
В последних версиях УТ 11 (особенно в ветке 11.5) кардинально менялась архитектура регистров накопления, отвечающих за взаиморасчеты:
РасчетыСКлиентамиРасчетыСПоставщикамиВ современных конфигурациях используется механизм БСП — Отложенное обновление данных. Когда вы нажимаете "Обновить" в конфигураторе, процесс не заканчивается. Самые тяжелые операции по переносу данных из старых регистров в новые выполняются фоновыми заданиями уже в пользовательском режиме.
Риск "каши" в данных:
Если мы перепрыгиваем через 5 релизов, существует вероятность наложения алгоритмов. Обработчик из релиза N+3 может попытаться обратиться к данным, которые еще не подготовил обработчик из релиза N+1. Если в этот момент задания упадут с ошибкой, а пользователи продолжат вводить документы, восстановить корректный учет будет крайне сложно.
Поэтому успешным обновлением считается не просто отсутствие ошибок в Конфигураторе, но и выполнение всех регламентных заданий со статусом «Завершено успешно» в панели «Обслуживание».
Если ваша конфигурация содержит доработки в виде расширений, обновление платформы и конфигурации требует дополнительной проверки. Рассмотрим, почему расширения "ломаются".
Расширения тесно связаны с основной конфигурацией через аннотации:
&Вместо&Перед&ПослеЕсли при обновлении типовой конфигурации разработчик 1С изменил количество параметров в функции, которую вы перехватываете в расширении, при запуске предприятия вы получите ошибку, и база может не открыться.
Также существуют риски, связанные именно со скачком версии платформы (например, с 8.3.18 на 8.3.27). Некоторые методы работы с СКД (Системой Компоновки Данных) или запросами в расширениях могут работать иначе в новых версиях платформы из-за ужесточения контроля синтаксиса или изменения планов запросов.
Сформулируем пошаговый план действий для безопасного перехода, основанный на опыте сообщества.
Сделайте полную резервную копию рабочей базы (dt или sql-dump). Разверните её на тестовом сервере.
Смело обновляйте платформу на тестовом сервере до требуемой версии (или выше, например, до актуальной LTS-версии). Убедитесь, что старая копия базы на ней запускается корректно. Это подтвердит, что РежимСовместимости отрабатывает штатно.
Выполните обновление конфигурации на тестовой базе. Если прыжок большой (5+ релизов), рассмотрите возможность поэтапного обновления (накатывать по 1-2 релиза с запуском в режиме Предприятия).
После первого запуска в режиме Предприятия откройте:
НСИ и Администрирование -> Обслуживание -> Обновление программы -> Результаты обновления.
Дождитесь, пока все процедуры перейдут в статус "Выполнено". Если есть ошибки — анализируйте Журнал регистрации.
Проверьте работоспособность всех расширений. Отключите галочку "Безопасный режим", если это требуется для их работы. Если расширение препятствует запуску, его придется дорабатывать в Конфигураторе.
Это самый важный этап. Сформируйте ключевые отчеты (Оборотно-сальдовая ведомость, Ведомость расчетов с клиентами) в рабочей базе и в обновленной тестовой базе за один и тот же период. Цифры должны совпадать до копейки.
Только после успешного прохождения всех этапов на копии можно приступать к обновлению рабочей базы ("боевой"). И помните: если вы обновляете сервер рабочей базы, заранее подготовьте дистрибутивы клиентов для пользователей или настройте их автоматическое развертывание.