Всем привет, меня зовут Сергей Прощаев. Я Tech Lead и руководитель направления Java | Kotlin разработки в FinTech & E-commerce, а ещё преподаю на курсах разработки и архитектуры в OTUS. Сегодня расскажу о том, как мы годами незаметно душили скорость разработки собственными руками — и как self-service деплой помог нам из этого выбраться.

Когда в очередной раз слышу «деплой — это не наша забота, это к DevOps», внутри что-то переворачивается. Не потому, что я против DevOps. Наоборот. Я сам прошёл путь от разработчика до лида, который вынужден был по полчаса висеть в Slack в ожидании, пока кто-то накатит сборку на стенд.

Проблема не в людях. Проблема в том, что с ростом команд инженер платформы или DevOps-инженер превращается в единственный шлюз между разработчиком и продакшеном. И это бутылочное горлышко, которое самортизирует любую Agile-культуру в ноль.

Почему DevOps становится узким местом?

Представьте: пять микросервисных команд, в каждой по 4–5 разработчиков. Все они хотят выкатывать фичи несколько раз в день. А канал один — дежурный DevOps-инженер, который помимо деплоя ещё и мониторит кластер, чинит CI/CD и настраивает сетевые политики. В один непрекрасный понедельник у нас случился коллапс: разработчик из команды А ждал деплой 4 часа, потому что инженер разбирал инцидент с прод-базой. 4 часа ожидания кнопки «deploy» — и это в компании, где спринт длится неделю.

Таких примеров масса. В небольших стартапах это ещё терпимо. Но как только вы перешагиваете 20–30 разработчиков, ручная модель «заявка → жди → молись» начинает съедать до 30% полезного времени команды. И ладно бы просто время — оно убивает автономию. Разработчик перестаёт чувствовать ответственность за доставку фичи до пользователя. Он сделал код, кинул тикет — и всё, дальше «не моя зона». Знакомо?

Именно в этот момент мы начали всерьёз смотреть в сторону платформенной инженерии и self-service инфраструктуры.

Что такое self-service инфраструктура (без маркетинга)?

Self-service инфраструктура — это не просто портал с красивыми кнопками. Это набор инструментов, внутренних сервисов и абстракций, который позволяет разработчику самостоятельно, без ручного участия DevOps, создавать нужные ему ресурсы: стенды, базы данных, очереди, деплой-пайплайны.

По сути, команда платформенной инженерии строит «продукт для разработчиков». Они не бегают по вызову, нажимая кнопки за других. Они автоматизируют это нажатие и упаковывают в удобный интерфейс — будь то CLI, Internal Developer Platform (например, Humanitec, Port, Mia‑Platform) или Backstage с кастомными плагинами.

Как это работает на практике:

• Разработчик создаёт feature-окружение одной командой в Slack или через веб-интерфейс.

• База данных поднимается по шаблону с уже настроенными бэкапами и политиками доступа.

• Пайплайн деплоя с канареечным выпуском инициируется автоматически при пуше в ветку.

• Мониторинг и логи подключаются сами, потому что это часть шаблона.

И никакой переписки типа: «Слушай, я тут новый микросервис запилил, влей мне, пожалуйста, базу и секреты».

Схема перехода от ручного хаоса к self-service

Я хочу показать, как меняется поток работы. Вот два состояния — до и после внедрения self-service, отрисованные в виде принципиальной схемы.

Перед нами (рис. 2) классический портрет команды, запертой в ручном конвейере. Три независимых разработчика хотят выполнить три разные задачи – получить стенд, базу данных, запустить деплой. Но все их запросы замыкаются на единственного DevOps-инженера, который вынужден вручную обрабатывать каждую заявку.

Схема сразу показывает главную сложность: один человек становится шлюзом для целой команды. Вместо того чтобы параллельно работать, разработчики выстраиваются в невидимую очередь, ожидая, пока освободится «ручной запуск». Производительность упирается не в их способности, а в пропускную способность одного занятого инженера.

Обратите внимание: во втором блоке (рис. 3) разработчик вообще не взаимодействует с живым инженером ради рутины. Платформа сама оркестрирует Terraform, создаёт ресурсы в Kubernetes, прописывает DNS и возвращает готовый endpoint. Время получения окружения сокращается с часов до минут.

Какие задачи стоит автоматизировать в первую очередь?

Исходя из моего опыта, не нужно пытаться автоматизировать всё и сразу. Есть высокочастотные запросы, которые съедают львиную долю времени платформенной команды. Вот три слона, на которых держится любой self-service:

1. Деплой и управление релизами
   Сюда входит не только «пушить образ в прод». Это вся цепочка: canary-деплой, автооткат по метрикам, управление feature-флагами, деплой на конкретное окружение. Инструменты вроде Argo Rollouts, Spinnaker или встроенного GitLab CI с ручным триггером — здесь выбор зависит от экосистемы.

