Обновление 1С: пошаговая инструкция для администратора инфраструктуры

Привет! Я, Евгений Семёнов, директор ITFresh. За свои пятнадцать с лишним лет в поддержке 1С я повидал столько, что хватило бы на пару книг. Видел, как бухгалтеры теряли целую неделю из-за какой-то одной, казалось бы, мелочи — неудачного обновления. А что говорить про админов, которые выкатывали свежую 'Бухгалтерию' в пятницу вечером, а потом в понедельник утром 40 человек просто не могли закрыть период? Кошмар! Поверьте мне, обновление 1С — это не просто 'кликнуть и ждать'. Это целый инженерный процесс. Он требует и надёжных бэкапов, и серьёзного тестирования, и обязательно выделенного окна для обслуживания. Сегодня я расскажу вам о рабочем алгоритме, который мы в ITFresh используем каждый божий месяц.

Зачем вообще обновлять 1С

Почему же нам вообще приходится этим заниматься? Вот три главные причины, по которым нужно постоянно обновлять и конфигурации, и саму платформу:

• Законодательные изменения. Новые формы деклараций, изменения в НДС, обновления справочников КЛАДР, новые поля в первичке — всё это ФНС выпускает с конкретными сроками, к которым нужно успеть обновиться.
• Исправление ошибок платформы. В 8.3.2x регулярно выходят правки критических багов, утечек памяти, проблем с производительностью.
• Безопасность. Старые релизы не получают фиксов уязвимостей. Для инфраструктур, доступных из интернета через 1С: Web-клиент, это критично.

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

Подготовка: что должно быть до первого клика

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

1. Первый шаг: забираем релиз и, главное, не забываем про release notes с портала ИТС. Затем обязательно просматриваем весь список изменений. И тут уж совсем не пропустите раздел «Изменения, требующие вмешательства» — поверьте, это сэкономит вам часы головной боли.
2. Помните о совместимости! Прежде чем что-то трогать, убедитесь, что версия платформы точно подходит под вашу конфигурацию. Ведь если у вас, к примеру, свежая «Бухгалтерия» 3.0, она вполне может потребовать платформу не ниже 8.3.24. В таком случае — да-да, сначала обновляем платформу!
3. Важный момент: проверьте, достаточно ли места на диске. Для реструктуризации больших таблиц — а это частая история — на SQL-томе вам понадобится как минимум полтора размера самой базы. Лучше перестраховаться, чем потом ловить ошибку!
4. Не забудьте заранее согласовать «окно обслуживания» с вашими пользователями. Это поможет избежать недовольства и срыва работы! Для небольшой конфигурации хватит минимум двух часов, а вот для монстров вроде УТ или ERP закладывайте спокойно 6–8 часов. Лучше предупредить и сделать всё спокойно, чем потом разгребать жалобы.
5. А что, если что-то пойдёт не так? Чтобы не паниковать, заранее составьте план отката. В него должны входить чёткие ответы: сколько именно времени займёт восстановление из бэкапа, и, главное, есть ли у вас гарантированный доступ к той самой резервной базе. Это ваш аварийный выход.

Полный бэкап — главный этап

Вот я, например, ни за что не начну обновление, пока у меня не будет свежайшего бэкапа. Мало того, я делаю их целых два! Один – прямо через средства 1С, ну, это та самая dt-выгрузка, которую все знают. А второй – уже на уровне СУБД, полноценный SQL-бэкап. Почему два? На нашей практике первый вариант здорово выручает от всяких логических ошибок, а второй – ваш спасательный круг при серьёзных поломках во время реструктуризации базы.

# Файловая база
# Просто копируем папку с 1Cv8.1CD в архив с датой
robocopy "D:\1C\BuhBase" "E:\Backup\BuhBase-2025-06-24" /MIR /R:2 /W:5

# Клиент-серверная на MSSQL
sqlcmd -S SQL01 -Q "BACKUP DATABASE [buh_prod] TO DISK='E:\Backup\buh_prod_2025-06-24.bak' WITH COMPRESSION, STATS=5"

# Выгрузка DT через Designer (для страховки)
"C:\Program Files\1cv8\8.3.24.1234\bin\1cv8.exe" CONFIG /S SQL01\buh_prod /N"Администратор" /P"********" /DumpIB "E:\Backup\buh_prod_2025-06-24.dt"

Наши бэкапы всегда хранятся на отдельной системе хранения данных. И не где-нибудь, а в надёжном дата-центре МТС. Конкретно на нашем стенде это выделенный том: 40G Mellanox SFP28 с Dell PowerVault. Туда стекаются ежедневные бэкапы 1С от всех наших клиентов. Можно спать спокойно!

Обновление платформы

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

# Тихая установка на сервере
setup.exe ENABLESERVER=1 ENABLEWEBSERVEREXT=1 ENABLECONFREPOSSERVER=0 /qn

# Тихая установка на клиенте
setup.exe ENABLETHINCLIENT=1 ENABLEDESIGNER=1 ENABLESERVER=0 /qn

