DevOps и SRE часто запихивают в одну вакансию, добавляют туда облака, Kubernetes, безопасность, базы данных и круглосуточное дежурство, а потом удивляются, почему сильные инженеры проходят мимо. Проблема обычно не в дефиците рынка. Компания сама не решила, какую задачу должен закрыть человек и за что он будет отвечать после выхода.
Грамотный подбор разработчиков начинается не со списка технологий, а с ответа на простой вопрос: бизнесу нужно ускорить поставку изменений, повысить надёжность сервиса или вытащить команду из постоянных пожаров? От этого зависит профиль, опыт кандидата и весь сценарий интервью.
DevOps и SRE: в чём реальная разница
DevOps — это прежде всего подход к совместной работе разработки и эксплуатации: меньше ручных передач, больше автоматизации, единые процессы поставки и ответственность команды за продукт в production. В вакансиях под DevOps-инженером обычно понимают специалиста, который строит инфраструктуру как код, CI/CD, контейнерную платформу, окружения, управление конфигурациями и базовую наблюдаемость.
SRE — инженерная функция вокруг надёжности сервиса. Здесь важны SLI и SLO, error budget, управление инцидентами, снижение toil, capacity planning и автоматизация повторяющихся операций. SRE не просто поддерживает инфраструктуру: он переводит надёжность в измеримые цели и помогает продукту балансировать стабильность со скоростью изменений.
Когда компании нужен DevOps-инженер
DevOps-профиль логичен, если узкое место находится в delivery и платформе: релизы выполняются вручную, окружения расходятся, инфраструктура не воспроизводится, разработчики неделями ждут доступы, а развертывание зависит от одного человека. Результат роли должен звучать измеримо: сократить ручные шаги релиза, стандартизировать пайплайны, внедрить IaC, улучшить developer experience.
- построить или переделать CI/CD
- управлять cloud-ресурсами и Kubernetes
- внедрить Terraform, Ansible или другой IaC-инструмент
- настроить секреты, доступы и базовые security controls
- дать командам повторяемые окружения и понятный путь релиза
Когда нужен именно SRE
SRE нужен там, где сервис уже критичен для бизнеса, а цена деградации понятна: теряются транзакции, пользователи или выручка. У компании должны появиться цели надёжности, дежурства, инженерная работа с причинами инцидентов и решения, которые уменьшают количество ручной эксплуатации. Если от кандидата ждут только настройки алертов и реакции на каждый чих системы, это эксплуатация под модным названием, а не полноценная SRE-функция.
- определить SLI и SLO вместе с продуктом
- настроить алертинг по пользовательскому влиянию
- вести incident response и постмортемы без поиска виноватых
- уменьшать toil через код и автоматизацию
- планировать ёмкость, устойчивость и восстановление
Почему гибридная роль иногда допустима
В небольшой компании один инженер действительно может совмещать платформенные и reliability-задачи. Но это должно быть осознанным выбором, а не бесконечным списком обязанностей. Зафиксируйте основной результат на ближайшие шесть–двенадцать месяцев, долю проектной работы, частоту on-call и то, какие функции остаются у разработчиков, security и системных администраторов.
Что выяснить до запуска поиска
- Опишите текущую инфраструктуру, масштабы нагрузки и критичные сервисы.
- Назовите три проблемы, которые должен решить новый сотрудник.
- Разделите обязательный стек и инструменты, которые можно освоить после выхода.
- Зафиксируйте формат дежурств, компенсацию и уровень поддержки команды.
- Определите результат испытательного срока и метрики через полгода.
Как читать резюме DevOps-кандидата
Список из двадцати инструментов почти ничего не доказывает. Ищите контекст: размер инфраструктуры, число команд и сервисов, облако или on-premise, личный вклад, ограничения и результат. Сильное описание показывает не только «настроил Kubernetes», но и зачем менялась платформа, какие риски были, как измерили эффект и что кандидат делал сам.
Как оценивать SRE-кандидата
Попросите разобрать реальный сервис: какие пользовательские сигналы выбрать, где поставить SLO, какие алерты разбудят человека ночью и что делать при исчерпании error budget. Хороший кандидат задаёт вопросы о бизнес-критичности, зависимостях и допустимом риске. Слабый сразу перечисляет инструменты мониторинга, не определив, что именно нужно защищать.
Практический кейс для интервью
Дайте ситуацию: после релиза выросла latency, ошибок немного, но поддержка получает жалобы. Попросите проговорить диагностику, первые действия, коммуникацию, откат и дальнейшую профилактику. Оценивайте последовательность мышления, работу с данными, границы уверенности и способность объяснять решение разработчикам и бизнесу. Угадывание вашей внутренней архитектуры не должно быть критерием найма.
Красные флаги в процессе найма
- в вакансии одновременно DevOps, SRE, DBA, security и helpdesk
- on-call скрывают до финального этапа
- требуют опыт со всеми облаками без связи с задачами
- проверяют синтаксис команд вместо инженерного мышления
- не могут назвать владельцев сервиса и критерии надёжности
- ожидают нулевых инцидентов и стопроцентной доступности
Чек-лист сильного профиля
В профиле должны быть: цель роли, зона ответственности, архитектурный контекст, обязательные инженерные компетенции, формат дежурств, полномочия на изменения и критерии успеха. После этого рынок становится заметно шире: можно искать кандидатов по реальному опыту, а не по совпадению каждой строчки стека.
Как продать вакансию сильному инженеру
DevOps и SRE-кандидаты внимательно смотрят не только на зарплату и стек. Им важно, смогут ли они менять систему или будут бесконечно тушить последствия чужих решений. Покажите зрелость инженерной среды: кто владеет сервисами, как принимаются архитектурные решения, есть ли время на автоматизацию, как устроены постмортемы и поддерживает ли руководство инвестиции в надёжность. Честно назовите технический долг и ближайшие проекты. Сильного инженера скорее заинтересует сложная, но управляемая задача с полномочиями, чем рекламный текст про идеальную инфраструктуру, которой в реальности нет.
Если внутри компании нет времени строить карту рынка и глубоко проверять инфраструктурный опыт, подключите подбор IT и digital-специалистов. Важно передать агентству не только вакансию, но и контекст системы, команды и будущих изменений.
FAQ
Можно ли назвать вакансию DevOps/SRE?
Можно, если роль действительно гибридная и в описании честно указан приоритет задач. Но двойное название не должно маскировать отсутствие решения, кого ищет компания.
Обязателен ли Kubernetes?
Только если он реально используется или будет внедрён. Опыт с контейнерной оркестрацией важнее механического совпадения конкретного инструмента.
Нужно ли давать тестовое задание?
Для senior-профиля чаще достаточно предметного кейса и разбора прошлых решений. Большое домашнее тестовое ухудшает конверсию и редко показывает работу в production.
Кто должен проводить техническое интервью?
Инженер или руководитель, который понимает архитектуру и будет работать с кандидатом. Рекрутер проверяет контекст, мотивацию и релевантность, но не изображает технический экзаменаторский комитет.
Как понять, что вакансия перегружена?
Если задачи невозможно приоритизировать, они принадлежат нескольким функциям, а успех роли нельзя описать тремя результатами, профиль нужно пересобрать до выхода на рынок.
Вывод
Сильный найм начинается с разделения задач платформы и надёжности. Если вам нужен подбор разработчиков, передайте вакансию IT and Digital: мы поможем уточнить профиль и искать инженеров по реальному масштабу ответственности, а не по коллекции модных слов.
Главное — не искать «универсального спасателя». Правильно собранный подбор разработчиков экономит недели интервью и снижает риск нанять сильного специалиста совсем не на ту работу.