Как проводите обновление с СГО? : УКМ-4

СГО+86 СМ-ов+2 кассы на каждом СМ-е.
В два последних раза делал так:
делал клон СГО, обновлял его, заходил на каждый СМ, обновлял СМ, переподключал его к временному СГО, обновлял кассы по одной.

Медленно, муторно, потери чеков (после ручной перевыгрузки - все норм).

В последний раз - почти месяц обновлялись.

Вопрос: как эту процедуру Вы делаете?
На уровне обновления СМ-а процедура обновления вопросов не вызывает. Интересует именно связка СГО=СМ-ы=кассы.

Есть еще одно ограничение: если в офисе (СГО) не будет чеков 6 часов - это ЧП вселенского масштаба. Именно по этому такая схема и применялась.

Обновление до последних версии занимает несколько часов на дюжине магазинов и 50 кассах.
По-моему, при обновлении до 60 версии происходит обрезка чеков.

1. Каким-то образом передаем пакеты обновления на СМ (существуют несколько способов).
2. Закладываем пакеты обновлений в папку C:\Program Files\ukmserver\ukmupman\update\
3. Производим загрузку обновлений на кассу. Контролируем через Монитор оборудования, что обновления загрузились на кассу.
4. Останавливаем службы УКМ сервер (можно и порт службы поменять, но никогда этого не делаю).
5. Делаю бэкапы СМ и СГО.
6. Запускаю Менеджер обновления. После обновления смотрю лог сервера и подкидываю лицензию.
7. Включаю авто-обновление касс . Делаю по одной -две кассы. После обновления кассы выключаю автообновление.

К сожалению проблема безболезненного обновления УКМ 4 решена не будет, это я вам со всей ответственностью могу сказать. А вся проблема лежит в структуре софта, невозможность работать с разными версиями в момент перехода, пусть и с ограничениями, приводит к отсутствию автоматического обновления.

У Вас месяц - еще не самый худший вариант, я знаю клиентов, которые по 3-4 месяца обновление продолжают. Лучше не будет.

Вообще бытует мнение в С+, что обновление стало существенно легче, где-то с 64 версии, но это лажа :), быстрее, из-за правки ошибок алгоритмов работы СГО, но не легче.
Начинать процедуру обновления нужно с рассылки дистрибутивов по кассам и СМ, далее в ночь обновляем СГО, якобы на сотне магазинов с 64 версии этот процесс занимает не более 6-8 часов, ну а далее запускаем обновление СМ и касс.

Проблема остается в том, что если клиент имеет круглосуточные магазины, а так же развитую дисконтную программу, то далее, после обновления, нужно садится и ручками коррекции проводить )))

Для особо крупных клиентов, на каждое обновление С+ заводит Проект (за деньги), где прописываются все эти шаги, действия, все это проходит под удаленным контролем сотрудников тех поддержки С+. Собственно документ и алгоритм можно попросить у начальника тех поддержки, я думаю он может бросить примеры, как например Одежда 3000 обновляется и т.п.

1. Для чего собственно нужны чеки на СГО? Если продажи нужны для выгрузки в бэк, то лучше всего завести на каждом магазине своей конвертер экспорта. И самому заняться транспортом чеков с магазинов до офиса. Тогда "потеря" СГО на период обновления не так критична.
2. Мы существенно увеличили скорость обновления делая бэкапы mysql вручную - копированием бд без её архивации. Аппач, пхп, укмсервер копируются задолго до обновления.
3. Готовить персонал для помощи в обновлении или привлекать его со стороны. Я мой коллега, например с удовольствием помогли бы кому-нибудь с переходом за небольшую денежку. Да и вообще тут достаточно много авторитетных специалистов.
4. Очень помогают cmd, повершелл и баш. Я например сварганил скрипт, который засылает на сго инфу о свободном месте на дисках, размере mysql и.т.п - невероятно помогает, в т.ч при обновлении. Апдейты тоже не ручками на магазины копируем (хотя вот репликация файлов меня не очень устраивает - будем переделывать).
5. Важно как посылаются товары из бэка. Для одного из переходов на новый укм мы ставили конвертор импорта на каждый магазин, и сами занимались транспортом товаров до сервера магазина.
6. Собственно сами пакеты обновления можно переписывать исходя из потребностей. Один раз мне пришлось его переписать т.к мой каталог апдейта находился на D: а не в %progfiles%, а какие-то умники жёстко привязали систему обновления на C:.
7. В некоторых случаях таблицу по которой ведётся альтер можно переименовать и создать пустую. Альтер таблицы с отложенными данными делается до обновления, либо после.
8. А где у вас всё-таки временной затык? У нас 40 магазинов, 400+ касс. Обновились за неполный день. Самой большой проблемой оказалась административная - админы на магазинах не почистили место, а я не проконтролировал. Сделал выводы - написали вёб форму для расчёта необходимого места на дисках (навроде что на D: должно быть свободно: mysql\data*1.2+5Gb.
9. У нас основная проблема это обслуживание сертификатов и юр.лиц по счетам.

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

Для клиентов у которых нет СГО и развитого маркетинга это просто видимо не особо критично :).