# Принудительно выбрать версию для базы
ragent -C "/PathToBase" /F"D:\1C\BuhBase" /UseVersion"8.3.24.1234"

Как только всё установлено, мы сразу же перезапускаем службу сервера 1С. А затем обязательно проверяем через консоль администрирования, что кластер благополучно поднялся уже с новой платформой. Знаете, на нашей практике бывали случаи, когда старая служба 'держала' процесс, не давая ему завершиться. Тогда помогала только полная перезагрузка сервера. Лучше перестраховаться!

Сравнение и объединение: где теряют доработки

Если ваша конфигурация хоть чуть-чуть отличается от типовой – а, признаемся честно, у 90% наших клиентов так и есть – тогда обновление мы проводим через опцию 'Сравнить, объединить с конфигурацией из файла'. И вот здесь, внимание! На этом шаге ну просто КРИТИЧЕСКИ важно не нажать случайно 'Установить всё по умолчанию'! Поверьте, иначе все ваши ценные доработки просто возьмут и исчезнут. Этого же никто не хочет, правда?

Я всегда перед объединением делаю конфигурационный отчёт «Отчёт по сравнению» (в Конфигураторе → Конфигурация → Сравнить конфигурации). Сохраняю его в текстовом виде — это документ, по которому потом можно разобраться, что именно менялось.

Порядок типового обновления

Какая же последовательность действий работает безотказно? Вот что мы применяем на нашей практике:

1. Теперь самый ответственный момент: нужно вывести абсолютно всех пользователей из базы. Делается это либо через консоль кластера, либо путём активации параметра блокировки начала сеансов. Убедитесь, что никто не остался внутри!
2. Сделать бэкап — dt и SQL.
3. Заходим в Конфигуратор. А дальше — смотрите по ситуации: если предстоит править типовой объект, то снимаем его с поддержки. В других случаях, когда вмешиваться в стандартный функционал не планируете, просто оставляем всё в режиме «Конфигурация поставщика».
4. Теперь переходим в меню: «Конфигурация» → «Поддержка» → «Обновить конфигурацию». Выбираем «из файла» и указываем нужный cf-файл. Просто, как дважды два.
5. Разобрать конфликты в таблице сравнения.
6. Обязательно сохраните все изменения, а затем обновите конфигурацию базы данных. Простое сочетание F7, и кнопка «Обновить» — не пропустите этот шаг!
7. Запускаем реструктуризацию. Будьте готовы: если в базе много больших таблиц, этот этап может растянуться не на минуты, а на часы. Запаситесь терпением!
8. Завершили? Отлично! Теперь перезапустите службу 1С, затем запустите базу уже в пользовательском режиме и обязательно прогоните первичный старт. Это как финальная проверка перед запуском двигателя.
9. Важно: не пропустите регламентные обработки обновления. Это отдельный, критически важный шаг, ведь в новых релизах часто появляются специальные обработки типа «первый запуск», которые нужно запустить вручную.
10. И вот он, финиш! Сначала внимательно сверьте контрольные отчёты. Всё в порядке? Отлично, можно смело пускать первого тестера — пусть проверит, как всё работает на практике.

Мини-кейс: производство, УТ 11.5, 120 пользователей

Хотите живой пример из нашей практики? В апреле 2026 года у одного нашего клиента — они производят электротехнику прямо здесь, под Москвой — вышло ну очень критичное обновление для 'Управления торговлей 11.5'. Там были новые маркировки для целых групп товаров и важные изменения в учёте комплектов. А теперь представьте их базу: 380 гигабайт! 120 одновременных пользователей! И вдобавок около 40 объектов с доработками. Серьёзно, да?

План обновления:

• Пятница, 20:00. Начало нашего технического окна. Сперва делаем бэкап SQL — всего 25 минут, спасибо Mellanox 40G! Затем ещё 45 минут уходит на копирование через dt.
• К 20:45 пора остановить все регламентные задания, выгрузить активных пользователей, и, конечно, заблокировать сеансы. Иначе как мы обновимся без сюрпризов?
• В 21:00 стартуем обновление прямо в Конфигураторе. Это был долгий этап: объединение заняло 2 часа 10 минут. Почему так долго? Нам пришлось вручную разбирать целых 14 конфликтов – в основном это были наши уникальные доработки, вроде хитрых печатных форм или особенной обработки загрузки заказов. Куда без них?
• К 23:15 переходим к самой базе: её обновление и реструктуризация заняли ещё 1 час 40 минут. Тут главное не торопиться, чтобы всё прошло гладко.
• Почти час ночи, 00:55. Наконец, первый запуск в пользовательском режиме! Проверяем, как отрабатывают обработчики обновления. Это занимает минут 25, и каждый раз замирает сердце: всё ли загрузилось правильно?
• 01:20 — начинается самое важное: тщательное тестирование. Мы проводим тестовый документ, обязательно формируем отчёт «Остатки на складах», ведь это критично. И, конечно, проверяем выгрузку в 1С: Маркировку. Всё должно работать как часы.
• К 02:10 база наконец-то открыта для пользователей! Наша работа почти закончена, можно немного выдохнуть. А уже в 08:00 все смогут начать штатную работу, как будто ничего и не произошло.

