Platform Engineer строит internal developer platform, golden path и self-service для разработчиков. SkillStat показывает вакансии, медиану зарплаты, спрос, навыки и курсы.
Platform Engineer отвечает за путь, по которому разработчики создают, выпускают и сопровождают приложения. Его продуктом становятся внутренние инструменты: service templates, CI/CD, GitOps, окружения, секреты, observability, портал, API, CLI и документация.
Главная ценность роли — сократить повторяемую инфраструктурную работу без превращения платформы в бюрократию. Хорошая платформа помогает команде сделать типовой шаг самостоятельно, а сложный случай передать с понятным контекстом.
Свежие данные рынка: 11 активных вакансий, медиана зарплаты 210 000 ₽, спрос 6/100. Срез по Москве и МО от 23.06.2026.
Для этой профессии доступны ограниченные данные. Аналитика носит ориентировочный характер.
По зарплате у профессии нет достаточной собственной актуальной выборки. Поэтому на странице показана оценка с явной маркировкой источника, а не точная медиана только по текущим активным вакансиям.
Числовые метрики показывают вакансии Москвы и Московской области. Описание роли, задач и навыков относится к профессии в целом.
Актуальный срез по вакансиям, зарплате, спросу и динамике найма для платформенного инженера в Москве и МО.
Platform Engineer — это платформенный инженер, который строит внутреннюю платформу разработки. Его задача не в том, чтобы лично настраивать каждый сервис, а в том, чтобы типовой путь был понятным, безопасным и повторяемым для многих команд. В этот путь входят шаблоны приложений, CI/CD, GitOps, инфраструктура как код, секреты, окружения, observability, документация, портал, API или CLI для самообслуживания.
Профессию часто путают с DevOps, SRE или системным администрированием, потому что инструменты пересекаются. Разница в фокусе: DevOps чаще помогает поставке и инфраструктурным практикам, SRE отвечает за измеримую надёжность production, а Platform Engineer строит внутренний продукт для разработчиков. Его результат — не отдельно настроенный кластер, а удобный путь от репозитория до рабочей среды, которым команды могут пользоваться без постоянной ручной помощи.
Платформенная инженерия нужна там, где компания уже выросла из личных договорённостей. Если каждый новый сервис заводится по-разному, секреты и окружения настраиваются вручную, а документация живёт в головах нескольких людей, скорость разработки падает и растёт риск ошибок. Платформа должна снизить эту сложность, но не стать жёсткой клеткой: хороший golden path удобнее обходного пути, а исключения описаны прозрачно.
Internal developer platform, developer portal, golden path и self-service для команд разработки
Снижает ручные заявки, ускоряет старт сервисов и делает релизы безопаснее
Платформа может стать golden cage, если её внедрять без пользователей и обратной связи
Платформенный инженер проектирует и развивает внутренние инструменты разработки. Он помогает командам не собирать каждое приложение с нуля и не вспоминать вручную правила релиза, секретов, окружений и мониторинга.
В работе много инфраструктуры, но фокус шире инструментов. Нужно понять сценарий разработчика, убрать лишний шаг, оставить понятную документацию и сделать так, чтобы стандартный путь был удобнее обходного.
Платформенный стандарт живёт на границе нормы и исключения. Если всё запретить, платформа замедлит разработку. Если всё разрешить, компания вернётся к хаосу разных окружений и ручных релизов.
Сильный инженер выбирает базовый путь, описывает допустимые расширения и заранее продумывает миграцию старых сервисов.
Platform Engineer не равен DevOps, SRE или Kubernetes-инженеру. Пересечения есть, но фокус другой: платформа — внутренний продукт для разработчиков. Если специалист только чинит окружения по заявкам, это ещё не платформенная роль.
Эта таблица помогает быстро понять профессию и не спутать platform engineering с обычным DevOps или администрированием Kubernetes.
| Параметр | Значение | Как читать |
|---|---|---|
| Кто это | Платформенный инженер, который строит internal developer platform | Пользователь результата — разработчики и инженерные команды |
| Главная задача | Сделать типовой путь сервиса быстрым, безопасным и повторяемым | Важен путь от репозитория до production, а не один инструмент |
| Что строит | Golden path, self-service, service templates, CI/CD, GitOps, observability, portal | Платформа должна помогать, а не заставлять через бюрократию |
| Кто пользователь | Разработчики, DevOps, SRE, QA, security, продуктовые команды | Platform Engineer работает с внутренними пользователями как с клиентами продукта |
| Ключевые навыки | Linux, Python, Bash, Kubernetes, Grafana, Prometheus, Docker, CI/CD, Terraform | Частотность навыков смотрите в live-блоке SkillStat |
| Медиана зарплаты | 210 000 ₽, Оценка по профессии и близкому рынку, n=4 | Медиана по Москве и МО на 23.06.26, не гарантия по каждому грейду |
| Вакансии и спрос | 11 вакансий, спрос 6/100, ранг #54 из 71 | Отдельная роль пока нишевая; часть спроса спрятана в DevOps/SRE/Cloud |
| Формат работы | Удалённо 9%, гибрид 45%, офис 45% | Платформенная работа требует плотной коммуникации с командами |
| Уровень входа | Senior 78%, Middle 77.8%, Junior —, Intern —, Lead — | Junior-вход есть, но рынок сильно смотрит на опыт |
| Куда растёт | Senior/Lead Platform Engineer, Staff, Platform Architect, Engineering Productivity | Рост идёт через влияние на много команд и стратегию платформы |
Рабочий день платформенного инженера редко состоит только из настройки кластера. Он начинается с повторяемой проблемы команды и заканчивается платформенной возможностью, которую можно поддерживать как продукт.
| Ситуация | Что делает Platform Engineer | Какой результат ожидается | Как измерить эффект | Когда нужна эскалация или исключение |
|---|---|---|---|---|
| Новый сервис долго запускается | Разбирает шаги от репозитория до окружения и убирает ручные ожидания | Service template и documented golden path | Time to first deploy, количество ручных заявок | Если сервис нарушает типовые требования или нужен новый capability |
| Команды вручную настраивают одинаковые пайплайны | Выносит повторяемые стадии в общий шаблон | Единый pipeline с понятными расширениями | Reuse rate шаблонов, failed deployments | Если команда имеет нестандартный release flow |
| Секреты хранятся хаотично | Проектирует безопасный способ выдачи и обновления секретов | Guardrails для секретов без ручной передачи | Policy compliance rate, инциденты секретов | Если есть legacy-сервис без поддержки нового механизма |
| Окружения dev/stage/prod расходятся | Описывает IaC-модель и controlled differences | Предсказуемые окружения с видимыми отличиями | Drift incidents, время создания окружения | Если старый сервис нельзя мигрировать сразу |
| Разработчики не видят логи и метрики приложения | Подключает базовый dashboard и ссылки из service catalog | Команда сама видит состояние сервиса | Снижение обращений в поддержку, быстрее triage | Если нужны production-доступы повышенного риска |
| Релиз требует ручного согласования | Встраивает проверки и approval там, где они действительно нужны | Меньше ручных блокировок без потери governance | Lead time, deployment frequency | Если compliance требует отдельный контроль |
| Новый сотрудник долго разбирается в инфраструктуре | Улучшает onboarding, docs и примеры | Понятный путь для первого сервиса | Onboarding time, documentation usefulness | Если знания спрятаны в командах-владельцах |
| Команды обходят платформу через личные договорённости | Ищет причину обхода, а не усиливает запрет | Удобный стандарт и прозрачные исключения | Adoption rate, manual exceptions | Если обход связан с срочным бизнес-риском |
| Security требует обязательные проверки | Встраивает проверки как guardrails | Безопасность появляется раньше релиза | Policy compliance rate, false blocks | Если правило ломает легитимные сценарии |
| Старый сервис нужно мигрировать на новый путь | Планирует поэтапную миграцию и совместимость | Сервис входит в новый путь без остановки разработки | Migration progress, support tickets | Если миграция требует архитектурных изменений |
Платформа работает только тогда, когда её удобно использовать. Административное принуждение даёт видимость стандарта, но не решает developer experience.
| Принцип | Что означает | Как выглядит на практике | Ошибка новичка | Метрика успеха |
|---|---|---|---|---|
| Platform as a Product | У платформы есть пользователи, roadmap и value | Команда собирает feedback и планирует capability | Считать платформу набором скриптов | Adoption и self-service rate |
| Developer Experience | Снижение трения для разработчика | Понятные шаблоны, docs, быстрый первый deploy | Мерить только число инструментов | Developer satisfaction |
| Self-service | Типовой запрос выполняется без личной заявки | Портал, API, CLI или шаблон | Оставить ручные согласования везде | Ticket reduction |
| Golden Path | Рекомендуемый end-to-end путь сервиса | Repo, CI/CD, IaC, deploy, observability | Сделать золотую клетку | Golden path coverage |
| Thinnest Viable Platform | Минимальная полезная платформа | Сначала закрыть самый частый путь | Строить универсальную платформу сразу | Time to first value |
| Documentation as Product | Документация — часть интерфейса | README, examples, troubleshooting, ownership | Писать документацию после внедрения | Documentation usefulness |
| Feedback Loop | Команды влияют на развитие платформы | Интервью, issues, офис-часы, roadmap | Игнорировать обходные пути | Доля повторных проблем |
| Guardrails, not Gates | Правила помогают, а не блокируют без причины | Security checks с понятным сообщением | Превратить платформу в бюрократию | Policy compliance без роста lead time |
| Controlled Exceptions | Исключения прозрачны и управляемы | Есть процесс, владелец и срок пересмотра | Запретить всё нестандартное | Number of manual exceptions |
Backstage или другой портал может быть важной частью платформы, но не заменяет всю платформенную экосистему.
| Термин | Простое объяснение | Что делает | Чем не является | Пример использования |
|---|---|---|---|---|
| Internal Developer Platform | Вся система возможностей для разработчиков | Оркестрирует шаблоны, CI/CD, IaC, секреты, окружения, observability | Не один интерфейс и не один кластер | Команда создаёт сервис и получает готовый путь |
| Internal Developer Portal | Единое окно к платформе | Показывает каталог, docs, templates, ownership, links | Не выполняет всю automation сам | Разработчик находит сервис и запускает шаблон |
| Backstage | Open-source developer portal | Service catalog, software templates, TechDocs, plugins | Не делает компанию платформенной сам по себе | Портал для сервисов и стандартных действий |
| Service catalog | Каталог сервисов и владельцев | Показывает owner, lifecycle, зависимости, ссылки | Не заменяет observability | Найти команду, repo, dashboard и docs |
| Software templates | Шаблоны новых сервисов | Создают repo, структуру, pipeline и базовые файлы | Не должны быть копипастой без поддержки | Создать backend-service по стандарту |
| Platform APIs / CLI | Программный интерфейс self-service | Позволяет автоматизировать платформенные действия | Не должен обходить guardrails | Создать окружение или запросить capability |
| GitOps | Модель доставки через Git как источник правды | Синхронизирует желаемое состояние | Не заменяет product-подход | Изменение платформы проходит через review |
| Developer control plane | Слой управления платформенными возможностями | Связывает portal, automation, policies и ownership | Не один vendor-продукт | Единое управление стандартными сценариями |
Golden path должен быть рекомендуемым путём, а не тюрьмой. Команда должна понимать, что платформа скрывает, какие правила встроены и как оформить исключение.
| Этап пути | Что получает разработчик | Что скрывает платформа | Какие guardrails встроены | Метрика успеха |
|---|---|---|---|---|
| Создание нового сервиса | Понятный старт без пустого репозитория | Выбор структуры, базовых файлов и owners | Минимальные standards и naming | Time to create service |
| Репозиторий и шаблон проекта | Готовую структуру и README | Повторяемую настройку проекта | Required files и code owners | Reuse rate templates |
| CI/CD | Pipeline по умолчанию | Стадии сборки, тестов, артефактов | Quality gates без лишних блокировок | Failed deployments |
| Контейнеризация | Предсказуемый runtime | Базовые образы и registry | Security scan и versioning | Build success rate |
| Инфраструктура и окружения | Dev/stage/prod с понятными различиями | IaC-модули и cloud details | Policy-as-code и limits | Environment creation time |
| Секреты и доступы | Безопасный способ подключить секрет | Backend хранилища и rotation | Least privilege | Secret policy compliance |
| Деплой | Стандартный release flow | GitOps, approvals, rollout details | Rollback/canary criteria | Deployment frequency |
| Observability | Логи, метрики, traces и dashboards | Инструментальные детали | Минимальный набор signals | MTTR и dashboard usage |
| Документация | Инструкции и troubleshooting | Поиск владельцев и ссылок | Docs review | Documentation usefulness |
| Support / ownership | Понятно, кто отвечает за сервис | Case management детали | Escalation path | Ticket resolution time |
Внутренняя платформа состоит из слоёв. Инструменты могут отличаться, но каждый слой должен отвечать на понятную пользовательскую задачу.
| Слой платформы | Зачем нужен | Типичные инструменты | Кто пользователь | Что важно не забыть |
|---|---|---|---|---|
| Developer portal | Единое окно платформы | Backstage, Port, Humanitec | Разработчики и владельцы сервисов | Портал не заменяет automation |
| Service catalog | Ownership и карта сервисов | Backstage catalog, CMDB | Разработка, SRE, security | Данные должны обновляться |
| Software templates | Быстрый старт сервиса | Backstage templates, cookiecutter | Разработчики | Шаблоны нужно поддерживать |
| CI/CD | Сборка, тесты, публикация | GitLab CI, GitHub Actions, Jenkins | Разработка и DevOps | Не скрывать ошибки непонятно |
| GitOps | Декларативный deploy | Argo CD, Flux | DevOps, SRE, разработчики | Нужен review и rollback |
| Infrastructure as Code | Повторяемые окружения | Terraform, OpenTofu, Crossplane | Platform, cloud, DevOps | Не раскрывать лишнюю сложность |
| Secrets management | Безопасные секреты | Vault, External Secrets | Разработка, security | Rotation и least privilege |
| Observability | Видимость состояния сервиса | Prometheus, Grafana, Loki, ELK, OpenTelemetry, Jaeger | Разработка и SRE | Дашборд должен вести к действию |
| Policy-as-code | Guardrails и compliance | OPA, Kyverno | Security, platform | Правила не должны ломать поток без объяснения |
| APIs / CLI | Self-service вне портала | REST API, CLI, SDK | Инженерные команды | Интерфейс должен быть стабильным |
| Cost management / FinOps | Контроль стоимости окружений | Cloud billing, tags, reports | Platform, product, finance | Не оптимизировать вслепую |
| Incident and support process | Понятный путь помощи | Jira, ServiceNow, on-call docs | Все пользователи платформы | Support — часть продукта |
Платформу нельзя оценивать только количеством внедрённых инструментов. Хорошая метрика показывает, стало ли командам проще и безопаснее выпускать изменения.
| Метрика | Что показывает | Почему важна | Как улучшает работу команд | Ошибка интерпретации |
|---|---|---|---|---|
| Adoption rate | Доля команд на платформе | Показывает доверие к платформе | Помогает искать причины обхода | Считать adoption принуждением |
| Time to first deploy | Сколько нужно до первого деплоя | Показывает скорость старта | Ускоряет onboarding сервиса | Игнорировать качество результата |
| Time to create service | Время создания сервиса | Снимает самый частый friction | Уменьшает ожидание DevOps | Считать только happy path |
| Lead time for changes | Путь изменения до релиза | Связывает платформу с delivery | Убирает лишние ручные шаги | Смешивать с продуктовой сложностью |
| Deployment frequency | Частота безопасных релизов | Показывает доверие к delivery | Команды выпускают меньше batch-релизов | Гнаться за частотой без стабильности |
| Change failure rate | Доля неудачных изменений | Показывает качество guardrails | Помогает улучшать проверки | Считать все сбои виной платформы |
| Self-service rate | Доля сценариев без заявки | Измеряет настоящую платформенность | Снижает очередь поддержки | Скрывать ручные согласования |
| Ticket reduction | Снижение ручных заявок | Показывает снятую нагрузку | Освобождает platform/SRE время | Срезать полезную поддержку |
| Developer satisfaction | Оценка удобства разработчиками | Сигналит о реальном DevEx | Направляет roadmap | Заменять данными только мнением |
| Golden path coverage | Какие сценарии покрыты | Показывает зрелость стандартного пути | Убирает хаотичные решения | Пытаться покрыть всё сразу |
| Number of manual exceptions | Сколько обходов требуется | Показывает трение и legacy | Помогает улучшать правила | Запретить исключения без анализа |
сценарии, критерии и постановка задачи
данные, api, статусы и интеграции
согласование и работа с разработкой
Рабочий цикл платформенного инженера начинается с боли разработчиков. Потом он превращает повторяемую проблему в self-service capability, проверяет её на реальных сервисах и сопровождает как внутренний продукт.
Смотрит, какие инфраструктурные действия команды делают вручную снова и снова: сервисы, доступы, окружения, пайплайны, логи, метрики, документация.
Формулирует, кто пользователь платформы, какой шаг нужно упростить, какие guardrails обязательны и где нужны контролируемые исключения.
Собирает стандартный путь: шаблон сервиса, CI/CD, GitOps, секреты, окружения, observability, rollback и ownership.
Выносит типовой сценарий в портал, API, CLI, шаблон или документацию, чтобы разработчик не ждал ручной помощи.
Смотрит adoption, ticket reduction, time to first deploy, developer satisfaction и причины обхода платформы.
Роли пересекаются по инструментам, но отличаются пользователем результата и главной метрикой.
Многие команды разработки как пользователи внутреннего продукта.
Команда сервиса, production-пользователи или разработчики в зависимости от роли.
Повторяемый путь, который команды проходят самостоятельно.
Работающие пайплайны, надёжный сервис, улучшенная документация или tooling.
Adoption, time to first deploy, self-service rate, ticket reduction, developer satisfaction.
Lead time, SLO, MTTR, deployment frequency, incident rate или DevEx-сигналы.
Работодатели смотрят не только на Kubernetes, Terraform и CI/CD. Для платформенной роли важно показать, что инженер умеет превращать инфраструктурные практики в внутренний продукт: с пользователями, документацией, обратной связью, метриками и контролируемыми исключениями. В требованиях SkillStat чаще встречаются Linux, Python, Bash, Kubernetes, Grafana, Prometheus, Docker, CI/CD, PostgreSQL, Ansible, Terraform, GitLab и REST API, но этот список нужно читать как рабочий контекст, а не как полный учебник.
На собеседовании обычно проверяют кейсы: новый сервис запускается слишком долго, команды копируют одинаковые пайплайны, окружения расходятся, секреты хранятся хаотично, разработчики не видят логи и метрики, а платформа обходится через личные договорённости. Сильный кандидат объясняет исходную боль, пользователей, стандартный путь, разумные исключения и метрику эффекта.
Для senior и lead уровней особенно важна способность не строить платформу на все случаи жизни. Нужно выбрать thinnest viable platform, дать командам удобный paved road и не превратить внутренний продукт в бюрократический слой.
Рынок ориентирован на опытных специалистов.
Столько требований работодатели обычно собирают в одной позиции по этой роли.
Сравнение помогает не смешивать соседние роли SkillStat и показывает, где проходит граница ответственности Platform Engineer.
| Роль | Главный фокус | Пользователь результата | Чем занимается | Какие метрики важны | Чем отличается от Platform Engineer |
|---|---|---|---|---|---|
| Platform Engineer | Внутренняя платформа и self-service | Разработчики и инженерные команды | Строит golden path, IDP, portal, templates, automation | Adoption, self-service, time to first deploy | Базовая роль сравнения |
| DevOps-инженер | Delivery, automation, infrastructure practices | Команда сервиса | CI/CD, окружения, IaC, релизы | Lead time, deployment frequency | Не всегда строит общий продукт для многих команд |
| SRE-инженер | Надёжность production | Пользователи сервиса и продукт | SLO, incident response, postmortem, toil | SLO, MTTR, error budget | Фокус на reliability, а не на DevEx-платформе |
| Системный администратор | Работоспособность систем | Внутренние пользователи и инфраструктура | Серверы, доступы, ОС, базовая эксплуатация | Uptime, tickets, SLA | Чаще работает по системам и заявкам |
| Cloud Engineer | Облачная инфраструктура | DevOps, platform, product teams | Landing zones, IAM, сети, managed services | Cost, security, availability | Cloud — слой платформы, но не весь продукт |
| Infrastructure Engineer | Инфраструктурные компоненты | Инженерные команды | Compute, network, storage, automation | Availability, capacity | Может не отвечать за developer portal и adoption |
| DevEx Engineer | Опыт разработчика | Разработчики | Docs, tooling, feedback, onboarding | Developer satisfaction, friction | Может быть ближе к productivity, чем к infra layer |
| Platform Product Manager | Ценность и roadmap платформы | Пользователи платформы и бизнес | Исследует потребности, приоритизирует roadmap | Adoption, value, NPS | Не обязательно сам реализует инфраструктуру |
По данным SkillStat рынок заметно ориентирован на опытных специалистов: Senior 78%, Middle 77.8%, Junior —, Intern —, Lead —.
| Уровень | Роль | Типичные задачи | Какие навыки нужны | Что показать в портфолио | Куда расти дальше |
|---|---|---|---|---|---|
| Intern / стажёр | Помощник платформенной команды | Docs, простые templates, проверки инструкций | Git, Linux basics, YAML, аккуратность | Улучшенная документация и маленький template | Junior Platform Engineer |
| Junior Platform Engineer | Исполнитель понятных платформенных задач | Pipeline, Docker, базовый Kubernetes, dashboard | Linux, Docker, CI/CD, Bash/Python | Service template и простой golden path | Middle или DevOps/Platform |
| Middle Platform Engineer | Владелец компонента платформы | Terraform module, GitOps, secrets, portal, observability | Kubernetes, IaC, GitOps, feedback | Компонент платформы с adoption и docs | Senior Platform Engineer |
| Senior Platform Engineer | Проектировщик capability для нескольких команд | Roadmap, migration, guardrails, DevEx metrics | Architecture, security, communication | Миграция команд на новый путь | Lead или Staff |
| Lead Platform Engineer | Владелец стратегии платформы | Roadmap, standards, governance, команда | Platform as Product, negotiation | Платформенная стратегия и метрики | Platform Architect, Head of Platform |
| Staff / Principal Platform Engineer | Архитектор платформенной экосистемы | Оргуровень, архитектура, стандарты | Глубокий platform/system design | Архитектурный case study | Engineering Productivity / Architecture |
Навыки платформенного инженера удобнее читать слоями: продуктовый подход, инфраструктура, delivery, observability/governance, программирование и коммуникация.
| Группа | Что входит | Зачем нужно | Как подтверждать |
|---|---|---|---|
| Platform/Product skills | Platform as a Product, DevEx, golden path, user research, adoption, roadmap, docs, feedback loop | Чтобы платформа решала реальные боли команд | Case study с метриками и обратной связью |
| Infrastructure skills | Linux, networks, DNS, HTTP, Kubernetes, Docker, Terraform/OpenTofu, Ansible, Helm, cloud, IAM, secrets | Чтобы платформа могла создавать рабочие окружения | Учебный сервис и воспроизводимое окружение |
| Delivery skills | CI/CD, GitLab CI, GitHub Actions, Jenkins, Argo CD, Flux, GitOps, release strategy, rollback | Чтобы путь релиза был стандартным и безопасным | Pipeline и GitOps-flow с документацией |
| Observability and governance | Prometheus, Grafana, ELK/Loki, OpenTelemetry, Jaeger, alerting, OPA, Kyverno, scanning, FinOps | Чтобы команды видели сервис и соблюдали правила | Dashboard, policy и troubleshooting |
| Programming and soft skills | Python, Bash, Go, SQL, YAML, REST API, documentation, communication, systems thinking | Чтобы автоматизировать платформу и договариваться с пользователями | CLI/API prototype, docs и feedback loop |
Инструменты нужно описывать в резюме через безопасный платформенный сценарий: какой путь разработчика они улучшили и какую ручную работу убрали.
| Инструмент / класс | Для чего нужен | На каком уровне нужен | Как безопасно описать в резюме | Что важно понимать |
|---|---|---|---|---|
| Linux | База окружений и диагностики | Junior+ | Работал с Linux-средой платформы и документацией для команд | Не сводить роль к администрированию |
| Kubernetes | Запуск контейнерных сервисов | Junior+/Middle | Поддерживал путь деплоя сервисов в Kubernetes | Кластер не равен платформе |
| Docker | Контейнеризация сервисов | Junior+ | Описал стандарт сборки и запуска контейнера | Нужны registry и security basics |
| Helm | Упаковка Kubernetes-приложений | Middle | Поддерживал chart как часть golden path | Шаблон должен быть понятен пользователю |
| Terraform / OpenTofu | Infrastructure as Code | Middle | Сделал модуль типового окружения | Важны интерфейс модуля и миграции |
| Ansible | Конфигурация и automation | Junior+/Middle | Автоматизировал повторяемую настройку | Не плодить скрытую магию |
| GitLab CI / GitHub Actions / Jenkins | CI/CD | Junior+ | Собрал pipeline с docs и guardrails | Ошибки pipeline должны быть понятны |
| Argo CD / Flux | GitOps-деплой | Middle | Настроил GitOps-flow в учебной среде | Нужны ownership и rollback |
| Backstage / developer portal | Интерфейс платформы | Middle+ | Собрал catalog/template prototype | Портал — часть IDP, не вся платформа |
| Vault / External Secrets | Секреты | Middle+ | Встроил безопасный способ работы с секретами | Нужны least privilege и rotation |
| Prometheus / Grafana | Метрики и dashboards | Junior+ | Добавил базовую observability для сервиса | Dashboard должен вести к действию |
| Loki / ELK / OpenTelemetry / Jaeger | Логи и трассировки | Middle | Связал logs/traces с service catalog | Не перегружать команды сигналами |
| OPA / Kyverno / Trivy / SonarQube | Policy и проверки | Middle+ | Встроил guardrails в delivery | Правила должны объяснять отказ |
| Python / Bash / Go / REST API | Automation и интеграции | Junior+ | Автоматизировал self-service сценарий | Код должен быть поддерживаемым |
| Jira / ServiceNow | Support и case management | All | Связал platform support с ownership | Support — часть продукта |
Для estimated-режима грейдовые зарплаты не показываются, чтобы не создавать ложную точность.
Рынок Platform Engineer часто смешивается с DevOps, SRE, Cloud Engineer и Infrastructure Engineer, поэтому одна вакансия может быть платформенной по сути, но называться иначе. Доход растёт, когда специалист влияет не на один пайплайн, а на общий путь для нескольких команд: владеет internal developer platform, строит golden path, внедряет developer portal или Backstage, работает с Kubernetes и Terraform, GitOps, observability, secrets, security guardrails и platform adoption.
На уровень оплаты влияет способность снизить ручные заявки, улучшить time to first deploy, провести миграцию старых сервисов и договориться с SRE, security, архитектурой и разработчиками. Kubernetes сам по себе не делает инженера платформенным; важна польза для команд и бизнеса.
Спрос на платформенного инженера лучше читать как сочетание объёма найма, ранга профессии в общей выборке и устойчивости вакансий во времени. Виджеты выше дают быстрый срез рынка, а график ниже помогает понять, насколько этот спрос поддерживается от месяца к месяцу.
В срезе SkillStat по Москве и МО на 23.06.2026 у Platform Engineer 11 активных вакансий, спрос 6/100 и ранг #54 из 71, статус спроса — низкий. Это не массовая junior-профессия: отдельные платформенные команды чаще появляются в компаниях, где много сервисов, команд и повторяемых инфраструктурных операций. Текущую точку лучше читать вместе со значениями за 7 и 30 дней и сглаженными окнами: 78 и 41 показывают краткосрочный контекст, но помесячные средние остаются волатильными.
Часть спроса прячется в названиях DevOps, SRE, Infrastructure Engineer, Cloud Engineer, Platform Infrastructure Engineer или Internal Tools Engineer. Чтобы понять, платформенная ли вакансия перед вами, ищите слова IDP, developer portal, self-service, golden path, platform as product, Kubernetes, Terraform, GitOps, observability, secrets и CI/CD.
Если в описании есть только администрирование серверов, ручная поддержка пайплайнов и заявки без ответственности за общий путь разработчика, это скорее инфраструктурная или DevOps-роль, а не полноценный Platform Engineering.
Этот срез показывает, в каком формате работодатели чаще всего открывают вакансии по профессии: удалённо, гибридно или с полной привязкой к офису.
Грейдовые медианы не показаны: для платформенного инженера сейчас используется estimated-режим зарплаты, поэтому SkillStat не выводит отдельные зарплаты по уровням, чтобы не создавать ложную точность.
Intern помогает с документацией, простыми шаблонами, проверкой инструкций, небольшими pipeline-задачами и безопасной поддержкой учебных окружений. На этом уровне важно понять путь сервиса глазами разработчика.
Junior Platform Engineer понимает Linux, Git, Docker, базовый Kubernetes, CI/CD и документацию. Он может поддержать service template, простой pipeline, dashboard или инструкцию для разработчиков. По SkillStat junior-вход есть, но рынок всё равно заметно ориентирован на опытных специалистов.
Middle ведёт отдельный компонент платформы: Terraform-модуль, GitOps-деплой, observability, secrets, шаблон сервиса, портал или service catalog. От него ждут самостоятельной работы с пользователями платформы и понятного эффекта для команд.
Senior проектирует capability для нескольких команд, думает о adoption, миграциях, guardrails, DevEx-метриках и контролируемых исключениях. По SkillStat senior-вакансии составляют самую большую долю рынка.
Lead Platform Engineer управляет roadmap платформы, стандартами self-service, взаимодействием с SRE, security и архитектурой. Дальше рост возможен в Staff/Principal Platform Engineer, Platform Architect, Engineering Productivity или Platform Product Manager.
Платформа помогает множеству команд запускать сервисы по единому и понятному пути.
Большой вес получают безопасность, аудит, стандарты, управление секретами и контролируемые релизы.
Роль связана с масштабированием разработки, внутренним PaaS и удобством инженерных команд.
Практический путь входа в профессию: что освоить сначала, как собрать рабочую базу и на чём быстрее всего набирается прикладная уверенность.
Docker, CI/CD, GitLab CI или GitHub Actions, простое приложение и деплой, переменные окружения, базовые секреты и документация для разработчика.
Kubernetes, Helm, Terraform или OpenTofu, базовый cloud, GitOps, Prometheus, Grafana, логи и алерты в учебной среде.
Golden path, service template, developer portal или Backstage на концептуальном уровне, service catalog, self-service workflow, policy-as-code и migration plan.
Platform as a Product, DevEx-метрики, adoption, onboarding, developer feedback, security and governance, резюме и adjacent-вакансии DevOps, Platform, Infrastructure, Cloud, SRE support или internal tools.
Не начинайте с редких enterprise-инструментов, сложного multi-cloud и полной реализации Backstage. Сначала нужен один рабочий путь сервиса, понятная документация и измеримый эффект.
Портфолио должно показывать не набор конфигураций, а пользовательский путь разработчика и эффект для команды.
Шаблон нового сервиса: структура, README, владельцы, базовые проверки, инструкция запуска и ограничение области применения.
Golden path от репозитория до тестового окружения: CI/CD, контейнер, секреты в учебной схеме, деплой, логи и метрики.
Terraform/OpenTofu-модуль для типового окружения: входные параметры, безопасные значения по умолчанию, пример использования и миграционные ограничения.
GitOps-деплой в учебной среде: что меняет разработчик, что делает платформа, где видно состояние и как описан rollback.
Базовый service catalog или Backstage template: карточка сервиса, owner, документация, ссылки на логи, метрики и пайплайн.
Observability dashboard для учебного сервиса: latency, errors, traffic, saturation, логи и понятное действие при проблеме.
Policy-as-code для базовых проверок: какие guardrails встроены, почему они нужны и как оформляется контролируемое исключение.
Сравнение ручного процесса и self-service: сколько шагов исчезло, какие ошибки стали невозможны, какую DevEx-метрику можно улучшить.
Roadmap строится от базового пути сервиса к платформенному продукту. Не нужно сразу собирать полный Backstage или multi-cloud: сначала покажите один работающий golden path.
| Период | Что учить | Практика | Результат |
|---|---|---|---|
| 0–1 месяц | Linux, сети, DNS, HTTP, Git, Bash/Python basics | Запустить простой сервис и описать его lifecycle | Понимание сервиса, окружения, релиза, лога и метрики |
| 2–3 месяц | Docker, CI/CD, GitLab CI/GitHub Actions, секреты | Собрать pipeline и деплой в учебное окружение | Первый repeatable delivery path |
| 3–5 месяц | Kubernetes, Helm, Terraform/OpenTofu, GitOps, Prometheus, Grafana | Описать окружение как код и добавить observability | Инфраструктурный слой платформы |
| 5–8 месяц | Golden path, service template, portal/Backstage basics, service catalog, policy-as-code | Сделать self-service workflow для нового сервиса | Платформенный кейс вместо набора configs |
| 8–12 месяц | Platform as Product, DevEx metrics, adoption, onboarding, security/governance | Собрать portfolio case с метрикой до/после | Готовность к Platform/DevOps/SRE-adjacent вакансиям |
Переход проще, если показать не только стек, а платформенный эффект для нескольких команд.
| Откуда | Что уже полезно | Чего не хватает | Что учить первым | Как собрать портфолио | Какие ошибки не делать |
|---|---|---|---|---|---|
| Из DevOps | CI/CD, IaC, Docker, Kubernetes | Product thinking и DevEx | Golden path, adoption, docs | Общий template для нескольких сервисов | Не остаться в ручной помощи |
| Из SRE | Observability, incidents, reliability | Self-service и platform product | IDP, portal, service catalog | Runbook + platform capability | Не сводить платформу к monitoring |
| Из системного администрирования | Linux, доступы, инфраструктура | CI/CD, Kubernetes, IaC | Docker, Git, pipelines | Автоматизация типового окружения | Не работать только заявками |
| Из backend | Понимание сервиса и developer pain | Infra и delivery глубина | Docker, CI/CD, IaC, observability | Template сервиса с деплоем | Не забыть эксплуатацию |
| Из поддержки / NOC | Понимание повторяемых проблем | Engineering automation | Linux, Git, Docker, docs | FAQ/runbook и dashboard | Не ограничиться triage |
| Из cloud engineering | Облака, IAM, сети | DevEx и internal platform | Portal, GitOps, templates | Landing zone как self-service | Не делать только cloud-admin |
| Из security / DevSecOps | Governance, secrets, policy | Удобство для разработчиков | Guardrails, exception process | Policy-as-code с понятной ошибкой | Не строить только запреты |
| Из QA automation | Пайплайны, тестовые среды | Инфраструктура и ownership | Docker, CI/CD, Kubernetes | Тестовое окружение self-service | Не сводить платформу к тестам |
Интервью проверяет не только знание инструментов, но и способность строить внутренний продукт без лишней сложности.
| Тема | Пример вопроса | Что проверяет интервьюер | Как отвечать | Что добавить в портфолио |
|---|---|---|---|---|
| Kubernetes | Как дать команде стандартный деплой сервиса? | Понимание orchestration как слоя платформы | Через шаблон, guardrails, observability и docs | Kubernetes-deploy с README |
| Terraform / OpenTofu | Как сделать типовое окружение self-service? | IaC-интерфейс и migration thinking | Описать модуль, defaults, exceptions | Terraform-модуль окружения |
| CI/CD | Как уменьшить копипасту пайплайнов? | Reusable pipeline design | Общий template с расширениями | Pipeline с понятными ошибками |
| GitOps | Когда GitOps полезен платформе? | Delivery control и auditability | Git как desired state и review | Argo CD/Flux учебный flow |
| Backstage / portal | Зачем нужен developer portal? | Понимание portal vs platform | Портал как интерфейс к IDP | Catalog/template prototype |
| Golden path | Как не построить golden cage? | Баланс стандарта и свободы | Удобный путь плюс controlled exceptions | Case study с исключениями |
| DevEx metrics | Как доказать пользу платформы? | Метрики и продуктовый подход | Adoption, time to first deploy, ticket reduction | Before/after metrics |
| Security and governance | Как встроить проверки без торможения команд? | Guardrails, not gates | Policy-as-code с понятным feedback | Policy example без production-команд |
| Migration of legacy services | Как перевести старый сервис на новый путь? | Риск и совместимость | Поэтапная миграция, rollback, support | Migration plan |
| DevOps vs Platform | Чем ваша работа отличается от DevOps? | Граница роли | Многие команды, self-service, product ownership | Платформенный кейс |
Сертификат помогает структурировать обучение, но не заменяет портфолио с работающим платформенным сценарием.
Kubernetes and Cloud Native Associate, Linux Foundation courses, базовые cloud-сертификаты и учебные стенды помогают закрыть фундамент. Важно сразу связывать сертификат с практикой сервиса.
Certified Kubernetes Administrator, Certified Kubernetes Application Developer, HashiCorp Terraform Associate, Prometheus Certified Associate и cloud certifications полезны, если они поддержаны реальными кейсами.
CNCF resources, Backstage community resources, учебные IDP-прототипы, service catalog, templates и platform case study показывают ближе к роли, чем один Kubernetes-кластер.
Не раскрывайте внутренние URL, секреты, production-конфигурации и данные работодателя. Показывайте обезличенный кейс: проблема, users, решение, guardrails, метрика эффекта и ограничения.
Роль усиливается там, где ручная инфраструктурная поддержка уже мешает скорости разработки и безопасности релизов.
ИИ ускорит конфигурации и документацию, но не заменит product-подход, работу с командами и ответственность за границы платформы.
Платформенная инженерия растёт как ответ на усталость компаний от ручной помощи каждой команде. Бизнесу уже мало просто нанять ещё одного инфраструктурного специалиста: нужен общий внутренний продукт, который снимает типовые задачи и делает выпуск изменений предсказуемым.
ИИ ускорит генерацию конфигураций, документации, шаблонов сервисов и черновиков pipeline. LLM-инструменты могут усилить developer portal: поиск по сервисам, документации, ownership и инцидентам. Но человек останется нужен для границ платформы, архитектуры, безопасности, миграций, adoption и ответственности.
Сильнее будут цениться специалисты, которые понимают инфраструктуру, разработчиков, безопасность, продуктовые метрики и экономику инженерного времени.
Роль подходит инженерам, которым интересно улучшать систему работы многих команд, а не только закрывать отдельные заявки. Нужны системное мышление, терпение к миграциям и умение смотреть на инфраструктуру глазами разработчика.
Platform Engineer — это платформенный инженер, который строит внутреннюю платформу для разработки. Он помогает командам быстрее создавать сервисы, запускать окружения, проходить CI/CD, подключать observability, работать с секретами и выпускать изменения по понятному пути. Его работа ценна не отдельным инструментом, а тем, что разработчики получают self-service вместо ручных заявок и личных договорённостей.
Платформенный инженер ищет повторяемые проблемы разработчиков и превращает их в платформенные возможности: шаблоны сервисов, пайплайны, GitOps, инфраструктуру как код, управление секретами, окружения, observability, документацию, portal, API или CLI. Он не просто настраивает инструменты, а измеряет, стало ли командам проще и безопаснее выпускать сервисы.
Junior Platform Engineer нужен уверенный минимум: Linux, Git, Docker, базовый Kubernetes, CI/CD, Bash или Python, понимание логов, метрик, секретов, окружений и документации. В портфолио стоит показать service template, простой pipeline, учебный deploy, dashboard и README, где видно, как разработчик проходит путь без устных подсказок.
Middle Platform Engineer должен вести отдельный компонент платформы: Terraform-модуль, GitOps-сценарий, service catalog, software template, observability, secrets или developer portal. От него ждут самостоятельной работы с пользователями, миграции старого процесса, измеримого эффекта и умения оставить controlled exceptions без разрушения стандарта.
Senior Platform Engineer проектирует возможности для нескольких команд, думает о product roadmap, adoption, security guardrails, platform architecture, DevEx-метриках, миграциях и стоимости поддержки. Он умеет сказать нет лишней универсальности и доказать, что платформа действительно снижает ручную работу, а не только добавляет новый инструмент.
Стать Platform Engineer с нуля можно, но прямой вход сложнее, чем в более массовые IT-роли. Нужна база Linux, сетей, Git, Docker, CI/CD, Kubernetes, IaC, observability и понимание разработки. Практичный путь — сначала собрать портфолио с сервисом, шаблоном, pipeline, документацией и self-service-сценарием, а затем смотреть DevOps/Platform-adjacent вакансии.
60-дневный срез используется, чтобы не привязывать нишевую роль к одной шумной дневной точке. Вакансии Platform Engineer часто смешиваются с DevOps, SRE, Cloud и Infrastructure Engineer, а открытые вилки распределены неравномерно. Поэтому медиану нужно читать вместе с методологией, регионом, датой и размером выборки.
По данным SkillStat для Москвы и МО на 23.06.2026 медиана зарплаты Platform Engineer составляет 210 000 ₽. Она рассчитана по вакансиям за 60 дней, n=4.
Часто нужны Linux, Kubernetes, Docker, Helm, Terraform/OpenTofu, Ansible, GitLab CI, GitHub Actions, Jenkins, Argo CD, Flux, Backstage или другой portal, Vault, Prometheus, Grafana, Loki/ELK, OpenTelemetry, OPA/Kyverno, PostgreSQL, Redis, Nginx, Python, Bash, Go и Git. Но инструменты нужно показывать через платформенный сценарий.
Важны adoption rate, time to first deploy, time to create service, self-service rate, ticket reduction, lead time, deployment frequency, failed deployments, onboarding time, developer satisfaction, documentation usefulness, platform NPS, golden path coverage и number of manual exceptions. Метрика должна показывать пользу для команд, а не только количество внедрённых инструментов.
Чаще всего полезны Python, Bash и Go; дополнительно нужны YAML, SQL и понимание REST API. Python удобен для automation и внутренних инструментов, Bash — для системных сценариев, Go часто встречается в cloud native-экосистеме. В вакансиях SkillStat среди частых навыков видны Python, Bash, REST API и SQL-контекст.
Kubernetes часто нужен, потому что многие внутренние платформы строятся вокруг контейнеров, окружений, деплоя и observability. Но Kubernetes сам по себе не делает специалиста Platform Engineer. Нужно уметь превратить кластер, Helm, GitOps, секреты и мониторинг в понятный путь для разработчиков, а не просто администрировать workloads.
Terraform или OpenTofu часто нужны для Infrastructure as Code: окружения, облачные ресурсы, политики, сетевые компоненты и повторяемые модули. Но важен не только синтаксис, а интерфейс для команд: какие параметры доступны, что спрятано внутри модуля, как описана миграция и как не превратить IaC в новый источник ручных исключений.
Да, хотя роль не всегда требует писать продуктовый backend каждый день. Нужны Python, Bash или Go для автоматизации, генерации шаблонов, CLI, интеграций, проверок и работы с API. Важнее не язык сам по себе, а способность превращать ручной процесс в поддерживаемый инструмент, который команда может безопасно использовать.
Платформенная роль требует понимать последствия решений для многих команд, поэтому работодатели часто ищут Middle и Senior. По SkillStat junior-вход есть, но рынок ориентирован на специалистов с опытом. Новичку помогает смежный старт: DevOps, infrastructure support, cloud support, backend с инфраструктурными задачами, QA automation или internal tools.
На базовый roadmap обычно закладывают 6–12 месяцев при регулярной практике, если уже есть технический фундамент. За это время нужно пройти Linux, сети, Git, Docker, CI/CD, Kubernetes, Terraform/OpenTofu, GitOps, observability, security basics, документацию и один законченный платформенный кейс. Без практики с реальным или учебным сервисом срок легко растягивается.
IDP — это вся платформа: инструменты, automation, пайплайны, инфраструктура, секреты, политики, observability и процессы поддержки. Developer portal — один из интерфейсов к этой платформе. Проще говоря, портал показывает и запускает сценарии, а IDP обеспечивает их выполнение и правила.
Системный администратор чаще отвечает за работоспособность систем, серверов, пользователей и инфраструктуры. Platform Engineer строит повторяемые возможности для разработчиков и убирает ручную поддержку типовых сценариев. Если специалист только исполняет заявки, это ещё не platform engineering; платформа появляется там, где команды получают self-service.
Cloud Engineer чаще работает с облачной инфраструктурой: сети, IAM, landing zones, хранилища, управляемые сервисы и безопасность облака. Platform Engineer может использовать облако как слой, но его главный пользователь — разработчик. Он собирает из облачных и внутренних инструментов удобный путь создания и сопровождения сервисов.
DevEx Engineer сильнее фокусируется на опыте разработчика: friction, onboarding, документация, tooling, feedback и productivity. Platform Engineer обычно глубже отвечает за инфраструктурную платформу и delivery. В небольших командах роли могут совпадать, но DevEx без инженерной платформы не решит проблемы окружений, релизов и доступов.
DevOps чаще фокусируется на delivery-процессах, автоматизации и инфраструктурных практиках вокруг команды или сервиса. Platform Engineer строит общий внутренний продукт, которым пользуются многие команды. DevOps-опыт часто помогает войти в роль, но platform engineering требует думать о пользователях, adoption, документации и self-service.
SRE отвечает за надёжность production: SLI, SLO, error budget, incident response, postmortem и снижение повторных сбоев. Platform Engineer отвечает за путь разработки и внутреннюю платформу: templates, CI/CD, GitOps, порталы, доступы, observability и developer experience. В зрелой компании роли пересекаются, но измеряют разный результат.
Platform Engineer означает инженера, который отвечает за внутреннюю инженерную платформу. В русских вакансиях встречаются варианты «платформенный инженер», «инженер внутренней платформы», «platform engineering» и «internal developer platform». Важен не перевод, а фокус: создать повторяемый и безопасный путь для многих команд.
Backstage — популярный open-source developer portal для service catalog, templates, docs и плагинов. Platform Engineer может использовать Backstage, Port, Humanitec или другой портал, но важно не путать инструмент с профессией. Backstage помогает дать интерфейс, но не заменяет продуктовую работу, архитектуру платформы и договорённости с командами.
Golden path — рекомендуемый стандартный путь сервиса: создать репозиторий по шаблону, пройти проверки, получить окружения и секреты, задеплоить, подключить логи, метрики, алерты и документацию. Он должен быть удобнее обходного пути и оставлять понятные исключения для нестандартных случаев.
Internal Developer Platform, или IDP, — это не один портал, а система возможностей для разработчиков: service templates, CI/CD, GitOps, окружения, секреты, observability, policy-as-code, каталог сервисов, документация, API и CLI. IDP помогает командам получать типовые ресурсы самостоятельно и в рамках правил компании.
Internal Developer Portal — это интерфейс к платформе: единое окно для каталога сервисов, шаблонов, документации, ownership, статуса сервисов и self-service-сценариев. Портал может быть важной частью IDP, но сам по себе не является всей платформой. Без автоматизации и полезного golden path портал останется витриной.
Paved road — близкий к golden path термин: хорошо подготовленный путь, по которому команде проще ехать, чем строить дорогу самостоятельно. В platform engineering это означает набор готовых практик и guardrails. Важно, чтобы paved road не превращался в административный запрет на любую инженерную самостоятельность.
Platform as a Product означает, что внутренняя платформа развивается как продукт для разработчиков: с пользователями, roadmap, user research, документацией, метриками, поддержкой и обратной связью. Команды должны хотеть пользоваться платформой, потому что она удобнее обходного пути, а не потому что их заставили приказом.
Platform Engineering — это практика создания внутренней платформы разработки как продукта. Она объединяет инфраструктуру, delivery, security, observability, документацию и developer experience. Цель — снизить cognitive load у команд и дать удобный golden path, но не заставлять всех жить в жёсткой golden cage.