Pull to refresh

Comments 45

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

казалось бы, чего проще? разверни клон прода и тестируй на нём всё, что хочешь..но.. автор не ищет лёгких и безопасных путей! его заводит азарт, адреналин щекочет нервы..а не поставить ли раком "боевой" сервер и всю работу предприятия..ведь ничего плохого при обновлении компонент системы не может случится? ведь нет же? ведь при накате и развертывании бд не может, например, навернутьсч системная бд master..мы все доподлинно знаем о надежности работы продуктов MS. или появится в новый платформе новая версия какой нибудь системной библиотеки...

штош. хочется сказать - это порочная практика. всё новое надо выносить отдельно

казалось бы, чего проще? разверни клон прода и тестируй на нём всё, что хочешь..но.. автор не ищет лёгких и безопасных путей! его заводит азарт, адреналин щекочет нервы..а не поставить ли раком "боевой" сервер и всю работу предприятия..ведь ничего плохого при обновлении компонент системы не может случится? 

Справедливости ради, наличие тестовой среды часто упирается в лицухи. Там до сих пор "аппаратная" привзяка ключей внутри. Поэтому сделав клон прода вы получаете тыкву. Нужно или закупать всех лицензий х2 (если тестовое окружение у нас копирует прод) или ограничиваться вариантом сервера-мини, но тогда тесты будут не вполне релевантны.

для этого есть сервер лицензирования 1С

И как он поможет, если на нем 1C Сервер лицензий, одна штука. А проду и тесту совместно - нужно две? Т.е. это как раз вариант всех лицензий х2.

Вроде бы есть возможность запросить на сайте 1С тестовый комплект 1С-предприятия с серверной лицензией на 14 дней.

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

В статье нет ни слова про тестирование, тем более на проде.

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

Обновление платформы (если платформа вышла в свет хотя бы больше недели назад, то есть не успела быть отозвана и не из тестовой ветки) практически никогда не несет за собой никаких рисков. Тестовый контур при работе с типовыми конфигурациями не нужен, это огромные расходы ради непонятного чего: платформу уже протестировали до вас со всеми типовыми конфигурациями. Вообще возможны 3 варианта:

Используется типовая конфигурация без доработок - можно смело обновлять и платформу и конфигурацию, если релизы уже полежали в общем доступе недельку и не успели быть отозванными. Никакой тестовый контур не нужен.

Используется типовая конфигурация с незначительными доработками (незначительные, это, например, если не менялись ключевые свойства, такие как режим совместимости) - можно смело обновлять платформу, а конфигурацию обновлять сначала строго на копии, которую можно разместить на том же сервере для минимизации затрат.

Самописная конфигурация или сильно доработанная типовая - только полноценный тестовый контур на отдельном сервере/серверах.

Благодарю за ваш комментарии. К сожалению мои клиенты не могут это себе позволить.

Для тех, кто использует СУБД MS SQL, я покажу, как это сделать быстро, без лишних движений.

те кто используют СУБД MS SQL знают как что угодно сделать быстро, без лишних движений, там куча документации по делу. При чем здесь 1С?

Спасибо за ваш комментарий. К сожалению, наличие во многих организациях сервера СУБД, не означает, что им умеют пользоваться. Конкретно, в этой организации был опытный системный администратор, но с SQL не дружил конкретно. :)))))

А где перерегистрация .COM объектов без которой в 99% случаев после обновления платформы умрут обмены БУХ <-> ЗУП?

А с чего вы взяли, что почти все юзают ком? И с чего вы взяли, что в рассмотеренном примере есть ЗУП, ведь на скрине со списком баз его нет? В 2025, для обменов, в том числе БУХ <-> ЗУП актуально использовать http через публикацию на вебсервер. А вот то что пример без веба, ИМХО делает всё описанное в статье частным и устаревшим. Обновить платформу это далее-далее-готово, в этом нет ничего сложного. Сложности в современной клиент-серверной концепции работы с 1С возникают в том как новые тонкие клиенты развернуть на десятки пользовательских ПК.

А с чего вы взяли, что почти все юзают ком?

С того, что это до сих пор типовой механизм обмена искаропки. Который стабильно ломается именно при обновлении платформы, поэтому не учитывать и не проверять его наличие - несколько странно.

В 2025, для обменов, в том числе БУХ <-> ЗУП актуально использовать http через публикацию на вебсервер.

Актуально использовать то, что вас устраивает по функционалу и по сложности реализации. Не у всех есть отдел внутренней разработки под 1С, чтобы пилить кастомные обмены. И не все используют веб-публикации сервиса (знаю тех, кто наоборот, принципиально их не использует).

Сложности в современной клиент-серверной концепции работы с 1С возникают в том как новые тонкие клиенты развернуть на десятки пользовательских ПК.

