SRE vs Platform Engineering: кто за что отвечает?

Когда компании начинают путь к повышению надежности, они часто сталкиваются с путаницей. На сцене появляются два подхода, два названия, две команды, которые на первый взгляд делают что-то вокруг инфраструктуры и разработки. Это SRE и Platform Engineering.

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

Давайте разберемся, кто есть кто, используя простую аналогию.

Аналогия: Город, кварталы и дороги

Представьте, что ваша компания - это растущий город.

  • Разработчики (Dev) это жители и предприниматели. Они хотят строить новые дома (фичи), открывать магазины (сервисы) и привлекать клиентов. Им нужно быстро возводить новые здания.
  • SRE это служба благоустройства и МЧС. Они следят, чтобы в городе не было аварий, чтобы дороги были чистыми, а если случается пожар (сбой), они приезжают первыми, тушат его и пишут инструкции, как не допустить пожара в следующий раз. Их главная метрика: безопасность и доступность города для жителей.
  • Platform Engineering это департамент транспорта и градостроительства. Они не строят дома сами. Они проектируют и строят дороги, коммуникации, разрабатывают стандарты на строительные материалы. Их задача в том, чтобы любой предприниматель (разработчик) мог взять типовой проект, подключиться ко всем необходимым магистралям и коммуникациям и построить готовый к заселению дом за две недели, а не за год.

Проблема многих компаний в том, что они путают этих людей. Они просят МЧС (SRE) строить новые дороги, а департамент транспорта (Platform Engineering) тушить пожары. В итоге обе команды работают неэффективно.

Что такое SRE? (если говорить о надежности)

SRE это роль, сфокусированная на "что" и "почему". Точнее, на том, почему система работает или не работает и что нужно сделать, чтобы она работала стабильно.

SRE смотрит на мир через призму рисков: - У нас есть Error Budget, это количество времени, которое сервис может быть недоступен, не вызывая гнева клиентов. - Пока бюджет не исчерпан, разработчики могут выпускать новые фичи. Как только бюджет на исходе - SRE говорит: "стоп, мы не можем рисковать, нужно повышать надежность".

Чем занимается SRE: 1. Защита пользовательского опыта: обеспечение соблюдения SLO (соглашений об уровне надежности). 2. Управление инцидентами: они либо сами тушат пожары, либо выстраивают процесс, чтобы это делали разработчики (но с четкими правилами). 3. Борьба с рутиной (toil): они автоматизируют повторяющиеся задачи, чтобы у команды было время на развитие. 4. Анализ рисков: они говорят продукту: "если мы добавим эту функцию сейчас, вероятность сбоя вырастет на 20%. Вы готовы к этому?".

Для продукт-менеджера SRE это партнер, который переводит бизнес-требования ("нам нужна высокая доступность") в инженерные ограничения ("мы можем позволить себе 43 минуты простоя в месяц").

Что такое Platform Engineering? (если говорить о скорости)

Platform Engineer это роль, сфокусированная на "как". А именно, как разработчики создают и доставляют код максимально быстро и безболезненно.

Platform Engineer создает внутреннюю платформу (Internal Developer Platform, IDP). Это, по сути, "магазин стройматериалов и готовых проектов" для разработчиков. Разработчику не нужно думать: "Как настроить базу данных? Как настроить сеть? Как развернуть сервер?". Он просто нажимает кнопку в интерфейсе платформы, и ему автоматически выдается готовое окружение, соответствующее всем стандартам безопасности и надежности.

Чем занимается Platform Engineer: 1. Снижение когнитивной нагрузки: разработчики пишут код, а не возятся с инфраструктурой. 2. Стандартизация: все сервисы в компании строятся по единым шаблонам и правилам. Это значит, что SRE знает, как устроен любой сервис, даже не глядя в его код. 3. Золотые пути (Golden Paths): создание "проторенных дорог", по которым безопасно и быстро идти. Если разработчик идет по "золотому пути", он автоматически получает мониторинг, логи, трейсы и правильную конфигурацию безопасности.

Для разработчика Platform Engineering это инструмент, который убирает бюрократию и позволяет сосредоточиться на бизнес-логике.

Главные различия

Если вам нужно объяснить разницу коллегам, используйте эту таблицу:

