Обновление 1С без остановки работы: порядок действий и переход на платформу 8.5

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

Что именно обновляется в 1С

Путаница начинается с терминов, поэтому разведём их сразу.

• Платформа — «движок» 1С:Предприятие, общий для всех программ: версии 8.3, 8.5. Обновление платформы меняет то, как работает сама среда: интерфейс, механизмы, требования к серверу.
• Конфигурация — прикладное решение, которое работает на платформе: Бухгалтерия, Управление торговлей, ЗУП, ERP. Именно её обновляют чаще всего: новые формы отчётности, изменения законодательства, новые возможности.
• Релиз — очередная версия конфигурации. Типовые решения обновляются регулярно, у активно меняющихся конфигураций вроде ЗУП релизы выходят особенно часто.
• Редакция — крупное поколение конфигурации: Бухгалтерия 3.0, Управление торговлей 11.5, ЗУП 3.1. Смена редакции — это уже не обновление в один клик, а отдельная работа, а иногда и перенос данных.

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

Почему «после обновления всё сломалось»

Причина первая: доработки внутри конфигурации

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

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

Причина вторая: пропущенные релизы

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

Причина третья: расширения и интеграции, не рассчитанные на новый релиз

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

Причина четвёртая: обновляли рабочую базу

Все три предыдущих проблемы лечатся, если найдены на тестовой копии. И почти не лечатся, если найдены в рабочей базе в понедельник утром — когда люди уже начали вводить документы, а вернуться к бэкапу значит потерять их работу. Или когда «бэкапа нет — восстанавливать нечего».

Во что обходится неудачное обновление

Прямые потери считаются легко: день простоя отдела продаж, несколько несостоявшихся отгрузок, вечер бухгалтера на перепроведение документов. Косвенные дороже. Отчётность не сдана в срок. Обмен с маркетплейсом молча стоял три дня, и товар продавался по неактуальным остаткам. Маркированная продукция уехала без корректно переданных кодов — а штрафы за нарушения правил маркировки доходят до 300 тысяч рублей с конфискацией товара, по алкоголю и табаку — до 1,5 миллиона.

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

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

Порядок безопасного обновления

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

Отдельное правило: не обновляйтесь в пятницу вечером и в конце квартала. Если что-то пойдёт не так, разбираться придётся в выходные или в дни сдачи отчётности.

Обновление без остановки работы: что возможно, а что нет

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

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

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

Переход на платформу 8.5

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

Что проверяем перед переходом на 8.5:

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

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

Смена редакции: БП 3.0, УТ 11.5, ЗУП 3.1

Внутри одной редакции обновление — рядовая процедура. Переход между редакциями — почти всегда проект. Самый показательный пример — Управление торговлей: десятая редакция и одиннадцатая устроены по-разному, и переход между ними делается переносом данных, а не обновлением. То же с производственными решениями при переходе на 1С:ERP.

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

Что вы получаете после нормально выстроенного обновления

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

Сколько это стоит

Обновление типовой конфигурации, стоящей на поддержке, — короткая работа. Обновление базы с доработками и снятой поддержкой считается по фактическому объёму слияния: чем больше изменённых объектов, тем дольше. Наша модель оплаты — 8 900 ₽ в месяц с десятью включёнными часами, это 890 ₽ за час, и 2 500 ₽ за каждый следующий час по факту. Для сравнения, рекомендованная фирмой «1С» ставка специалиста — от 3 000 ₽ за час. Не франчайзи «1С» — вместо статуса отвечаем опытом и ответственностью: свои ошибки исправляем за свой счёт, подписываем NDA, перед любыми работами делаем резервную копию базы. И главное для обновлений: у нас не бывает ситуации «специалист недоступен, а проблема срочная» — если один человек занят или в отпуске, задачу ведёт другой.

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