Обновление платформы 1С:Предприятие 8.3 на сервере и рабочих местах

Обновление 1С 8.3 — это две разные задачи, которые часто путают. Первая — обновить платформу (ядро 1cv8, которое ставится на сервер и на компьютеры пользователей). Вторая — обновить конфигурацию (саму прикладную базу: Бухгалтерию, ЗУП, УТ). Порядок жёсткий: сначала поднимают платформу на сервере и клиентах, потом обновляют конфигурацию базы.

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

Что сделать до установки: копия и совместимость версий

Перед любым обновлением снимите резервную копию. Для клиент-серверной базы — средствами СУБД (например, backup PostgreSQL или MS SQL). Для файловой — выгрузка в .dt через Конфигуратор: Администрирование → Выгрузить информационную базу.

Без свежей резервной копии обновление не начинают. Реструктуризация базы и загрузка обновления — операции, которые при сбое оставляют базу в нерабочем состоянии, и откат возможен только из копии.

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

Что собрать заранее:

• 📦 дистрибутив платформы нужной разрядности (для сервера — x64);
• 🔑 действующую подписку, дающую право на обновление (файлы .cfu/.cf конфигурации качаются с сервиса обновлений по договору сопровождения);
• 👥 договорённость с пользователями об окне: установка платформы на сервере и реструктуризация базы требуют, чтобы в базе никого не было;
• 🗒️ номер текущего релиза конфигурации и платформы — чтобы знать, с чего обновляемся.

Отдельно проверьте, что регламентные и фоновые задания не запустятся в момент обновления. На клиент-серверной базе удобно заранее установить блокировку начала сеансов в консоли администрирования — тогда новые подключения не появятся, пока вы работаете. На свободном месте диска тоже стоит убедиться: реструктуризация крупной базы временно требует дополнительного пространства под служебные таблицы СУБД.

Установка новой платформы на сервере 1С:Предприятия

На сервере платформа запускается как служба — по умолчанию она называется «Агент сервера 1С:Предприятия». Пока служба работает, файлы платформы заняты, поэтому порядок такой.

1. Предупредите пользователей и дождитесь, пока все выйдут из базы. Проще всего — через консоль администрирования серверов или командой rac session list посмотреть активные сеансы.
2. Остановите службу агента сервера: Службы Windows → остановить «Агент сервера 1С:Предприятия», либо net stop по имени службы. Остановка службы разрывает все сеансы и фоновые задания в этот момент. Делайте это только в согласованное окно.
3. Запустите установщик новой платформы (setup.exe из дистрибутива) и обязательно отметьте компоненту «Сервер 1С:Предприятия». Разрядность компоненты сервера должна совпадать с тем, что стоял раньше (обычно x64).
4. Мастер установки предложит переустановить службу агента под новую версию — согласитесь. Так служба начнёт указывать на ragent.exe новой платформы.
5. Запустите службу агента и убедитесь, что кластер поднялся: в консоли администрирования видны рабочие процессы, список информационных баз на месте.

Каталог данных кластера (srvinfo) при обновлении платформы не трогают — он остаётся прежним, базы в нём никуда не деваются.

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

Обновление платформы на рабочих местах пользователей

На клиентах платформу ставят тем же дистрибутивом, но с компонентами клиента (толстый и/или тонкий клиент). Службу тут останавливать не нужно — достаточно, чтобы у пользователя была закрыта 1С.

Запуск нужной версии берёт на себя 1cestart.exe — общий лаунчер. Он читает список установленных версий и файл с настройками запуска и сам подбирает версию под базу. Поэтому обычно достаточно:

• установить новую платформу на компьютере (старую можно оставить — версии не конфликтуют);
• при первом запуске базы лаунчер подхватит подходящую версию.

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

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

Обновление конфигурации и реструктуризация базы

После того как платформа на сервере и клиентах поднята, обновляют саму конфигурацию. Делается это в Конфигураторе.

