Platform engineering, DevOps и SRE: чем отличаются роли и подходы
Основы4 минРедакция Innovialabs
Коротко
DevOps — культура общей ответственности разработки и эксплуатации, SRE применяет инженерные методы к надёжности через SLO и error budget, а platform engineering строит внутреннюю self-service платформу, чтобы разработчики выпускали код без ожидания ops.
Коротко о главном
Эти три термина часто используют как названия должностей, но они описывают разное:
- DevOps — это культура и набор практик: разработка и эксплуатация вместе отвечают за выпуск и работу софта, опираясь на автоматизацию и быструю обратную связь.
- SRE (Site Reliability Engineering) — конкретная инженерная дисциплина про надёжность. Она измеряет её через SLO и управляет риском через error budget.
- Platform engineering строит внутренний продукт для разработчиков: self-service платформу, которая прячет сложность инфраструктуры за простыми проторенными путями.
Они не конкурируют. SRE и platform engineering — два способа воплотить идеи DevOps в масштабе.
Цели и зоны ответственности
| DevOps | SRE | Platform engineering | |
|---|---|---|---|
| Главная цель | Выпускать быстрее и безопаснее за счёт совместной работы | Держать надёжность сервиса на согласованном уровне | Сделать разработчиков продуктивными и самостоятельными |
| Ключевая мера | Поток поставки: частота деплоев, lead time, восстановление после сбоя | SLO, расход error budget | Использование платформы, время до первого деплоя, удовлетворённость разработчиков |
| Типичные задачи | CI/CD, инфраструктура как код, автоматизация, разрушение барьеров между командами | Мониторинг, алерты, реакция на инциденты, постмортемы, планирование мощностей | Портал разработчика, шаблоны, self-service окружения, общие инструменты |
| Кто «клиент» | Весь процесс поставки | Конечные пользователи сервиса | Внутренние разработчики |
DevOps на практике
DevOps — не отдельная команда, которая «делает деплои». Если «DevOps-команда» становится единственными людьми с доступом к продакшену, вы воссоздали старую изоляцию под новым названием.
Типичные практики:
- CI/CD-пайплайны, которые собирают, тестируют и деплоят каждое изменение.
- Infrastructure as code с инструментами вроде Terraform или Ansible.
- «You build it, you run it»: команда, написавшая сервис, отвечает за него и в продакшене.
- Небольшие частые релизы и быстрый откат.
SRE на практике
SRE выросло из идеи относиться к эксплуатации как к задаче разработки. Основные понятия:
- SLI — что измеряем (например, долю успешных запросов).
- SLO — целевое значение, согласованное с бизнесом.
- Error budget — сколько ненадёжности допускает SLO. Пока бюджет есть, команда выпускает фичи. Когда он исчерпан, приоритет смещается на надёжность.
- Сокращение toil: повторяющаяся ручная работа — сигнал автоматизировать.
- Blameless-постмортемы: инцидент разбирают ради системных причин, а не поиска виноватых.
SRE-инженеры обычно пишут код: автоматизацию, инструменты, исправления надёжности в самом сервисе.
Platform engineering и golden paths
Когда команд становится много, ситуация «каждая сама настраивает Kubernetes, пайплайны и мониторинг» становится дорогой и разнобойной. Ответ platform engineering — внутренняя платформа разработчика (IDP).
IDP обычно включает:
- Портал разработчика с каталогом сервисов и документацией (частая open-source основа — Backstage).
- Шаблоны сервисов: новый сервис сразу получает репозиторий, CI/CD, логи, метрики и конфигурацию деплоя.
- Self-service: создать базу, preview-окружение или секрет без тикета.
- Разумные ограничения: правила безопасности и расходов уже встроены.
Golden path — рекомендованный и полностью поддерживаемый способ решить типовую задачу, например «создать и задеплоить новый HTTP-сервис». Он не обязателен, но настолько удобен, что большинство команд выбирают его сами. Главное — относиться к платформе как к продукту: общаться с разработчиками, измерять использование, убирать трение.
Что подходит именно вам
Стартап, одна-две команды. Отдельные SRE- и платформенная команды не нужны. Внедрите DevOps-практики: CI/CD, инфраструктуру как код, базовый мониторинг и алерты, общее дежурство. Управляемая облачная платформа или PaaS часто полностью заменяет внутреннюю платформу.
Растущая продуктовая команда, несколько squad. Надёжность и повторяющаяся настройка начинают мешать. Введите SLO для ключевых пользовательских сценариев, процесс работы с инцидентами и небольшую группу, которая ведёт общие шаблоны и пайплайны. Это зародыш платформенной команды.
Enterprise, много команд. Выделенная платформенная команда с IDP и golden paths и SRE-практики для критичных сервисов — центральной командой или встроенными инженерами. DevOps-культура остаётся фундаментом для обоих.
Частые ошибки
- Переименовать отдел эксплуатации в «DevOps», ничего не поменяв в разделении работы.
- Строить платформу, о которой никто не просил: большой внутренний портал без разговора с разработчиками.
- SLO без последствий: цели, на которые никто не смотрит, когда error budget исчерпан.
- Копировать структуру крупной компании в стартап из десяти человек.