Характеристика SRE (Надежность) Platform Engineering (Платформа)
Главная метрика Доступность (Uptime), Latency, SLO, Error Budget Time to Market, скорость онбординга, удовлетворенность разработчиков
Основной вопрос "Не упадет ли это в 3 часа ночи?" "Как быстро разработчик запустит новый сервис?"
Кто потребитель Бизнес, Клиенты, Разработчики (как подконтрольная сторона) Разработчики (как внутренние клиенты)
Инструменты Мониторинг (Prometheus, Victoria Metrics), Инцидент-менеджмент, Chaos Engineering CI/CD (GitHub Actions, GitLab), IaC (Terraform), Портал разработчика (Backstage)
Реакция на сбой "Тушим пожар, делаем postmortem, обновляем SLO" "Строим дорогу так, чтобы пожарные машины проезжали быстрее, и чтобы пожар не возникал из-за кривых настроек"

Очень часто в компаниях возникает непонимание: "Кто нам нужен? Нам нужен SRE или Platform Engineering?" Это неправильная постановка вопроса. SRE без платформы это команда пожарных, которые бегают с ведрами. Платформа без SRE это город с идеальными дорогами, но без пожарной службы.

Они решают разные проблемы, которые влияют на один и тот же результат: успех продукта.

  1. SRE задает требования к платформе. SRE говорит платформенной команде: "Я хочу, чтобы любой микросервис автоматически имел дашборд с SLO и стандартный набор алертов". Платформенная команда добавляет это в свой "золотой путь". В итоге надежность становится "встроенной" (built-in), а не "надстроенной" (bolt-on).

  2. Платформа убирает рутину (toil) для SRE. Одна из главных задач SRE - бороться с рутиной. Если SRE тратит 50% времени на то, чтобы вручную настраивать окружения для разработчиков - это очень плохо. Если Platform Engineering автоматизирует это, SRE может сосредоточиться на реальном улучшении архитектуры и анализе инцидентов.

  3. Единая цель: быстрая и надежная доставка. Продукту не нужна супернадежность, если релизы выходят раз в полгода. И не нужны ежечасные релизы, если эти релизы каждый раз ломают сервис.

    • Platform Engineering отвечает за скорость (сделать релиз легким).
    • SRE отвечает за безопасность (сделать релиз безопасным, используя Canary deployments, Feature Flags и контроль Error Budget).

Как это выглядит для неинженера?

Сценарий 1: Нет никого. Вы говорите разработчикам: "Сделайте надежно". Они пожимают плечами: "Мы не умеем настраивать мониторинг, и у нас нет времени". Сервис падает в выходные, никто не знает, как его чинить.

Сценарий 2: Только SRE. Вы нанимаете SRE. Они приходят и говорят: "Ваш код хорош, но ваша инфраструктура это ад. Каждый сервис настроен по-своему. Мы не можем гарантировать надежность, пока вы не приведете все к единому стандарту". SRE начинают вручную править инфраструктуру, отвлекаясь от реальной работы по надежности. Разработчики жалуются, что SRE тормозят релизы.

Сценарий 3: SRE + Platform Engineering (идеально). Platform Engineering строит внутренний портал. Разработчик создает новый сервис в три клика. Автоматически создается репозиторий, настраивается сеть, поднимаются дашборды. SRE настраивает правила: "Ваш сервис имеет SLO 99,9%. Пока вы укладываетесь в Error Budget, вы выпускаете релизы когда хотите". Разработчик счастлив (ему не мешают), SRE спокоен (все сервисы соответствуют стандартам), продукт выходит быстро и не падает.

Если вы владелец продукта или руководитель, запомните главное:

  • SRE это про "Почему мы не падаем?" и "Сколько еще мы можем рисковать?". Это функция управления рисками и надежностью.
  • Platform Engineering это про "Как мы делаем это быстро?" и "Как мы не даем разработчикам ошибиться в настройках?". Это функция внутренней автоматизации и повышения скорости разработки.

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

С точки зрения бизнеса, инвестиции в Platform Engineering окупаются через скорость выхода фич, а инвестиции в SRE через стабильность работы сервисов и сохранение репутации (и прибыли) во время сбоев. Оба направления одинаково важны, и попытка заменить одно другим обычно приводит к тому, что компания получает либо медленную разработку, либо нестабильный прод.