Обновление сервера 1С — задача, где цена ошибки часто выше, чем сама польза от свежей версии платформы. Один неудачный апдейт на работающей базе способен остановить бухгалтерию, склад и кассы на целый день, а откат к старой конфигурации потом занимает в два-три раза больше времени, чем планировалось.
Поэтому крупные компании давно ушли от схемы «вечером накатим, утром посмотрим» и работают по сценариям, которые позволяют менять платформу, конфигурацию и СУБД без полного простоя.
Виды обновлений сервера 1С и их последствия
Обновление платформы 1С:Предприятие 8.3
Платформа выходит несколькими релизами в год, каждый закрывает уязвимости, добавляет API и оптимизирует движок. Обновление 1С 8.3 сервер на одной машине требует остановки служб ragent, замены дистрибутива и перезапуска. На рабочей конфигурации это 5–15 минут полного простоя, на кластере из 2+ узлов — ноль минут, если применять rolling update.
Обновление прикладной конфигурации
Бухгалтерия, УТ или ERP меняются чаще платформы: каждые две недели приходят регламентные обновления с правками законодательства, новыми отчетами и формами. Здесь главный риск — реструктуризация, при которой меняется структура таблиц и платформа делает монопольный захват базы. Без подготовки это превращается в часовой простой среди рабочего дня.
Обновление СУБД и операционной системы
Раз в квартал или полугодие выходят кумулятивные апдейты MS SQL Server и минорные релизы PostgreSQL, плюс патчи безопасности Windows Server и Linux. Без AlwaysOn или потоковой репликации обновление СУБД требует полного окна обслуживания, с ними — переключение primary на secondary за 5–30 секунд.
Подготовка к обновлению без простоя
Обновление сервера 1С предприятия начинается не с дистрибутива, а с трех документов: списка изменений из Release Notes, плана отката и согласованного окна обслуживания. Без этих шагов любая нештатная ситуация превращается в скандал с бизнесом.
Изучение Release Notes
В разделе «Что нового» на портале its.1c.ru фиксируются исправления ошибок, изменения структур данных, требования к совместимости с конфигурациями. Особое внимание — пунктам про реструктуризацию, удаление устаревших методов языка и смену форматов обмена. Если ваша самописная доработка использует объявленные deprecated методы, ее придется править до обновления, а не после.
Тестовый стенд и пилотное обновление
Развертывается отдельный сервер с тестовой базой — копией продуктивной, на нем устанавливается новая версия платформы, прогоняются типовые сценарии: проведение документа, формирование оборотно-сальдовой ведомости, запуск регламентных заданий, обмен с маркетплейсами.
В сложных проектах применяют simulating — синтетическую имитацию нагрузки от десятков пользователей одновременно. Под такие стенды разумно держать отдельный сервер для 1С и не пытаться обновлять прод без предварительной обкатки тестовой базы.
План отката и окно обслуживания
В плане отката четко описано: какой дистрибутив установить обратно, как восстановить cf-файл конфигурации, при каких условиях разворачивается бэкап базы из системы резервного копирования. Окно обслуживания согласуется с заказчиком за неделю, пользователи оповещаются за два-три дня — это формальность, без которой даже технически успешное обновление оставит шрамы в отношениях с бизнесом.
Сценарий 1: обновление платформы 1С на сервере
Этот сценарий подходит для небольших клиент-серверных внедрений до 30–40 пользователей, где допустим простой 15–30 минут в ночное окно. Обновление платформы 1С на сервере выполняется по простой последовательности.
- Бэкап. Полная копия базы СУБД и cf-файла конфигурации делается за минуты до начала работ.
- Остановка ragent. На Windows — команда Stop-Service "1C:Enterprise 8.3 Server Agent", на Linux — systemctl stop srv1cv83. Активные сеансы пользователей завершаются принудительно.
- Установка дистрибутива. Новая версия платформы накатывается поверх старой, дистрибутив берется с портала its.1c.ru. Проверка совместимости платформы с целевой конфигурацией — обязательно до установки. Совместимость указана в Release Notes для каждого релиза.
- Перезапуск сервиса. Команды Start-Service или systemctl start srv1cv83, после чего ragent поднимает rphost и rmngr с новой версией.
- Smoke test. Тестовые пользователи проводят документ, открывают отчет, запускают регламентное задание. Параллельно проверяется диагностика через технологический журнал — нет ли новых ошибок.
Если smoke test прошел успешно, пользователи возвращаются в систему. На рабочем сервере процесс умещается в 5–15 минут.
Сценарий 2: обновление кластера серверов 1С поузлово
Обновление кластера серверов 1С без простоя — это аналог замены шины на ходу: машина не останавливается, потому что колеса меняются по очереди. Метод работает только при наличии 2+ узлов и общей СУБД.
- Вывод первого узла из ротации. В консоли администрирования снимается флаг «использовать в работе», новые сеансы перестают приходить на эту машину.
- Дренаж сеансов. Активные подключения завершаются естественным образом или принудительно — за 5–10 минут узел остается пустым.
- Обновление платформы. На освобожденном узле останавливается ragent, устанавливается новый дистрибутив, перезапускается сервис. На этом шаге фактически и проходит обновление 1С клиент сервер на конкретной машине.
- Возврат в кластер. Узел снова помечается активным, на него уходят новые сеансы. Параллельно проверяется нагрузка и отсутствие ошибок в технологическом журнале.
- Повтор для остальных узлов. Поочередно проходим вторую и третью машину. Общее время для кластера из 3 узлов — 20–40 минут, простой пользователей при этом нулевой.
Принципиальное условие — версия платформы на всех узлах в один момент времени должна совпадать или различаться не более чем на минорный релиз. По сути это и есть обновление 1С клиент сервер с нулевым простоем для пользователей. Иначе кластер откажется собирать сеансы.
Сценарий 3: обновление конфигурации 1С сервер без простоя
Платформа с версии 8.3.10 поддерживает динамический режим обновления конфигурации. Платформа применяет изменения в фоне, пользователи продолжают работать, реструктуризация структур таблиц происходит между транзакциями.
Динамическое обновление работает при двух условиях: меняются только формы, отчеты, обработки и алгоритмы; структура таблиц регистров и документов остается прежней. Если разработчик добавил новый реквизит в документ или поменял измерение регистра, динамика не сработает — потребуется монопольный режим и короткое окно простоя.
Когда динамическое обновление не подходит
Полный простой нужен в трех случаях: при изменении структуры данных с реструктуризацией, при обновлении ядерных подсистем платформы, при смене типа СУБД. Здесь работает классическая схема — выгон пользователей, монопольный захват базы, накат cf-файла, реструктуризация, smoke test. Типовое окно — от 30 минут до 4 часов в зависимости от размера базы.
Обновление СУБД и ОС: окно обслуживания и переключение
Под СУБД обычно ставится отдельный сервер баз данных, и его обновление идет по логике высокой доступности.
AlwaysOn AG для MS SQL Server
В Availability Group обновляется сначала secondary-реплика: устанавливается кумулятивный апдейт, выполняется перезагрузка, реплика возвращается в группу. Затем primary переключается на обновленную secondary за 5–30 секунд, и теперь обновляется бывший primary. Простой пользователей — единичные секунды на переключении.
Потоковая репликация PostgreSQL
Принцип тот же: сначала обновляется standby-узел, затем выполняется failover через repmgr или Patroni — 10–60 секунд. После этого обновляется бывший primary, и роли можно вернуть назад, если это требуется по архитектуре.
Обновление сервера 1С Linux и Windows
Серверы операционной системы в кластере обновляются по той же логике rolling update: одна машина выводится из ротации, на ней ставятся патчи и выполняется перезагрузка, после чего она возвращается. Поочередное обновление всех узлов занимает 30–90 минут, простоя по логам ноль.
Обновление веб-сервера 1С
Обновление веб-сервера 1С идет параллельно с обновлением платформы: на машине с публикацией останавливается nginx или Apache, обновляются модули 1С, перезапускается веб-сервер. Через утилиту webinst при необходимости пересоздается файл default.vrd с актуальными настройками. На кластере веб-серверов используется тот же rolling update — узлы обновляются по очереди.
Тестирование после обновления
Сразу после возврата пользователей в систему обязателен smoke test, который проверяет ключевые сценарии бизнеса.
- Проведение документа. Типовая приходная накладная или акт сверки проводится тестовым пользователем.
- Формирование отчета. Оборотно-сальдовая ведомость, движения по счету, отчет по регистру.
- Регламентные задания. Ночные обмены, выгрузки, расчеты — запускаются вручную и проверяются на ошибки.
- Apdex. Замеряется производительность — после обновления показатель не должен упасть ниже 0,85.
Если хотя бы один пункт показывает отклонения, инцидент фиксируется и запускается план отката.
Откат при критичных ошибках обновления
Возврат к предыдущей версии платформы
Дистрибутив старой версии устанавливается поверх новой, ragent перезапускается. Если конфигурация не претерпела реструктуризации, база открывается на старой платформе без проблем. Типовое время отката — 30–60 минут.
Восстановление конфигурации из cf-файла
Если апдейт затронул только конфигурацию, а структура данных не менялась, достаточно загрузить старый cf-файл через конфигуратор. Операция занимает 10–20 минут.
Восстановление базы из бэкапа
Крайний сценарий — когда реструктуризация прошла и откатиться через cf уже нельзя. Тогда разворачивается полный бэкап базы из системы резервного копирования — фактически это локальная миграция данных на момент до начала обновления. Здесь критичны заранее настроенные RPO и RTO: при инкрементах раз в час теряется до 60 минут работы, при log shipping — до 15 минут.
Сравнительная таблица: сценарии обновления
Из таблицы видна логика: чем критичнее простой для бизнеса, тем больше предварительной инфраструктуры нужно поднять — кластер из нескольких узлов, AlwaysOn или Patroni, регулярный тест восстановления из резервных копий.
Заключение
Обновление сервера 1С без остановки — это вопрос не свежести релиза, а архитектуры. На одном сервере апдейт всегда означает короткое окно простоя, в кластере из 2+ узлов через rolling update пользователи не замечают изменений, а с AlwaysOn или потоковой репликацией СУБД переключение измеряется секундами.
Динамическое обновление конфигурации решает большинство еженедельных задач без перерывов, а полный простой остается только для случаев с реструктуризацией и сменой типа СУБД. Перед сложным проектом разумно провести аудит ИТ-инфраструктуры и выбрать сценарий, который подходит под текущие требования бизнеса.
Ответы на частые вопросы
Можно ли обновить платформу 1С без перезагрузки сервера?
Сам сервер перезагружать не нужно — достаточно остановить службы ragent, заменить дистрибутив и запустить службы заново. Перезагрузка ОС требуется только при обновлении системных компонентов или установке патчей Windows.
Что такое динамическое обновление конфигурации?
Это режим, при котором платформа применяет изменения cf-файла в фоне, без выгона пользователей. Работает с версии 8.3.10 и только при правках, не затрагивающих структуру таблиц. Безопасно для апдейтов отчетов, форм и алгоритмов.
Сколько занимает обновление платформы 1С на одном сервере?
Типовое время — 5–15 минут с учетом остановки ragent, установки дистрибутива, запуска службы и smoke test. На крупных конфигурациях с большим числом регламентных заданий процедура может растянуться до 30 минут.
Как обновить кластер 1С без простоя?
Через rolling update: узлы выводятся из ротации по очереди, на каждом обновляется платформа, затем возврат в работу. Для кластера из 3 узлов общее время 20–40 минут, простой пользователей нулевой.
Можно ли пропустить промежуточные версии платформы?
Технически можно, но не рекомендуется. Между релизами 8.3.18 и 8.3.24 могут накопиться изменения, которые лучше обкатать поэтапно. Прыжок через несколько версий повышает риск несовместимости с самописными доработками.
Что делать, если обновление сломало регламентные задания?
Сначала зафиксировать конкретный сценарий в технологическом журнале, затем проверить, не использовал ли код удаленные deprecated методы. Если откат конфигурации невозможен, исправление выполняется через доработку под новые API. До восстановления критичные регламенты запускаются вручную.
Нужно ли обновлять лицензию 1С при смене версии платформы?
Программные ключи переносятся автоматически без переактивации, USB-HASP тоже работает без вмешательства. Лицензия привязана к серверной машине, а не к конкретной версии платформы.
Как быстро откатиться к старой версии платформы?
Подробный сценарий описан в разделе «Откат при критичных ошибках обновления» выше. Если структура данных не менялась — 30–60 минут на установку предыдущего дистрибутива поверх новой версии. Если была реструктуризация — только через разворачивание бэкапа.