2. Провижионинг баз данных и middleware
   Разработчику не обязательно знать, как именно поднимается PostgreSQL через Crossplane или Zalando Operator. Ему нужно получить connection string и быть уверенным, что бэкапы настроены. Мы для этого сделали шаблонизированные каталоги в Backstage, где он выбирает «PostgreSQL 15, размер small» — и через минуту база готова.

3. Полноценные preview-окружения на каждую фичу
   Это самое мощное, что можно дать команде. Открываешь PR — автоматически разворачивается изолированный стенд с актуальными миграциями и, возможно, анонимизированными прод‑данными. Закрываешь PR — окружение умирает. Платформа управляет жизненным циклом, разработчик даже не думает об очистке.

Когда эти три вещи автоматизированы, количество ручных запросов от разработчиков падает на 70–80%.

Я видел цифры в отчёте команды платформенного DevOps из Spotify: после внедрения self-service фреймворка Backstage время ожидания инфраструктуры упало с 3 дней до 15 минут (по их публичным докладам и блогам), а количество тикетов на DevOps сократилось в пять раз.

Как выглядит процесс деплоя с self-service: план действий

Я набросал ещё одну диаграмму — она показывает последовательность шагов при деплое через self-service платформу. Это не «идеальная теория», а та схема, которую мы внедрили у себя в команде (рис. 4).

Главное здесь — асинхронность. Разработчик пушит код и идёт делать код-ревью. Деплой происходит в фоне под управлением платформы. Никто никого не дёргает!

Реальная история: как Monzo переизобрели деплой

В 2018–2019 годах британский необанк Monzo рос бешеными темпами. Количество микросервисов перевалило за сотню, девелоперов стало больше 80. Их ручной процесс деплоя начал трещать по швам. Инженеры платформенной команды рассказывали в своих блогах, что они построили фреймворк, при котором dev‑команды полностью владеют деплоем своих сервисов через универсальный пайплайн, а платформа предоставляет «золотой путь» — преднастроенные шаблоны CI/CD, мониторинга и автомасштабирования.

Вместо DevOps-инженера, который вручную жмёт кнопки, они создали концепцию «platform as a product». Разработчики сами выбирали параметры деплоя в YAML‑конфиге сервиса. Система сама вычисляла diff между текущим состоянием кластера и желаемым, и применяла изменения. В результате частота деплоев выросла в 4 раза, а количество инцидентов из-за ошибок ручного деплоя заметно снизилось. Это не магия — это просто инженерный подход к устранению рутины.

Best practices, которые реально работают

Поделюсь тем, что в итоге прижилось в нашей практике:

• Начните с золотого пути. Не давайте разработчикам абсолютную свободу — вы получите зоопарк конфигураций. Определите один-два «золотых» способа деплоя, которые покрывают 80% случаев. Для нас это Helm-чарт с несколькими кастомизируемыми параметрами через values.yaml.

• Платформа как продукт, а не как набор скриптов. Относитесь к платформе так же, как к пользовательскому софту: собирайте фидбэк от dev‑команд, измеряйте NPS, итерируйтесь. Введите DORA-метрики (время от коммита до деплоя, частота деплоев) — они покажут реальную эффективность.

• Инфраструктура как код везде. Не важно, Terraform, Pulumi или Crossplane. Вся конфигурация окружения должна быть в репозитории. Тогда воспроизводимость 100%.

• Автоматизируйте безопасность, а не отдавайте на откуп. Встроенные политики: сканирование образов, проверка секретов, compliance-шаблоны — всё это должно быть частью платформы по умолчанию. Разработчик получает безопасный деплой без дополнительных действий.

• Не бойтесь начать с CLI, а не с красивого UI. У нас первая версия self-service работала через Makefile и пару скриптов. Покрытие разработчиков выросло мгновенно, потому что интерфейс командной строки для инженеров часто роднее, чем веб-портал.

Вывод: Self-service — это не мода, а выживание!

Оглядываясь на свой прошлый опыт, понимаю, что самой дорогой вещью в команде была не зарплата инженеров, а их время ожидания. Self-service деплой — не про то, чтобы уволить DevOps. Это про то, чтобы дать разработчикам автономию, а инженерам по инфраструктуре — возможность наконец заняться сложными задачами, а не бесконечным созданием баз данных по тикетам.

Команды, которые внедрили этот подход, деплоят в десятки раз чаще, меньше устают и быстрее валидируют гипотезы. Это не просто инструмент, это культурный сдвиг.

Если эта тема резонирует с тем, что вы видите у себя, и хочется разобраться, как строить такие платформы не на ощупь, а системно, приглашаю на открытый урок, который пройдёт 18 мая в 20:00 в рамках курса «Инженер платформенной инфраструктуры». Участие бесплатное, достаточно зарегистрироваться.

На уроке можно будет познакомиться с подходом преподавателя‑практика, разобрать реальные вопросы по теме и задать свои — про архитектуру платформ, процессы, инструменты и типовые ошибки внедрения.

Полный список бесплатных уроков мая смотрите в дайджесте.