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

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

Разделите обновление на проверяемые этапы

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

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

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

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

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

Затем сверьте требования выбранного обновления: какая исходная версия допустима, нужны ли промежуточные релизы, какая версия платформы требуется, есть ли ограничения для расширений и доработок. У 1С есть отдельный сервис обновлений с дистрибутивами платформы и прикладных решений; доступность материалов зависит от прав пользователя. Файл с номером «посвежее» сам по себе не доказывает, что переход поддержан. Читайте описание поставки и инструкцию к конкретной конфигурации, а не случайную таблицу из поисковой выдачи.

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

Сделайте копию и проверьте восстановление

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

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

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

Проведите обновление сначала на копии

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

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

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

Условный сценарий: школа на 17 рабочих мест

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

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

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

Подготовьте возврат и проверьте рабочие места

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

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

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

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

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