Розробка Internal Developer Platform (IDP) із самообслуговуванням

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

Найпоширеніша помилка: «ми поставили Backstage, значить у нас є IDP». Backstage — це портал, frontend для платформи. Сама платформа — це те, що за ним: автоматизація provisioning, управління secrets, стандартизовані pipeline, observability за замовчуванням. Наш досвід показує, що 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.

---
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 та витратити місяць на його налаштування, поки основні проблеми залишаються невирішеними.

Наш підхід: спочатку фіксуємо 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 кастомне рішення

Backstage запускається в 2 рази швидше, ніж кастомне рішення.

Етапи проєкту

Загальна тривалість — від 6 тижнів до 3 місяців залежно від поточного стану інфраструктури та кількості сервісів. Вартість впровадження IDP залежить від обсягу і може становити від $30,000 до $100,000. Отримайте консультацію з побудови IDP під ваш проект — ми оцінимо ситуацію та запропонуємо план.

Що обов'язково зафіксувати на старті

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

Без цих домовленостей платформа буде автоматизувати хаос — швидко, масштабно, але все одно хаос. Наша команда має сертифікацію CKA (Certified Kubernetes Administrator) та досвід понад 5 років у побудові платформ для розробників. Ми гарантуємо результат за договором. 5+ років на ринку, 20+ реалізованих проектів з IDP. Основна мета IDP — забезпечити самообслуговування розробників при роботі з Kubernetes. Самообслуговування Kubernetes через IDP скорочує час на 50-80%.