Я много лет занимался инфраструктурой. Потом ушёл в продукт, а привычка смотреть, как у людей устроена разработка, осталась. Особенно интересно становится на вопросе: «Что нужно сделать, чтобы задеплоить новый сервис?»
Иногда в ответ дают ссылку. Иногда начинают перечислять, кому надо написать. Вот об этом и поговорим.
По данным исследования State of DevOps Russia 2025 (более 3300 респондентов), половина участников уже работает с одной или несколькими внутренними платформами разработки (47%), а около трети внедрять их не планирует (37%). Половина компаний тратит на внедрение IDP от 10 до 30% своих ресурсов. В пользу сборки на open source это выглядит убедительно, хотя из цифр о ресурсах состав стека не узнаешь.
Я понимаю желание купить готовое. Но сначала хочется выяснить, за что именно платим и кто потом будет это обслуживать?
Сначала разработчику нужен доступ
Типичная картина. Новый человек пришёл в команду, получил продуктовую задачу и пошёл настраивать окружение. Dev отличается от stage, prod отличается от обоих. Потому что настраивали разные люди и в разное время.
Чтобы выкатить фичу, нужно написать «дай доступ». Подождать. Потом повторить для трёх разных систем. Документация есть, но часть в репозиториях, часть где-то ещё, а последнее изменение помнит только тот, кто его делал.
Он сейчас занят.
Пока команда маленькая можно договориться в чате, но с ростом команды те же простые операции начинают съедать время DevOps и платформенных инженеров, потому что каждому разработчику приходится ждать человека, который может их выполнить.
IDP - Internal Developer Platform, внутренняя платформа разработки - выносит такие действия в самообслуживание. Разработчик заходит в одно место, сам поднимает окружение или деплоит сервис. Там же находит документацию, смотрит метрики. У платформенной команды остаётся время на саму платформу.
Звучит скучновато. Зато можно работать.
А можно купить коробку?
Можно. Есть коммерческие платформы для developer portal, CI/CD, управления инфраструктурой, governance и self-service. В большой организации готовые интеграции и поддержка могут окупиться. Особенно когда нужны аудит и строгая ролевая модель, а за требования безопасности кто-то отвечает подписью.
Но представим команду в 30 человек. Ей тоже продают весь этот набор. Красивый интерфейс, впечатляющий список возможностей. Какие из них понадобятся в работе?
Тут я обычно и начинаю задавать неудобные вопросы.
Многое можно собрать из открытых компонентов. За проектами стоят CNCF, Spotify, HashiCorp и другие организации, тысячи контрибьюторов. Только лицензию конкретного продукта всё равно читаем (после истории с HashiCorp особенно).
И честно считаем работу. Внедрение тоже стоит денег. Интеграции тоже. Обновлять и чинить будет своя команда. Если убрать лицензионный платёж из сметы, инженеры бесплатно работать не начнут.
Мне интересна полная стоимость, включая эксплуатацию. С ней уже можно сравнивать предложение вендора.
Что придётся собрать
Слои у платформы разные. Все сразу устанавливать я бы не торопился, сначала нужно понять, где у команды очередь.
Портал. Где найти документацию по сервису? В Confluence, README, у Димы. Backstage собирает каталог сервисов с владельцами, документацию и шаблоны новых компонентов в одном интерфейсе. Это open source-проект Spotify под управлением CNCF.
Backstage на слуху, но установить его и получить работающую IDP - разные задачи. Это фреймворк. Каталог нужно наполнить, шаблоны написать, интеграции подключить под свои процессы.
После установки работы ещё достаточно.
Ресурсы по запросу. Разработчику нужна база. Он пишет DevOps, ждёт. Потом выясняется, ещё очередь и S3-бакет. Ещё сообщение, ещё ожидание.
Terraform или OpenTofu описывают ресурсы кодом. OpenTofu появился как открытый форк после смены лицензии HashiCorp. Когда команда подготовила модули, записала правила и настроила права вместе со способом запуска, разработчик может заказать нужное сам, причём контроль у инфраструктурной команды остаётся. Ресурсы создаются по тем правилам, которые она определила.
Сам по себе файл с описанием инфраструктуры такого сервиса не создаёт. Его ещё надо встроить в процесс.
Доставка кода. GitLab CI, GitHub Actions, Argo CD. Пайплайн рядом с кодом, деплой запускается пушем или кнопкой, без звонка в соседний отдел.
По данным State of DevOps Russia 2025, доля респондентов, использующих Argo CD, за год выросла с 14 до 21,8%, Flux CD - с 2,8 до 6,2%. GitOps растёт, хотя пока остаётся выбором меньшинства. Суть подхода: желаемое состояние хранится в Git, инструменты приводят фактическое к нему. Только CI и GitOps-контроллер делают разную работу, это нужно учитывать при сборке.
Окружения. Kubernetes как основа, Helm для упаковки приложений. Через Crossplane можно управлять внешними облачными ресурсами с помощью Kubernetes API. Удобно, если команда уже работает декларативно и хочет так же описывать инфраструктуру.
Но жизненный цикл базы от этого не становится таким же, как у приложения. За одинаковыми манифестами всё равно стоят разные ресурсы.
Что там сломалось? Prometheus + Grafana для метрик, Loki для логов. Разработчик сам смотрит, жив ли сервис, сколько ошибок и что было перед инцидентом. В три часа ночи очень хочется иметь такую возможность. Без отдельного квеста «найди DevOps».
Теперь глазами нового человека
Вместо инструкции на 40 страниц ему дают ссылку на портал. В каталоге шаблоны: Python API, Go-сервис, фронтенд на React. Выбрал нужный - пошла подготовленная цепочка.
Создался репозиторий со структурой проекта. Подключился CI/CD, поднялось dev-окружение и нужные инфраструктурные ресурсы. Сервис появился в каталоге, мониторинг тоже настроен.
Красиво? Да. Если команда заранее подготовила golden path и всё это связала между собой.
Через несколько минут разработчик получает рабочую заготовку по стандартам компании. Для своего внедрения я бы замерял время отдельно. Где человек начал работу, на чём остановился, сколько пришлось делать руками.
Спойлер: поставленный Backstage не мешает людям по-прежнему просить доступ в чате. Пока этот сценарий не переделан, так и будут просить. Проблема типовая, в State of DevOps Russia 2025 управление доступом названо самой важной функцией внутренней платформы (45,8% респондентов).
Грабли с красивым интерфейсом
Сначала месяцами выбирают плагины, потом спрашивают разработчиков, что им мешает. Оказывается, долго поднимается окружение, документацию не найти, доступы надо выпрашивать. Начать стоило с этого разговора, а портал подождал бы.
Есть и другая история: платформу сделали, пользоваться обязали. Удобно ли? «Мы так решили». Ну да, внутренние пользователи ведь не могут уйти к конкуренту.
Я бы смотрел, сколько людей реально пользуются платформой и сколько занимает создание сервиса. Какие ручные операции остались? Стало ли меньше обращений к платформенной команде? Если нет, выясняем причину, даже когда интерфейс всем нравится.
Следующие грабли- эксплуатация. Backstage обновлять, плагины поддерживать, Kubernetes обслуживать. Где-то ещё сломается пайплайн. На всё это нужен человек с выделенным временем.
Я бы закладывал хотя бы одного, для кого платформа - основная задача. Вариант «кто-нибудь поправит между делом» со временем деградирует. И обычно это замечают в самый неудобный момент.
Ну и автоматизация процесса, который никто толком не описал. Если деплой вручную устроен плохо, сначала разбираемся с порядком действий и ответственностью. Иначе просто запишем ту же путаницу в код. Она станет воспроизводимой, только радости мало.
Где всё-таки нужен Enterprise
Границы «до ста разработчиков хватит open source» я не знаю. Размер команды сам по себе мало что говорит.
Может быть большая команда с довольно простой инфраструктурой. Может быть маленькая, но с жёсткими требованиями безопасности. Во втором случае коммерческое решение иногда обходится дешевле собственной сборки.
Смотрим на количество команд и кластеров, multi-cloud, compliance. Потом на ролевую модель, аудит и круглосуточную поддержку. Есть ли свои люди, которые это потянут? Вот тут расчёт становится интересным.
Перед контрактом я бы попросил назвать конкретное ограничение, что на открытом стеке сделать не получается или слишком дорого поддерживать, сколько времени съедает эта работа и как изменится ситуация после покупки продукта с централизованным аудитом, сложными правами и готовыми интеграциями?
«Нужна поддержка» - тоже нормальный ответ. Только уточните, какая, с каким временем реакции и кто будет работать с обращениями на вашей стороне. А то подписка есть, инцидент есть, ответственный где-то потерялся.
С чего я бы начал
Возьмите создание нового сервиса и пройдите его вместе с разработчиком. От первого запроса до работающего окружения. Запишите, где пришлось ждать чужого действия.
Выберите такую остановку и уберите её через самообслуживание. Потом повторите проход. Если стало быстрее и команда готова это поддерживать, можно двигаться дальше. Заказывать весь каталог инструментов пока рано.
Автор статьи: Денисенко Александр, основатель "Септем Решение"