ab-kily,Alexander Bogdanov,github

Привет! Это страничка Александра Богданова, CPO, CTO, backend-программиста, IT-инженера, тим-лида... и просто хорошего человека 🤗

Свою первую программу на BASIC-е, перепечатанную с книжки по программированию, я продал в 13 лет моему другу, и с тех пор увлечение программированием меня не отпускает 😂

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

Настоящая моя страсть это технологии! Для меня высшее удовольствие находиться на острие современного IT, развивая себя и компании, где я работаю.

А по любым вопросам пишите в Телеграм: https://t.me/exiper

🏗️ Реализованные проекты

Ниже представлен список некоторых проектов, в которых мне приходилось участвовать, с кратким описанием каждого из них. При клике на элементе списка выпадет подробное описание 😉

Переезд IT-инфраструктуры с Virtuozzo на Kubernetes на базе Яндекс.Облака

🧐 Кейс: В процессе развития наших e-commerce сервисов мы заметили, что всё чаще отвлекаемся на проблемы, связанные с обеспечением мониторинга, доступности и надежности работы наших сервисов. То где-то кончатся ресурсы, то ляжет целый хост-сервер с кучей виртуалок "на борту". И хотя у нас были наработки по холодной и горячей замене, а также налажен процесс восстановления из бекапов, всё-таки хотелось тратить еще меньше времени на то, чтобы заниматься любимым делом - создавать любимые сервисы. Поэтому мы начали искать более гламурное решение.

❔ Проблема: Рассмотрев разные варианты (а среди них были: другое решение по виртуализации, приватное и публичное облако) мы остановились на варианте переезда в Яндекс.Облако. Причины, которые побудили нас это сделать:

