Бесперебойная работа тысяч магазинов «Пятёрочка» во многом зависит от надежного и кастомизированного программного обеспечения. Сейчас в сети используется продукт компании 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 целевую инфраструктуру исключительно под сервер закачки. И совместно с коллегами внедрили дополнительный новый инструмент, который существенно расширил наши возможности.
На текущий момент большая часть задач из нашего плана уже реализована:
В работе остаются задача по внедрению новой проверки магазинов и доработки целевого инструмента обновления.
Дальше больше. Теперь наши усилия направлены на обновление 20000 (+) магазинов за ночь, но это уже будет на новой другой платформе, с новыми инструментами и методами. Об этом мы обязательно расскажем в будущем.
Авторы
Василий Голубев, руководитель группы распространения релизов программного обеспечения #ITX5
Евгений Лапшин, начальник отдела поддержки решений для магазинов #ITX5
Дела давно минувших дней, преданье старины глубокой
Десятилетний период для ИТ в современном мире — это уже история. В 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
voted
Что то не ясно, к чему такие цели и «прорывы»? Вот вообще не видно проблемы 1 миллион магазинов в 1 клик сделать и люди не нужны будут ночью вообще. Может правда в статье не описали сами проблемы которые вы решали и достижение ваши действительно высоки, но не видно этого.
sakhapovi
Зоопарк оборудования, сотни конфигураций под каждую кассу, вечно отваливающееся железо, обновление не только своего софта но и third party драйверов(со своими косяками в тихих инсталляциях и неожиданных ошибках после перезагрузки), одним обновление сегодня нужно, одним ни в коем случае нельзя, у всех разные часовые пояса, у всех есть проходные и непроходне кассы — «которые трогать вот прям сейчас нельзя, а через 1,5 часа можно», у всех есть кассы в заначке, которые «забыли включить» в ночь обновления… Да, есть множество нюансов. Здесь не перечислили, а я так, галопом вспомнил потирая свой горящий зад.
voted
Вот обычный Jenkins вроде со всем этим должен справиться, медленно, надо больше касс обработать — берем больше нод. У нас моменты были (когда надо много и сразу) — через API на Digital Ocean запрос — берем 2 000 виртуальных серверов из образа нод для обработки, и вот у нас кластер из 2 000 машин выполняет наше задание, а через 3 минуты (при таком распаралеливании 3 минуты задача выполняется) — посылаем запрос и у нас их больше нет (мы за них не платим). 3 * 3000 = 6 000 минут машинонного времени = 0.7$ (1 час стоит $0.007, 100 часов надо оплатить). Если надо можно и 10 000 или даже 100 000 машин взять (честно не пробовал, но кроме лимитов заложеных в тарифный план не вижу проблем).
gecube
Это все красиво звучит в теории.
На практике… Все значительно "веселее"
Те же кассы. Я не спец, но я не понимаю, почему нельзя было их держать включенными 24/7 (пожарная безопасность?) или придумать способ их включать удаленно (vpro? Wake-on-lan? Реле с сетевым управлением )))
Sergey-S-Kovalev
На серверах виртуализация. Базовод отдельно. Сервер приложений отдельно. Грустно когда нем же и видеонаблюдение.
На кассах виртуализацию не видел, но видел VDI, но с ним сложно из-за зоопарка весового и прочего оборудования.
В времена, когда ТСД с вафлей еще толком не было, мы мутили ревизорам нетбуки в рюкзачках к которым были подключены обыкновенные проводные сканеры штрихкодов. Ревизоры чекали остатки, а прога в нетбуке формировала отчет который уже сравнивался с тем что по базе.
Золотые времена костылей, колхоза и импровизации на ходу. Сейчас как то скучно.
X5RetailGroup Автор
Основная проблема – это достижение баланса между количеством обновляемых конфигурационных единиц (касс/серверов) и безопасности обновления для Бизнес-процессов. Безопасность достигается наличием строго регламентированной последовательности действий: подготовки системы, предварительных проверок и исключения объектов из обновления, самого процесса обновления, комплексной проверки, четкого порядка действий по «реанимации» проблемной кассы/сервера в срок, остающийся до открытия магазина утром.
Прорыв, необходимый компании – это трехсоткратное увеличение количества объектов, в отношении которых возможно безопасное обновление силами 1 сотрудника.