Регламент обновления конфигураций 1С: как не уронить учёт в понедельник

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

От этого зависит вообще всё: сложность, длительность и риск.

Проверяется за минуту. В конфигураторе смотрим поддержку: если стоит «Конфигурация находится на поддержке» и правила установлены как «Объект поставщика не редактируется» — конфигурация типовая, обновление будет почти автоматическим.

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

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

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

Обновлять сразу боевую базу нельзя. Это правило без исключений, и оно не про перестраховку.

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

Минимальный тестовый контур — это одна виртуальная машина или даже файловая копия базы:

1. Выгружаем боевую базу в .dt либо снимаем бэкап средствами СУБД.
2. Разворачиваем копию под другим именем, например buh_test.
3. Обязательно отключаем в копии обмены, отправку почты и регламентные задания. Иначе тестовая база начнёт слать реальным контрагентам реальные письма — мы такое видели.
4. Обновляем копию и засекаем время.
5. Прогоняем контрольные операции.

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

Время обновления на копии — важная цифра. Она говорит, сколько будет длиться окно на боевой базе. У базы бухгалтерии на 60 ГБ переход между релизами с изменением структуры занимает от сорока минут до трёх часов. Разброс большой, и знать своё число надо заранее.

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

Базовый набор для бухгалтерии:

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

Третий пункт — самый ценный. Сверка ОСВ до и после обновления ловит те самые ошибки обработчиков перехода, которые иначе всплывут через месяц при сдаче отчётности. Мы делаем скриншот или выгрузку в файл до обновления и сравниваем построчно.

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

Динамическое обновление позволяет применить изменения без выгона пользователей. Соблазнительно. И безопасно ровно в одном случае.

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

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

Что происходит, если всё-таки сделать. Часть сеансов продолжает работать со старой структурой метаданных в памяти, часть — с новой. Результат непредсказуем: от «Ошибка формата потока» до тихой порчи данных, которая обнаружится не сразу.

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

Технически заблокировать соблазн можно параметром запуска конфигуратора /DisableStartupMessages… нет, шучу — надёжнее административно, регламентом и правами. Право на изменение конфигурации в боевой базе должно быть у двух человек, а не у всех, кто когда-то просил.

Правильное обновление начинается с корректного выгона людей, а не с их отключения рубильником.

Штатный механизм — блокировка начала сеансов. Задаётся в консоли администрирования кластера или через параметр запуска. Пользователи получают внятное сообщение с указанием времени, а не «Соединение разорвано».

"C:\Program Files\1cv8\8.3.24.1234\bin\1cv8.exe" ENTERPRISE ^
  /S "srv-1c\buh_prod" /N "Администратор" /P "***" ^
  /CДисциплинаБлокировки ^
  /UC ОбновлениеКонфигурации

Код разрешения /UC — это ваш пропуск в заблокированную базу. Не задав его, вы заблокируете и себя тоже. Классическая ошибка вечера пятницы.

Порядок действий в окне:

1. Объявляем блокировку за 15 минут до старта, с сообщением.
2. Проверяем список сеансов, добиваем зависшие.
3. Делаем бэкап — именно сейчас, а не утром. Между утренним бэкапом и обновлением люди успевают ввести полдня документов.
4. Обновляем.
5. Прогоняем контрольные операции под своей учёткой при ещё закрытой базе.
6. Снимаем блокировку.
7. Просим одного-двух ключевых пользователей зайти и проверить свои задачи до общего открытия.

Шаг седьмой стоит десять минут и снимает большинство сюрпризов. Бухгалтер по зарплате найдёт проблему в своём участке быстрее любого администратора.

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

Наш шаблон отката для базы на MS SQL:

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

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

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

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

Клиент — производственная компания, 46 рабочих мест, база БП 3.0 объёмом 78 ГБ на MS SQL 2019. Обновлялись раз в квартал, релизы копились.

Плановое окно — суббота, 22:00–23:30. По прогону на копии обновление заняло 41 минуту, и это число мы взяли в план. Ошибка была уже здесь, но заметили её позже.

В 22:10 запустили обновление на боевой. В 23:30 оно шло. В 01:00 шло. Прогресс-бар в конфигураторе не даёт процента по обработчикам перехода, поэтому понять, сколько осталось, было невозможно. Ситуация неприятная: откат по плану занимал 55 минут, точка принятия решения формально прошла.

Обновление завершилось в 04:12. Шесть часов вместо сорока минут.

Разбор показал банальное. Тестовую копию развернули из .dt-выгрузки — а выгрузка-загрузка через .dt попутно перестраивает все индексы и уплотняет таблицы. Копия получилась «чистой», с нулевой фрагментацией. Боевая база на тот момент имела фрагментацию индексов выше 80 % по десятку крупных таблиц регистров накопления, статистика не обновлялась четыре месяца, и обработчики перехода, которые массово читают и пишут эти регистры, работали в разы медленнее.

Что изменили в регламенте после этого случая:

• тестовая копия разворачивается только из бэкапа СУБД, не из .dt — чтобы физическое состояние совпадало с боевым;
• за сутки до обновления на боевой базе прогоняется реиндексация и обновление статистики с FULLSCAN;
• время из теста умножается на 1,5 и берётся как расчётное окно;
• в окне назначается контрольная точка: если к её наступлению обновление не прошло половину этапов, эскалация к ответственному, а не «подождём ещё».

После введения этих четырёх пунктов расхождение прогноза и факта у нас держится в пределах 20 % на десятке обновлений подряд. Шесть часов больше не повторялись.

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

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

Обязательно ли обновлять конфигурацию до каждого релиза?

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

Можно ли обновлять базу днём при работающих пользователях?

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

Что делать, если доработки затёрлись при обновлении?

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

Сколько времени занимает обновление базы на 60 ГБ?

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