Как спланировать и провести модернизацию 1С без остановки учёта

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

Типичная картина: Бухгалтерия на релизе двухлетней давности, конфигурация доработана программистом, которого уже нет, база выросла до 60 ГБ, и проведение документа занимает 15 секунд. Пытаться за вечер поставить свежий релиз в такой базе — верный способ потерять неделю. Ниже порядок, который работает для файловых и клиент-серверных баз на платформе 8.3.

1. Аудит системы перед модернизацией 1С

Аудит отвечает на три вопроса: что у вас стоит, насколько оно изменено и что тормозит. Без этих ответов нельзя оценить ни сроки, ни риски.

Что собрать:

• 🔢 Версию платформы и релиз конфигурации. Видны в окне «О программе» (значок с буквой «i» или меню с тремя полосками в правом верхнем углу).
• 🧩 Состояние поддержки. В Конфигураторе: Конфигурация → Поддержка → Настройка поддержки. Если там «Изменения разрешены» или конфигурация снята с поддержки, обновление будет идти через сравнение и объединение, а не одной кнопкой.
• 📦 Список расширений и внешних обработок. Расширения видны в Администрирование → Печатные формы, отчеты и обработки → Расширения, внешние отчёты и обработки — в соседнем пункте «Дополнительные отчеты и обработки».
• 💾 Тип базы и размер. Файловая база — один файл 1Cv8.1CD, его размер виден в проводнике. Для клиент-серверной смотрите размер базы в СУБД.
• 🐢 Узкие места. Какие операции медленные, в какие часы, сколько пользователей работает одновременно. Запишите 3–5 конкретных замеров: «проведение реализации — 12 с», «ОСВ за год — 3 мин». Потом с ними сравните результат.
• 🔗 Обмены и интеграции. Обмен с УТ, банк-клиент, ЭДО, сайт, обработки обмена с торговым оборудованием. Каждую интеграцию после обновления придётся проверить.

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

2. Стратегия обновления платформы и конфигурации

Стратегию определяет степень доработки конфигурации. Сравните свой случай с таблицей.

Последовательность релизов

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

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

Платформа и режим совместимости

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

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

Смена редакции — это не обновление

Переход между редакциями (например, Бухгалтерия 2.0 → 3.0, ЗУП 2.5 → 3.1) делается не через .cfu, а переносом данных в новую базу. Заранее решите, что переносить: только остатки на дату перехода или историю. Для ЗУП это особенно важно — от объёма перенесённой истории зависят расчёты отпускных и больничных в первые месяцы.

3. Инфраструктура и резервные копии

Серверная часть

Для клиент-серверной базы версии платформы на сервере и на клиентах должны совпадать. Поэтому обновление платформы сервера — это одновременно обновление клиентов на всех рабочих местах (или настройка автоматической загрузки клиента).

Порядок на сервере:

1. Скачайте дистрибутив нужной версии платформы с портала обновлений по своей подписке.
2. Установите новую версию рядом со старой — старую не удаляйте до конца приёмки.
3. В нерабочее время остановите службу «Агент сервера 1С:Предприятия 8.3».
4. Зарегистрируйте и запустите службу новой версии.
5. Обновите клиенты на рабочих местах.

Модернизация часто включает и железо. Две вещи дают самый заметный эффект: перенос базы на SSD и достаточный объём оперативной памяти под СУБД. Если файловая база выросла и в ней одновременно работают больше 5–10 человек, рассмотрите переход на клиент-серверный вариант с PostgreSQL или MS SQL Server.

Резервные копии

Перед любым обновлением рабочей базы — свежая резервная копия, проверенная восстановлением. Копия, которую ни разу не разворачивали, копией не считается.

Способы:

• Выгрузка .dt — в Конфигураторе Администрирование → Выгрузить информационную базу. Подходит для любой базы, требует монопольного доступа.
• Копия файла 1Cv8.1CD — для файловой базы при закрытых сеансах.
• Бэкап средствами СУБД — для клиент-серверной базы: полный бэкап MS SQL или pg_dump для PostgreSQL. Быстрее выгрузки .dt на больших базах.