Серьезный крупный провайдер, который завтра не закроется
Выполнение требования к лоализации данных
По предварительным подсчетам стоимость выходила меньше (хотя здесь мы обманулись
Встроенный по-умолчанию мониторинг и бекапы
Решение проблем с доступностью благодаря наличию Managed Kubernetes
Большое количество интересных сервисов, которые мы могли бы использовать в процессе развития наших сервисов

Выбрав решение, мы стали делать план переноса с текущей инфраструктуры в облако. По предварительным прикидкам выходило, что перенести предстояло порядка 130 сервисов, и переносить их в том виде, в каком они ранее работали (1 сервис - 1 виртуальная машина) не представляется возможным из-за очень высокой цены.

➡️ Решение: Было решено сразу начать оформлять каждый из сервисов в виде docker-образа и размещать сервисы в Kubernetes. Это, в свою очередь потребовало от нас изменить подход к разработке, внедрив полноценный CI/CD, но благо на базе платформы Kubernetes сделать это оказалось очень просто.
Таким образом, в течение порядка 6 месяцев был произведен переезд внутренних корпоративных систем (WMS, CRM, CMS, PIM) в облако.

✅ Результат: Уже после переноса первых сервисов на новую платформу и настройку CI/CD удалось оценить, насколько стал удобен процесс разработки и обслуживания инфраструктуры. Релизы теперь делались гораздо быстрее (часы вместо дней), а контроль над состоянием инфраструктуры стал просто тотальным. К сожалению, я ушел из компании, когда процесс переезда еще только продолжался, поэтому полностью оценить весь спектр преимуществ от переезда мне не удалось.

Используемый стек технологий:

Интеграция с системой Честный Знак

🧐 Кейс: Бизнес, в котором я работал, помимо всего прочего, продавал верхнюю одежду. С 1-го января 2021 года, в соответствии с законодательством, такая одежда в обязательном порядке должна маркироваться специальными кодами формата DataMatrix, эмитировать которые поручено единому оператору - Центру Развития Перспективных Технологий (ЦРПТ), а сама система маркировки называется Честный Знак.

❔ Проблема: Проблема заключалась в том, что данные коды являются аналогом акцизных марок для алкоголя, и учет должен производиться как на входе (при приёмке или возврате товара от покупателя), так и на выходе (при продаже или возврату поставщику). Учет должен быть стожайший, т.к., помимо штрафов, система накладывала множество ограничений на движение неучтенных кодов маркировки между организациями по линии продавец-поставщик или продавец-покупатель. Кроме этого, наличие кодов и необходимости дополнительного сканирования этого кода приёмщиками и продавцами на каждом из этапов движения товара вело к увеличению времени сборки заказов, что печалило руководство, а оно печалило нас... Соответственно, учет этих кодов без использования какой-либо автоматизации являлся абсолютно нереалистичным. Ситуация усугублялась тем, что рынке не было приемлемых решений по маркировке товаров, т.к. сам рынок только создавался.

➡️ Решение:Изучив доступные на рынке решения, мы пришли к выводу, что они нам не подходят и стали думать над собственным решением. Изучив API множества подсистем системы Честный Знак (а подсистем было много - TRUE API, API ГИС МТ, СУЗ API и ряд других), они показались нам достаточно зрелыми и юзабельными (что не часто для API гос. компаний), и мы решили сделать собственное решение, автоматизирующее работу с данными кодами. Были разработаны:

PHP-библиотека (https://github.com/kilylabs/true-api-cli) для взаимодействием с API Честный Знак
Интеграция между нашей складской WMS-системой и Честный Знак
Закуплено оборудование для печати маркировки

✅ Результат: Разработка заняла порядка 2-х месяцев, по итогам которой нам удалось практически полностью автоматизировать работу с кодами маркировки (за исключением участка приёмки и пересортицы). Более того, внедрение нашего решения позволило отслеживать историю движения каждого маркируемого товара, что дало маркетологам новую порцию интересных данных для анализа (например, почему одна и та же женская куртка продавалась и возвращалась 5 раз подряд на склад). Более того, в нашем решении нам удалось избавиться от необходимости двойного сканирования штрих кодов - самого штрих-кода изделия и DataMatrix кода Честного Знака. Таким образом, все операции по работе с макировкой производились прозрачно для комплектовщиков, и не приводили к увеличению сроков сборки заказов.

Используемый стек технологий:

Разработка и внедрение PIM (Product Information Management) системы

🧐 Кейс: Бизнес, в котором я работал, одной из первоочередных задач ставил качество контента, размещенного на сайтах (карточки товаров) и в печатных материалах. Однако, когда речь идет об одежде (а именно она составляла наибольший портфель заказов в компании), которая очень вариативна по своей природе (одной модели может соответствовать множество вариаций цветов, и размеров), и были определенные сложности с тем, чтобы обеспечивать должное качество и заполненность карточек товаров.

❔ Проблема: Стандартные техники работы с контентом, такие как хранение всё на каком-нибудь корпоративном файл-сервере и ведение карточек в Excel-е были очень не удобны (большая вероятность ошибиться), и нам было поручено найти подходящее решение. Первым делом, изучив проблему, для более гибкого управления контентом было решено попробовать использовать систему класса PIM (Product Information Management). Изучали 2 системы - Akeneo и PIMcore. Выбор пал на них по очень простым причинам - они OSS (хотя и имели Enterprise версии), и обе имели развитые возможности по работе с одеждой. Проведя исследования этих систем, как часто это бывает с OSS системами, качество оставляло желать лучшего.

➡️ Решение: Отправив несколько багрепортов и даже пару пул-реквестов, и получив стандартную отписку, мол, покупайте Enterprise версию и будет вам счастье, нами было решено разработать подобную систему самостоятельно. Были реализованы основные необходимые нам функции PIM-системы, в частности:

Централизация информации о контенте
Поддержка CRUD-операций для всего спектра информации о товаре (текст, характеристики, картинки, документация, связи между товарами и др.)
Workflow для заполнения карточки товара
KPIs по статусу заполненности карточек товара
Поддержка операцией импорта, также и экспорта контента (GraphQL)

✅ Результат: По результату внедрения этой системы на горизонте 6-и месяцев качество контента заметно улучшилось, что положительно сказалось на выручке компании.

Используемый стек технологий:

Система управления складом (WMS)

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

❔ Проблема: Как и все другие компании, для работы склада использовался 1С, где в полуручном режиме руководителем склада заносились движения товара при приёмке от поставщика, сборке и возрвтов заказов. Нужно ли говорить, что подобный подход вел к пересортицам, недостачам которые доходили до безумных 10% среди заявок на сборку товаров (то есть, по каждому десятому заказу была недостача или пересортица). Это всё накладывалось на долгое время поиска необходимого товара для сборки заказа, и в самые нагруженные месяцы ситуация решалась тем, что брались на работу 2-3 сборщика заказов. Кроме этого, менеджеры по продажам не имели информации о количестве товаров на складе, и не могли дать точные сроки по времени отправки заказов. Эта ситуация категорически не устраивала руководство компании. Предпринимались попытки перейти на другое ПО, типа облачного сервиса Мой Склад, но это никак не решало проблемы, лежавшией в основе - присутствие человеческого фактора при большинстве движений товаров.

➡️ Решение: После анализа ситуации и выявления корневой проблемы, было решать проблему комплексно:

Автоматизация по всему спектру операций движения товаров (приёмка товаров от поставщика, сборка заказа, приём возврата, возврат поставщику)
Внедрение ячеестого склада для сокращения времени поиска нужного товара
Максимальное исключение человеческого фактора из любый операций, связанных со складом (кроме контрольных)
Остатки должны обновляться в режиме реального времени по мере поставки или убытия товара со склада
Сбор статистики по каждому типу операций для дальнейшего анализа
Отчетность по товарам, заполненности склада и ячеек, движениям товара
Интеграция с CRM и CMS системами для обновления данных об остатках

Для решения этих проблем было проведено исследование доступного на российском рынке ПО на тот момент. Оказалось, что большинство решений было заточено под крупных игроков, и стоило очень дорого, и с требованием обязательной оплаты поддержки. Было решено самостоятельно разработать WMS систему, закупить ТСД терминалы и произвести интеграцию с тогда еще очень молодым и активно развивающимся стартапом, создающим ПО для терминалов - DataMobile. Преимущества решения:

Современное standalone решение на базе ОС Android, которое не требует обязательной покупки какой-нибудь WMS-системы
Открытый и хорошо докментированый протокол обмена на базе SOAP
Очень продуманный интерфейс приложения, позволяющий минимизировать время проведения операций
Широкий возможности по настройке приложения
Очень дружелюбная качественная, бесплатная тех. поддержка

Определившись с программно-аппаратным комплексом, мы приступили к проектированию WMS системы. В качестве архитектуры приложения была выбрана распределенная Event-driven architecture, а в качестве системы обработки событий использовался RabbitMQ.

✅ Результат: После нескольких месяцев разработки, опытно-тестовой эксплуатации и внедрения решения, и после года эксплуатации удалось добиться следующих результатов:

Доля пересортиц в процессе сборки стала не более 0.3%
Среднее время сборки заказаов сократилось на 70%
Благодаря своевременному и точному количеству остатков на складе, у менеджеров по продажам стали расти CR уровня заказ-продажа.
Благодаря скорости сборки заказа, даже в пиковые месяцы в компании работает один сборщик (экономия на 3-х доп. сборщиках, которые привлекались ранее).

Данная система позволила компании решить текущие проблемы, а гибкость её архитектуры позволила в дальнейшем легко расширять и интегрировать в неё дополнительную функциональность (см. проект по интеграции системы Честный Знак).

Используемый стек технологий: