Материал для Форума ИТ и инноваций в розничной торговле по мотивам доклада Андрея Лазарева, архитектора решений Linx Cloud.
Когда международная бьюти-сеть решает запустить локальный e-commerce в России, задача выглядит понятной: сайт с оплатой, партнерский портал, интеграция с глобальными системами. Непонятным остается другое – сколько времени и трудозатрат закладывать на подготовку надежной инфраструктуры. Почему на подготовку платформы уходит больше ресурсов, чем на сам продукт. И можно ли по-другому?
Андрей Лазарев, архитектор решений Linx Cloud, разобрал на конференции механику этого разрыва – и показал, за счет чего в конкретном проекте удалось его сократить.
Цифры, ради которых ритейл идет в контейнеры
Начнем с бизнес-уровня. По данным международных исследований аналитических агентств, таких как McKinsey&Co, компании, грамотно использующие Kubernetes, показывают:
● рост темпов выручки в разы по сравнению с теми, кто не использует контейнеризацию
● более высокие показатели прибыльности относительно конкурентов
Для продуктовых команд метрик с возросшими показателями больше, вот некоторые из них:
Последний пункт стоит пояснить. Контейнеризация предполагает итерационную работу над продуктом: гипотезы проверяются короткими циклами, корректировка курса стоит дешево. В монолитной архитектуре часто ошибка на старте выясняется к концу проекта, когда переделывать уже дорого. Для e-commerce, где требования меняются от сезона к сезону, это принципиальная разница.
Почему «просто взять Kubernetes» не работает
Kubernetes – open source. Скачал, развернул, получил заявленные преимущества. На практике так не происходит.
Для эксперимента одного Kubernetes достаточно. Проверить гипотезу, собрать прототип, показать демо – да, этого хватит.
Для продакшена – нет. Особенно если сервис генерирует выручку. Нужна обвязка: автомасштабирование, отказоустойчивость, балансировка нагрузки, логирование, мониторинг, резервное копирование, управление доступом, сетевые политики.
Каждый компонент – отдельное решение, которое надо выбрать, интегрировать с остальными, настроить, поддерживать и обновлять. И здесь у команды развилка: собирать все самостоятельно или взять готовую платформу.
Как растет команда при самостоятельном пути
Прототип. Готовый фреймворк разворачивается на инфраструктуре без требований к ее надежности. Достаточно одного DevOps-инженера. Результат получен, эксперимент закрыт.
Продакшен. Начинается поиск людей:
● сетевые инженеры
● серверные инженеры
● команда разработки
● команда тестирования
● команда поддержки
● тимлиды на каждое направление
Сроки удлиняются, появляются итерации согласований, растет количество потенциальных точек отказа, усложняются коммуникации и взаимосвязи компонент продукта. И те самые 50% сокращения time-to-market, ради которых все затевалось, «тают или вообще уходят в отрицательную зону».
Для ритейла это особенно чувствительно: наем инфраструктурных специалистов конкурирует по бюджету с наймом разработчиков, которые делают продукт. А сезонный дедлайн не двигается.
Различные модели ответственности
Первый сценарий – все сам. Изучение технологии, выбор компонентов, развертывание, настройка, обновление, поддержка. Команда тратит ресурс на слои, которые не являются частью бизнеса компании. Бьюти-ритейлер занимается не косметикой, а обслуживанием кластера.
Второй сценарий – управляемая платформа. Команда фокусируется на приложении, данных и конечном цифровом продукте. Все промежуточное – инфраструктура, платформенный слой, эксплуатация – на стороне провайдера.
В случае Linx Cloud второй сценарий реализован как совместный продукт с технологическим партнером: Deckhouse Kubernetes Platform от компании «Флант» на инфраструктуре Linx Cloud. Платформа дает готовый набор компонентов и автоматизацию, дата-центры – надежность основания.
Кейс: локальный e-commerce для бьюти-ритейла
Реальная ситуация. Крупная международная компания из сегмента бьюти-ритейла. Количество пользователей, клиентов и партнеров растет, прогноз – дальнейший рост. На российском рынке действуют регуляторные ограничения, требующие локального размещения данных.
Задача:
1. Локальный сайт класса e-commerce – продающая витрина
2. Партнерский портал для взаимодействия с каналами продаж
3. Сверхсжатые сроки
4. Решение не изолированное – нужна работа в связке с существующим ИТ-ландшафтом компании
Что было сделано
Проект вёлся как комплексная реализация, а не поставка отдельных ресурсов.
Подготовка инфраструктуры. Развернута вычислительная инфраструктура и кластеры Kubernetes в конфигурациях под задачи проекта – с дополнительными сервисами, необходимыми для промышленной эксплуатации.
Нагрузочные испытания. Проведены по методике, аналогичной продуктивной. Это принципиальный момент для e-commerce: тест, воспроизводящий реальный профиль нагрузки, показывает поведение системы при пиковых значениях до того, как эти нагрузки будут создавать реальные клиенты. Проверка «на синтетике» такой гарантии не даёт.
Оптимизация хранения. Отдельно проработано хранение файлов и объектов. Для бьюти-ритейла это не второстепенная задача: карточка товара – это фотографии в нескольких ракурсах, свотчи оттенков, видео нанесения. Объём медиа в этой категории выше, чем в большинстве других сегментов розницы, и напрямую влияет на скорость загрузки витрины.
Сдача в эксплуатацию. Система принята заказчиком и переведена в продуктивный режим.
Состав услуг: публичное облако, резервное копирование, Kubernetes as a Service.
Что получил клиент
Комплексная реализация. Один подрядчик отвечает за инфраструктуру, платформу, тестирование и ввод в эксплуатацию. Нет стыков между поставщиками, где обычно теряется время и возникают споры о зоне ответственности.
Индивидуальные коммерческие условия. Конфигурация и модель оплаты подобраны под конкретный проект, а не под стандартную тарифную сетку.
Изолированная инфраструктура. Соответствует одновременно двум наборам требований – российских регуляторов и собственной службы безопасности заказчика. Для международной компании второе часто строже первого: корпоративные политики головного офиса добавляют условия сверх локального законодательства. Контур выстроен так, чтобы проходить обе проверки.
Сроки. Проект реализован в кратчайшие сроки с учётом технологической сложности – то есть без размена скорости на упрощение архитектуры.
Как устроен сервис Managed Kubernetes
Linx Cloud полностью управляет системными компонентами, обновлениями и безопасностью кластера.
Это снимает работу с команды продукта, которая не заканчивается после запуска: обновления Kubernetes выходят регулярно, патчи безопасности – чаще. В самостоятельной модели каждое обновление требует планирования, тестирования на стенде и окна для накатки. В управляемой – этим занимается провайдер.
На базе Deckhouse Kubernetes Platform
Все модули интегрированы в платформу изначально: сеть, хранилище, мониторинг, балансировщики, политики безопасности.
Разница с самостоятельной сборкой в том, что компоненты не нужно выбирать, состыковывать и проверять на совместимость.
На инфраструктуре Linx Cloud
Гарантированные ресурсы, SLA, интеграция с VDC и Load Balancers.
Кластер работает не в абстрактном облаке, а на собственных дата-центрах Tier III с четырьмя последовательными сертификатами Uptime Institute M&O. Для продающей витрины, где недоступность конвертируется в упущенную выручку напрямую, операционная зрелость площадки значит не меньше, чем характеристики платформы.
Эффект для бизнеса
Kubernetes даёт измеримый эффект для бизнеса: сокращение time-to-market почти вдвое, снижение нагрузки на команду по инфраструктурным задачам на треть, около 60% возврата инвестиций. Эти цифры подтверждаются международной аналитикой — но получают их не все, кто разворачивает Kubernetes.
Разрыв возникает на переходе от прототипа к продакшену. Эксперимент делает один DevOps-инженер за короткий срок. Промышленная эксплуатация требует сетевых и серверных специалистов, тестирования, поддержки, тимлидов — и той обвязки, без которой контейнерная платформа не выдерживает продуктивную нагрузку: автомасштабирования, отказоустойчивости, балансировки, логирования, мониторинга. Собирая всё это самостоятельно, команда съедает то самое ускорение, ради которого технология и внедрялась.
Управляемая платформа убирает этот этап целиком. Модули уже интегрированы, системные компоненты и обновления — зона провайдера, инфраструктура под кластером имеет гарантированные ресурсы и SLA. Команда работает над продуктом с первого дня, а не через несколько месяцев после найма инфраструктурных специалистов.
Кейс бьюти-ритейлера показывает эту модель в действии. Локальный e-commerce и партнерский портал для международной компании — задача с одновременно жесткими сроками, требованиями двух контуров безопасности и технологической сложностью. Проект прошёл полный цикл: подготовка инфраструктуры и кластеров, нагрузочные испытания по продуктивной методике, оптимизация хранения медиаконтента, сдача в эксплуатацию. И был реализован в кратчайшие сроки — без упрощения архитектуры ради скорости.
Для розницы вывод практический. Разработчик витрины создаёт выручку напрямую. Инженер, обслуживающий кластер, — опосредованно. Когда сезонный дедлайн не двигается, а бюджет на найм ограничен, вопрос не в том, использовать ли Kubernetes, а в том, кто отвечает за слои ниже приложения. Каждый месяц, потраченный на сборку платформы, — это месяц, на который откладывается запуск продукта.
