В среде администраторов и разработчиков 1С термин "динамическое обновление" часто называют "демоническим". Несмотря на то что фирма 1С постоянно совершенствует платформу, вопрос безопасности этого механизма остается открытым. Многие руководители полагают, что после 2020 года все риски были устранены, однако практика показывает обратное. В этой статье мы подробно разберем, какие опасности таит в себе обновление конфигурации "на лету", проанализируем технические причины сбоев и выработаем регламент безопасной работы.
Динамическое обновление позволяет внести изменения в конфигурацию базы данных без завершения работы пользователей. При нажатии кнопки "Обновить конфигурацию базы данных" система анализирует изменения. Если они не затрагивают структуру таблиц (не добавляются новые реквизиты, справочники или документы), платформа предлагает выполнить обновление динамически.
Проблема заключается в том, как 1С обрабатывает это обновление. В системной таблице Config создается новая версия объектов, но активные сеансы пользователей продолжают работать со старой версией, закэшированной в памяти процесса rphost. Разберем основные риски, с которыми сталкиваются специалисты даже на последних релизах платформы (8.3.21–8.3.24):
rphost, записи в таблице Config могут оказаться в противоречивом состоянии.1С:ERP или Комплексная автоматизация) при большом количестве пользователей (от 100 и выше) динамическое обновление может вызвать резкий скачок нагрузки на процессор и "завешивание" процесса rphost.Рассмотрим ситуацию, описанную коллегами. Даже при исправлении только программного кода в модулях, система может выдать критическую ошибку "Текущему соединению с базой не назначен сеанс". Это происходит из-за того, что механизм назначения сеансов не успевает корректно отработать подмену версии конфигурации для активного соединения.
Проанализируем мнение ведущих экспертов. В статье Вячеслава Гилева от марта 2021 года четко указано: "Динамическое обновление есть смысл делать только в том случае, если информационная система уже стоит, неработоспособна и хуже уже не будет". Это утверждение базируется на глубоком анализе технологического журнала и поведения СУБД. Основной посыл экспертов: избегайте этого механизма в штатном режиме работы.
Также важно понимать разницу между динамическим и фоновым обновлением. Последнее доступно только в лицензиях уровня КОРП и позволяет выполнять реструктуризацию таблиц параллельно с работой пользователей. Однако фоновое обновление — это другой технологический процесс, и путать его с классическим динамическим обновлением (доступным в ПРОФ) — опасная ошибка руководства.
Несмотря на все риски, бывают ситуации, когда "выгнать" пользователей невозможно, а ошибку нужно исправить немедленно. Мы можем сформулировать правило безопасного минимума:
BackUp, сделанный непосредственно перед операцией.Если же вы работаете с крупной базой 1С:ERP, где количество сеансов превышает 100, динамическое обновление с высокой вероятностью приведет к простою всей компании на несколько часов.
Если динамическое обновление все же было выполнено и пользователи начали жаловаться на ошибки, проанализируем алгоритм "лечения" базы:
Это первое, что необходимо сделать. Нужно остановить службу 1C:Enterprise Server и удалить содержимое папок с именами snccntxt и временных файлов в каталоге регистрации кластера.
Иногда помогает простое "выбивание" всех пользователей через консоль администрирования серверов 1С. После повторного входа система заново считает актуальную версию конфигурации из таблицы Config.
Существует проверенный метод восстановления консистентности. Посмотрим на последовательность действий:
dbNames и очистить старые записи версионирования.Для оперативного исправления ошибок без динамического обновления основной конфигурации лучше использовать Механизм расширений. Расширения позволяют переопределять код модулей без изменения основной базы. Однако помните, что динамическое обновление самого расширения, которое добавляет данные, несет те же риски, что и обновление основной конфигурации.
Чтобы защитить себя от претензий руководства и обеспечить стабильность системы, мы рекомендуем внедрить внутренний регламент. Рассмотрим пример такого документа:
Хранилище для фиксации изменений. Это позволит всегда откатиться к стабильной версии.Для автоматизации выгона пользователей можно использовать встроенные средства платформы. Посмотрим на пример кода, который можно добавить в регламентное задание для подготовки базы к обновлению:
// Установка блокировки соединений
Блокировка = УправлениеСоединениями.ПараметрыБлокировкиСеансов();
Блокировка.Установлена = Истина;
Блокировка.Начало = ТекущаяДата();
Блокировка.Конец = ТекущаяДата() + 600; // на 10 минут
Блокировка.Сообщение = "Выполняется плановое обновление системы. Пожалуйста, завершите работу.";
УправлениеСоединениями.УстановитьБлокировкуСеансов(Блокировка);
Выясним причину, почему начальники часто настаивают на динамическом обновлении. Обычно это страх перед жалобами пользователей на кратковременный простой. Однако 15 минут планового простоя в обед несравнимы с 3 часами аврального восстановления базы после неудачного динамического обновления. Аргументируйте свою позицию именно стоимостью потенциального простоя бизнеса.
Подведем итог: Платформа 1С 8.3 не гарантирует 100% стабильности при динамическом обновлении. Несмотря на отсутствие официальных опровержений безопасности от самой фирмы 1С, сообщество экспертов и накопленный опыт эксплуатации высоконагруженных систем однозначно указывают на высокие риски. Используйте этот механизм только в исключительных случаях и всегда имейте под рукой план восстановления.