Разработка Internal Developer Platform (IDP) с самообслуживанием

Разработчики ждут DevOps-инженера, чтобы создать namespace, задеплоить сервис или получить доступ к логам? Это знакомая ситуация для компаний с 20+ разработчиками. Мы решаем её с помощью Internal Developer Platform (IDP) — набора абстракций, которые позволяют разработчикам выполнять эти задачи самостоятельно, без DevOps-команды на каждом шаге.

Самое частое заблуждение: «мы поставили Backstage, значит у нас есть IDP». Backstage — это портал, frontend для платформы. Сама платформа — это то, что за ним: автоматизация provisioning, управление secrets, стандартизированные pipeline, наблюдаемость по умолчанию. Наш опыт показывает, что IDP сокращает время деплоя нового сервиса в 3 раза по сравнению с ручным согласованием.

Какие проблемы решает IDP?

Задеплоить новую версию в staging — нужно зайти в GitLab, найти нужный pipeline, запустить его вручную или дождаться триггера. Посмотреть логи — открыть Grafana, переключиться в Loki, собрать правильный запрос LogQL. Завести новый сервис — открыть тикет в DevOps, подождать, пока кто-то создаст репозиторий, namespace в кластере, выдаст secrets.

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

Архитектура IDP: что реально нужно

Рабочая IDP строится на нескольких слоях. Не обязательно реализовывать все сразу — важно понимать, что в неё входит.

Уровень портала

Точка входа для разработчика. Backstage — стандарт де-факто. Он даёт: service catalog (реестр всех сервисов с метаданными, owner, статусом деплоя), software templates (scaffolding новых проектов), TechDocs (документация рядом с кодом), plugin ecosystem для интеграций с Kubernetes, Vault, GitHub Actions, PagerDuty, Datadog.

# catalog-info.yaml — регистрация сервиса в Backstage
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: payments-service
  description: Сервис обработки платежей
  annotations:
    gitlab.com/project-slug: backend/payments-service
    backstage.io/techdocs-ref: dir:.
    prometheus.io/rule: payments_service
    grafana/dashboard-selector: "payments"
spec:
  type: service
  lifecycle: production
  owner: group:payments-team
  system: billing
  dependsOn:
    - component:postgres-payments
    - component:redis-sessions

Уровень provisioning

Self-service создание инфраструктурных ресурсов. Два подхода: GitOps через Crossplane (ресурсы описываются как Kubernetes CRD, reconciler их применяет) или pull-request automation через Terraform + Atlantis/Spacelift.

Crossplane удобен, когда вся команда уже в Kubernetes-экосистеме:

# Crossplane XRD — разработчик запрашивает базу данных
apiVersion: database.company.com/v1alpha1
kind: PostgreSQLInstance
metadata:
  name: payments-db
  namespace: payments-service
spec:
  parameters:
    storageGB: 20
    version: "15"
    environment: production
  compositionRef:
    name: postgresql-aws-rds

DevOps заранее написал Composition, которая разворачивает RDS instance, создаёт secret с credentials и прокидывает его в namespace сервиса. Разработчик просто применяет YAML — не знает ничего про AWS, IAM роли, subnet groups.

Уровень secrets

HashiCorp Vault с динамическими credentials. Сервисы не хранят статические пароли. Vault генерирует credentials на лету с TTL, отзывает их при остановке пода. External Secrets Operator синхронизирует Vault secrets в Kubernetes Secrets.

# ExternalSecret — получение credentials из Vault
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: payments-db-credentials
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-backend
    kind: ClusterSecretStore
  target:
    name: payments-db-credentials
    creationPolicy: Owner
  data:
    - secretKey: DB_PASSWORD
      remoteRef:
        key: secret/payments/database
        property: password

Уровень observability

Каждый сервис, созданный через IDP, автоматически получает ServiceMonitor для Prometheus, базовый Grafana dashboard по шаблону команды, structured logging с correlation ID в Loki, трейсинг через OpenTelemetry.

Это не просто удобно — это устраняет ситуацию «сервис задеплоен, но метрик нет, логи где-то потерялись».

Как строится IDP: не Backstage в первый день

Самая дорогая ошибка — начать с установки Backstage и потратить месяц на его настройку, пока основные проблемы остаются нерешёнными.

Наш подход: сначала фиксируем developer journey. Что происходит от git commit до работающего сервиса в production? На каждом шаге: кто участвует, сколько времени, где ждём. Эта карта показывает, где платформа нужна больше всего.

Потом строим automation снизу вверх: сначала стандартизируем Helm charts и CI pipeline templates, потом добавляем self-service provisioning для самых частых запросов, потом надстраиваем Backstage как portal поверх уже работающей автоматизации.

Backstage без автоматизации снизу — это красивый UI над хаосом.

Реальный проект: IDP для финтех-компании

Компания с 40 разработчиками, 60+ микросервисами на Kubernetes в AWS EKS. DevOps-команда из 3 человек тратила ~60% времени на «операционные» запросы разработчиков.

Первые две недели: аудит. Выяснилось, что 70% запросов — это либо «создай мне namespace», либо «помоги с secrets», либо «почему мой деплой упал». Всё остальное — единичные кейсы.

Месяц 1–2: решаем top-3 проблемы. Namespace creation — автоматизировали через GitOps repo: разработчик открывает PR с namespaces/payments-team/new-service.yaml, Flux/ArgoCD применяет. Secrets — перешли на External Secrets Operator + Vault, убрали все статические секреты из ConfigMaps. Debug деплоев — добавили в Backstage плагин Kubernetes, разработчик видит pod status, последние events, логи прямо в портале.

Месяц 3: добавили software templates. Три шаблона — Node.js сервис, Go сервис, Python worker. После scaffold разработчик получает репозиторий с Dockerfile, Helm chart, .gitlab-ci.yml, catalog-info.yaml, базовым Grafana dashboard, набором Prometheus alert rules.

Результат через 3 месяца: количество DevOps-тикетов от разработчиков упало на 70%. Время от идеи до первого деплоя в dev — с 2–3 дней до полутора часов.

Что входит в проект

Сравнение подходов: Backstage vs кастомное решение

Этапы проекта

Общая длительность — от 6 недель до 3 месяцев в зависимости от текущего состояния инфраструктуры и количества сервисов. Получите консультацию по построению IDP под ваш проект — мы оценим ситуацию и предложим план.

Что обязательно зафиксировать на старте

Перед тем как писать первый шаблон, нужно договориться о стандартах: как именуются ресурсы (namespace naming convention), какие labels обязательны для всех Kubernetes ресурсов (team, app, env, version), какие resource requests/limits минимально допустимы, что считается «прошедшим quality gate» для деплоя в production.

Без этих договорённостей платформа будет автоматизировать хаос — быстро, масштабно, но всё равно хаос.