Сохраните также файл текущей конфигурации (Конфигурация → Сохранить конфигурацию в файл) и, если есть, файлы расширений. Это пригодится при ручном переносе доработок.

4. Обновление и конвертация данных на тестовой копии

Сначала всё проходит на копии базы. Разверните .dt в новую пустую базу и прогоните на ней полный цикл: так вы узнаете реальное время работы и поймаете конфликты до рабочего дня.

Обновление типовой конфигурации

1. Закройте сеансы пользователей. В типовых конфигурациях для этого есть Администрирование → Обслуживание → Блокировка работы пользователей.
2. Откройте Конфигуратор, Конфигурация → Поддержка → Обновить конфигурацию, укажите файл .cfu.
3. После загрузки нажмите F7 («Обновить конфигурацию базы данных») и примите изменения структуры. Этот шаг требует монопольного доступа.
4. Запустите базу в пользовательском режиме. Программа выполнит обработчики обновления — на больших базах это занимает от минут до часов, не прерывайте процесс.
5. Повторите шаги 2–4 для каждого следующего релиза цепочки.

Часть обработчиков работает в фоне уже после входа пользователей. Их ход виден в Администрирование → Обслуживание в блоке результатов обновления. Пока фоновая обработка не завершилась, отдельные отчёты могут показывать неполные данные.

Доработанная конфигурация

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

Если база повреждена

Перед модернизацией базы с давней историей полезно прогнать «Тестирование и исправление» (Администрирование → Тестирование и исправление в Конфигураторе) — на копии. Галочки «Реиндексация таблиц», «Проверка логической целостности» и «Пересчёт итогов» безопасны. Режимы с удалением ссылок на несуществующие объекты включайте осознанно — они могут удалить данные.

5. Оптимизация производительности после обновления

Обновление само по себе базу не ускоряет. Нужна отдельная работа, и её результат сравнивают с замерами из аудита.

Для клиент-серверной базы:

• 📊 Обслуживание СУБД. В MS SQL настройте план обслуживания: регулярное обновление статистики и перестроение индексов, ночью. Без обновления статистики запросы 1С на большой базе деградируют заметнее всего. В PostgreSQL ту же задачу решают VACUUM ANALYZE и автовакуум.
• 🧠 Память СУБД. Ограничьте максимальную память MS SQL так, чтобы операционной системе и процессам 1С осталось несколько гигабайт.
• 🔎 Технологический журнал. Включается файлом logcfg.xml на сервере. Помогает найти долгие запросы и ожидания на блокировках. Включайте ограниченный набор событий: полный журнал быстро съедает диск.

Для любой базы:

• 🧹 Регламентные задания. Отключите те, что не нужны вашей организации: например, загрузку курсов, если валютных операций нет, или синхронизацию с сервисами, которыми не пользуетесь. Список — Администрирование → Обслуживание → Регламентные операции.
• 📁 Версии объектов. Если включено версионирование, старые версии документов раздувают базу. Их удаляют по правилам хранения в настройках программы.
• 📉 Объём данных. Для баз с многолетней историей помогает свёртка: старые периоды сворачиваются в остатки. Перед этим нужна отдельная архивная копия.
• 🧾 Права и RLS. Сложные ограничения доступа на уровне записей замедляют запросы. Проверьте, нужны ли они всем ролям.

6. Тестирование и ввод в эксплуатацию

На тестовой копии проверьте не «открывается ли программа», а учётный результат.

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

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

Интеграции. Запустите обмены с тестовыми узлами, загрузку банковской выписки, отправку документа в ЭДО. Обмены после обновления — частое место сбоев, потому что меняются правила обмена.

Ввод в рабочий контур:

1. Назначьте окно: вечер пятницы или выходные, с запасом времени в два раза больше, чем ушло на тестовую копию.
2. Предупредите пользователей, заблокируйте вход.
3. Сделайте свежую резервную копию рабочей базы.
4. Повторите отработанную последовательность.
5. Пройдите короткую приёмку по списку ниже.
6. Откройте вход, первые два дня держите под рукой копию и старый дистрибутив платформы для отката.

7. Как выбрать путь для своей базы

Частые вопросы о модернизации 1С