Основная причина этого ускорения - резка чеков :)).

Могу добавить что после пары обновлений я стал сильно против обновлять ВСЕ кассы в ночь - с утра можно получить неработающую Сеть.. :(.

Ещё один момент забыл добавить. При последнем обновлении в mysql ложилось по 2-3 файлика, и базы касс после рестарта клиента начинались чекаться.
И ещё - в некоторых случаях в процессах по два апача запускается, было на 2ух магазинах. В итоге обновление фейлиться. Так же нужно быть внимательным и не сидеть в каталогах обновлений..
Весь процесс обновления должен быть расписан по пунктам. Хотя и знаешь уже наизусть, но очень важно с каждым магазином иметь этот чеклист перед глазами - это здорово ускоряет.

Хороший топик, давайте опытом делиться :)

А я про сервис паки вообще не слова не говорил, только обновление с версии на версию. Особенность сервис пака в том, что в нем нет изменения структуры и таблиц ядра, поэтому он легко ставится и особо не влияет на работоспособность. Как правило, в сервис паке либо доп функциональность не затрагивающая ядро, либо подключение оборудования, т.е. все, что "сбоку". Поэтому сервис пак можно на отдельные кассы повесить. Но обновление на версию, там уже сервис пак вшит в софт.

Нет СГО - это как? Один два магазина? У Монетки не было СГО, господа менеджеры забыли продать, а потом проект на два года открыли, как скриптами воссоздать СГО на нескольких сотнях магазинов, чем закончился проект не знаю, выгнали меня к тому времени.


Не совсем, это 50% успеха, дело в том, что были косячные математики в бонусных схемах, ошибки в алгоритмах СГО, обработка которых иногда уходила далеко за двое суток, а иногда и умирала в процессе обновления СГО. Все исправления можно посмотреть в протоколах изменений и исправлений софта.


Это да :) И чем больше сеть, тем больше проблема. Именно поэтому я рекомендую переходить на софт, в котором данные детские болезни устранены и 3000 касс обновляются автоматом за 2 дня, без участия рук и ног.

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

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

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

Это какой? Было бы очень интересно пощупать и может чему-то поучится.

Это да.. Плюсую :(.

Чек-лист и делал.
Еще не понял почему из под пользователя user (из группы Администраторы) процесс не пошел, а из под пользователя update (из группы Администраторы) прошло.
А еще - в последнем обновлении процентов 50 СМ-ов в логах обновления писал ошибку. А по бд (что-то там ukmversions) - обновилось. Вроде-бы не менеджер обновлений не смог очистить временные папки.

1. Обновление состоит из двух пакетов - sql и файловые операции. В случае облома с файловым пакетом - можно по идее начать с того же места, ликвидировав ошибку.

2. У меня есть правило, что любой новый магазин должен пройти те же обновления, что и все предыдущие.
Это означает что если у меня сейчас 67ая версия, то открывая новый магазин я не буду ставить сразу 67ую. А в начале поставлю 60ую, потом на неё 63ю с сервис паками и только после этого 64,65,66,67 и сп.

Ошибку после которой я так начал делать словил ещё в 40ых версиях. Версия на магазинах (а самое главное - на тестовом стенде!!!) была одна, но одни магазины у меня обновились нормально, а другие - не обновились.
Потому что одни магазины ставились с одной версии, а другие - с другой.

Вот тут мне повезло!
Несколько раз дох СМ.
Ставил "крайнюю" версию, обновлял до нужных СП, а потом прописывал GUID - и СМ сам затягивал все нужное с СГО.
Правда, еще ни разу не было такого, что СМ дох НЕ ИМЕЯ всязи с СГО (т.е. на СГО были все данные на момент смерти СМ-а)