1. Войдите в базу в режиме Конфигуратор под пользователем с полными правами.
2. Меню Конфигурация → Поддержка → Обновить конфигурацию. Выберите источник обновления:
   • файл обновления .cfu — если обновляетесь последовательно, релиз за релизом;
   • файл поставки .cf — если ставите конфигурацию целиком на новую версию;
   • автоматический поиск, если настроено получение обновлений через сервис.
3. Платформа покажет, с какого релиза на какой идёт обновление, и список изменений. Примите обновление основной конфигурации.
4. Выполните Конфигурация → Обновить конфигурацию базы данных (горячая клавиша F7). На этом шаге изменения из конфигурации переносятся в структуру базы.

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

Отдельный случай — конвертация старых баз. База с конфигурацией, созданной для прежней версии платформы, при первом запуске на новой платформе обновляется автоматически. Если конфигурация работает в режиме совместимости, режим задаётся в свойствах корня конфигурации (свойство «Режим совместимости»); менять его стоит, только понимая последствия — часть прикладного кода может зависеть от старого поведения.

После крупного обновления или конвертации полезно выполнить Администрирование → Тестирование и исправление в Конфигураторе с проверкой логической и ссылочной целостности. Эта операция тоже требует монопольного доступа, поэтому её логично совместить с тем же окном, пока пользователи ещё не вернулись в базу.

Хранилище конфигурации и цепочка файлов обновления

Если конфигурация дорабатывалась (сняты с поддержки объекты, есть свои доработки) или над ней работает несколько разработчиков, обновление идёт через хранилище конфигурации.

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

1. захватить в хранилище объекты, которые затронет обновление (или всю конфигурацию);
2. выполнить обновление основной конфигурации из .cfu/.cf в Конфигураторе;
3. сравнить и объединить изменения поставщика со своими доработками (платформа показывает трёхстороннее сравнение: старая типовая, новая типовая, ваша);
4. поместить результат обратно в хранилище;
5. обновить конфигурацию базы данных (F7).

Про цепочку обновлений. Файл .cfu рассчитан на переход с конкретного релиза. Нельзя перепрыгнуть через несколько версий одним .cfu, если он не поддерживает ваш исходный релиз, — обновляйтесь последовательно, релиз за релизом, либо ставьте новую конфигурацию целиком из .cf. Какой релиз текущий, видно в Конфигураторе: Справка → О программе или в свойствах конфигурации (номер версии).

Диагностика и типичные ошибки при обновлении

Чаще всего обновление спотыкается на занятых файлах, правах и несовпадении версий. Короткая диагностика по симптому:

Ещё несколько мест, где легко ошибиться:

• Разрядность. На x64-сервере компонента сервера должна быть x64. Смешивать разрядность клиента и сервера допустимо, а вот компонента сервера неправильной разрядности просто не запустится.
• Права на запись в каталог кластера. Служба агента работает под определённой учётной записью; у неё должны быть права на каталог srvinfo.
• Доработанная конфигурация без снятия с поддержки. Если конфигурация на полной поддержке, но в ней есть изменения, обновление может затереть доработки. Всегда сравнивайте и объединяйте, а не принимайте изменения поставщика целиком.

Перед запуском полезно пройтись по короткому чек-листу.

Что проверить после обновления

Обновление не заканчивается на том, что база открылась. Прежде чем впускать пользователей, пройдитесь по нескольким контрольным точкам:

• 🚀 Запуск. База открывается и в режиме 1С:Предприятие, и в Конфигураторе, без сообщений о незавершённой реструктуризации.
• 🔢 Версии. В Справка → О программе номер платформы и релиз конфигурации — те, на которые обновлялись. На клиентах лаунчер подставляет ту же версию.
• 📝 Проведение документов. Проверьте на свежем документе, что проводки формируются и база не выдаёт ошибок при записи.
• ⏱️ Регламентные задания. Снимите блокировку начала сеансов и убедитесь, что фоновые и регламентные задания запускаются штатно.
• 🖨️ Печатные формы и обмены. Если были свои доработки, проверьте их в первую очередь — после объединения с типовой они чаще всего и «отваливаются».

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

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