Не спать! Как мы научились тиражировать релизы на 12000 касс за ночь

    Бесперебойная работа тысяч магазинов «Пятёрочка» во многом зависит от надежного и кастомизированного программного обеспечения. Сейчас в сети используется продукт компании GK SOFTWARE, который совершенствовался от коробочной версии до разработки кода внутри X5. В нашей статье мы расскажем, какой путь прошли в установке релизов, обеспечивая рост бизнеса компании от единичных магазинов на новом ПО до текущих 15000.



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


    Десятилетний период для ИТ в современном мире — это уже история. В 2009 первые магазины сети «Пятёрочка» только перешли на GK, появились первые задачи по обновлению ПО. Процесс выглядел примерно так: полностью ручной труд, анализ логов «глазами» в каждом магазине, постоянные проблемы с запуском ПО — то на кассе перестает инициализироваться оборудование, то службы GK не стартуют на сервере.

    По мере стабилизации системы GK и развития инструментов обновления мы вышли на deploy через центральный компонент системы GK — Storemanager- в объёме 100 — 200 магазинов за ночь (на одного сотрудника). Тогда это считалось большим достижением. Для обеспечения скорости обновления в 1000 магазинов уже требовалось привлечение аутстаффа — только командой из 6 человек в ночь мы могли выйти на требуемое количество торговых точек. Чтобы создать задание на обновление требовалось руками «прокликивать» каждый магазин. Каждый джоб содержал всего 50 объектов, так как была вероятность из-за внутренней ошибки потерять все статусы после обновления и тогда бы нужна была уже полная ручная проверка.



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

    На 2014 год трудоемкость обновления на 1 человека в ночь составляла 150 магазинов.

    Первый прорыв


    Такая ситуация со скоростью и стоимостью обновления не могла устраивать ни нас, ни бизнес. Важнейшим направлением работы стал процесс совершенствования и автоматизации процесса для обеспечения быстрой и качественной «доставки» изменений в магазины, чтобы помогать бизнесу эффективно решать поставленные задачи.

    Так как код GK не принадлежал компании X5, мы не могли самостоятельно делать доработки Storemanager, менять процесс и исправлять ошибки. Поэтому совместно с подрядчиками мы начали работу над разработкой «с нуля» технологичного альтернативного инструмента, который мы назвали “Booster”.

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

    В “Booster” появился единый список всех магазинов в дашборде, предпроверки и статусы по каждому этапу и первая примитивная автоматизированная проверка после обновления.



    Реализация проекта “Booster” позволила сократить трудозатраты в 6 раз и обновлять примерно 1000 магазинов в ночь силами одного сотрудника (к концу 2016). На тот момент это был небывалый прорыв.

    Развитие успеха


    Следующий этап должен был закрепить и развить наш успех. Мы запустили пул доработок, которые назвали “Booster2”.

    Платформа была перенесена на новое железо, был полностью переработан интерфейс пользователя, мы избавились от торможений. Внедрили новые проверки и статусы по каждому этапу.



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

    Актуализированный “Booster” позволил выйти на обновление 1500 магазинов на одного сотрудника в ночь в конце 2017- начале 2018 года.

    Вперед к новым вершинам


    1500 магазинов в ночь — это хорошо, мы легко справляемся с графиком релизов, берём в установку дополнительные спринты, готовы обеспечить исправление ошибок и устанавливать в сумме до 6 сборок по кассе и бэк-офису, но задача нашей компании – уже сегодня построить ритейл следующего поколения. Процессным, техническим и технологическим фундаментом цифровизации нашего бизнеса является, в том числе, скорость разработки и распространения новых версий ПО. И в марте 2019 года была поставлена амбициозная задача – уже к осени достичь обновления 3000 серверов и 12000 касс за одну ночь. Мы абстрагировались от наших текущих реалий, ещё раз провели большую аналитическую работу по определению узких мест в процессе. Были выявлены задачи, которые требуют автоматизации, технических доработок, разработки нового специализированного ПО, а также общего переосмысления. Кроме того, мы сформировали пул организационных задач.

    В результате родился внутренний ИТ-проект, составлена дорожная карта, рассчитан бюджет, определены контрольные точки, чётко очерчен круг подразделений и подрядчиков для внутреннего и внешнего взаимодействия.

    Дорожная карта

    Подробнее остановимся на сформированных задачах. Мы выделили 3 направления:

    • задачи по уменьшению рисков;
    • административные и организационные задачи;
    • задачи на увеличение обновляемых магазинов за сутки.

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

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

    Новый инструмент проверки позволяет быстро определять работоспособность магазина в целом, формировать отчёт по большему количеству параметров и сразу показывать сотруднику поддержки те объекты, которые не смогут открыться утром после обновления. Мы анализируем как запуск программного обеспечения, так и этапы его загрузки. Проверяем формирование базы для кассы на стороне бэк-офиса, инициализацию оборудования, выход кассового ПО на режим регистрации кассира и т.д. Процесс строится на новейшей в нашей компании системе – «Бизнес-мониторинг» с использованием современного стека технологий (Filebeat, Kafka, ClickHouse, Grafana).

    В инструменте (системе) комплексной подготовки магазинов к обновлению мы объединили все разрозненные скрипты проверки, которые могли находиться даже на разных серверах. Подключили автоматические сценарии исправления типовых ошибок (мало места, нет нужных прав и т.д.) и рассылку на ответственных сотрудников по разным направлениям, если автоматически проблема не устраняется. Добавили робота, который «без устали» шерстит заявки в MFSM и исключает из обновления кассы у круглосуточных магазинов. Такой робот каждый день спасает более трёх часов рабочего времени сотрудника.

    Роботизированный инструмент по учету работ на сетевой инфраструктуре: обеспечивает разбор совершенно разрозненных писем от провайдеров, выявляя по указанным адресам SAP коды магазинов и загружая данные по дате и времени работ в базу данных. Далее на основе этой информации актуализируется график тиража. Так постепенно исключаются моменты, когда по 300 магазинов остаются без связи, а мы не можем получить статус обновления или проверки.

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

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

    Решение — дополнительное обучение, добавили в график работы выходные дни, настроили взаимодействие со всеми линиями. Деплой в выходные дни.

    Мы провели внутреннее обучение сотрудников, обеспечив взаимозаменяемость и возможность перераспределения любых задач. Также был пересмотрен график работы команды — всех сотрудников перевели на сменную работу в ночь, что создало возможность для обеспечения непрерывного обновления. Эту опцию мы реализовали уже в этом году. Теперь обновления GK проходят 7 дней в неделю без привлечения дополнительных штатных единиц.

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

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

    Также в рамках проекта мы решали, какой инструмент должен стать целевым для обновления, а какой необходимо развивать дальше. Целевым инструментом был выбран Storemanager, так как с приобретением исходного кода GK, мы самостоятельно смогли разрабатывать и совершенствовать штатные инструменты.

    С момента запуска проекта мы определили шаги по внедрению всего функционала “Booster” в Storemanager и в этом году сформировали дополнительные требования к доработкам для обеспечения обновления требуемого количества магазинов.

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

    Что уже получилось


    На текущий момент большая часть задач из нашего плана уже реализована:

    • Апгрейд и улучшение системы прокачки.
    • Сокращение размеров дистрибутивов GK.
    • Административные и организационные задачи в команде.
    • Автоматизация подготовки магазинов к обновлению.
    • Учёт сетевых работ.

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



    Что же дальше?


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

    Авторы

    Василий Голубев, руководитель группы распространения релизов программного обеспечения #ITX5
    Евгений Лапшин, начальник отдела поддержки решений для магазинов #ITX5
    X5 Retail Group
    Все о цифровой трансформации ритейла

    Comments 24

      +2
      Что то не ясно, к чему такие цели и «прорывы»? Вот вообще не видно проблемы 1 миллион магазинов в 1 клик сделать и люди не нужны будут ночью вообще. Может правда в статье не описали сами проблемы которые вы решали и достижение ваши действительно высоки, но не видно этого.
        –1
        Зоопарк оборудования, сотни конфигураций под каждую кассу, вечно отваливающееся железо, обновление не только своего софта но и third party драйверов(со своими косяками в тихих инсталляциях и неожиданных ошибках после перезагрузки), одним обновление сегодня нужно, одним ни в коем случае нельзя, у всех разные часовые пояса, у всех есть проходные и непроходне кассы — «которые трогать вот прям сейчас нельзя, а через 1,5 часа можно», у всех есть кассы в заначке, которые «забыли включить» в ночь обновления… Да, есть множество нюансов. Здесь не перечислили, а я так, галопом вспомнил потирая свой горящий зад.
          +2
          • Берем обычный 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 машин взять (честно не пробовал, но кроме лимитов заложеных в тарифный план не вижу проблем).
            +1

            Это все красиво звучит в теории.
            На практике… Все значительно "веселее"
            Те же кассы. Я не спец, но я не понимаю, почему нельзя было их держать включенными 24/7 (пожарная безопасность?) или придумать способ их включать удаленно (vpro? Wake-on-lan? Реле с сетевым управлением )))

              +1
              вы же знаете какие кассы надо обновлять
              Могут и не знать. Маркетинг может перевести магазин в круглосуточный, если увидит в этом смысл в любой момент, и ровно так он можете перестать им быть. Они считают, что ИТ сервисы всегда 100% доступны и это норма.
              Берем CDN
              Доставку можно растянуть на несколько дней, а вот релиз должен быть идеально раскатан в строго определенный промежуток времени.
              Менеджер знает какую кассу сейчас нельзя трогать
              На местах есть директор магазина, кассиры/операторы и разнорабочие/грузчики. Там нет «менеджеров». Оператор делает приемку товара утром, занимается выкладкой днем и встает за кассы горячего резерва вечером в час пик или в любое время по сигналу с кассовой зоны. В магазинах часто очень большая текучка и низкая дисциплина. Директор может не смочь прочитать письмо наполненное красными надписями 48 размера. И вообще им там некогда про ваши ИТшные проблемы думать.

              На серверах виртуализация. Базовод отдельно. Сервер приложений отдельно. Грустно когда нем же и видеонаблюдение.

              На кассах виртуализацию не видел, но видел VDI, но с ним сложно из-за зоопарка весового и прочего оборудования.
              В времена, когда ТСД с вафлей еще толком не было, мы мутили ревизорам нетбуки в рюкзачках к которым были подключены обыкновенные проводные сканеры штрихкодов. Ревизоры чекали остатки, а прога в нетбуке формировала отчет который уже сравнивался с тем что по базе.

              Золотые времена костылей, колхоза и импровизации на ходу. Сейчас как то скучно.
            +1
            Основная проблема – это достижение баланса между количеством обновляемых конфигурационных единиц (касс/серверов) и безопасности обновления для Бизнес-процессов. Безопасность достигается наличием строго регламентированной последовательности действий: подготовки системы, предварительных проверок и исключения объектов из обновления, самого процесса обновления, комплексной проверки, четкого порядка действий по «реанимации» проблемной кассы/сервера в срок, остающийся до открытия магазина утром.
            Прорыв, необходимый компании – это трехсоткратное увеличение количества объектов, в отношении которых возможно безопасное обновление силами 1 сотрудника.
            +1
            А что Вы понимаете под термином «обновление касс»? В моём случае, всё упирается в сервисную организацию, которая приедет и перепрошьёт кассу под новое ПО.
              +2
              Автор написал не про Контрольно-Кассовую-Машину, которая выбивает чеки, а про компьютер к которому подключены весы, та же ККМ, и куча другого оборудования.
                +1
                Под непосредственно обновлением касс подразумевается доставка дистрибутивов приложения торгового программного обеспечения до каждой локальной конфигурационной единицы (сервер/касса), распаковка, запуск и успешное прохождение процесса инсталляции новой версии приложения. Все работы проводятся удаленно без выезда специалистов в магазин.

                  0
                  Про перенос ПО в облако не задумывались? Решит проблему с обновлением и сохранностью данных, на POS будет запускаться только сервер оборудования и тонкий клиент. Или сильно завязаны на текущее ПО?
                    0

                    А теперь подсчитайте бюджет такого мероприятия + вопрос каналов связи где-нибудь на отшибе

                      0
                      Я думаю, бюджет будет меньше, чем стоимость использующегося в настоящий момент лицензий ПО. Вопрос связи с удаленными точками действительно острый. Но время идет, интернет уже стал почти как электричество, думаю в ближайшие несколько лет решат.
                      +1
                      Естественно мы задумываемся про облачные решения. В наших планах реализовать пилот по переводу пока одной кассы в магазине в облако. Главная проблема облачных решений – доступность, у нас обширная география расположения магазинов и, к сожалению, не везде возможно обеспечить качество и доступность каналов связи на высоком уровне.
                        0
                        Да, пока без гибридного решения с использованием оффлайн-касс в местах с нестабильной связью не обойтись. Но если процент таких точек не очень большой, то выгода от перевода кассы в облако может быть значительной. Особенно с учетом того, что ФН тоже может быть в облаке, а на точках только чековые принтеры.
                          +2
                          Онлайн кассы хорошо идут в бутиках с рюшечками, ибо там только планшет с онлайн кассой и терминал оплаты и нет потока покупателей.

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

                          Мы все любим облака, но в масштабах Х5, я уверен, дешевле и безопаснее для бизнеса держать свой ЦОД.
                            0
                            ККМ еще забыл.
                              +1
                              Ну и при падении сервера или связи касса может работать оффлайн сутками, при восстановлении связи все данные благополучно попадут на сервер. Достаточно представить обрыв связи в крупном продуктовом магазине, оснащённом только облачными кассами в новогоднюю ночь.
                    0

                    В своей системе Бизнес-мониторинг вы используете kafka, при том что штатным транспортом является sap pi. Почему пошли на использование новой технологии, а не старой-доброй-проверенной?

                      +1
                      Речь идёт меньше про кассу как железку, а больше про АРМ кассира, обвешанный связкой с внутренней учётной системой, моделями CRM, склада и чёрта в ступе.
                      При этом физически на разном железе, подключённый к разным моделям касс и кассового оборудования — x5 спецом покупает разное оборудование у разных поставщиков, чтобы не подсесть на одного поставщика. Это позволяет получать лучшую цену, но очень разнообразную среду, плюс есть ещё разные поколения разного железа, т.к. закупки волнообразные.

                      p.s. Не сотрудник X5, но закрывал проект обновления кассового ПО в одном крупном е-коме, потому хорошо понимаю описанную кухню.
                        +1
                        X5RetailGroup,
                        суть статьи сводится к тому что вместо ручного обновления касс (человек с флешкой объезжает магазины) вы перешли к клиент-серверной, когда касса клиент по событию обращается к серверу за запуском программы обновления? без раскрытия тех. данных
                          +1
                          Обновление торгового ПО с выездом в магазин не используется с того момента, как счет магазинов Компании пошел на сотни.
                          Суть статьи сводится к описанию кардинального увеличения скорости и безопасности распространения релизов торгового ПО путем автоматизации этапов работ, оптимизации и изменения технических и организационных процессов.
                          С точки зрения архитектуры, используется клиент-серверная схема взаимодействия кассы и локального сервера в магазине.
                          0

                          Как откат при сбое реализован, или если надо отозвать версию?


                          Если рядом два магазина стоят (физически в городе), оба обновятся, или, на всякий случай, сначала один, а при успехе — второй?

                            +1
                            Откат на предыдущую версию реализован восстановлением из бэкапа. Процесс обновления включает в себя бэкапирование предыдущей версии ПО на сервере и на каждой кассе, что позволяет нам быстро и с почти 100% успешностью восстановить работоспособность магазина. Восстановить можно как отдельную кассу, так и весь магазин в целом. Магазины, которые не сформировали бэкап, исключаются из обновления.

                            Практически 100% восстановление работоспособности магазина при неудачном обновлении, позволяет нам не учитывать количество магазинов в конкретном населенном пункте. “На всякий случай”, мы обновляем половину касс в магазинах, на стадии пилота новой версии ПО, особенно в его первой фазе. Это позволяет нам исключить остановку продаж, в случае форс мажорных ситуаций.

                            +1
                            Впечатляет! 15 лет работал в ритейле, занимался кассовым ПО (УКМ4). Обновления очень много крови попили и седых волос добавили.

                            Only users with full accounts can post comments. Log in, please.