Developer

Platform Engineering: внутренние платформы, golden paths, self-service

↑ Этап 8 · Senior: надёжность, безопасность, платформа

По желанию~7 мин чтенияУровень: senior

Зачем это на собесе

Тренд и путь роста DevOps: внутренняя платформа как продукт, снижающая когнитивную нагрузку разработчиков.

Проблема

В росте организации DevOps «каждая команда сама» приводит к: разрозненным пайплайнам/шаблонам, высокой когнитивной нагрузке (разработчик должен знать Kubernetes, Terraform, безопасность, наблюдаемость), дублированию, очередям в команду DevOps (тикеты), неодинаковому качеству и рискам безопасности.

Platform Engineering — проектирование и развитие внутренней платформы разработчика (IDP — Internal Developer Platform): набора самообслуживаемых инструментов, сервисов и стандартных путей, позволяющих командам быстро и безопасно поставлять ПО. Платформа — продукт, а разработчики — её клиенты.

Ключевые понятия

ПонятиеСуть
IDPсамообслуживаемая платформа: окружения, деплой, наблюдаемость, секреты, доступы, документация
Golden path (золотой путь)рекомендуемый, поддерживаемый и автоматизированный способ решить типовую задачу («создать сервис → пайплайн → деплой → мониторинг»); «быстро и безопасно по умолчанию», но не принуждение
Paved road (асфальтированная дорога)то же: удобный путь, отклонение возможно, но на свой риск
Self-serviceразработчик сам создаёт ресурсы через портал/CLI/Git без тикетов
Developer Experience (DevEx)удобство, скорость обратной связи, снижение трения
Cognitive loadобъём знаний, необходимых для работы; платформа его абстрагирует
Team Topologiesтипы команд: stream-aligned (продуктовые), platform team, enabling, complicated-subsystem; взаимодействия: X-as-a-Service, коллаборация, фасилитация
Platform as a Productroadmap, обратная связь, метрики, поддержка, документация, SLA

Слои платформы

Developer Portal (Backstage, Port, Cortex, OpsLevel) — каталог, шаблоны, документация, self-service
        │
Оркестрация / Control plane (Crossplane, Terraform/OpenTofu, Humanitec Score/Orchestrator, Kratix, Argo/Flux)
        │
Инфраструктура и сервисы (Kubernetes, облака, БД/очереди как сервис, сети, секреты, реестры)
        │
Сквозные возможности: CI/CD, GitOps, observability (метрики/логи/трейсы), безопасность (политики, сканирование), FinOps, доступ (SSO/RBAC)

Backstage

Открытый фреймворк Developer Portal (Spotify, CNCF):

  • Software Catalog: все сервисы, библиотеки, команды, API, владельцы, зависимости (catalog-info.yaml в каждом репозитории; сущности Component, API, System, Domain, Resource, Group, User);
  • Software Templates (Scaffolder): создание нового сервиса по шаблону (репозиторий, CI, Helm/манифесты, регистрация в каталоге, мониторинг) одной формой;
  • TechDocs: документация как код (Markdown в репозитории → портал);
  • Плагины: Kubernetes (состояние подов), ArgoCD, GitLab/GitHub CI, PagerDuty/Grafana, SonarQube, Vault, стоимость, Scorecards, поиск;
  • Аутентификация (OIDC/Keycloak), права (permissions framework).
# catalog-info.yaml
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: clinic-api
  description: API записи на приём
  annotations:
    gitlab.com/project-slug: clinic/api
    argocd/app-name: clinic-api
    grafana/dashboard-selector: "service=clinic-api"
    pagerduty.com/integration-key: XXXX
spec:
  type: service
  lifecycle: production
  owner: team-clinic-backend
  system: clinic
  dependsOn: [resource:default/clinic-db]
  providesApis: [clinic-api]

