Что сегодня входит в DevOps-подход для ecommerce
DevOps помогает поддерживать стабильную работу всей цифровой инфраструктуры. Интернет-магазин — это постоянно нагруженная система, где одновременно работают каталог, поиск, корзина, CRM, 1С, оплата, доставка, аналитика и внешние сервисы. Даже небольшие проблемы в одной части инфраструктуры быстро влияют на остальные.
Например, в период распродажи обмен данными с 1С начинает сильнее нагружать базу данных: сначала становится сложнее найти нужный товар, потом дольше оформляется заказ. Через некоторое время пользователи обращаются в поддержку, хотя начаться всё могло с одной перегруженной интеграции.
Я считаю, что современный DevOps-подход — это работа со стабильностью всей системы под нагрузкой. В крупных ecommerce-проектах DevOps-команда обычно отвечает за несколько направлений:
Кейс: как DevOps помог стабилизировать крупный ecommerce-проект
Один из показательных кейсов — крупный интернет-магазин в сегменте сантехники с собственным производством, широкой товарной матрицей и развитой региональной сетью. Проект уже находился в разработке у подрядчика, команда продолжала выпускать новые функции, а инфраструктура работала стабильно, но лишь на первый взгляд: внутри системы постепенно накапливались проблемы.
Задача
Со временем сайт начал заметно деградировать:
- страницы загружались по 4–6 секунд;
- при росте трафика появлялись сбои;
- каталог и фильтрация работали нестабильно под нагрузкой.
Для ecommerce это критично: пользователь не готов ждать несколько секунд, пока откроется каталог или карточка товара. На проектах с большим ассортиментом даже небольшая задержка быстро влияет на поведение покупателей: по данным исследования, 53% пользователей уходят с мобильного сайта, если загрузка занимает больше трех секунд.
Проблема осложнялась тем, что система долго развивалась разными командами. В проекте накопилось большое количество сложных зависимостей, тяжелого кода и неиспользуемого функционала. Любое изменение начинало влиять сразу на несколько частей системы.
Кроме того, дополнительную нагрузку создавала интеграция с внешними источниками данных и 1С. Обновление информации запускало цепочку операций, которая перегружала базу данных и вызывала каскадные задержки по всей системе.
Еще одна задача со звездочкой — архитектура каталога. Логика фильтрации плохо масштабировалась при большом количестве товаров и свойств. Чем больше рос каталог, тем сильнее увеличивались количество запросов и время отклика. Но самым неожиданным источником деградации оказался бот-трафик.
Что показал аудит
Работу начали с технического аудита:
- проверили серверное окружение;
- провели нагрузочное и функциональное тестирование;
- проанализировали тяжелые участки кода;
- проверили фоновые задачи и работу фронтенда;
- исследовали структуру трафика, нагрузку на сервисы и поведение системы в периоды пиковых запросов.
Выяснили, что значительную часть нагрузки создают не реальные пользователи, а автоматизированные запросы.
Причем речь шла не только о вредоносных сценариях. Нагрузку создавали поисковые краулеры, спам-боты, автоматические сканеры и боты из отдельных сетей и регионов.
Ситуацию усугубляла структура проекта. Большое количество поддоменов приводило к тому, что поисковые системы и боты фактически сканировали инфраструктуру как множество отдельных сайтов.
В пиковые периоды сервер получал нагрузку, как при многократном росте пользовательского трафика. Без мониторинга заметить такие сбои заранее было практически невозможно.
Решение
После аудита специалисты сфокусировались на стабилизации всей системы.
-
Построили полноценную наблюдаемость
Первым шагом подключили непрерывный мониторинг инфраструктуры и сервисов.
Команда начала отслеживать:
- аномалии нагрузки;
- поведение бот-трафика;
- состояние базы данных;
- производительность критичных сценариев;
- деградацию сервисов до появления инцидентов.
В больших ecommerce-проектах без наблюдаемости инфраструктура часто начинает деградировать незаметно для команды.
-
Разделили пользовательский и бот-трафик
Из ключевых изменений — новая серверная схема. Пользовательские запросы и бот-трафик начали обслуживаться разными веб-серверами. Дополнительно настроили маршрутизацию запросов через балансировщик.
Теперь команда могла:
- изолировать нестабильную нагрузку;
- снизить давление на основную инфраструктуру;
- гибко управлять поведением системы в зависимости от типа трафика.
После разделения потоков сайт перестал реагировать на активность ботов как на критический инцидент.
-
Оптимизировали работу базы данных
Следующим этапом пересмотрели, как работает база данных. Для проекта внедрили проксирующий слой ProxySQL, который дал возможность кешировать часть запросов, разделить операции чтения и записи и снизить нагрузку на базу данных.
-
Пересмотрели фильтрацию трафика
Отдельный блок работ касался фильтрации запросов.
Что сделали специалисты:
- ограничили количество запросов с одного IP;
- настроили блокировку нежелательных сетей;
- добавили правила работы с User-Agent;
- снизили влияние агрессивных краулеров и спам-ботов.
В результате всплески бот-трафика больше не были аварийными ситуациями.
-
Исправили внутренние ограничения системы
После стабилизации инфраструктуры команда перешла к внутренним проблемам проекта:
- исправила ошибки в работе фасетного индекса;
- сократила количество тяжелых запросов к базе данных;
- провела рефакторинг проблемных участков кода;
- убрала накопленные архитектурные противоречия;
- пересмотрела хранение данных для большого каталога;
- оптимизировала фоновые процессы и работу интеграций под нагрузкой.
Итоги
После изменений проект начал стабильнее работать под нагрузкой:
- сократилось время отклика страниц;
- снизилось влияние бот-трафика;
- инфраструктура стала предсказуемее при росте посещаемости;
- новые доработки перестали вызывать цепочку критичных ошибок.
Вместо масштабирования инфраструктуры команда сначала разобралась, где система теряет ресурсы. Основной эффект дали перераспределение трафика и оптимизация процессов, которые создавали лишнюю нагрузку на сервисы и базу данных.
Простое масштабирование инфраструктуры без пересмотра архитектуры редко решает проблему полностью. Если не менять процессы, со временем нагрузка снова приводит к сбоям.
Результаты внедрения DevOps-подхода
От стабильности системы напрямую зависят продажи, скорость запуска изменений и способность компании выдерживать рост каталога, трафика и интеграций. Для бизнеса результат обычно выглядит так:
DevOps-подход в крупных интернет-магазинах давно не ограничивается серверами и релизами. Его задача — держать проект в рабочем состоянии по мере роста: спокойно выкатывать обновления, выдерживать нагрузку и не разбирать инфраструктурные проблемы после каждого изменения.
