Рано или поздно перед каждым системным администратором и разработчиком 1С встает вопрос обновления технологической платформы. С одной стороны, новые релизы конфигураций (таких как «Бухгалтерия предприятия» или «Зарплата и управление персоналом») начинают жестко требовать новые версии платформы. С другой стороны, поспешный переход на самый свежий релиз часто чреват неожиданными сбоями: от падения клиентских приложений до полной остановки обменов данными. В этой статье мы подробно проанализируем, как правильно подходить к выбору релиза платформы 1С, рассмотрим стратегию безопасного обновления и разберем способы решения наиболее частых проблем, возникающих при переходе.
При выборе версии платформы профессиональное сообщество 1С традиционно разделяется на два лагеря. Сторонники первого лагеря предпочитают использовать исключительно проверенные временем, «зрелые» ветки (например, долгое время эталоном стабильности считалась ветка 8.3.15, в частности релиз 8.3.15.1830). Логика здесь проста: в этих версиях уже исправлено большинство критических ошибок, и они гарантируют предсказуемую работу системы в продакшене.
Второй лагерь ратует за установку самых последних версий платформы, аргументируя это тем, что в них реализован новый функционал и исправлены ошибки предыдущих релизов. Однако на практике погоня за новизной без предварительного тестирования может парализовать работу компании. Оптимальным решением является соблюдение баланса и использование проверенных методик выбора.
Рассмотрим подробнее метод «1С:Фреш», который часто используют опытные администраторы. Перед тем как принять решение о переходе на конкретную версию платформы, мы можем поинтересоваться, какая именно версия сейчас развернута в облачном сервисе 1С:Фреш. Поскольку в этом облаке одновременно работают миллионы пользователей, фирма «1С» тестирует там новые релизы с максимальной нагрузкой. Если платформа стабильно работает во «Фреше», ее можно с высокой долей уверенности внедрять и на локальных серверах предприятия.
Если раньше администраторы могли годами не обновлять платформу, работая на старых стабильных версиях, то сегодня фирма «1С» лишила их такой возможности. В современных типовых конфигурациях внедрен жесткий контроль минимального релиза платформы.
Проанализируем, как это устроено. При запуске информационной базы конфигурация выполняет проверку версии программного файла. Если текущая платформа ниже требуемой, система не просто выдает предупреждение, а физически блокирует запуск. Программный код такой проверки в общих модулях выглядит примерно следующим образом:
МинимальнаяВерсияПлатформы = "8.3.15.1830";
ТекущаяВерсияПлатформы = СистемнаяИнформация.ВерсияПриложения;
Если ОбщегоНазначенияКлиентСервер.СравнитьВерсии(ТекущаяВерсияПлатформы, МинимальнаяВерсияПлатформы) < 0 Тогда
ВызватьИсключение "Запуск программы невозможен. Требуется версия платформы не ниже " + МинимальнаяВерсияПлатформы;
КонецЕсли;
Именно поэтому оставаться бесконечно на старой ветке не получится. Нам необходимо планировать регулярные обновления, но делать это максимально осознанно.
Одной из наиболее частых жалоб после перехода на новую платформу является внезапный отказ работы COM-соединений между базами (например, при обмене данными между «Управлением торговлей» и «Бухгалтерией предприятия»). Пользователи часто сталкиваются с ситуацией, когда регламентные задания обмена начинают выдавать ошибки инициализации.
Выясним причину этой проблемы. При установке новой платформы операционная система Windows часто теряет регистрацию библиотеки comcntr.dll, отвечающей за работу класса V83.COMConnector. Для восстановления работоспособности обменов нам необходимо перерегистрировать эту библиотеку вручную.
Разберем по шагам, как решить эту проблему:
regsvr32 "C:\Program Files\1cv8\8.3.17.1549\bin\comcntr.dll"
Если сервер 1С работает в 64-разрядном режиме, а внешние системы, подключающиеся по COM, используют 32-разрядные компоненты (или наоборот), то простой регистрации библиотеки может быть недостаточно. В этом случае мы рекомендуем настроить обертку через Службы компонентов Windows, создав отдельное приложение COM+ (так называемый «триггер разрядности»).
Важная рекомендация: учитывая регулярные проблемы с безопасностью и регистрацией COM-компонентов в современных ОС Windows, мы советуем постепенно отказываться от технологии COM в пользу современных интеграционных механизмов, таких как HTTP-сервисы или Web-сервисы. Они работают быстрее, не зависят от версий платформы на клиенте и не требуют админских прав для регистрации библиотек.
Иногда после обновления платформы пользователи начинают жаловаться на регулярные аварийные завершения работы тонкого или толстого клиента (особенно часто это замечают в тяжелых конфигурациях, таких как «Зарплата и управление персоналом»). При этом в технологическом журнале или системном журнале событий Windows могут фиксироваться ошибки работы с сетевыми пакетами или библиотеками прорисовки интерфейса.
Рассмотрим реальный кейс: на платформе 8.3.16.1063 при клиент-серверном подключении регулярно происходили вылеты программы без видимых причин. Выяснилось, что проблема крылась в несовместимости сетевого стека платформы с определенными сборками операционной системы Windows 10 и драйверами сетевых карт.
Для решения подобных проблем рекомендуется выполнить следующий комплекс мер:
IPv6, если она не используется в локальной сети.Давайте проанализируем, почему не стоит сразу переходить на новые технологические ветки сразу после их выхода, на примере платформы 8.3.17. Хотя она и принесла много полезных функций (например, полноценный клиент для macOS и интеграцию с «1С:Аналитикой»), ее промышленная эксплуатация на начальных этапах вскрыла критические уязвимости.
Во-первых, в конце 2022 года пользователи столкнулись с глобальным сбоем системы лицензирования, из-за которого серверы аварийно завершали работу с ошибкой использования нелицензионного ПО. Это потребовало от администраторов экстренного обновления на последние исправительные релизы.
Во-вторых, в релизе 8.3.17.2757 содержалась критическая ошибка работы с регистрами бухгалтерии: при проведении документов с одинаковыми счетами дебета и кредита некорректно заполнялись субконто кредита. Для исправления этой ситуации фирме «1С» пришлось выпускать специальный патч исправления данных (EF_60004003).
Этот пример наглядно показывает, что спешка при переходе на новые технологические ветки в промышленной среде недопустима. Только планомерное тестирование и отслеживание официального баг-трекера вендора уберегут базу данных от повреждения.
Для того чтобы минимизировать риски при обновлении платформы 1С на предприятии, мы советуем придерживаться следующего пошагового алгоритма:
Соблюдение этих простых правил и осознанный подход к выбору версии платформы обеспечат стабильную и бесперебойную работу всей системы автоматизации вашего предприятия.