Перед стартом у нас была дублированная IT-инфраструктура двух сетей магазинов, состоящая из 955 розничных точек, 30 000 сотрудников и трёхсот тысяч чеков в день.
Теперь, когда все успешно запущено и работает, мы хотим поделиться историей — как нам удалось сделать этот проект.
В этой публикации (первой из двух, чем черт не шутит, может и трех) мы презентуем вам некоторые данные по проведённым работам, подробнее о которых можно узнать на SAP ME meetup в Москве.
Полгода проектировки, полгода написания кода, полгода оптимизации и тестирования. И 12 часов, чтобы переключить систему, обслуживающую 450 магазинов «Эльдорадо» по всей России, при этом не нарушив работу магазинов «М.Видео». Также мы без малейшего даунтайма переключили сайт «Эльдорадо» с милионным трафиком.
Может звучать нереально, но мы это сделали! Подробности под катом.
В процессе объединения компаний «М.Видео» и «Эльдорадо» перед нами встала задача оптимизации расходов и объединения бэкенд-процессов двух разных компаний.
Наверное, это можно назвать удачей или совпадением — оба ритейлера для автоматизации бэкенд-процессов пользовались решением SAP ERP. Нам пришлось заниматься адаптацией фронтэнд-решений к новому бэкенду и оптимизацией производительности решений «М.Видео» в связи с возросшей в 2 раза нагрузкой.
Функционально задача была разбита на три (на самом деле четыре) этапа:
- Дизайном, проектированием архитектуры, оргструктуры и выбором целевой модели занимались наш трансформационный офис с консультантами McKinsey.
После анализа ряда показателей уже работающего бэкенда двух компаний за основу для разработки единой системы был взят бэкенд «М.Видео». Одним из главных критериев, по которым был сделан выбор — эффективность компании в целом, бОльшая выручка и прибыль при более низких затратах на бизнес-операцию.
На этап анализа и проектирования ушло около шести месяцев, миллиарды нервных клеток руководителей подразделений и технических специалистов, и было выпито очень-очень много литров кофе. - Реализация в коде. Приведем немного цифр по итогам проекта:
- 2 000 маршрутов в день, планируемых с помощью модуля логистики.
- 30 000 пользователей фронт и бэкенда.
- 270 000 товаров на складах объединённого предприятия.
Около 300 000 чеков, обрабатываемых системой за день, которые впоследствии хранятся до пяти лет в целях обеспечения покупателей гарантией, а также в целях маркетинговых исследований.
Расчет зарплат, авансов и премий для 30 000 сотрудников каждый месяц.
В проекте была задействована команда из 220 технических специалистов, которые работали на протяжении десяти месяцев. Путем несложных арифметических подсчётов получим две цифры, наглядно отображающие масштаб проделанной работы: 90 000 человеко/дней и… 720 000 часов работы.
Далее — оптимизация отдельных подпрограмм модулей SAP, порядка сотни подпрограмм было ускорено в пять-шесть раз путём оптимизации кода и запросов в БД.
По отдельным кейсам, нам удалось сократить время выполнения программы с шести часов до десяти минут с помощью оптимизации запросов к СУБД - Третий этап, пожалуй, самый сложный — тестирование. Он состоял из нескольких циклов. Для их проведения мы собрали команду из 200 сотрудников, они были задействованы в функциональном, интеграционном и регрессионном тесте.
Отдельным пунктом опишем нагрузочные тесты, они состояли из 15 циклов для SAP ERP, модулей POS DM, PI.
По результатам каждого теста проводилась оптимизация кода и параметров СУБД, а также индексов баз данных (они у нас работают на SAP HANA, часть на Oracle).
После всех нагрузочных тестов к расчетным вычислительным мощностям было добавлено ещё порядка 20% процентов, а также сформирован резерв примерно такого же (20%) объема.
Ко всему прочему, после проведения вышеописанных циклов начался анализ 100 наиболее ресурсоёмких программ, по результатам которого мы отрефакторили код и ускорили их работу в среднем в пять раз (что в очередной раз подтверждает важность рефакторинга и оптимизации кода).
Последним из проводимых тестов стал «cut over». Для него была создана отдельная тестовая зона, которая копировала нашу продуктивную среду. Тестирование «сut over» мы проводили дважды, каждый раз на это уходило порядка двух недель, в которые мы проводили замеры скорости выполнения операций таких как: перенос настроек программ из тестовой зоны в продуктивную, загрузка открытых позиций по запасам товаров и периоды недоступности операций. - И четвертый этап — непосредственный запуск после прохождения тестов. Задача стояла, прямо скажем, сложная: за 12 часов переключить порядка 450 магазинов по всей стране и большой сайт, и при этом не остановить продажи.
В ночь с 24 на 25 февраля, команда из 50 специалистов нашей компании и ещё около 40 сотрудников партнёров-консультантов заступила на «вахту» в офисе, и началась магия перехода. О ней мы подробно расскажем на нашем meetup’е, а после вторую статью посвятим техническим подробностям нашей магии SAP.
Результаты.
Итак, результатом работы стало увеличение таких показателей как:
- Нагрузка на бэкенд увеличилась приблизительно вдвое.
- Количество чеков в день увеличилось на 50% с 200 тысяч до 300 тысяч.
- Нагрузка на бэкенд увеличилась вдвое.
- По модулю расчета зарплат количество сотрудников увеличилось с 15 тысяч до 30 тысяч человек.
Обо всех технических подробностях мы будем рассказывать на нашем SAP митапе в Москве, который состоится 6 июня в офисе «М.Видео-Эльдорадо». Эксперты поделятся опытом внедрения. По результатам встречи молодые специалисты смогут попасть на оплачиваемую стажировку в компанию с перспективой дальнейшего трудоустройства.
Узнать подробности и зарегистрироваться можно по этой ссылке
Комментарии (13)
0sya
06.06.2019 10:27В проекте была задействована команда из 300 технических специалистов, которые работали на протяжении десяти месяцев. Путем несложных арифметических подсчётов получим две цифры, наглядно отображающие масштаб проделанной работы: 90 000 человеко/дней и… 720 000 часов работы.
Не получим 90000 человеко-дней. Получим приблизительно на треть меньше.
Не верю, что 300 специалистов 10 месяцев без выходных работали.
Кстати, а почему вы людей на дни делите? Они что, торт?
be_a_dancer
06.06.2019 17:32+1Я выскажу свое, сугубо субъективное мнение. Проблема этого материала в том, что он состоит только из воды с вкраплением отдельно взятых и не особо связанных фактов. Вопрос в том, а что конкретно хотели таким материалом донести? То, что вы смогли слить две больших разрозненных системы в одну? Молодцы. Поработали, постарались. А поделиться архитектурой этих систем и рассказать в чем конкретно были сложности и какие были подводные камни?
У меня есть ощущение, что я прочитал отчет менеджера, который выпрашивает повышение зарплаты у директора. Много громких слов, абстрактные обозначения (значительно, сильно и другие подобные слова без особой конкретики было-стало), использование нагоняющих мистику фраз и подобное.
ИМХО. Статья несет два посыла: "придите к нам на конференцию, мы вас еще напоим водичкой" и "смотрите, какие мы крутые".
P. S. Прошу прощения за агрессивный тон комментария. Не претендую на истину в последней инстанции — личное мнение.
Leon_aka_KoHb
07.06.2019 20:30+1Я как автор этого материала, не могу не согласиться с Вами, дали очень мало данных для написания, и очень много воды. Так что могу сказать видя ситуацию «изнутри», да Ваше ИМХО верно по всем пунктам.
be_a_dancer
07.06.2019 20:41А вот за этот ответ — уважение. Признать ошибку это уже многое. И все же, на мой взгляд, необходимо доносить до маркетологов информацию о том, что подобные материалы можно публиковать на неспециализированных платформах, вроде Яндекс.Дзена, но никак не на ресурсе, посвященном IT, где львиная доля посетителей — разработчики различного уровня, желающие более качественного раскрытия материала. В общем-то говоря, выдает небольшую некомпетентность специалистов, не учитывающих целевую аудиторию.
P.S. Надеюсь, что второй материал из серии раскроет информацию подробнее.Leon_aka_KoHb
07.06.2019 23:01К сожалению, очень сложно взаимодействовать, как привлеченный автор, с большой и бюрократизированной структурой. Я тоже надеюсь, что вскоре будет расширенный материал, для Xабра. Одно согласование интервью с «верховными SAP'ерами» отожрало неделю времени, а потом оставалось три дня на написание и редактуру материала.
be_a_dancer
08.06.2019 09:47Здесь могу ответить только примерно так: вас привлекли, как профессионала для того, чтобы сделать свою работу. Также, как привлекают программистов, дизайнеров и так далее. Вы, как специалист в определенной области знаете ее гораздо лучше, чем все маркетологи и директора вместе взятые. Следовательно, и вопрос следует ставить так: либо вы доверяете и я делаю так, как считаю правильным с точки зрения знаний и опыта, а вы способствуете этому, либо мы делаем так, как сказали вы и получаем негатив от потребителей контента. При этом, естественно, за основу берется пожелание заказчика, то есть делать что-то абстрактное, естественно не нужно.
alexpaknix
06.06.2019 21:07Спасибо за материал, надеюсь во второй части вы расскажете подробнее с помощью чего делалось нагрузочное тестирование, как именно удалось уменьшить время выполнение программ, как сильно менялся объем базы SAP в ходе вашего проекта и как вы сейчас всё это дело бэкапите.
krids
SAP БД в 5… петабайт ??? Одной SAP-системы ???
Assimilator
Они небось весь Data Warehouse в SAP держат.
abezugly
DWH не весь на SAP, у нас много различных решений. Но активнее всего используется сейчас действительно SAP BW on HANA. В планах внедрить Data Lake и консолидировать все дополнительные хранилища.
abezugly
Это небольшая неточность. 5 Пб — это размер всех систем компании. Используемого места примерно 60%. Из этого на SAP системе приходится около 25%, все остальное не SAP.