Всем привет, меня зовут Сергей Прощаев. Я 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:
Деплой и управление релизами
Сюда входит не только «пушить образ в прод». Это вся цепочка: canary-деплой, автооткат по метрикам, управление feature-флагами, деплой на конкретное окружение. Инструменты вроде Argo Rollouts, Spinnaker или встроенного GitLab CI с ручным триггером — здесь выбор зависит от экосистемы.Провижионинг баз данных и middleware
Разработчику не обязательно знать, как именно поднимается PostgreSQL через Crossplane или Zalando Operator. Ему нужно получить connection string и быть уверенным, что бэкапы настроены. Мы для этого сделали шаблонизированные каталоги в Backstage, где он выбирает «PostgreSQL 15, размер small» — и через минуту база готова.Полноценные 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 в рамках курса «Инженер платформенной инфраструктуры». Участие бесплатное, достаточно зарегистрироваться.
На уроке можно будет познакомиться с подходом преподавателя‑практика, разобрать реальные вопросы по теме и задать свои — про архитектуру платформ, процессы, инструменты и типовые ошибки внедрения.
Полный список бесплатных уроков мая смотрите в дайджесте.