Клиент — логистический сервис: десятки тысяч заказов в день, вечерние и распродажные пики, жёсткие SLA перед магазинами-партнёрами. Инфраструктура выросла стихийно: разрозненные VPS, конфигурации «на серверах», деплой руками по инструкции в вики. Каждый релиз — ночная выкатка с простоем, каждый пик — риск потери заказов. Инцидент в предновогодней распродаже, когда платформа не работала четыре часа и сервис выплатил компенсации партнёрам, и стал поводом обратиться к нам.
Перевести платформу на управляемую инфраструктуру без остановки бизнеса:
инфраструктура как код, автоматическая поставка, контейнеризация и оркестрация, наблюдаемость и предсказуемое восстановление после сбоев. Критерий успеха сформулировал основатель: «деплой в рабочее время, без даунтайма и без человека с доступом по SSH».
Мы двигались по проверенной последовательности: сначала контейнеры и воспроизводимые окружения, затем автоматизация поставки, и только после этого — оркестрация с автоскейлингом.
- Провели аудит инфраструктуры: карта сервисов и зависимостей, замеры пикового профиля нагрузки, реестр ручных операций, которые чаще всего приводили к авариям.
- Контейнеризовали сервисы: унифицировали сборку, вынесли конфигурацию из кода в переменные окружения, подняли идентичные dev/stage/prod.
- Описали инфраструктуру кодом на Terraform: окружения разворачиваются из репозитория, ручные изменения в консоли облачного провайдера запрещены.
- Собрали конвейер GitLab CI: тесты и сборка образов автоматически, деплой на stage — сразу, в prod — по кнопке после ревью; откат — одним действием.
- Перевели платформу на Kubernetes с автоскейлингом: вечерние и распродажные пики платформа встречает дополнительными инстансами, а не авральными ручными работами.
- Развернули мониторинг и алертинг: метрики золотого сигнала — латентность, ошибки, трафик, насыщение — с дежурством и эскалацией по графику.
- Настроили бэкапы и disaster recovery: регламент восстановления, репетиция сбоя на stage с измерением фактического MTTR.
Самое ценное в проекте — не технологии, а смещение ответственности: инфраструктура перестала зависеть от «человека с доступом по SSH». Любой деплой воспроизводим, любое окружение восстанавливается из кода, а любой сбой виден на дашбордах раньше, чем напишет первый клиент. Именно это превращает простои из катастрофы в рутинный инцидент с понятным плейбуком и измеримым временем восстановления.
Экономика проекта сложилась из трёх частей: прямая экономия на инфраструктуре — минус 32% за счёт автоскейлинга и отказа от постоянно разогретых «пиковых» мощностей; экономия часов команды, которые раньше уходили на ночные выкатки; и главное — сохранение выручки в пиках, которые теперь проходят без инцидентов. Крупный клиент-сеть магазинов продлил контракт именно после первой распродажи на новой инфраструктуре.
| Показатель | Результат |
|---|---|
| Деплой релиза | 3–4 часа вручную → 15 минут автоматически |
| Частота релизов | 2–3 в месяц → Почти ежедневно |
| Доступность платформы | 97,8% → 99,95% |
| Пиковые нагрузки | Риск простоя → Автоскейлинг без участия человека |
Показатели перенесены из исходных материалов кейса. Период указан там, где он зафиксирован в источнике.
- деплой релиза (было 3–4 часа вручную)
- 15 мин
- доступность платформы (было 97,8%)
- 99,95%
- восстановление после сбоя (было 2–4 часа)
- 20–30 мин
- стоимость инфраструктуры
- −32%
Показаны верхние границы диапазонов (4 часа, 30 минут). Недоступность = 100% − доступность.
- 01Commit
- 02Тесты
- 03Сборка образа
- 04Stageсразу
- 05Prodпо кнопке после ревью
Точки развития инфраструктуры на следующий цикл:
- FinOps-практика — алерты на аномалии затрат и прозрачность стоимости по командам.
- GitOps-подход — состояние prod описано в репозитории, изменения только через pull request.
- Multi-region — реплика критичных сервисов для устойчивости к авариям провайдера.
Раньше релиз — это ночь, кофе и молитва. Теперь это кнопка и пятнадцать минут. Первую распродажу без инцидентов мы отмечали всей компанией.
— Технический директор логистического сервиса