Платформа 1С: как выбрать частоту обновлений без лишнего риска

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

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

Ниже — от чего зависит частота, какой цикл выбрать под размер бизнеса, как не сломать доработки и как пройти обновление безопасно.

От чего зависит, когда ставить новый релиз

Решение «обновлять или подождать» складывается из нескольких факторов. Расставьте их по важности для своей базы.

• 🔗 Требования конфигурации. Каждый релиз прикладного решения указывает минимальную и рекомендованную версию платформы. Если новая Бухгалтерия или ЗУП не запускается на вашей платформе — платформу придётся поднять. Это самый частый триггер.
• 🛡️ Исправления ошибок и уязвимостей. В новых релизах закрывают дефекты и проблемы безопасности. Если вас касается конкретная ошибка из списка изменений — есть повод обновиться вне графика.
• ⚙️ Новые возможности. Ускорение запросов, работа с внешними источниками, механизмы кластера. Нужны не всем и не всегда оправдывают риск.
• 🧩 Доработки и расширения. Чем сильнее конфигурация изменена под вас, тем осторожнее с платформой: поведение запросов и форм между версиями иногда меняется.
• 📈 Стабильность текущей версии. Если база работает ровно и жалоб нет — менять платформу «на всякий случай» не стоит. Разумный консерватизм тут экономит время.

Отдельно про «штрафы», которыми часто пугают. Штраф грозит не за старую платформу, а за сдачу отчётности по устаревшей форме. Формы живут в конфигурации, а не в движке. Платформу поднимают ради отчётности только в одном случае — когда свежий релиз конфигурации с новыми формами требует более новую версию платформы.

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

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

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

Общее правило для всех: не ставьте «актуальную» версию сразу после выхода. У фирмы 1С есть два статуса релиза. Актуальная — это самая свежая версия, в ней могут остаться свежие же дефекты. Рекомендованная к использованию — та, что прошла продолжительное тестирование. Для рабочих баз берут рекомендованную; актуальную — только на тестовом контуре и только если нужна конкретная новая возможность.

Технические риски и проверка совместимости

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

• 🧩 Доработанная конфигурация. Собственные модули, запросы и формы — зона риска: отдельные конструкции между версиями ведут себя иначе.
• 🔌 Расширения конфигурации . Проверьте, что они встают и не конфликтуют. Расширения появились в платформе 8.3.6; загрузка файла .cfe и последующее обновление конфигурации базы — отдельные шаги.
• 🖨️ Внешние компоненты и печатные формы. Компоненты, завязанные на конкретную версию, после обновления иногда требуют переустановки.
• 🚀 Производительность. Новый релиз может изменить план выполнения запросов. На нагруженной базе это заметно, поэтому и нужен тест.

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

1. Посмотрите в требованиях нужного релиза конфигурации минимальную и рекомендованную версию платформы. Сравнивайте по номеру однозначно: ваша версия должна быть не ниже минимальной.
2. Разверните копию рабочей базы на тестовой машине с новой платформой.
3. Прогоните на копии ключевые операции: проведение документов, закрытие периода , обмены, печать, типовую отчётность.
4. Отдельно проверьте расширения и доработки.

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

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

Как обновить платформу без сбоев

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

Файловая база (один-несколько пользователей):

1. Сделайте резервную копию — выгрузку в файл .dt (Администрирование → Выгрузить информационную базу) или копию каталога базы. ⚠️ Без актуального бэкапа обновление не начинают.
2. Установите новый дистрибутив платформы. Старая версия останется на месте.
3. Запустите базу. По умолчанию стартует подходящая установленная версия; нужную можно выбрать через список информационных баз.
4. Проверьте работу: откройте журнал, проведите тестовый документ, запустите привычный отчёт.

Клиент-серверная база :

1. Сделайте резервную копию (средствами СУБД или выгрузкой).
2. Выберите окно с минимальной нагрузкой и предупредите пользователей.
3. Обновите платформу на сервере. ⚠️ Перезапуск службы «1С:Предприятие» оборвёт активные сеансы — делайте это только в согласованное окно, когда в базе никого нет.
4. Обновите платформу на рабочих местах. Тонкий клиент, подключённый через веб-сервер, при правильной настройке подтянет новую версию сам; толстый клиент ставят вручную или через средства раздачи ПО.
5. Проверьте вход и ключевые операции под обычной учётной записью, а не только под администратором.

Монопольный доступ к базе для простого обновления платформы не нужен — он требуется при изменении структуры, загрузке .dt, тестировании и исправлении базы. А вот обновление самой конфигурации базы (кнопка Обновить конфигурацию базы данных) монопольный режим требует.

Как связаны версия платформы и конфигурации

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

Из этого следуют практические выводы:

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

Автоматизация и контроль за обновлениями

Полностью без ручного контроля платформу обновлять не стоит — слишком велика цена ошибки на рабочей базе. Но часть рутины автоматизируется.

• 🔄 Автообновление конфигурации через интернет -поддержку: Администрирование → Интернет-поддержка и сервисы. Это про прикладное решение, не про платформу, и требует действующего договора сопровождения.
• 💻 Автоматическое обновление клиента. В клиент-серверном варианте тонкий клиент, работающий через веб-сервер, может получать новую версию платформы автоматически после обновления сервера — это настраивается при публикации.
• 📋 Контроль релизов. Следите за списком изменений в личном кабинете на портале поддержки: там видно, какие ошибки закрыты и какая версия помечена рекомендованной. Это помогает отличить «можно подождать» от «надо ставить».
• 🗂️ Чистка старых версий. Платформы накапливаются в каталоге установки. Удалять их можно, оставив текущую рабочую и предыдущую как запасную, но не раньше, чем убедитесь, что откат не понадобится.

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

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

Частые ошибки при обновлении платформы

Короткий список того, на чём спотыкаются чаще всего.

• ❌ Ставят актуальную версию в бой сразу после выхода. Правильно — дождаться статуса рекомендованной или хотя бы обкатать на копии.
• ❌ Обновляют рабочую базу без бэкапа и без окна. Нет резервной копии — нет и права на ошибку; обрыв сеансов во время рабочего дня злит пользователей.
• ❌ Меняют платформу, игнорируя доработки. Доработанная конфигурация без теста после обновления — лотерея.
• ❌ Поднимают платформу «заодно» с конфигурацией без проверки минимальной версии. В итоге одно из двух обновлений встаёт криво.
• ❌ Чистят старые версии платформы сразу после обновления. Запасная версия — бесплатная страховка на случай отката, не удаляйте её поспешно.

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