Как часто обновлять платформу 1С

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

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

В этой статье разберём, как часто стоит обновлять платформу 1С, чем отличается обновление платформы от обновления конфигурации, какие риски несут запоздалые и слишком частые обновления, как организовать процесс на рабочем сервере и как проверить, что обновление прошло успешно.

Чем обновление платформы отличается от обновления конфигурации

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

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

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

Как часто выпускаются новые версии платформы

Фирма «1С» выпускает обновления платформы регулярно: внутри одной линейки (например, 8.3.x) новые релизы выходят несколько раз в месяц. Часть из них — плановые версии с новой функциональностью, часть — исправительные релизы, устраняющие конкретные ошибки и уязвимости.

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

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

Рекомендуемая периодичность обновления

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

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

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

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

Когда обновлять платформу

Конфигурация требует более новую версию платформыОбновите платформу до требуемой версии или выше сразу, до обновления конфигурации

Вышло исправление ошибки, которая воспроизводится в вашей работеУстановите исправительный релиз вне планового графика

С последнего обновления прошло 3–6 месяцев, критических проблем нетПроведите плановое обновление на стабильный проверенный релиз

Вышел новый релиз, но исправления вас не касаются и требований конфигурации нетПропустите релиз и дождитесь следующего планового окна

Платформа не обновлялась больше годаЗапланируйте обновление в ближайшее время, проверив совместимость всей цепочки версий

Риски слишком редкого обновления

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

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

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

Риски слишком частого обновления

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

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

Практический компромисс — использовать не самый свежий, а предпоследний стабильный релиз линейки, если нет острой необходимости в конкретном исправлении. К моменту вашей установки основные проблемы версии обычно уже известны и описаны.

Как безопасно провести обновление: порядок действий

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

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

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

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

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

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

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

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

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

Как проверить результат

Запуск информационной базы

Норма

База открывается в пользовательском режиме без сообщений об ошибках

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

Ошибки при запуске, требование другой версии, аварийное завершение

Расширения конфигурации

Норма

Все расширения применены и работают

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

Расширения отключены из-за ошибок безопасности или совместимости

Веб-публикации и тонкий клиент

Норма

База доступна через браузер и тонкий клиент

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

Ошибка 404/500, требование переустановки клиента

Регламентные задания и обмены

Норма

Задания выполняются по расписанию, обмены проходят

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

Задания завершаются с ошибками, обмены остановлены

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

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

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

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

Плановый регламент: как встроить обновления в работу

Чтобы обновления перестали быть аварийным мероприятием, закрепите их в регламенте. Назначьте ответственного, определите периодичность проверки новых релизов (например, раз в месяц), типовое окно обслуживания (вечер, выходной) и чек-лист проверки после обновления.

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

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

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

Можно ли вообще не обновлять платформу, если всё работает?

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

Что обновлять сначала — платформу или конфигурацию?

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

Сколько времени занимает обновление платформы?

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

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

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

Что делать, если после обновления платформы база перестала работать?

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

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

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