Тестовая копия базы 1С для обновлений: как не проверять новый релиз на боевых данных бухгалтерии

За пятнадцать лет в IT-аутсорсинге я видел десятки историй, когда обновление 1С «уронило» бухгалтерию прямо перед сдачей отчёта. Каждый раз причина одна: релиз ставили сразу на боевую базу, без тестовой копии. Расскажу, как мы в «АйТи-Фреш» выстроили процесс так, чтобы обновления вообще перестали быть источником стресса.

Почему обновление на проде — это русская рулетка

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

У одного клиента, торговой компании на 18 рабочих мест, обновление конфигурации «Бухгалтерия предприятия» с 3.0.145 на 3.0.148 снесло кастомную обработку для сверки с маркетплейсом. Бухгалтер обнаружила это в понедельник утром, когда нужно было выгружать отчёт в СБИС. Три часа простоя, нервы, звонки мне в девять утра. А могли бы всё увидеть заранее — на копии, вечером в пятницу.

Обновление — это не кнопка «Далее-Далее-Готово». Это операция с ненулевой вероятностью сломать то, что работало годами. И чем крупнее база, тем выше цена ошибки: если у вас 5 пользователей и учёт простой — риск один, если 40 рабочих мест и три юрлица в одной базе — совсем другой.

Что вообще может пойти не так

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

Второе по частоте — проблемы с правами доступа и ролями. После обновления иногда «слетают» настройки RLS (ограничения доступа на уровне записей), и бухгалтер по зарплате внезапно видит проводки по всей компании, а не только по своему участку. Мелочь? Для налоговой и службы безопасности — нет.

Третье — банальная несовместимость с версией платформы. Обновили конфигурацию, а платформа 1С:Предприятие на сервере старая. База не запускается вообще, приходится в авральном режиме обновлять и платформу, и клиентские места на терминальном сервере. Причём если у вас RDS-ферма на 20+ пользователей, обновить клиентские части на всех сессиях — это отдельная задача на пару часов, а не пять минут.

Как мы делаем тестовую копию — без магии, но по чек-листу

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

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

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

Сколько это стоит по времени и почему это не роскошь

На развёртывание копии файловой базы до 5-10 ГБ уходит обычно 15-30 минут: выгрузка, копирование, подключение. Для SQL-баз побольше — час-полтора, там нужно ещё бэкап с боевого SQL Server снять и восстановить на тестовый инстанс. Проверка релиза по чек-листу — ещё час-два, в зависимости от того, сколько у клиента доработок.

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

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

Особые случаи: переход на новую редакцию и смена платформы

Отдельная история — переход с одной редакции на другую, например с «Бухгалтерии 2.0» на «Бухгалтерию 3.0», или обновление ЗУП с 3.1 на 3.1 нового поколения. Это не рядовое обновление, а фактически миграция данных с перестроением структуры справочников и документов. Здесь тестовая копия — не рекомендация, а обязательное условие. Без неё вообще не стоит начинать.

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

Похожая история с обновлением платформы 1С:Предприятие на новый релиз, особенно если параллельно меняется версия Windows Server или SQL Server. Мы всегда сначала поднимаем тестовый стенд — виртуальную машину с той же версией ОС и СУБД, что и на проде, — и только после успешной проверки идём на боевой сервер.

Кто должен участвовать в проверке, кроме айтишника

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

Поэтому в нашем процессе обязательно участвует ключевой пользователь со стороны клиента — главбух или замещающий её сотрудник. Мы даём доступ к тестовой копии, присылаем короткий список: что проверить, на какие документы посмотреть, какой отчёт сформировать и сверить с прошлым периодом. Занимает у бухгалтера минут 20-30, но именно это закрывает риски, которые чисто техническая проверка не покроет.

Да, это требует немного больше координации и времени, чем просто нажать «обновить» в пятницу вечером. Но обратная связь от клиентов однозначная: лучше потратить полчаса на проверку заранее, чем потом полдня разгребать последствия во время сдачи отчётности.

Что делать, если у вас пока нет тестовой копии

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

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

Мы в «АйТи-Фреш» это делаем на автомате для всех клиентов на абонентском обслуживании: перед каждым релизом — копия, чек-лист, проверка ключевым пользователем, и только потом прод. Если у вас пока не так — это первое, что я бы поменял в работе с вашей IT-инфраструктурой.

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

Сколько времени занимает создание тестовой копии базы 1С?
Для файловой базы среднего размера — 15-30 минут: выгрузка dt-файла и разворачивание копии. Для баз на SQL Server побольше — час-полтора, включая бэкап и восстановление на тестовый инстанс. Это не считая самой проверки релиза, которая занимает ещё час-два.

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

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

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