Наши работы тогда обошлись в 28 000 рублей. Это было ночное обновление, включающее полное тестирование. Но давайте прикинем: если бы клиент взялся за это сам и что-то пошло не так, то даже один день простоя мог бы стоить им минимум 400 000 рублей потенциальных потерь производства. В итоге, получается, они сэкономили огромную сумму! Чувствуете разницу? Это же колоссальная выгода!

Тестирование перед продакшеном

Я никогда, вот просто НИКОГДА, не трогаю сразу боевую базу. Это золотое правило! У нас есть чёткая стандартная схема:

1. Первым делом, конечно, делаем полную копию продакшн-базы. Мы можем использовать классический backup-restore или воспользоваться dt — как удобнее в конкретной ситуации.
2. Затем мы обновляем эту копию и очень внимательно замеряем время, которое уходит на каждый этап. Почему? Чтобы точно спланировать время простоя для боевой системы!
3. Дальше прогоняем наши ключевые сценарии. Это значит, что мы проводим 3–5 самых типовых документов, формируем 5 критически важных отчётов, и обязательно проверяем все выгрузки обменов. Никаких сюрпризов!
4. После всех этих манипуляций обязательно сверяем все суммы с исходной базой. Оборотно-сальдовые ведомости, обороты, остатки — всё должно совпасть до копейки. Это наша гарантия, что ничего не «поехало».
5. И только когда все эти этапы прошли успешно, когда мы получили «зеленый свет» — тогда и начинаем планировать обновление боевой базы в техническое окно. Не раньше.

Да, я понимаю, что тестирование – это небыстро. Оно, конечно, займёт свои 2–4 часа. Но поверьте, за все эти годы оно спасло меня, да и нашу команду, от нескольких десятков по-настоящему серьёзных инцидентов. Сколько раз обновление грозило просто 'убить' боевые данные! Так что я твёрдо уверен: это время потрачено более чем не зря. Это инвестиция в спокойствие.

Откат: что делать, если пошло не так

Что делать, если после обновления пользователи вдруг начинают жаловаться на ошибки, которые, вот никак, быстро не исправить? Тут без вариантов: откатываемся назад. Схема такая:

# Останавливаем службу 1С
net stop "1C:Enterprise 8.3 Server Agent (x86-64)"

# Восстанавливаем SQL-базу из бэкапа
sqlcmd -S SQL01 -Q "USE master; RESTORE DATABASE [buh_prod] FROM DISK='E:\Backup\buh_prod_2025-06-24.bak' WITH REPLACE, STATS=5"

# Запускаем службу
net start "1C:Enterprise 8.3 Server Agent (x86-64)"

# Убеждаемся, что версия конфигурации откатилась
# Все пользователи заходят как на старой

Представьте ситуацию: вы сделали бэкап, но потом кто-то успел поработать в базе — скажем, ночная смена внесла данные. А после отката вся эта работа просто исчезнет! Понимаете, насколько это критично? Именно поэтому блокировка новых сеансов и обязательная эвакуация пользователей перед любым обновлением — это не пустая формальность, а железобетонное правило.

Частые ошибки администраторов

• Бэкап «для галочки» без проверки. Регулярно проверяйте, что из бэкапа действительно восстанавливается работоспособная база.
• Обновление без release notes. Пропустили раздел «требует вмешательства» — получили критический баг в проведении.
• Одновременное обновление платформы и конфигурации. Нельзя. Сначала платформу, проверили, потом конфигурацию.
• Нажатие «Установить всё по умолчанию» в сравнении. Так все доработки уходят в типовую версию.
• Обновление в пятницу вечером. Если что-то пойдёт не так — выходные уйдут на восстановление. Лучше ночь со среды на четверг, а весь четверг на мониторинг.
• Игнор обработчиков обновления. После реструктуризации обязательно запустите обработки перехода — иначе данные могут оказаться в неконсистентном состоянии.

FAQ — частые вопросы про обновление 1С

Как часто нужно обновлять 1С?

Платформу — по мере выхода стабильных релизов (примерно раз в квартал), конфигурации — при выходе критичных обновлений налогового учёта и квартальных форм отчётности. В среднем 4–6 обновлений конфигурации в год для активно поддерживаемых типовых.

Можно ли обновить 1С с доработками без программиста?

Только если все доработки вынесены в расширения. Если конфигурация «вручную» изменена администратором или прошлой командой разработчиков — без 1С-специалиста высокий риск потерять наработки или получить ошибки в процессе сравнения и объединения.

Сколько занимает обновление типовой «Бухгалтерии»?

Чистая типовая без доработок обновляется за 30–60 минут вместе с реструктуризацией. Конфигурация с доработками — от 2 до 8 часов в зависимости от объёма изменений и размера базы.

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

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

Как понять, что обновление безопасно?

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