Тестовая база 1С перед обновлением: как накатывать релизы, не ломая прод

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

Как это обычно ломается

Дело было в марте. Клиент — бухгалтерская фирма на 18 рабочих мест, ведут человек 40 клиентов на аутсорсе. Пятница, конец месяца, все закрывают отчётность. Штатный «эникейщик» видит жёлтый восклицательный знак «доступно обновление» в 1С:Бухгалтерии и жмёт «Обновить». Без вопросов, без скачивания в отдельную папку, прямо в бою.

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

Самое обидное — этого можно было избежать за 15 минут работы. Просто разворачиваешь копию базы рядом, накатываешь релиз туда, смотришь, что не открывается. Всё. Но почему-то этот шаг регулярно пропускают — то ли лень, то ли иллюзия, что «у нас типовая, всё будет ровно».

Почему «у нас же типовая конфигурация» — это не аргумент

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

У меня есть клиент — производственная компания, база 1С:УПП на 340 гигабайт, 11 лет истории без единой чистки. У них реструктуризация таблиц при обновлении конфигурации занимает пять с половиной часов. Пять с половиной часов простоя склада и цеха, если делать это в рабочее время. Узнали мы это, разумеется, на тестовой копии — на проде такое даже пробовать смысла нет.

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

Что такое изолированный тестовый контур на практике

Никакой магии тут нет. Тестовый контур — это отдельная база 1С, физически или логически изолированная от рабочей, куда вы обновляетесь первой. Она должна быть максимально похожа на прод: та же версия платформы, тот же СУБД-движок (если у вас MS SQL Server, тест тоже должен быть на SQL, а не на файловой базе — иначе вы тестируете не то, что реально будет в бою), примерно тот же объём данных.

У небольших компаний — до 50 рабочих мест — чаще всего файловый режим 1С, и тут тестовый контур делается совсем просто. Копируете папку с базой (или делаете выгрузку в .dt через «Администрирование → Загрузка/выгрузка данных»), разворачиваете на отдельном ПК или в отдельной виртуалке, отключаете там регламентные задания и обмены с банком, чтобы тестовая база случайно не начала слать платёжки или выгружать данные в облако ФНС. Это критично: у одного клиента тестовая база с не отключённым обменом умудрилась продублировать выгрузку зарплатной ведомости в клиент-банк. Потом полдня разбирались, откуда взялся лишний файл.

Для клиентов на терминальном сервере — а таких у меня большинство, RDS на Windows Server со всеми базами в одном месте — я обычно разворачиваю тестовый контур либо на отдельной виртуальной машине в том же Hyper-V/ESXi хосте, либо прямо на том же сервере под отдельным пользователем SQL с именем вроде Buh_TEST. Ресурсов это ест немного: копия базы 20-30 гигабайт плюс место под лог, обновление гоняется вечером или ночью, никто не мешает.

Пошаговый процесс, которым я реально пользуюсь

Первое — снимаю свежую копию рабочей базы. Не вчерашний бэкап, а именно текущий срез, максимально близкий к боевым данным. Через SQL Server это просто BACKUP DATABASE / RESTORE с другим именем, через файловую базу — банальное копирование каталога при выключенной 1С или через выгрузку .dt.

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

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

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

Когда откладывать обновление — тоже правильное решение

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

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

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

Автоматизация для тех, у кого баз много

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

Мы у себя в ITfresh как раз разрабатываем собственный групповой обновлятор баз 1С именно под эту задачу — чтобы не тыкать релиз в каждую базу вручную, а прогонять через тестовый контур автоматически и получать сводку по всем базам разом. Не реклама, просто иллюстрация того, что задача массовая и типовая, а значит — автоматизируемая.

Но даже без сложной автоматизации минимальный уровень — это пара bat-файлов или PowerShell-скриптов: один снимает бэкап и разворачивает тест, второй запускает конфигуратор в режиме обновления через параметр /UpdateDBCfg. Час на настройку один раз — и потом обновление тестовой базы занимает пять минут вместо получаса ручной возни.

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

Сколько стоит содержать отдельный тестовый контур для маленькой компании?
Для файловой базы — практически ничего, кроме места на диске: 20-50 гигабайт и лицензия 1С на тестовое рабочее место не нужна, если запускать через тот же сервер приложений. Для клиент-серверного варианта нужна отдельная виртуальная машина, но её можно развернуть на существующем гипервизоре без докупки железа — у большинства клиентов ресурсы для этого уже есть, просто не используются.

Можно ли обойтись без тестовой базы, если делать полный бэкап перед обновлением?
Бэкап спасает от потери данных, но не от простоя. Пока вы восстанавливаетесь из бэкапа, бухгалтерия не работает — час, два, иногда больше, если база большая. Тест не отменяет бэкап, он снижает вероятность того, что бэкап вообще понадобится в рабочее время.

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

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