В условиях, когда бизнес функционирует круглосуточно без выходных, вопрос обновления информационных систем 1С становится критически важным. Выясним, как подойти к этому процессу, минимизируя простои и обеспечивая стабильность работы. Мы рассмотрим различные подходы, от базовых принципов до современных автоматизированных конвейеров CI/CD, а также специальные механизмы платформы 1С.
Прежде чем приступить к обновлению рабочей базы, необходимо тщательно подготовиться. Это позволит избежать большинства критических проблем и сократить время простоя. 1. Всестороннее тестирование на копии: * Всегда тестируйте все изменения и предстоящее обновление на копии продуктивной среды, максимально приближенной к боевой. Это включает не только конфигурацию, но и объем данных, а также нагрузку. * Проведите полный цикл бизнес-процессов, затрагиваемых обновлением, чтобы убедиться в их корректной работе. * Замерьте время обновления: На копии базы обязательно замерьте, сколько времени займет обновление конфигурации базы данных. Это поможет точно спланировать технологическое окно и уложиться в отведенные сроки. 2. Осторожность с полной автоматизацией без присмотра: * Идея "ночного обновления без участия человека" может показаться привлекательной, но она таит в себе риски. Если процесс сломается (а это "когда", а не "если"), простой будет дольше, потери выше, а оперативное устранение проблемы может быть затруднено. * Даже при наличии скриптов, автоматизирующих процесс, всегда должен быть дежурный специалист, который дождется уведомления об успешном или неуспешном завершении обновления и будет готов оперативно вмешаться. 3. Выделение технологических окон: * Несмотря на режим 24/7, согласуйте и выделите минимальные технологические окна, когда можно остановить работу системы на час или более для выполнения критически важных обновлений. * Для менее критичных обновлений, которые не требуют монопольного режима, можно использовать более гибкие подходы. 4. Обеспечение ночной поддержки: * Если вы используете автоматизированное обновление и что-то пойдет не так ночью, у вас должен быть ночной саппорт, готовый оперативно решить проблему или попробовать обновить вручную. 5. Блокировка базы и перезапуск служб: * Перед началом обновления, требующего монопольного режима, обязательно выгоните всех пользователей из базы. Для этого можно использовать команду `net stop "1C:Enterprise 8.3 Server Agent (x86-64)"` (или аналогичную для вашей версии сервера 1С). * Перезагрузка службы 1С, а иногда и SQL-сервера, помогает избежать проблем, связанных с кэшем или долго висящими соединениями. * В некоторых случаях, если есть долгое обращение из базы к веб-сервису, перезапуск службы 1С может не помочь, и такое обращение может автоматически подняться после перезапуска. В таких ситуациях может потребоваться прямое блокирование соответствующего кода в определенные часы.
Для крупных организаций, работающих 24/7, внедрение практик CI/CD (Continuous Integration и Continuous Delivery/Deployment) и DevOps становится стандартом. Это позволяет автоматизировать сборку, тестирование и развертывание обновлений, значительно повышая скорость и качество релизов.
* Сокращение времени на рутинные задачи: Автоматизация сборки, тестирования и развертывания освобождает специалистов от монотонной работы. * Снижение вероятности ошибок: Автоматические тесты и стандартизированные процессы уменьшают человеческий фактор. * Быстрый и качественный выпуск ПО: Возможность частых итераций с уверенностью в стабильности системы. * Улучшение взаимодействия: Четкие процессы способствуют лучшей координации между разработкой и эксплуатацией.
Используйте Git как основную систему для хранения конфигурации. Разработка может вестись как в привычном Конфигураторе, так и в более современном инструменте 1C:Enterprise Development Tools (1C:EDT), который имеет встроенную поддержку Git.
Лайфхак для сочетания Конфигуратора и EDT: Вы можете начать разработку в EDT, затем запустить Конфигуратор из EDT, выполнить там изменения, вернуться в EDT и использовать "зеленую стрелку" для запуска пользовательского сеанса 1С. Система проанализирует и покажет изменения, которые легко импортируются в проект EDT. После этого можно выполнить коммит и отправить изменения в Git. Это позволяет сочетать скорость работы в Конфигураторе с удобной интеграцией EDT и Git.
При изменениях в основной ветке (например, `master`) в Git, запускается пайплайн, который автоматически собирает файл конфигурации (`.cf`) из исходников. Для этого могут использоваться скрипты или специализированные инструменты, такие как "Обновлятор" (который, по отзывам, работает стабильно даже для десятков баз с тысячами пользователей) или `vanessa-runner`.
После сборки `.cf` запускаются автоматические тесты на предварительно подготовленной тестовой базе. Это позволяет оперативно выявлять ошибки (например, длительная реструктуризация, неуникальные записи регистров сведений, методологические проблемы с новыми настройками) и исключать "битые" релизы до того, как они попадут в продуктивную среду.
Для автоматизации тестирования используйте инструменты, такие как Vanessa-Automation (известный, например, как `vanessa-runner` для запуска обработок, которые шлют результат в Telegram) или встроенные механизмы 1C:EDT.
Пример использования `vanessa-runner`:
// Предположим, у вас есть обработка, которая выполняет тесты
// и отправляет результат в Telegram.
// Вы можете запустить ее через Vanessa-Runner после обновления.
// Пример команды для запуска обработки через командную строку
// (путь к vanessa-runner.exe и параметры могут отличаться)
C:\Path\To\VanessaRunner\VanessaRunner.exe --ibconnection="File=C:\Path\To\Base;Usr=User;Pwd=Password;" --execute="C:\Path\To\Processing\MyTests.epf" --parameter="SendToTelegram=true"
Не пустой регистр, например, должен отслеживаться автотестами.
Для оркестрации всех этих процессов используйте серверы CI/CD, такие как Jenkins, GitLab CI, TeamCity. Они могут работать с Docker-образами сервера 1С, обеспечивая изолированные и воспроизводимые среды для сборки и тестирования.
После успешного прохождения всех тестов обновления могут автоматически доставляться в продуктивную среду в заранее определенное технологическое окно. Например, при изменениях в ветке `master` запускается пайплайн, который собирает `.cf`, импортирует его в базу предпродакшена, прогоняет тесты, и при успехе автоматически накатывает на продуктив.
Даже при полной автоматизации, мониторинг является ключевым элементом. Дежурный специалист должен получать уведомления (например, в Telegram) об успешном или неуспешном завершении обновления, чтобы оперативно реагировать на проблемы.
Для организаций 24/7 критически важно сократить время, когда система недоступна для пользователей. Рассмотрим специальные механизмы 1С и другие подходы.
* Динамическое обновление:
Позволяет вносить изменения в конфигурацию базы данных без монопольного доступа, но с существенным ограничением: оно возможно только при отсутствии изменений в структуре метаданных. После такого обновления пользователи продолжают работать со старой конфигурацией, и новая вступает в силу только после перезапуска их сеансов 1С. Однако, динамическое обновление может приводить к непредсказуемому поведению системы, ошибкам СУБД, проблемам с кэшем метаданных и падению производительности, особенно если изменения затрагивают функции или удаляют объекты. Используйте его с осторожностью и только для незначительных изменений.
* Фоновое обновление конфигурации базы данных (только для 1С:КОРП):
Это более продвинутый механизм, предназначенный для выполнения основного объема операций по обновлению без прерывания работы пользователей. Он особенно актуален для крупных компаний, где простои критичны. Фоновое обновление состоит из нескольких этапов: обработки, актуализации и принятия изменений. Только на последнем этапе — принятия изменений — требуется монопольный режим и кратковременная остановка работы пользователей. Этот функционал работает исключительно в клиент-серверных базах и не применяется к конфигурациям, поддерживающим режим совместимости с версией 8.1, а также работающим на СУБД IBM DB2 9.1. Рассмотрите этот механизм как приоритетный, если ваша организация использует версию 1С:КОРП.
* Методика "Обновление через копию", доступная в БСП (Библиотека стандартных подсистем), позволяет сначала обновить копию боевой базы, связанную по РИБ, а затем мигрировать обновления в боевую. Это позволяет провести основные, трудоемкие работы по обновлению на копии, сокращая время монопольного доступа к рабочей базе. * Однако, стоит отметить, что некоторые специалисты высказывают критику в адрес этого механизма, указывая на его не всегда корректную работу и необходимость дополнительных доработок. Тем не менее, проанализируйте этот подход, поскольку он может значительно сократить простои. * Альтернативный вариант: Обновляйте пустую базу с текущей конфигурацией рабочей базы на отдельном компьютере. Это значительно быстрее, чем на рабочих серверах. Там же перепроверяйте, не потерялись ли "свои" изменения. Затем выгружайте `.cf` из пустой базы и загружайте в копию из архива рабочей базы на рабочем сервере, перепроверяя работоспособность на текущих рабочих данных. Если все нормально — загружайте `.cf` в рабочую базу.
* Для нетиповых конфигураций, особенно при пропуске нескольких релизов, важно определить проблемные места обновления и оптимизировать отработку промежуточных конфигураций. Это может включать загрузку базы в файловом варианте для ускорения обработки и перепроведения данных.
* Максимальный перенос доработок в расширения позволяет обновлять типовую конфигурацию без необходимости снимать ее с поддержки. Это значительно упрощает процесс обновления, снижает риски и сокращает время на разрешение конфликтов. Примите волевое решение: либо все в конфигуратор, либо все в EDT и расширения.
* Существуют специализированные инструменты (например, "1С‑Рарус: СОК"), которые анализируют индивидуальные доработки, сопоставляют изменения в новом релизе и автоматически обновляют конфигурацию, предлагая формы для разрешения конфликтов. Это может сократить время на обновление нетиповых конфигураций до 40%. Рассмотрите возможность использования таких решений.
Для поддержания актуальности всей системы, возможно автоматическое обновление платформы 1С на рабочих местах пользователей. * Создайте общую папку с дистрибутивами платформы на сетевом ресурсе. * На клиентских машинах создайте или измените конфигурационный файл `1cestart.cfg`, который указывает на этот сетевой каталог. * При запуске 1С программа будет проверять наличие более свежей версии платформы и, при необходимости, принудительно устанавливать ее.
Если вы или ваши разработчики ведете разработку на домашних компьютерах, обратите внимание на лицензионное соглашение 1С. * Для правомерного использования системы "1С:Предприятие 8" на домашнем компьютере в такой ситуации необходимо приобрести отдельную основную поставку. * Использование ключа защиты организации без отдельной основной поставки нарушает Лицензионное соглашение. * В качестве основной поставки может быть использована конфигурация, аналогичная той, что приобретена организацией, или "Комплект специалиста по разработке и внедрению".
Эффективное выполнение релизов 1С в организациях, работающих 24/7, требует комплексного подхода, сочетающего тщательное планирование, автоматизацию процессов и использование всех доступных механизмов платформы. Внедряйте практики CI/CD, максимально используйте расширения, рассматривайте фоновое обновление и не забывайте о необходимости постоянного мониторинга. Это позволит вам выпускать обновления быстро, качественно и с минимальными простоями.
← К списку