Администрирование · 14 мин
Динамическое обновление конфигурации 1С: что это и как выполнить безопасно
Что такое динамическое обновление конфигурации 1С, когда оно применяется, как выполнить его без остановки работы пользователей и какие риски учесть.
Динамическое обновление конфигурации — это механизм платформы 1С:Предприятие, который позволяет применить изменения конфигурации базы данных без завершения сеансов пользователей и без монопольного доступа к информационной базе. В обычном режиме обновление требует, чтобы все пользователи вышли из системы, а при динамическом — изменения вступают в силу «на лету»: работающие пользователи продолжают свои сеансы, а новые подключения сразу получают обновлённую конфигурацию.
Механизм появился для крупных внедрений, где остановить работу десятков или сотен пользователей ради небольшого исправления невозможно. Например, нужно поправить печатную форму, добавить реквизит в справочник или исправить ошибку в модуле — выгонять из базы всю бухгалтерию ради этого нерационально. Динамическое обновление решает именно такие задачи.
Важно понимать: динамическое обновление — не универсальный способ, а инструмент с жёсткими ограничениями. Он применим только для определённых типов изменений, а при нарушении условий может привести к ошибкам у пользователей и даже к необходимости аварийного перезапуска сеансов. Ниже разберём, как он работает, когда его можно использовать и как проверить результат.
Как работает механизм динамического обновления
В клиент-серверном режиме работы 1С кластер серверов кэширует конфигурацию базы данных. При обычном обновлении этот кэш сбрасывается только после завершения всех сеансов. При динамическом обновлении сервер создаёт новую версию конфигурации параллельно со старой: текущие сеансы продолжают работать со старой версией, а каждый новый сеанс стартует уже с обновлённой.
Технически это означает, что какое-то время в базе одновременно «живут» две версии конфигурации. Старые сеансы завершаются естественным образом — пользователи заканчивают работу и выходят. После того как завершится последний сеанс со старой версией, она окончательно выгружается, и остаётся только новая конфигурация.
Именно сосуществование двух версий — источник и преимуществ, и рисков. Пользователь со старым сеансом видит старые формы и старую логику, а его коллега, перезашедший в базу, — уже новые. Если изменение касается только интерфейса или внутренней логики обработки, это безопасно. Если же изменилась структура данных — старая версия может записать данные в формате, несовместимом с новой.
Какие изменения допустимы, а какие запрещены
Платформа сама анализирует изменения и определяет, возможно ли динамическое обновление. При попытке выполнить его с несовместимыми правками конфигуратор выдаст сообщение о необходимости обычного обновления. Но полагаться только на проверку платформы не стоит — важно понимать логику ограничений.
Безопасны для динамического обновления изменения, которые не затрагивают структуру существующих таблиц базы данных. К ним относятся правки модулей и кода, изменения форм, макетов, печатных форм, ролей (с оговорками), добавление новых объектов метаданных — справочников, документов, регистров, отчётов. Добавление нового реквизита к существующему объекту платформа также обычно допускает, поскольку это не ломает чтение старых данных.
Запрещены изменения, требующие реструктуризации существующих данных: удаление реквизитов и объектов, изменение типа или длины существующего реквизита, изменение состава измерений и ресурсов регистров, изменение признаков учёта и другие правки, при которых старые данные нужно физически преобразовать. Такие изменения требуют монопольного режима, потому что таблицы перестраиваются, и параллельная работа старых сеансов привела бы к ошибкам.
Что можно и что нельзя обновлять динамически
Модули и код, формы, макеты, печатные формы, новые объекты метаданных, новые реквизиты у существующих объектов
Удаление реквизитов и объектов, изменение типов и длин полей, изменение структуры регистров, любая реструктуризация существующих таблиц
Как выполнить динамическое обновление: порядок действий
Динамическое обновление выполняется из конфигуратора. Сначала внесите или загрузите изменения в конфигурацию (через «Конфигурация → Загрузить конфигурацию из файла» или «Поддержка → Обновить конфигурацию»), затем вызовите команду «Конфигурация → Обновить конфигурацию базы данных». Если в базе есть активные сеансы и изменения совместимы с динамическим режимом, платформа предложит выполнить динамическое обновление — нужно согласиться.
После завершения обновления платформа покажет информационное окно о том, что обновление выполнено динамически и для вступления изменений в силу у текущих сеансов пользователям необходимо перезапустить приложение. Это ключевой момент: сам сеанс, из которого вы обновляли, и все открытые до обновления сеансы продолжают работать со старой версией.
В файловом режиме работы динамическое обновление также возможно, но там механизм менее актуален: файловые базы обычно обслуживают небольшое число пользователей, и попросить их выйти на несколько минут проще, чем контролировать корректность динамического применения. Основной сценарий использования — клиент-серверные базы с десятками и сотнями одновременных сеансов.
- 1Сделайте резервную копию базы или убедитесь, что актуальный бэкап существует
- 2Внесите или загрузите изменения конфигурации в конфигураторе
- 3Выполните «Конфигурация → Обновить конфигурацию базы данных»
- 4При предложении платформы подтвердите динамическое обновление
- 5Дождитесь сообщения об успешном завершении
- 6Оповестите пользователей о необходимости перезапустить сеансы
- 7Проверьте работу ключевых функций в новом сеансе
Что происходит с пользователями во время и после обновления
Во время самого обновления пользователи ничего не замечают: их сеансы не прерываются, открытые документы и отчёты продолжают работать. Платформа применяет изменения на сервере в фоновом режиме. Длительность зависит от объёма изменений — правка модуля занимает секунды, добавление новых объектов может занять дольше.
После обновления возникает переходный период: часть пользователей работает на старой версии конфигурации, часть — на новой. Это нормально, но требует внимания. Если исправление касалось ошибки в проведении документов, то пользователи со старыми сеансами продолжат проводить документы по старому (ошибочному) алгоритму, пока не перезайдут. Поэтому после критичных исправлений пользователей нужно явно оповестить о необходимости перезапуска.
Принудительно завершить оставшиеся старые сеансы можно через консоль кластера серверов 1С или командой администрирования. Это крайняя мера: у пользователей могут быть несохранённые данные. Корректная практика — сначала отправить оповещение, дать время на завершение работы и только потом отключать «зависшие» сеансы.
Типичные ошибки и риски
Самая частая ошибка — выполнение динамического обновления без резервной копии. Аргумент «это же маленькое изменение» не работает: динамическое обновление изменяет конфигурацию базы данных так же необратимо, как и обычное. Откатить его штатными средствами нельзя — только восстановлением из копии или загрузкой предыдущей версии конфигурации.
Вторая типичная проблема — забытые старые сеансы. Пользователь, не перезапустивший приложение, может столкнуться с ошибками вида «Конфигурация базы данных была изменена динамически» при обращении к новым объектам, которых нет в его версии. Особенно это касается фоновых заданий и длительных сеансов: регламентные задания, запущенные до обновления, продолжают выполняться на старой версии кода.
Третий риск — обновление в разгар рабочего дня без оповещения. Даже совместимые изменения могут вызвать недоумение: у одного пользователя форма выглядит по-старому, у другого — по-новому, результаты отчётов могут отличаться, если изменилась логика расчёта. Для критичных бизнес-процессов (проведение документов, расчёт зарплаты) безопаснее планировать обновление на период минимальной активности.
Как проверить результат обновления
Сразу после обновления откройте новый сеанс (перезапустите своё клиентское приложение) и проверьте изменённую функциональность: откройте изменённую форму, сформируйте обновлённый отчёт, проведите тестовый документ, если менялась логика проведения. Проверку нужно делать именно в новом сеансе — старый покажет прежнее поведение, и вы получите ложный вывод, что «ничего не изменилось».
Дополнительно проверьте список активных сеансов в консоли кластера: убедитесь, что новые подключения создаются успешно, и оцените, сколько сеансов ещё работает на старой версии. Если обновление критичное, дождитесь перезапуска всех сеансов или инициируйте его через оповещение пользователей.
Признаком проблемы служат ошибки у пользователей сразу после обновления: сообщения о несоответствии версий конфигурации, невозможность открыть формы, ошибки фоновых заданий. В этом случае первое действие — перезапуск проблемного сеанса; если ошибка сохраняется в новом сеансе — анализ самого изменения и, при необходимости, откат.
Как проверить результат
Форма, отчёт или документ работают по новой логике без ошибок
Поведение не изменилось (проверка в старом сеансе) или возникают ошибки
Новые подключения создаются, число старых сеансов сокращается
Пользователи не могут подключиться или массово получают ошибки
Нет ошибок, связанных с обновлением, регламентные задания выполняются
Ошибки несоответствия конфигурации, падения фоновых заданий
Динамическое обновление и обычное: что выбрать
Выбор режима определяется не желанием администратора, а характером изменений. Если платформа допускает динамическое обновление — его можно применять, но и здесь есть градации. Для исправления опечатки в печатной форме динамический режим идеален в любое время. Для изменения логики проведения документов, даже технически допустимого, безопаснее дождаться вечера и выполнить обычное обновление с монопольным доступом — это гарантирует, что все пользователи сразу начнут работать на единой версии.
Обычное обновление остаётся единственным вариантом при реструктуризации: удалении и изменении реквизитов, переработке регистров, масштабных обновлениях типовых конфигураций. Релизы типовых решений почти всегда содержат изменения структуры данных, поэтому обновление версии конфигурации поставщика практически никогда не выполняется динамически.
Как выбрать режим обновления
Практические рекомендации
Выработайте простой регламент: любое динамическое обновление рабочей базы выполняется только при наличии свежей резервной копии, сопровождается оповещением пользователей и проверкой результата в новом сеансе. Даже тривиальные правки лучше сначала применить на тестовой копии базы — это занимает минуты и исключает сюрпризы на рабочей системе.
Ведите учёт динамических обновлений: дата, что изменено, кем выполнено. При накоплении множества мелких динамических правок становится сложно понять, какая версия конфигурации реально работает в базе, особенно если часть пользователей долго не перезапускала сеансы. Периодическое плановое обычное обновление «сбрасывает» эту ситуацию и приводит всех к единой версии.
Помните про связанные механизмы: если изменения затрагивают объекты, используемые в обменах данными, веб-сервисах или внешних соединениях, проверьте эти интеграции отдельно — внешние системы не «узнают» о динамическом обновлении и могут работать с устаревшими ожиданиями о структуре данных.
Сеанс конфигуратора, из которого выполнялось динамическое обновление, сам остаётся на старой версии конфигурации базы данных. Чтобы увидеть результат своих изменений, перезапустите клиентское приложение после обновления — иначе легко сделать ложный вывод, что правка не применилась.
Частые вопросы
Можно ли отменить динамическое обновление?
Штатной кнопки отката нет. Вернуть прежнее состояние можно восстановлением базы из резервной копии или загрузкой сохранённого файла предыдущей конфигурации с последующим обновлением конфигурации базы данных. Поэтому резервная копия перед обновлением обязательна.
Почему платформа не предлагает динамическое обновление?
Значит, среди изменений есть те, что требуют реструктуризации таблиц: удаление или изменение реквизитов, типов данных, структуры регистров. Проверьте список изменений в окне сравнения конфигураций — там видно, какие правки блокируют динамический режим.
Что увидят пользователи, которые не перезапустили сеанс?
Они продолжат работать со старой версией конфигурации: старые формы, старая логика. При обращении к объектам, появившимся только в новой версии, возможны ошибки. Для вступления изменений в силу каждому пользователю нужно перезапустить приложение.
Работает ли динамическое обновление в файловой базе?
Да, механизм доступен и в файловом режиме, но там его ценность ниже: пользователей обычно немного, и проще попросить их выйти на время обычного обновления. Основное применение — клиент-серверные базы с большим числом одновременных сеансов.
Опасно ли динамическое обновление для данных?
При соблюдении ограничений — нет: платформа не допускает динамического применения изменений, ломающих структуру данных. Риски связаны с человеческим фактором: отсутствием бэкапа, неперезапущенными сеансами и обновлением критичной логики в пик нагрузки.
Нужно ли перезапускать сервер 1С после динамического обновления?
Нет, перезапуск кластера не требуется — в этом и смысл механизма. Сервер сам переключает новые сеансы на обновлённую конфигурацию. Перезапускать нужно только клиентские приложения пользователей.
Что важно запомнить
Динамическое обновление применяет изменения конфигурации без остановки работы пользователей, но только для правок без реструктуризации данных. Всегда делайте резервную копию, оповещайте пользователей о перезапуске сеансов и проверяйте результат в новом сеансе. При изменении структуры данных используйте только обычное обновление с монопольным доступом.