Комментарии 24
Что то не ясно, к чему такие цели и «прорывы»? Вот вообще не видно проблемы 1 миллион магазинов в 1 клик сделать и люди не нужны будут ночью вообще. Может правда в статье не описали сами проблемы которые вы решали и достижение ваши действительно высоки, но не видно этого.
Зоопарк оборудования, сотни конфигураций под каждую кассу, вечно отваливающееся железо, обновление не только своего софта но и third party драйверов(со своими косяками в тихих инсталляциях и неожиданных ошибках после перезагрузки), одним обновление сегодня нужно, одним ни в коем случае нельзя, у всех разные часовые пояса, у всех есть проходные и непроходне кассы — «которые трогать вот прям сейчас нельзя, а через 1,5 часа можно», у всех есть кассы в заначке, которые «забыли включить» в ночь обновления… Да, есть множество нюансов. Здесь не перечислили, а я так, галопом вспомнил потирая свой горящий зад.
- Берем обычный CI/CD, добавляем правила (вы же знаете какие кассы надо обновлять, какие нет, где какие часовые пояса и т.д. это всё надо 1 раз описать).
- Берем CDN (что бы уменьшить влияние скорости сети) или вообще torrent'ы за основу сети.
- Вводим сервис для ручного переопределения расписания (Менеджер знает какую кассу сейчас нельзя трогать, а через 1,5 часа можно. Есть окошко апдейтов например с 2 до 4 утра, если менеджер исключения для этой кассы не выставил к этому времени — обновляем её).
- Насчёт касс которые «забыли включить» — я конечно не знаю что вы в этих случаях делаете — но я думаю можно записать сообщение с просьбой включить кассу и в базу касс добавить номер по которому через астерикс позвонить и «попросить включить» ответсвенного.
Вот обычный Jenkins вроде со всем этим должен справиться, медленно, надо больше касс обработать — берем больше нод. У нас моменты были (когда надо много и сразу) — через API на Digital Ocean запрос — берем 2 000 виртуальных серверов из образа нод для обработки, и вот у нас кластер из 2 000 машин выполняет наше задание, а через 3 минуты (при таком распаралеливании 3 минуты задача выполняется) — посылаем запрос и у нас их больше нет (мы за них не платим). 3 * 3000 = 6 000 минут машинонного времени = 0.7$ (1 час стоит $0.007, 100 часов надо оплатить). Если надо можно и 10 000 или даже 100 000 машин взять (честно не пробовал, но кроме лимитов заложеных в тарифный план не вижу проблем).
Это все красиво звучит в теории.
На практике… Все значительно "веселее"
Те же кассы. Я не спец, но я не понимаю, почему нельзя было их держать включенными 24/7 (пожарная безопасность?) или придумать способ их включать удаленно (vpro? Wake-on-lan? Реле с сетевым управлением )))
вы же знаете какие кассы надо обновлятьМогут и не знать. Маркетинг может перевести магазин в круглосуточный, если увидит в этом смысл в любой момент, и ровно так он можете перестать им быть. Они считают, что ИТ сервисы всегда 100% доступны и это норма.
Берем CDNДоставку можно растянуть на несколько дней, а вот релиз должен быть идеально раскатан в строго определенный промежуток времени.
Менеджер знает какую кассу сейчас нельзя трогатьНа местах есть директор магазина, кассиры/операторы и разнорабочие/грузчики. Там нет «менеджеров». Оператор делает приемку товара утром, занимается выкладкой днем и встает за кассы горячего резерва вечером в час пик или в любое время по сигналу с кассовой зоны. В магазинах часто очень большая текучка и низкая дисциплина. Директор может не смочь прочитать письмо наполненное красными надписями 48 размера. И вообще им там некогда про ваши ИТшные проблемы думать.
На серверах виртуализация. Базовод отдельно. Сервер приложений отдельно. Грустно когда нем же и видеонаблюдение.
На кассах виртуализацию не видел, но видел VDI, но с ним сложно из-за зоопарка весового и прочего оборудования.
В времена, когда ТСД с вафлей еще толком не было, мы мутили ревизорам нетбуки в рюкзачках к которым были подключены обыкновенные проводные сканеры штрихкодов. Ревизоры чекали остатки, а прога в нетбуке формировала отчет который уже сравнивался с тем что по базе.
Золотые времена костылей, колхоза и импровизации на ходу. Сейчас как то скучно.
Основная проблема – это достижение баланса между количеством обновляемых конфигурационных единиц (касс/серверов) и безопасности обновления для Бизнес-процессов. Безопасность достигается наличием строго регламентированной последовательности действий: подготовки системы, предварительных проверок и исключения объектов из обновления, самого процесса обновления, комплексной проверки, четкого порядка действий по «реанимации» проблемной кассы/сервера в срок, остающийся до открытия магазина утром.
Прорыв, необходимый компании – это трехсоткратное увеличение количества объектов, в отношении которых возможно безопасное обновление силами 1 сотрудника.
Прорыв, необходимый компании – это трехсоткратное увеличение количества объектов, в отношении которых возможно безопасное обновление силами 1 сотрудника.
А что Вы понимаете под термином «обновление касс»? В моём случае, всё упирается в сервисную организацию, которая приедет и перепрошьёт кассу под новое ПО.
Автор написал не про Контрольно-Кассовую-Машину, которая выбивает чеки, а про компьютер к которому подключены весы, та же ККМ, и куча другого оборудования.
Под непосредственно обновлением касс подразумевается доставка дистрибутивов приложения торгового программного обеспечения до каждой локальной конфигурационной единицы (сервер/касса), распаковка, запуск и успешное прохождение процесса инсталляции новой версии приложения. Все работы проводятся удаленно без выезда специалистов в магазин.
Про перенос ПО в облако не задумывались? Решит проблему с обновлением и сохранностью данных, на POS будет запускаться только сервер оборудования и тонкий клиент. Или сильно завязаны на текущее ПО?
А теперь подсчитайте бюджет такого мероприятия + вопрос каналов связи где-нибудь на отшибе
Естественно мы задумываемся про облачные решения. В наших планах реализовать пилот по переводу пока одной кассы в магазине в облако. Главная проблема облачных решений – доступность, у нас обширная география расположения магазинов и, к сожалению, не везде возможно обеспечить качество и доступность каналов связи на высоком уровне.
Да, пока без гибридного решения с использованием оффлайн-касс в местах с нестабильной связью не обойтись. Но если процент таких точек не очень большой, то выгода от перевода кассы в облако может быть значительной. Особенно с учетом того, что ФН тоже может быть в облаке, а на точках только чековые принтеры.
Онлайн кассы хорошо идут в бутиках с рюшечками, ибо там только планшет с онлайн кассой и терминал оплаты и нет потока покупателей.
В рознице всегда поток покупателей и куда больше набор оборудования на кассе:
Весы, ручной сканер штрихкодов, стационарный сканер, денежный ящик, терминал оплаты. Можно брать комплексное решение, где все одной пачкой, но это вендорлок и в рамках большой сети это только если самим все разрабатывать от железа и до софта.
Мы все любим облака, но в масштабах Х5, я уверен, дешевле и безопаснее для бизнеса держать свой ЦОД.
В рознице всегда поток покупателей и куда больше набор оборудования на кассе:
Весы, ручной сканер штрихкодов, стационарный сканер, денежный ящик, терминал оплаты. Можно брать комплексное решение, где все одной пачкой, но это вендорлок и в рамках большой сети это только если самим все разрабатывать от железа и до софта.
Мы все любим облака, но в масштабах Х5, я уверен, дешевле и безопаснее для бизнеса держать свой ЦОД.
В своей системе Бизнес-мониторинг вы используете kafka, при том что штатным транспортом является sap pi. Почему пошли на использование новой технологии, а не старой-доброй-проверенной?
Речь идёт меньше про кассу как железку, а больше про АРМ кассира, обвешанный связкой с внутренней учётной системой, моделями CRM, склада и чёрта в ступе.
При этом физически на разном железе, подключённый к разным моделям касс и кассового оборудования — x5 спецом покупает разное оборудование у разных поставщиков, чтобы не подсесть на одного поставщика. Это позволяет получать лучшую цену, но очень разнообразную среду, плюс есть ещё разные поколения разного железа, т.к. закупки волнообразные.
p.s. Не сотрудник X5, но закрывал проект обновления кассового ПО в одном крупном е-коме, потому хорошо понимаю описанную кухню.
При этом физически на разном железе, подключённый к разным моделям касс и кассового оборудования — x5 спецом покупает разное оборудование у разных поставщиков, чтобы не подсесть на одного поставщика. Это позволяет получать лучшую цену, но очень разнообразную среду, плюс есть ещё разные поколения разного железа, т.к. закупки волнообразные.
p.s. Не сотрудник X5, но закрывал проект обновления кассового ПО в одном крупном е-коме, потому хорошо понимаю описанную кухню.
X5RetailGroup,
суть статьи сводится к тому что вместо ручного обновления касс (человек с флешкой объезжает магазины) вы перешли к клиент-серверной, когда касса клиент по событию обращается к серверу за запуском программы обновления? без раскрытия тех. данных
суть статьи сводится к тому что вместо ручного обновления касс (человек с флешкой объезжает магазины) вы перешли к клиент-серверной, когда касса клиент по событию обращается к серверу за запуском программы обновления? без раскрытия тех. данных
Обновление торгового ПО с выездом в магазин не используется с того момента, как счет магазинов Компании пошел на сотни.
Суть статьи сводится к описанию кардинального увеличения скорости и безопасности распространения релизов торгового ПО путем автоматизации этапов работ, оптимизации и изменения технических и организационных процессов.
С точки зрения архитектуры, используется клиент-серверная схема взаимодействия кассы и локального сервера в магазине.
Суть статьи сводится к описанию кардинального увеличения скорости и безопасности распространения релизов торгового ПО путем автоматизации этапов работ, оптимизации и изменения технических и организационных процессов.
С точки зрения архитектуры, используется клиент-серверная схема взаимодействия кассы и локального сервера в магазине.
Как откат при сбое реализован, или если надо отозвать версию?
Если рядом два магазина стоят (физически в городе), оба обновятся, или, на всякий случай, сначала один, а при успехе — второй?
Откат на предыдущую версию реализован восстановлением из бэкапа. Процесс обновления включает в себя бэкапирование предыдущей версии ПО на сервере и на каждой кассе, что позволяет нам быстро и с почти 100% успешностью восстановить работоспособность магазина. Восстановить можно как отдельную кассу, так и весь магазин в целом. Магазины, которые не сформировали бэкап, исключаются из обновления.
Практически 100% восстановление работоспособности магазина при неудачном обновлении, позволяет нам не учитывать количество магазинов в конкретном населенном пункте. “На всякий случай”, мы обновляем половину касс в магазинах, на стадии пилота новой версии ПО, особенно в его первой фазе. Это позволяет нам исключить остановку продаж, в случае форс мажорных ситуаций.
Практически 100% восстановление работоспособности магазина при неудачном обновлении, позволяет нам не учитывать количество магазинов в конкретном населенном пункте. “На всякий случай”, мы обновляем половину касс в магазинах, на стадии пилота новой версии ПО, особенно в его первой фазе. Это позволяет нам исключить остановку продаж, в случае форс мажорных ситуаций.
Впечатляет! 15 лет работал в ритейле, занимался кассовым ПО (УКМ4). Обновления очень много крови попили и седых волос добавили.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Не спать! Как мы научились тиражировать релизы на 12000 касс за ночь