SRE (Site Reliability Engineer)

Также называют: Site Reliability Engineer, Reliability Engineer, Production Engineer, Senior SRE, Infrastructure Reliability Engineer.

Кто такой SRE и чем он занимается?

SRE (Site Reliability Engineer) — это инженер, который отвечает за надёжность сервисов в production и решает задачи эксплуатации как задачи разработки: пишет код, который заменяет ручную работу. В подходе, который сформулировали в Google, SRE тратит на операционную работу (тикеты, дежурства, ручные задачи) не больше половины времени, остальное — на разработку. Типичные задачи:

• вместе с продуктовыми командами задаёт SLI и SLO и следит за error budget;
• строит мониторинг, алерты и observability так, чтобы проблема была видна раньше, чем её заметят пользователи;
• дежурит в on-call, ведёт инциденты и проводит postmortem без поиска виноватых;
• ищет узкие места и причины деградации под нагрузкой: от утечек памяти до настроек баз данных;
• автоматизирует повторяющуюся эксплуатационную работу, чтобы рост нагрузки не требовал роста команды.

Когда компании нужен SRE?

SRE нужен, когда простои начинают стоить денег или клиентов, а инциденты повторяются, потому что разбирать их системно некому. Обычно это компания с заметной нагрузкой и несколькими командами, которая продаёт корпоративным клиентам с требованиями к SLA или выходит на новые регионы. Ещё один триггер — продуктовые команды тратят на пожары больше времени, чем на новые фичи. Если нагрузка небольшая и простой на час никого не пугает, отдельный SRE избыточен: дежурства можно разделить между Backend Developers, а инфраструктуру отдать DevOps Engineer.

Чем SRE отличается от DevOps Engineer?

SRE отличается от DevOps Engineer тем, что отвечает за надёжность, измеренную в SLO, а не за инфраструктуру и поставку кода как таковые. DevOps Engineer строит пайплайны и окружения, чтобы команды выкатывали изменения; SRE решает, сколько сбоев сервис может себе позволить, и останавливает релизы, когда error budget исчерпан. На практике названия часто смешивают, поэтому важнее, какую долю работы составляет код. От Platform Engineer SRE отличается фокусом на production, а не на удобстве разработки.

SRE и смежные роли: сравнение

Почему SRE сложно нанять?

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

• Во многих компаниях SRE называют администраторов и дежурных инженеров, которые настраивают алерты, но почти не пишут код.
• Роль требует редкого сочетания: глубокое знание Linux, сетей, Kubernetes и баз данных плюс уровень разработчика, который проходит лайвкодинг и задачи на алгоритмы.
• Опыт инцидентов на большой нагрузке можно получить только в компаниях, где такая нагрузка есть.
• On-call отпугивает часть сильных кандидатов, и без честного рассказа о дежурствах офферы срываются на финале.

Что выяснить до найма SRE?

• Какие SLO у сервисов сейчас и кто их задаёт? Если SLO нет, первые месяцы SRE уйдут на то, чтобы договориться о них с продуктом, и это нужно заложить в ожидания.
• Как устроены дежурства и сколько инцидентов в месяц? От этого зависит, сколько времени останется на разработку и кто вообще согласится на роль.
• Есть ли у SRE право остановить релиз, когда исчерпан error budget? Без этого права SRE превращается в пожарную команду, а не в инженера надёжности.
• На каком языке будет код автоматизации и насколько это жёсткое требование? Сильных SRE часто нанимают за инженерный уровень, а язык они осваивают на месте.

Где искать SRE?

SRE чаще всего приходят из компаний с высокой нагрузкой и жёстким инженерным отбором: крупных интернет-сервисов, облачных провайдеров, финтеха и инфраструктурных продуктов, где простои измеряются деньгами. Сильный сигнал в профиле — вклад в open-source вроде Kubernetes, баз данных или систем мониторинга и опыт разработки, а не только эксплуатации. NEWHR ищет таких кандидатов по результатам работы, а не по откликам на вакансию.

Как проверить SRE на интервью?

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

Сильные сигналы:

• подробно разбирает инцидент, в котором сам ошибся, и что автоматизировал после него;
• называет SLO и метрики надёжности сервисов, за которые отвечал;
• объясняет, какую ручную работу убрал кодом и сколько времени это освободило.

Красные флаги:

• описывает только эксплуатацию: тикеты, алерты, ручные выкладки, без своего кода;
• не может объяснить, зачем нужен error budget;
• ищет виноватого в разборе инцидента вместо причины.

Сколько длится поиск SRE?

Первых кандидатов на роль SRE показываем через 5–7 дней после брифа. Для Workato NEWHR с нуля собрали команду из 10 сеньорных SRE: все 22 кандидата, которых показали клиенту, получили приглашение на интервью.

Смежные роли

• DevOps Engineer — строит инфраструктуру и пайплайны поставки, а за надёжность по SLO обычно не отвечает.
• Platform Engineer — строит внутреннюю платформу для разработчиков, а не следит за надёжностью production.
• Staff Engineer — уровень инженера, который ведёт технические решения нескольких команд; опытный SRE может дорасти до него.
• AI Infrastructure / Inference Engineer — отвечает за скорость и стоимость запуска AI-моделей, в том числе за их надёжность.
• DevSecOps Engineer — встраивает безопасность в инфраструктуру и пайплайны.