Команди розробників витрачають години на завдання, які не пов'язані з продуктом: налаштовують локальне оточення, розбираються з деплоєм у staging, чекають, поки DevOps створить репозиторій або Kubernetes namespace. Platform Engineering — це відповідь на питання «як прибрати це тертя з повсякденного циклу розробки», не перетворюючи DevOps-команду на сервісний тікет-стол.
Ми застосовуємо цей підхід вже в сотні проєктів — від стартапів до enterprise. Суть: внутрішня платформа, яку DevOps будує як продукт для внутрішніх клієнтів-розробників. Не набір скриптів у shared папці, не wiki з інструкціями — а self-service інструментарій з певними гарантіями.
Проблеми з CI/CD
Типова біль: у компанії є GitLab CI з десятком .gitlab-ci.yml у різних репозиторіях, кожен написаний по-своєму. Десь використовується docker:dind, десь Kaniko, десь чистий shell. Коли змінюється базовий образ або registry — оновлювати потрібно всюди вручну. Новий проєкт запускається від двох тижнів: DevOps створює репозиторій, налаштовує pipeline, видає namespace у кластері, прописує secrets у Vault, додає моніторинг.
Platform Engineering вирішує це через стандартизацію деплою та автоматизацію на рівні платформи, а не окремих проєктів. Розробник отримує golden path — опініонований, попередньо сконфігурований шлях від коду до продакшену.
Компоненти Platform Engineering
Архітектура платформи залежить від зрілості організації, але типовий стек виглядає так:
- Control plane платформи — найчастіше Backstage (CNCF проєкт від Spotify). Backstage служить порталом розробника (DevPortal): service catalog, software templates, TechDocs. Конфігурується через
app-config.yaml, інтегрується з GitLab/GitHub, Kubernetes, Vault, PagerDuty.
---
# app-config.yaml — приклад інтеграції з GitLab і Kubernetes
integrations:
gitlab:
- host: gitlab.company.com
token: ${GITLAB_TOKEN}
kubernetes:
serviceLocatorMethod:
type: 'multiTenant'
clusterLocatorMethods:
- type: 'config'
clusters:
- name: production
url: https://k8s.company.com
authProvider: 'serviceAccount'
serviceAccountToken: ${K8S_SA_TOKEN}
---
- Provisioning шар — Crossplane або Terraform + atlantis/spacelift для self-service provisioning інфраструктури. Розробник відкриває PR з описом ресурсу (база даних, S3 bucket, черга) — платформа застосовує його автоматично.
- Secrets management — HashiCorp Vault з Kubernetes auth method. Кожен сервіс отримує політику з мінімальними правами, токени ротуються через Vault Agent Injector або External Secrets Operator.
- Observability за замовчуванням — кожен новий сервіс, створений через платформу, автоматично отримує: Prometheus scraping (через ServiceMonitor), structured logging у Loki, трейсинг через OpenTelemetry collector, базовий Grafana dashboard за шаблоном.
Побудова внутрішньої платформи
Починаємо з аудиту: розмовляємо з розробниками (не тільки з DevOps), щоб зрозуміти реальні вузькі місця. Де губиться час? Що блокує? На якому кроці найчастіше відкривають тікет у DevOps? Відповіді на ці питання визначають пріоритети першого етапу.
Перший інкремент завжди мінімальний. Не будуємо повну платформу одразу — беремо найболючішу точку і автоматизуємо саме її. Найчастіше це onboarding нового сервісу: створення репозиторію + CI pipeline + Kubernetes namespace + базові secrets.
Приклад template.yaml для Scaffolder
---
# template.yaml — scaffolding нового мікросервісу
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
name: microservice-nodejs
title: Node.js Microservice
spec:
parameters:
- title: Service Configuration
properties:
serviceName:
type: string
pattern: '^[a-z][a-z0-9-]*$'
team:
type: string
environment:
type: array
items:
enum: [dev, staging, production]
steps:
- id: fetch
action: fetch:template
input:
url: ./skeleton
- id: gitlab-repo
action: publish:gitlab
input:
repoUrl: gitlab.company.com?owner=${{ parameters.team }}&repo=${{ parameters.serviceName }}
- id: create-namespace
action: kubernetes:apply
input:
manifest: |
apiVersion: v1
kind: Namespace
metadata:
name: ${{ parameters.serviceName }}
labels:
team: ${{ parameters.team }}
Після scaffold розробник за кілька хвилин отримує репозиторій з готовим .gitlab-ci.yml, Dockerfile, Helm chart у charts/, catalog-info.yaml для реєстрації в Backstage і скелет застосунку з уже підключеним OpenTelemetry SDK.
Реальний кейс з нашої практики
Наш клієнт — продуктова компанія з ~15 розробниками і 2 DevOps. Кількість мікросервісів зросла до 30+, при цьому у кожного своя «традиція» деплою. Bottleneck став явним: DevOps брали участь у кожному релізі як обов'язкова ланка.
Перший місяць: стандартизували Helm charts у репозиторії company-charts, ввели єдиний values.yaml з обов'язковими полями (image.repository, image.tag, resources.requests, probes). Це одразу прибрало найчастіший тікет — «допоможи налаштувати chart».
Другий місяць: задеплоїли Backstage, додали всі існуючі сервіси в каталог через catalog-info.yaml. Підключили GitLab, Kubernetes, Grafana. Розробники отримали єдине вікно: статус деплою, логи, метрики, документація — все в одному місці.
Третій місяць: додали software template для створення нових сервісів. Час від «потрібен новий мікросервіс» до першого деплою в dev скоротився з 3 днів до 40 хвилин — у 108 разів швидше. Це на 95% швидше, ніж попередній процес.
Етапи роботи
- Аудит — інтерв'ю з командами, карта поточного developer journey, виявлення bottleneck'ів
- Проєктування — вибір стеку, дизайн golden path, домовленості про стандарти
- MVP платформи — мінімальний набір інструментів, що вирішує найгострішу біль
- Ітеративний розвиток — розширення функціональності за пріоритетами, зібраними від команд
- Документація та навчання — TechDocs у Backstage, воркшопи для розробників
- Передача — платформа переходить під ownership DevOps-команди замовника
| Масштаб | Оцінка строків |
|---|---|
| Стартап, до 10 розробників | 2–4 тижні |
| Компанія, 10–50 розробників | 1–2 місяці |
| Велика структура, 50+ розробників | 2–3 місяці |
Вартість MVP Platform Engineering — від 5000 до 15000 USD залежно від складності. Наші інженери мають 10+ років досвіду в DevOps і допомогли більш ніж 50 проєктам впровадити Platform Engineering. Згідно з опитуваннями організацій, які перейшли на платформний підхід, час виведення фіч на ринок скорочується на 40–60%, а задоволеність розробників (Developer Experience) зростає вдвічі. Наші клієнти підтверджують ці цифри: після впровадження кількість звернень до DevOps падає на 70%, а середня економія на DevOps-трудозатратах становить 2000–5000 USD на місяць.
Переваги Platform Engineering
Platform Engineering в 2 рази підвищує задоволеність розробників порівняно з традиційним DevOps. Крім того, згідно з опитуваннями, час виведення фіч скорочується на 40–60%.
Типові помилки при запуску Platform Engineering
- Будувати платформу без спілкування з розробниками. Результат — інструмент, який технічно правильний, але не вирішує реальних проблем. Developer portal без контенту і без adoption — це просто ще один інструмент, який потрібно підтримувати.
- Автоматизувати винятки, а не правило. Якщо 80% сервісів — Node.js, починати з Rust template — неправильно. Автоматизуй спочатку те, що використовується щодня.
- Ігнорувати governance. Self-service не означає «роби що хочеш». Платформа повинна гарантувати, що кожен створений через неї сервіс відповідає стандартам безпеки: правильні resource limits, network policies, non-root контейнер. Це кодується в шаблонах, а не в code review.
Порівняння підходів: Platform Engineering vs традиційний DevOps
| Критерій | Традиційний DevOps | Platform Engineering |
|---|---|---|
| Час на onboarding нового сервісу | від 2 тижнів | до 40 хвилин |
| Self-service для розробників | ні (тікети) | так (через портал) |
| Стандартизація деплою | різна в кожному проєкті | єдиний golden path |
| Навантаження на DevOps | висока (реактивний режим) | знижується в 3–5 разів |
Що входить в роботу
- Аудит поточної інфраструктури та developer journey
- Дизайн golden path і вибір стеку
- Впровадження Backstage та налаштування DevPortal
- Налаштування CI/CD автоматизації та self-service provisioning
- Створення документації в TechDocs
- Проведення воркшопу для команди розробників
- Підтримка на період трансферу знань
Хочете скоротити час релізів і позбавити команду від рутини? Оцінимо ваш проєкт — пишіть. Platform Engineering під ключ для вашої команди: за 2–4 тижні для стартапів, 1–2 місяці для компаній. Зв'яжіться з нами — обговоримо, як Platform Engineering підійде вашому стеку.
