Mazmunga o'tish
Tez Base

Семь репетиций одной ночи: как мы готовим тяжёлые работы с базой 1С

· Chop etilgan:

Свёртка и размер базы

Тяжёлые работы с боевой базой 1С - свертка, обрезка, переход на другой механизм доступа, крупная миграция - почти всегда упираются в одно ночное окно. Магазины закрылись, база свободна, до утра есть несколько часов. Если к открытию работа не завершена и не откачена, утром не откроются кассы. Права на “ой, не получилось, доделаем завтра” тут нет.

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

Почему одного прогона мало

Соблазн понятен: сценарий продуман, скрипты написаны, на тестовой базе всё отработало один раз - можно в прод. Так и рождаются ночи, которые заканчиваются в шесть утра звонком “касса не открывается”.

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

  • сколько реально займёт каждый шаг на боевом объёме, а не на урезанной тестовой базе;
  • какие краевые случаи всплывут на настоящих данных (битая ссылка, документ без проведения, усечённое значение измерения);
  • уложится ли всё в согласованное окно с запасом на откат;
  • совпадут ли цифры “до” и “после” до последнего знака.

На один прогон ни один из этих ответов не получить. Поэтому мы прогоняем сценарий целиком много раз, пока он не перестанет удивлять.

Что такое полная репетиция

Ключевое слово - полная. Репетиция это не “проверим тяжёлый скрипт на куске данных”. Это прогон всего сценария от начала до конца на свежей копии продуктива: от заморозки базы и снятия исходных цифр до финальных проверок и, если бы это был прод, разморозки. Со снятием таймингов каждой фазы.

Слово “свежей” здесь несущее. Репетиция на копии месячной давности врёт про тайминги и не показывает половину краевых случаев, потому что за месяц данные изменились. Поднимать копию руками перед каждым прогоном долго, и обычно нужен доступ к SQL, поэтому мы вынесли это в отдельную обработку - “Тестовая база из бэкапа рабочей”: она собирает скрипт задания, и тест поднимается из последнего бэкапа сам, по расписанию. В СУБД обработка не пишет, скрипт запускает администратор. Как устроено само восстановление копии - скрипты для обеих СУБД и предохранители - разобрано в статье про восстановление базы 1С из бэкапа.

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

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

Во-вторых, ускорял. Каскад операций от первой репетиции к финальной ужался с 10 часов до 2. Пересчёт итогов регистров - со 112 минут до 21. Это дают замеры: на каждом прогоне видно, какой шаг сколько стоит, и понятно, что чинить в первую очередь. За две с лишним тысячи гигабайт исходной базы к финалу прогонялось около 1,4 млрд строк за пару часов, с известным заранее таймингом каждого шага.

Числовые гейты: как репетиция понимает, что всё хорошо

Репетиция бесполезна, если её итог оценивается на глаз “вроде отработало”. Нужен объективный критерий, и это числовые гейты - контрольные суммы и цифры, которые обязаны совпасть до и после.

Мы снимаем эталон до работ (остатки по регистрам, контрольные суммы наборов, количество документов по периодам) и после каждой репетиции сверяем результат с эталоном. Совпало до последнего знака - шаг получает право на прод. Разошлось - разбираемся, почему, пока не сойдётся. Ускоренный SQL-пересчёт итогов, например, побитово сверяется с эталонным платформенным: платформа остаётся судьёй, SQL только исполнитель. Без такой сверки “стало быстрее” ничего не стоит, потому что рядом легко получить “стало неправильно”.

Гейты убирают из ночи Х субъективность. К проду мы приходим не с надеждой, а с семью прогонами, где все контрольные цифры сошлись.

Точки отката: план на случай, когда что-то пошло не так

Даже отрепетированный сценарий обязан иметь ответ на вопрос “а если посреди ночи что-то сломается”. Поэтому в сценарии заранее размечены точки отката: моменты, из которых можно вернуть базу в исходное состояние и разойтись до следующего окна, ничего не потеряв.

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

Что это даёт в ночь Х

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

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

Итог

Если вам предстоит тяжёлая работа с базой 1С в одно окно, техника - это половина дела. Вторая половина - процесс: полные репетиции на копии, числовые гейты на каждом шаге, размеченные точки отката и генеральный прогон перед боевым. Именно процесс отличает проект, который прошёл незаметно для бизнеса, от истории про “ночь, когда всё легло”.

Мы так и работаем: свертку и обрезку базы 1С выводим в прод только после того, как сценарий отрепетирован до предсказуемости, а контрольные цифры сошлись. Понять своё положение можно с бесплатного экспресс-аудита: посмотрим на объёмы и прикинем, что и в каком порядке делать в вашем ночном окне.

Buni siz uchun hal qila olaman

Har qanday hajmdagi 1C bazasini svertka qilamiz yoki qisqartiramiz - shu jumladan standart svertka xotira yetishmasligi va xatolar bilan toʻxtab qoladiganini ham. Maʼlumotlar yoʻqolmaydi: qoldiqlar mos keladi, tarix arxivlanadi. Qozogʻiston va MDH boʻylab masofadan ishlaymiz.

Narxi
450 000 ₸ dansoliqlarsiz; bepul auditdan keyin qatʼiy belgilanadi
svertkaning real keysi
4,2 TB → 105 GB

Yozishga erta? O'zingiz o'lchang

Карта объёмов базы 1С

Ishlov berishni ochish

INFOSTART TECH EVENT 2026: конференция для 1с-специалистов. если собираетесь, регистрируйтесь по нашей ссылке. Регистрация →

Buni ham o'qing

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

Что измерить до удаления данных из 1С: ссылочный контроль, файлы, старые периоды и скорость на копии. Как составить проверяемый план очистки.

Что растёт в базе 1С помимо документов

Когда база 1С раздувается до сотен гигабайт или терабайтов, интуиция подсказывает винить документы за десять лет. Часто это неверно: основную массу занимает служебное - кэш разграничения доступа, история версий, очереди пересчёта, итоги регистров, журнал регистрации. Каталог того, что реально растёт в базе, с признаками и тем, что с этим делать.

SQL-версия обрезки базы 1С: TRUNCATE, шринк за 89 минут и ошибка 3140

Техническое приложение к кейсу 4,2 ТБ → 105 ГБ: что именно выполнялось на уровне СУБД, в каком порядке и с какими проверками. Со скриптами карты объёмов, доказательства "мёртвости", TRUNCATE, шринка и перестроения индексов - плюс раздел о том, когда так делать нельзя.