Platform Engineering vs DevOps: разница без хайпа

Platform Engineering не «убивает DevOps» и не является новым названием системного администратора. Это способ превратить повторяющуюся инфраструктурную работу в продукт для разработчиков: с понятными рельсами, self-service и измеримой ответственностью.

Коротко. DevOps — набор принципов и практик, который сокращает путь изменения от кода до пользователя и объединяет ответственность разработки и эксплуатации. Platform Engineering — конкретная команда и продукт: внутренняя платформа, на которой разработчики сами получают окружение, деплой, наблюдаемость и стандартные интеграции. SRE отвечает за измеримую надёжность. В реальной компании эти модели не конкурируют, а накладываются.

Что осталось от DevOps

DevOps никогда не был должностью по стандарту, но рынок давно сделал из него роль. В вакансиях DevOps-инженер поднимает CI/CD, Kubernetes, IaC, мониторинг, доступы и помогает командам выпускать код. Проблема появляется при росте: десять продуктовых команд приходят к трём инженерам с одними и теми же заявками. DevOps превращается в очередь ручной поддержки, хотя должен был уничтожать ручную передачу работы.

Если инженер каждый день создаёт одинаковые namespace, копирует pipeline и выдаёт доступы по тикетам, это не зрелый DevOps. Это help desk для инфраструктуры с дорогими специалистами.

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

Platform team берёт повторяемые операции и собирает из них внутренний продукт. У него есть пользователи — разработчики, интерфейс — портал, CLI или репозиторий шаблонов, договор качества — SLO платформы и команда-владелец. Разработчик не пишет тикет «сделайте мне сервис». Он выбирает шаблон, получает репозиторий, pipeline, окружение, базовые метрики, секреты и правила безопасности.

Главная единица платформы — golden path, рекомендованный путь для типового сервиса. Это не единственный разрешённый путь. Если превратить платформу в новый отдел запретов, разработчики будут обходить её так же, как раньше обходили бюрократичный DevOps.

Разница по ответственности

Модель	Главный вопрос	Результат
DevOps	Как быстрее и безопаснее доставлять изменения?	Практики, автоматизация, общая ответственность
Platform Engineering	Как дать командам готовый self-service?	Внутренняя платформа и golden paths
SRE	Насколько надёжно работает сервис?	SLI/SLO, error budget, эксплуатационные практики

Один инженер может носить все три шапки в маленькой компании. В большой организации это разные команды. Смотрите не на название вакансии, а на результат, за который отвечают, и на то, кто является пользователем вашей работы.

Минимальная внутренняя платформа

Не начинайте с дорогого портала. Минимум можно собрать вокруг Git:

шаблон репозитория сервиса;
готовый CI с тестами, сборкой и сканированием;
Helm chart или Kustomize base;
GitOps-деплой через Argo CD;
секреты через понятный механизм, а не в values.yaml;
метрики, логи и трассы по умолчанию;
короткая документация «создай сервис за 30 минут».

Если этим пользуется одна команда без сопровождения автора — уже платформа. Если нужен созвон с создателем на каждый запуск — пока это набор скриптов.

Что учить инженеру

База остаётся той же: Linux, сети, контейнеры, Kubernetes, CI/CD, Terraform или OpenTofu, наблюдаемость. Сверху добавляются продуктовые навыки: интервью с внутренними пользователями, API и контракты, управление версиями шаблонов, документация, метрики принятия платформы. Platform Engineer пишет не только YAML — он проектирует интерфейс между инфраструктурой и десятками команд.

Новичку не стоит начинать с абстрактной «платформы предприятия». Сначала соберите один путь целиком: код → тест → образ → GitOps → метрики. Затем вынесите повторяемое в шаблон и дайте другому человеку запустить без вашей помощи. Такой проект показывает больше, чем список Backstage, Argo CD и Crossplane в резюме.

Agent workloads как новый клиент платформы

AI-агент — такой же пользователь внутренней платформы, только быстрее кликает и хуже понимает последствия. Ему нужны короткоживущая идентичность, ограниченный каталог инструментов, одноразовая среда, сетевые границы, лимиты стоимости и полный след действий. Если каждая команда подключает агента к production своим токеном, платформа снова проиграла ручному хаосу.

Golden path для агента может создавать sandbox namespace, read-only доступ к репозиторию, policy на команды, OTEL-трассу и автоматическое уничтожение среды после задачи. Запись, deploy и доступ к чувствительным данным остаются отдельными способностями. Практическая схема pipeline есть в материале про agentic CI/CD, а границы инструментов — в статье про безопасность MCP.

Как понять, что платформа полезна

время от создания репозитория до первого деплоя;
доля команд, которые используют golden path добровольно;
количество ручных инфраструктурных тикетов;
время восстановления типовой ошибки;
частота изменений и доля неудачных выкладок;
сколько исключений платформа заставляет поддерживать вручную.

Количество компонентов платформы не метрика. Сто экранов в портале могут создать больше работы, чем один хороший шаблон репозитория.

Как отвечать на собеседовании

Не говорите «Platform Engineering — это DevOps 2.0». Возьмите один сценарий: раньше команда просила окружение тикетом три дня; после шаблона и GitOps получает его сама за двадцать минут; доступы и наблюдаемость встроены; исключения идут через отдельный процесс. Назовите пользователя, интерфейс, границу ответственности и метрику. Это и отличает платформу от склада инструментов.

Для базы пройдите обзор роли DevOps, затем полный маршрут обучения. Platform Engineering — следующий слой, а не способ перепрыгнуть Linux и сети.

Частые вопросы

Platform Engineer заменит DevOps?
Нет. Платформенная команда реализует DevOps-принципы как внутренний продукт, а продуктовые команды всё равно отвечают за свои сервисы.

Нужен ли Backstage?
Нет. Портал полезен при масштабе, но платформа может начаться с шаблонов, API и GitOps.

Можно ли войти в Platform Engineering с нуля?
Название роли обычно требует уже собранной DevOps-базы. Реалистичный путь — поддержка или администрирование, затем DevOps, потом платформенная ответственность.