Золотые пути (примеры)

  • Новый .NET-микросервис: шаблон репозитория (Dockerfile, .gitlab-ci.yml, Helm-чарт, health checks, OTel, логирование, алерты, SLO-заготовка), автоматическая регистрация в каталоге, создание namespace, доступов, pipeline, Sentry/Grafana-дашборд;
  • Окружение по запросу (preview-environment на MR), временные стенды с TTL;
  • БД/кэш/очередь как сервис (через Crossplane/операторы: заявка → PostgreSQL с бэкапами и мониторингом);
  • Секреты и доступы: запрос в Git/портале → автоматически через Vault/ESO;
  • Релиз: стандартный progressive delivery (canary), автооткат;
  • Наблюдаемость «из коробки»: метрики, логи, трейсы, дашборд, алерты по SLO;
  • Безопасность по умолчанию: сканирование образов, политики, подписи, non-root — встроены, без усилий команд.

Crossplane и control plane

Crossplane превращает Kubernetes в универсальный control plane: облачные ресурсы описываются как K8s-объекты (Managed Resources), а Composition/XRD создают собственные абстракции («PostgreSQLInstance: size=small, region=…»); команды запрашивают через Claim, платформа реализует детали (облако, сеть, бэкапы, теги). Альтернативы: Terraform + Atlantis/Spacelift, Pulumi, Humanitec, Kratix, Cluster API (кластеры).

apiVersion: platform.example.org/v1
kind: PostgreSQLInstance
metadata: { name: clinic-db, namespace: clinic }
spec: { size: small, version: "17", backups: { enabled: true, retentionDays: 14 }, environment: prod }

Метрики платформы

  • DORA: частота деплоев, lead time, change failure rate, MTTR — для продуктовых команд;
  • Adoption: доля сервисов на золотом пути, использование шаблонов;
  • Time to first deploy / onboarding time нового сервиса/разработчика (дни → часы);
  • Self-service ratio (доля запросов без тикетов), число тикетов в платформенную команду, время выполнения запросов;
  • Developer satisfaction (NPS, опросы, SPACE/DevEx Framework), когнитивная нагрузка (опросы);
  • Надёжность платформы (SLO платформы, аптайм CI, время сборки), стоимость платформы и экономия.

Платформенная команда

  • состав: инженеры платформы (SRE/DevOps/разработчики), продакт-менеджер платформы, технический писатель/DevRel внутренний;
  • работа как продуктовая: интервью и опросы клиентов (разработчиков), roadmap, приоритизация по ценности, MVP + итерации, документация и обучение, поддержка (каналы, on-call платформы), обратная связь;
  • принципы: не навязывать, добиваться использования ценностью; пороги входа; расширяемость (возможность выйти за золотой путь с guard-rails); абстракция без сокрытия (разработчик может увидеть, что под капотом);
  • интерфейсы: Git/PR (декларативные запросы), CLI, портал/UI, API;
  • governance: политики и guardrails (policy as code), а не ручные согласования; автоматические проверки соответствия (scorecards: обязательные владельцы, SLO, runbook, сканирование).

Антипаттерны

  • «Ivory tower»: платформа без участия пользователей, навязанная сверху;
  • «DevOps как сервисная команда»: тикеты вместо самообслуживания;
  • Слишком ранняя/гигантская платформа (overengineering) при малой организации: до ~50–100 разработчиков часто достаточно общих шаблонов;
  • Портал без автоматизации (красивый каталог, но все операции вручную);
  • Отсутствие метрик и продукта (нет владельца, обратной связи);
  • Жёсткая унификация без гибкости: команды обходят платформу;
  • Копирование чужих решений без адаптации.

Этапы внедрения

  1. Пойти к командам: где боль и потери времени (онбординг, окружения, релизы, доступы).
  2. Стандартизировать: шаблоны репозитория, единый пайплайн, базовые чарты, наблюдаемость.
  3. Каталог (Backstage или проще: реестр сервисов).
  4. Self-service: автоматизировать самые частые запросы (создать сервис, окружение, БД, доступ).
  5. Политики и scorecards: безопасность и зрелость по умолчанию.
  6. Измерять и улучшать (DORA, DevEx, adoption).

Вопросы с ответами

Вид графа

Обратные ссылки