Настройка Platform Engineering подхода для DevOps

Команды разработчиков тратят часы на задачи, которые не связаны с продуктом: настраивают локальное окружение, разбираются с деплоем в 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 setup?

Архитектура платформы зависит от зрелости организации, но типовой стек выглядит так:

• Control plane платформы — чаще всего Backstage (CNCF проект от Spotify). Backstage служит порталом разработчика: 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.

Backstage software templates позволяют кодифицировать этот процесс:

# 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 раз быстрее.

Этапы работы

1. Аудит — интервью с командами, карта текущего developer journey, выявление bottleneck'ов
2. Проектирование — выбор стека, дизайн golden path, договорённости о стандартах
3. MVP платформы — минимальный набор инструментов, решающий самую острую боль
4. Итеративное развитие — расширение функциональности по приоритетам, собранным от команд
5. Документация и обучение — TechDocs в Backstage, воркшопы для разработчиков
6. Передача — платформа переходит под ownership DevOps-команды заказчика

Стоимость рассчитывается индивидуально — зависит от текущего состояния инфраструктуры, количества интеграций и объёма переноса существующих сервисов на платформу. Наши инженеры имеют 10+ лет опыта в DevOps и помогли более чем 50 проектам внедрить Platform Engineering. Получите консультацию, чтобы оценить ваш проект.

Почему Platform Engineering выгоднее традиционного DevOps?

Согласно опросам организаций, перешедших на платформенный подход, время вывода фич на рынок сокращается на 40–60%, а удовлетворённость разработчиков (Developer Experience) растёт в 2 раза. Наши клиенты подтверждают эти цифры: после внедрения количество обращений к DevOps падает на 70%.

Типичные ошибки при запуске 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

Хотите сократить время релизов и избавить команду от рутины? Свяжитесь с нами — обсудим, как Platform Engineering подойдёт вашему стеку.