Что это простыми словами
Platform Engineer (платформенный инженер) — это специалист, который строит внутренние инструменты для других разработчиков в компании. Его задача — сделать так, чтобы команды могли быстро разворачивать приложения, настраивать мониторинг и базы данных одной кнопкой, не копаясь в инфраструктуре каждый раз заново.
Аналогия: представьте большую стройку. Каждая бригада могла бы сама таскать материалы, ставить леса, подключать электричество — но это долго и неэффективно. Platform Engineer — это тот, кто строит общую инфраструктуру стройки: подъёмные краны, склады с готовыми модулями, электрощиты. Бригады берут готовое и сосредотачиваются на своей работе, а не на логистике.
Официальное определение
Теперь, когда суть понятна, вот как эту роль описывают в вакансиях. Такую формулировку вы будете получать от заказчика и видеть в резюме.
«Platform Engineer — специалист, разрабатывающий внутреннюю платформу разработки (Internal Developer Platform), которая автоматизирует инфраструктурные процессы и предоставляет self-service инструменты для команд разработки».
Разберём по словам. «Internal Developer Platform» (IDP) — это внутренняя платформа компании: набор инструментов и веб-интерфейсов, через которые разработчики сами развёртывают приложения, настраивают CI/CD, получают доступ к базам данных — без участия DevOps или админов. «Self-service» — принцип самообслуживания: нажал кнопку, запустил команду — всё настроилось автоматически, не нужно писать тикет в поддержку. «Автоматизация инфраструктурных процессов» — превращение ручных операций в автоматические: вместо «попросить админа настроить сервер» теперь «нажать кнопку в портале».
Что делает за обычный день
Разрабатывает и поддерживает внутренние порталы разработчика — веб-интерфейсы, где команды создают новые сервисы, смотрят документацию, проверяют статус своих приложений. Пишет шаблоны для быстрого создания проектов: разработчик за одну команду получает готовый репозиторий с CI/CD, тестами и инфраструктурой.
Настраивает инструменты для наблюдаемости: логи, метрики, трассировки — чтобы разработчики сами видели, что происходит с их приложениями, не дёргая DevOps за каждой цифрой. Интегрирует разрозненные системы (Kubernetes, CI/CD, облака, базы данных) в единую платформу, чтобы разработчику не приходилось разбираться в каждой отдельно. Пишет код на Go, Python или других языках для автоматизации и CLI-инструментов.
Из чего состоит направление
Platform Engineering — это пересечение DevOps, разработки и product-подхода. Суть направления — построить платформу как продукт для внутренних пользователей (разработчиков).
Ключевые области:
Developer Experience (DX) — удобство работы разработчика: насколько быстро и просто развернуть приложение, получить доступ к ресурсам, найти документацию.
Infrastructure as Code (IaC) — описание инфраструктуры кодом (Terraform, Crossplane), чтобы всё было воспроизводимо и автоматизировано.
CI/CD и автоматизация — настройка пайплайнов, чтобы код автоматически тестировался и деплоился.
Observability — инструменты для мониторинга, логирования и трассировки (OpenTelemetry, Prometheus, Grafana).
Каталоги сервисов — централизованные реестры всех сервисов компании, их владельцев, документации, зависимостей (Backstage, Port).
Инструменты простыми словами
Инструменты Platform Engineer удобно разложить по четырём слоям — от самого важного при отборе к вспомогательному.
Слой 1. Языки программирования — фундамент, на котором пишется автоматизация.
Go — быстрый язык для написания инфраструктурных инструментов и CLI. Популярен в облачных и Kubernetes-экосистемах, многие современные платформенные инструменты написаны на нём.
Python — универсальный язык для скриптов, интеграций и автоматизации. Проще Go, богатая экосистема библиотек, подходит для быстрых прототипов.
Слой 2. Developer Portals — веб-интерфейсы и каталоги сервисов для разработчиков.
Backstage — open-source платформа от Spotify: каталог сервисов, документация, шаблоны для создания новых проектов, плагины для интеграции с CI/CD, облаками, Kubernetes. Широко используется как основа для внутренних порталов разработчика.
Port — коммерческий продукт с похожим функционалом: каталог, self-service действия, визуализация зависимостей. Проще в установке, чем Backstage, но платный.
Слой 3. Инфраструктурные инструменты — управление облаками и Kubernetes.
Crossplane — инструмент для управления облачной инфраструктурой через Kubernetes API. Позволяет создавать базы данных, сети, серверы декларативно, как обычные Kubernetes-ресурсы. Разработчик пишет YAML-манифест, Crossplane создаёт реальные ресурсы в AWS, Azure или GCP.
Terraform — классический инструмент Infrastructure as Code. Описываете инфраструктуру кодом, Terraform создаёт её в облаке. Crossplane — более новый подход, интегрированный с Kubernetes.
Kubernetes — платформа для запуска контейнеров. Большинство современных платформ строится поверх Kubernetes.
Слой 4. Observability — инструменты наблюдаемости и мониторинга.
OpenTelemetry — стандарт для сбора логов, метрик и трассировок из приложений. Как общий язык для всех систем мониторинга: приложение один раз интегрирует OpenTelemetry, а дальше данные можно отправить в любую систему.
Prometheus, Grafana — стандартный стек для метрик и дашбордов. Prometheus собирает цифры (сколько запросов, сколько ошибок), Grafana рисует из них графики.
Что взаимозаменяемо, а что путать нельзя
Platform Engineer и DevOps Engineer — близкие, но не одно и то же. DevOps поддерживает инфраструктуру и CI/CD, часто решает задачи вручную или автоматизирует точечно. Platform Engineer строит платформу как продукт: self-service интерфейсы, шаблоны, порталы — чтобы DevOps-задач стало меньше. В некоторых компаниях эти роли объединены, в других разделены. Переход между ними возможен, но требует смещения фокуса с инфраструктуры на developer experience.
Backstage и Port взаимозаменяемы — оба решают задачу каталога сервисов и developer portal. Опыт с одним помогает освоить другой. Crossplane и Terraform тоже решают схожую задачу (Infrastructure as Code), но подходы разные: Terraform — отдельный инструмент, Crossplane — расширение Kubernetes. Переход между ними требует времени, но не критичен.
Go и Python — оба используются, но Go предпочтительнее в инфраструктурных проектах. Если кандидат знает один язык, второй освоит, но при выборе между равными Go даёт преимущество в современном стеке.
Уровни: junior / middle / senior
Уровень (грейд) определяется не годами, а самостоятельностью и масштабом задач.
Junior — настраивает существующие инструменты по инструкции, пишет простые скрипты и шаблоны под руководством старших. Нужен контроль и код-ревью.
Middle — самостоятельно разрабатывает фичи платформы, интегрирует инструменты, пишет документацию. Берёт задачу целиком и доводит до продакшена. Основная рабочая сила команды.
Senior — проектирует архитектуру платформы, выбирает инструменты и подходы, собирает обратную связь от пользователей (разработчиков), улучшает developer experience. Мыслит продуктово: как сделать платформу удобной и нужной.
Это общий ориентир. В разных компаниях требования отличаются, поэтому всегда сверяйтесь с текстом конкретной вакансии.
Как узнать роль в резюме
Ищите в разделе «опыт» или «навыки» упоминания Internal Developer Platform, Backstage, Port, developer experience, self-service. Хороший признак — описание задач через призму пользователя: «разработал портал, где команды сами создают сервисы», «автоматизировал onboarding новых проектов», «снизили время развёртывания с недели до часа».
В стеке технологий должны быть: Kubernetes, один из языков (Go, Python), инструменты IaC (Terraform, Crossplane), CI/CD (GitHub Actions, GitLab CI, Jenkins). Если человек называет себя Platform Engineer, но в опыте только настройка серверов без упоминания платформ и developer experience — скорее, это DevOps или системный администратор.
Что спросить на первичном скрининге
Строили ли вы внутреннюю платформу для разработчиков? Какие инструменты использовали?
Нормальный ответ: «Внедрили Backstage, добавили шаблоны для создания сервисов, интегрировали с CI/CD». Насторожить должно отсутствие конкретики или упор только на инфраструктуру без упоминания удобства разработчиков.
Как вы собирали обратную связь от разработчиков и что изменили на её основе?
Нормальный ответ: «Провели опрос, узнали, что долго разворачивается база, автоматизировали через self-service». Platform Engineer должен думать о пользователях, а не только о технологиях.
На каком языке писали автоматизацию и CLI-инструменты?
Нормальный ответ: «На Go писали операторы для Kubernetes, на Python — скрипты интеграции». Должен быть реальный опыт программирования, а не только конфигурирование готовых инструментов.
Работали ли с Kubernetes и Infrastructure as Code?
Нормальный ответ: «Да, разворачивали приложения в Kubernetes, инфраструктуру описывали в Terraform (или Crossplane)». Это база для роли.
Это общий ориентир. В разных компаниях требования отличаются, поэтому всегда сверяйтесь с текстом конкретной вакансии.
Частые путаницы и красные флаги
Platform Engineer ≠ DevOps Engineer. Близко, но Platform Engineer строит платформу как продукт для разработчиков, а не просто поддерживает инфраструктуру.
Platform Engineer ≠ системный администратор. Платформенный инженер пишет код, строит self-service, думает о developer experience — это не администрирование серверов.
Backstage ≠ Port — это конкурирующие инструменты, не взаимодополняющие. Если в вакансии указан Backstage, кандидат с опытом Port подходит: задача та же, инструмент другой.
Красный флаг: кандидат не может объяснить, как его работа помогла разработчикам. Platform Engineer должен думать об удобстве команд, а не только о технической корректности решений.
Красный флаг: в резюме только инфраструктурные задачи (настройка серверов, сети, бэкапы) без разработки платформенных инструментов. Это DevOps или sysadmin, а не Platform Engineer.