Что обновить сначала: платформу или конфигурацию 1С

Правильный ответ в большинстве случаев один: сначала обновляют платформу 1С:Предприятие, затем конфигурацию. Причина проста — новые релизы конфигураций (Бухгалтерия, Управление торговлей, ЗУП и другие) разрабатываются под определённую минимальную версию платформы. Если конфигурация требует платформу 8.3.22, а на сервере стоит 8.3.18, база либо не запустится, либо откажется обновляться с явным сообщением о несовместимости.

Обратная ситуация встречается реже, но тоже возможна: очень старая конфигурация может не работать на слишком новой платформе из-за изменений в режиме совместимости, механизмах безопасности или отказа от устаревших технологий. Поэтому обновление — это всегда пара действий, которые планируются вместе, а не два независимых события.

Ниже разобраны правило выбора очередности, проверка совместимости версий, безопасный порядок действий для рабочей базы и типичные ошибки, которые приводят к простою учётной системы.

Как устроена зависимость между платформой и конфигурацией

Платформа 1С:Предприятие — это исполняемая среда: сервер, клиентские приложения, механизмы СУБД, встроенный язык. Конфигурация — прикладное решение, которое работает внутри этой среды. Каждый релиз типовой конфигурации тестируется вендором на определённых версиях платформы, и в поставке указывается минимально допустимая версия.

Эта информация публикуется в файле описания поставки (1cv8upd.htm или аналогичном документе в дистрибутиве релиза) и на портале 1С в описании версии. Там указано, например: «для работы требуется платформа версии не ниже 8.3.22.1709». Игнорировать это требование нельзя — механизм обновления конфигурации сам проверит версию платформы и прерванёт процесс.

Режим совместимости смягчает проблему «новая платформа — старая конфигурация», но не отменяет её полностью. Если конфигурация использует механизмы, удалённые из платформы, или рассчитана на слишком старый режим совместимости, запуск на новой платформе может завершиться ошибкой ещё на этапе входа в базу.

Общее правило очерёдности обновления

Базовая последовательность для типового сценария выглядит так: сначала платформа поднимается до версии, требуемой целевым релизом конфигурации, затем выполняется обновление самой конфигурации. Платформа при этом обновляется на всех компьютерах и серверах, с которых работают пользователи, иначе часть сотрудников просто не сможет подключиться.

Обратный порядок — сначала конфигурация, потом платформа — технически невозможен, если новый релиз конфигурации требует более новую платформу: обновление конфигурации просто не запустится. Единственный случай, когда конфигурацию обновляют без смены платформы, — текущая версия платформы уже удовлетворяет требованиям нового релиза.

Маршрут решения

Как выбрать действие

Новый релиз конфигурации требует платформу новее текущейСначала обновите платформу, затем конфигурацию

Текущая платформа уже подходит под требования релизаОбновляйте только конфигурацию, платформу не трогайте

Планируется переход через несколько релизов конфигурацииПроверьте требования каждого промежуточного релиза — платформу, возможно, придётся поднимать поэтапно

Конфигурация старая, а платформу нужно обновить по требованиям ИТПроверьте режим совместимости и протестируйте запуск на копии базы до обновления боевой среды

Проверка совместимости перед началом работ

До любых действий с боевой базой соберите три факта: текущую версию платформы, текущий релиз конфигурации и требования целевого релиза. Версию платформы видно в окне «О программе» или в свойствах информационной базы, релиз конфигурации — в разделе «Администрирование — Обновление версии программы» либо в сведениях о конфигурации в конфигураторе.

Требования целевого релиза берутся из описания поставки. Важно проверить не только минимальную версию платформы, но и допустимый путь обновления: некоторые релизы можно ставить только поверх определённых предыдущих версий. Если база сильно отстала, обновление идёт через промежуточные релизы, и для каждого из них может понадобиться своя версия платформы.

Контрольные точки

Как проверить готовность к обновлению

Версия платформы после обновления

Норма

Не ниже требуемой целевым релизом конфигурации

Тревожный признак

Ниже требуемой — обновление конфигурации не запустится

Путь обновления конфигурации

Норма

Целевой релиз допускает обновление с вашей текущей версии

Тревожный признак

Требуется промежуточный релиз, которого нет в наличии

Резервная копия

Норма