У автора изначально озвучен сценарий с терминальным сервером. В этом случае нет никаких сложностей с клиентской частью, так как она живет на нашем терминале(терминалах).

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

>пилить кастомные обмены

Обмен по вебу это и есть типовой механизм из коробки, там не надо ничего разрабатывать. Любая современная конфигурация уже умеет коннектится к другим современным опубликованным на веб. Ком давно уже не стандарт, его поломки в 1С на 64 разрядных ОС довольно-таки утомили. При отсутствии веба, я выберу гонять обмены через файло, нежели постоянно ежемесячно искать решение работы лютейшего легаси в современных средах, в 1С просто забили болт на поддержку этого механизма.

>умрут обмены БУХ <-> ЗУП

>У автора изначально озвучен сценарий с терминальным сервером

А при чем тут, то что у него озвучено? Вы же проигнорировали, вводные данные автора в которых про ЗУП нет ни слова, и указали на некое действие которое по вашему стоило бы указать в статье. Я в свою очередь тоже опираясь не на вводные данные, а на текущий год в календаре выразил своё ИМХО.

При отсутствии веба, я выберу гонять обмены через файло, 

Ну через файло это совсем флоппинетом попахивает уже. :)

У COM обмена на самом деле есть один, большой плюс. Воспользоваться и настроить его может любой бухгалтер/пользователь 1С c нужными правами. Настроить же веб-публикацию и обмен через нее без доступа в конфигуратор и админки на сервере уже не получится.

И да, при обновлении платформы, с веб-публикациями тоже нужны будут определенные ручные манипуляции без которых старые базы не взлетят. Наверное упомянуть их тоже было бы не лишним. Так как обмены и веб-сервисы это как раз то самое, что используется далеко не каждый день в некоторых сценариях и о проблеме в их работе можно узнать сильно, так сказать, после.

разве при установке новой версии платформы не происходит автоматическая регистрация актуальной компоненты СоМ.Соединение?

не происходит автоматическая регистрация актуальной компоненты СоМ.Соединение?

Вы не поверите, но нет, не происходит. Шел 2025 год, а  C:\Windows\SysWOW64\regsvr32 "C:\Program Files (x86)\1cv8\<Platform Version>\bin\comcntr.dll" все еще актуальна. :)

это (что не регистриуется автоматически) странно и не соответствует
1. главе 6 документации КСВ.Руководство администратора: в ней нет пункта по регистрации компоненты
2. нашему ограниченному опыту: при обновлении версии платформы 8.3.25 соответствующая компонента автоматически зарегистрировалась. и только при возврате на старую версию (8.3.22) нам пришлось регистрировать компоненту (для старой версии) вручную, потому что после удаления версии 8.3.25 зарегистрированной осталась компонента для версии 8.3.25

На 24й делается точно руками. Плюс ведь зачем-то установщик аж в меню Пуск этот ярлык с регистрацией каждый раз добавляет.

точно ли добавляет ярлык регистарции comcntr.dll (СОМ.Соединения) добавляет в меню Пуск? (а не регистрацию ли утилиты админстрирования сервера)

Да, конечно я про оснастку mmc. Пардон если запутал.

все нормально - быстро же разобрались

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

Обновляем платформу 1С: Предприятие на ходу!

Сначала по заголовку подумал что появились способы обновлять платформу на горячую незаметно для пользователей. Думаю, о, интересно. Но нет, обычное скучное обновление в стиле "setup.exe -> Next -> Next -> Next -> Finish".

А как же механизм обновления клиентского приложения? Это действительно мощный способ обновить платформу на тысячах рабочих мест весело и на ходу.

Нет в действиях обновления веб-публикаций и/или СОМ-Коннектора.

Не увидел в списке действий бекап каталога данных сервера (ну или хотя бы конфигурации кластера). В нем, по хорошему, при переходе на версию надо некоторые каталоги удалить.

правильно понимаю, Вы сталкивались с тем, что после обновления платформы нарушались/разрушались данные в файлах настройки кластера?

когда это случается? из-за чего?

мы столкнулись с ситуацией "нарушены данные в файлах". пока не можем понять как случилось

Благодарю за ваш комментарий. При остановке службы можно удалить папки с сеансовыми данными кластера. Иногда они разрастаются до больших размеров. Полезное действие о котором я забыл упомянуть.

Доводилось ранее заниматься обновлением серверов 1с, в этой инструкции вот что бросилось в глаза. Зачем редактировать существующую службу 1С через реестр? Вы же устанавливаете новую платформу на сервер, она устанавливается по умолчанию в отдельный каталог. Намного проще будет после установки платформы (в инсталляторе галку убираем, службу не создаем!) создать дополнительную службу вручную. Можно это сделать, например, через sc.exe (может и через powershell сейчас можно нормально создать, нужно проверять). Итого, у вас получится 2 службы, указывающие на разные каталоги, разные exe файлы сервера. В момент обновления останавливаете одну, запускаете другую и все. В случае проблем, если надо откатиться, также останавливаете новую службу, запускете старую. Ну и соответственно смена ярлыков на RDS, предоставление доступов и т.п.

если правильно понял автора статьи, смысл как раз в том чтобы не делать то, о чем Вы написали в последнем предложении

если не затруднит ответьте пожалуйста:

  1. при каких сценариях обновления сервера 1с может сломаться информационная база? (и значит пригодится резервная копия информационной базы)

  2. порядок отката на старую версию платформы (при необходимости)? кратко крупными пунктами

  3. как при таком откате (п.2) используется резервная копия информационной базы?

У моих коллег из ИТС (которые обновляют конфигурацию) может что-то пойти не так. И в итоге у них получается не рабочая конфигурация. Они не имеют возможности долго экспериментировать. Поэтому просят меня просто вернуть "всё как было". А сами берут паузу на решение своих проблем.

Я просто возвращаю базы из бэкапа и редактирую сервис агента 1С в реестре. В итоге получаю старую платформу и базы на момент до обновления. Это занимает немного времени. Никакие строки подключения баз менять не надо.

спасибо за пояснения.
я понял, что у вас при обновлении сервера (не конфигурации) базы не ломались

Ни разу такого не было.Да и с чего бы вдруг? Я не написал в статье, что бэкапы делаю по просьбе коллег. Это моя ошибка.

такая же "ошибка" и в Главе 6 документации КСВ.Руководство администратора. это неспроста и хочется разобраться с основаниями делать копии баз в контексте обновления платформы.

спасибо за пояснения.

будем искать дальше тех, у кого базы "ломались" и пришлось восстанавливать

В итоге получаю старую платформу и базы на момент до обновления.

Базы от запуска на новой платформе подвергаются необратимым изменениям? По моему опыту база даже в режиме совместимости "Не использовать" после обновления платформы сама меняет режим совместимости на "Совместимо с 8.3.ххх" (предыдущая платформа), т.е. даже служебные таблицы без ручного изменения конфигурации (значения режима совместимости) не изменяются.

Спасибо за комментарий. Бэкап баз нужен моим коллегам. Разумеется к обновлению платформы это не имеет отношения. В тех. задании, которое давали на эту был такой пункт.

В 2025 году выкатывать статью про обновление сервера 1С на windows это как раз то что нужно.

А то многие уже забыли, что это такое сервера 1С на windows

Скрипты это вообще для слабых духом, настоящие админы конечно же лупят по кнопке Далее

Вопросики однако накопились

  1. Это COM коннектор, он наверняка есть при сервере на винде

  2. Кто вообще может вспомнить времена когда надо было через 5 минут откатывать платформу, потому что она не заработала?
    Это если и обнаруживается, то через дни или недели

>Это если и обнаруживается, то через дни или недели

Обычно в отчетный период, когда очередной условный НДФЛ вдруг не формируется.

статья полезная для нас, автор поделился личным опытом, не претендует на универсальность и полноту. статью модель сравнить с типовой документацией и выбрать для себя оптимальный подход как комбинацию. и комментарии к статье очень полезны с этой точки зрения.

так что спасибо автору

  1. Почему пользователей выгоняем после установки?

  2. Почему архивы создаем после установки

  3. Как мы проверим прод на старом образе службы не перезапуская его

  4. В конечном итоге всех выгоняем и блокируем вход. Почему нельзя это сделать до установки. 5 минут ничего не решат, не так ли.

  5. Каким образом новая платформа сломает базу тем более на скуле? Согласен, когда переход происходит между версиями год и более. Но это не наш случай. Был ли опыт слома базы в момент перехода на новую платформу.

  6. По тексту ощущение что путаете сервер терминалов и сервер служб 1с. Или опечатки.

  7. Не хватает в плане. проверка возможных сервисов- веб серверы, ком службы.

  1. В конечном итоге всех выгоняем и блокируем вход. Почему нельзя это сделать до установки. 5 минут ничего не решат, не так ли.

наверное потому что есть ситуации, когда обновиться как можно быстрее, решают и 5 минут.
кстати в Клиент-серверный вариант. Руководство администратора в Главе 6 ровно такой порядок, цитирую:

1. Отключить всех пользователей от информационных баз обновляемого кластера серверов.

2. Остановить кластер серверов

В статье это пункты одни из последних. А не 1 и 2.

именно так: эти пункты из последнего раздела инструкции - активации новой платформы, после выполнения всех других действий включая установку ПО на сервер 1С. все так?

О, да! Когда на тебе висит 15 разгневаных юзеров,удовольствие растягивать не будешь!

Sign up to leave a comment.

Articles