Выгрузка .dt или копия СУБД создана и проверена восстановлением на тестовом стенде

Тревожный признак

Копия есть только на том же диске, что и база, или её никто не проверял

Тестовый запуск

Норма

Обновление пройдено на копии базы, пользователи вошли и выполнили типовые операции

Тревожный признак

Обновление впервые выполняется сразу на рабочей базе

Безопасный порядок обновления рабочей базы

Полный цикл обновления продуктивной базы занимает больше времени, чем сама установка релизов, потому что основную часть составляют подготовка и проверка. Сокращать эти этапы — главная причина аварийных ситуаций.

1. 1
   Сделайте полную резервную копию базы (выгрузка .dt или средствами СУБД) и проверьте, что она восстанавливается
2. 2
   Изучите описание целевого релиза конфигурации: требуемую версию платформы и допустимый путь обновления
3. 3
   Обновите платформу на сервере и всех клиентских машинах до требуемой версии
4. 4
   Разверните копию базы на тестовом стенде и выполните полное обновление конфигурации на ней
5. 5
   Проверьте на тестовой копии вход пользователей, проведение документов, формирование регламентированной отчётности и обмены данными
6. 6
   Завершите работу пользователей в боевой базе, заблокируйте сеансы и повторите обновление на ней
7. 7
   После обновления выполните контрольные проверки и только затем откройте доступ пользователям

Отдельное внимание — обменам данными и внешним подключениям. Если база обменивается с другими конфигурациями, сайтом, кассами или банковскими сервисами, после обновления платформы и конфигурации каждый обмен нужно проверить вручную: форматы обмена и требования к версиям на обеих сторонах могут измениться.

Ситуации, когда платформу обновляют отдельно

Иногда платформу приходится обновлять без смены релиза конфигурации: для устранения уязвимостей, исправления критических ошибок, перехода на новую версию СУБД или поддержки новых операционных систем. В этом случае ключевой вопрос — сохранит ли текущая конфигурация работоспособность на новой платформе.

Проверка делается через режим совместимости, указанный в свойствах конфигурации, и обязательный тестовый запуск. Для типовых конфигураций вендор публикует списки рекомендованных версий платформы — ориентируйтесь на них, а не на принцип «поставить самое свежее».

Типичные ошибки при выборе очерёдности

Отдельная группа ошибок связана с нетиповыми доработками. Если конфигурация изменена, обновление может затронуть доработанные объекты, и после него потребуется ручная доработка. Такие базы обновляют только после тестового прогона с участием специалиста, который эти изменения поддерживает.

Частые вопросы

Можно ли обновить конфигурацию, не обновляя платформу?

Да, если текущая версия платформы соответствует требованиям целевого релиза. Проверьте описание поставки релиза: там указана минимально допустимая версия платформы. Если ваша версия её удовлетворяет, обновление платформы не требуется.

Что будет, если поставить слишком новую платформу для старой конфигурации?

Конфигурация может не запуститься или работать с ошибками, если использует устаревшие механизмы. Проверьте режим совместимости конфигурации и обязательно протестируйте запуск на копии базы. Для типовых решений ориентируйтесь на списки рекомендованных версий платформы от вендора.

Нужно ли обновлять платформу на всех компьютерах пользователей?

Да. Клиентское приложение и сервер должны работать на совместимых версиях платформы. Если обновить только сервер, пользователи со старыми клиентами не смогут подключиться к базе и работа остановится.

Как откатить обновление, если что-то пошло не так?

Штатного механизма отката обновления конфигурации нет. Единственный способ вернуться — восстановить базу из резервной копии, сделанной до обновления. Поэтому копия должна быть создана и проверена восстановлением до начала любых работ.

База сильно устарела, обновление идёт через несколько релизов. В каком порядке действовать?

Двигайтесь последовательно по цепочке релизов, допустимой поставщиком. Перед каждым шагом проверяйте требования к платформе: на некоторых этапах её придётся поднимать поэтапно. Весь путь сначала отрабатывается на тестовой копии базы.

Кто должен выполнять обновление — бухгалтер или специалист?

Типовую конфигурацию без доработок на однопользовательской базе опытный пользователь может обновить самостоятельно через встроенный механизм обновления. Для серверных баз, нетиповых конфигураций и баз с обменами данными работу должен выполнять специалист с правами администратора и опытом восстановления из резервных копий.