Где на самом деле публикуют вакансии DevOps-инженеров

Почему крупные площадки плохо подходят для этой роли

Опубликуйте вакансию DevOps-инженера на универсальной площадке — и вас завалят неподходящими откликами: Java-разработчики, которые раз открыли Dockerfile, сотрудники IT-поддержки, указавшие «AWS» в резюме после того, как создали S3-бакет в учебном туториале. Те, кто на этом обжёгся, перестают использовать универсальные площадки для чего-либо, кроме джуниор-позиций или общих должностей «инженер». На смену приходит не секретность, а фильтрация: переход на каналы, где аудитория уже самостоятельно отобрала себя по конкретному стеку.

Для DevOps это важнее, чем для многих технических ролей, потому что само название размыто. «DevOps-инженер» включает людей, работающих с Terraform и эксплуатацией Kubernetes-кластеров, людей, занимающихся поддержкой CI/CD-пайплайнов в Jenkins или GitLab, и тех, кто по сути SRE с дежурствами и обсуждением error budget с продуктовой командой. Расплывчатая публикация на Indeed или LinkedIn привлекает всех троих; публикация в Slack-канале, посвящённом Kubernetes, — в основном нужных. Поэтому вакансии всё ещё попадают на публичные площадки — но часто как низкоприоритетный, поздний канал, после того как рекрутер или нанимающий менеджер уже попробовал более узкие.

Где вакансии действительно появляются

Каналы сообщества CNCF и Kubernetes. Slack Cloud Native Computing Foundation и канал #kubernetes-jobs в Kubernetes Slack публикуют вакансии, требующие именно операционного опыта с Kubernetes — не просто «контейнеры» в резюме. В таких публикациях обычно называют конкретный CNI, service mesh (Istio, Linkerd) или GitOps-инструмент (ArgoCD, Flux), которым пользуется команда, потому что автор знает: аудитория будет фильтровать по этому.

Форум сообщества HashiCorp и пользовательские группы для компаний, активно использующих Terraform и Vault. Та же логика: компания, работающая с Terraform Enterprise или Vault в масштабе, предпочтёт опубликовать вакансию там, где кандидат уже знает, что такое state file.

r/devops и r/sre на Reddit, а также рассылка DevOpsish — время от времени публикуют темы с вакансиями. Сигнал слабее, чем в Slack-сообществах, но посмотреть стоит, особенно для remote-first компаний.

Партнёрские сети и сертификационные программы облачных провайдеров. AWS, Azure и Google Cloud ведут партнёрские программы, и наличие AWS Certified DevOps Engineer – Professional, Azure Administrator/DevOps Engineer Expert или Google Professional Cloud DevOps Engineer иногда попадаете в собственный talent-лист провайдера или партнёрский реферальный пайплайн — это зависит от региона и уровня партнёрства, так что воспринимайте это как то, что стоит проверить, а не как гарантию.

Темы «Who's Hiring» на Hacker News (ежемесячно, в первый рабочий день месяца) до сих пор публикуют инфраструктурные и платформенные вакансии от компаний, которые не хотят работать через рекрутеров, часто с прямым email нанимающего инженера вместо ссылки на ATS.

DevOpsDays и локальные митапы. Это очные или гибридные мероприятия, и вакансии упоминают со сцены или в Slack-канале события ещё до того, как их формально публикуют где-либо. Это не то же самое, что расплывчатый совет «больше нетворкайтесь» — это конкретный, регулярный формат событий с конкретной аудиторией платформенных и инфраструктурных инженеров, и организаторы обычно публикуют открытые вакансии в собственном канале события.

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

Агентства и важное разделение здесь

Рекрутинг в DevOps разделяется по линии, которая не вполне соответствует найму в других инженерных областях: постоянный наём идёт через универсальных технических рекрутеров или внутренние команды по подбору, но значительная доля работы — особенно проекты миграции в облако, создание платформ и замена SRE — идёт через рекрутеров контрактных и временных позиций.

Контрактная сторона работает на дневных ставках и, в Великобритании, на статусе IR35. Вакансия, объявленная как «outside IR35» через umbrella-компанию или вашу собственную limited company — это другие переговоры и другая налоговая позиция по сравнению с PAYE-контрактом или постоянной ролью, и специализированные инфраструктурные рекрутеры обычно сразу указывают этот статус в первом сообщении, потому что от него зависит, посмотрите ли вы вообще на ставку. Если рекрутер не может назвать статус IR35 при первом контакте, стоит спросить об этом до продолжения разговора, а не после.

Бутиковые рекрутеры, специализирующиеся именно на облачной инфраструктуре, SRE и платформенной инженерии (в отличие от общих агентств «IT-рекрутинга»), как правило, работают с более узкими, но точными заданиями — они обычно разговаривали с нанимающим менеджером, а не только с HR, и могут сказать, какой оркестратор, какое облако и есть ли дежурства. Универсальные агентства, работающие с DevOps-вакансией по списку ключевых слов, — это те, кто присылает вакансии, оказывающиеся должностями сисадмина с переименованным названием.

Значительное число DevOps- и платформенных вакансий вообще не попадает ни в одно внешнее агентство — их закрывает собственный рекрутер компании, напрямую обращаясь в LinkedIn к людям, чей профиль перечисляет конкретные инструменты (Terraform, Kubernetes, Prometheus, Grafana), а не просто должность. Поддержание этого раздела профиля актуальным и конкретным, а не только заголовка, здесь реально работает.

Внутренние перемещения и проблема платформенной команды

Большая часть найма DevOps в устоявшихся компаниях — вообще не наём, а внутренний перевод. Сисадмины и backend-разработчики переходят в платформенную или SRE-команду по мере того, как компания внедряет infrastructure-as-code и практики CI/CD, часто без внешней публикации вакансии. Компании, проходящие реорганизацию платформенной инженерии — разделение монолитной «DevOps-команды» на центральную платформенную команду плюс встроенные инженеры в продуктовых командах — обычно сначала набирают новую структуру из существующих сотрудников и открывают внешние позиции только для ролей, которые никто внутри не хочет или не имеет нужных навыков (часто это SRE-позиции с интенсивными дежурствами).

Это имеет практическое последствие: если вы пытаетесь перейти из сисадминов или backend-разработки в DevOps, внутренний путь у текущего работодателя может быть быстрее и реалистичнее, чем внешний рынок труда, потому что вы конкурируете ни с кем, а не с нанятыми извне специалистами. Если вы уже DevOps-инженер и пытаетесь сменить работодателя, это значит, что вакансия, за которой вы гонитесь, возможно, уже имеет неформального внутреннего кандидата, и внешняя публикация — если она есть — отчасти формальность, требуемая собственной политикой найма компании.

Тайминг и сезонность, характерные для этого рынка

Наём в DevOps и платформах следует двум календарям, которые не всегда совпадают: собственный финансовый год компании и вехи проектов облачных расходов или миграции.

Наём, обусловленный бюджетом, как правило, открывается в два окна: вскоре после начала нового финансового года (январь для компаний с календарным годом, апрель для британских компаний, привязанных к налоговому году), когда одобряются новые позиции, и в последнем квартале перед концом года, когда неизрасходованный бюджет используют до его потери — это часто упоминаемая модель в найме в технологиях вообще, не что-то уникальное для DevOps, но она применима здесь так же, как и везде.

Проектно-обусловленный наём более специфичен для этой области. Облачная миграция, создание Kubernetes-платформы или инфраструктурная модернизация, обусловленная комплаенсом (готовность к SOC 2, ISO 27001), создаёт определённую вспышку контрактного и постоянного найма DevOps, привязанную к началу проекта, и соответствующее падение продлений контрактов по мере достижения проектом стабильного состояния. Контрактные DevOps-инженеры, понимающие этот тайминг, иногда специально отслеживают, какие компании только что закрыли раунды финансирования или объявили облачные миграции, потому что это опережающий индикатор инфраструктурного найма через шесть-двенадцать недель.

Лето в северном полушарии и период вокруг декабрьских праздников широко известны как более медленные для найма в целом по технологиям, включая DevOps — меньше новых позиций открывается, больше вакансий застревает в лимбе интервью, потому что кто-то из панели в отпуске. Это не причина прекращать откликаться, но причина не читать молчание в августе как сигнал отказа.

Что с этим делать

Присоединитесь к Kubernetes Slack и CNCF Slack на этой неделе, если ещё не сделали этого, и проверяйте каналы с вакансиями напрямую, а не ждите дайджеста. Смотрите инженерные блоги и страницы карьеры целевых компаний напрямую — если они написали о миграции или перестройке платформы за последние полгода, это лучший сигнал, чем поиск на универсальной площадке вакансий. Если вы работаете по контракту, спрашивайте о статусе IR35 в первом разговоре, а не в третьем. И если вы уже внутри компании, спросите своего собственного лида платформы или SRE напрямую, реалистичен ли внутренний перевод, прежде чем предполагать, что придётся уходить для такого перехода.

То, что вы делаете на этом этапе, — в основном чтение и сопоставление: выясняете, какие из найденных вакансий действительно подходят вашему конкретному стеку и опыту, а какие нет. jobmarket.pro делает это чтение и сопоставление за вас: ищет по этим каналам, читает каждое объявление полностью и готовит отклик на основе вашего реального опыта, а не переписанного резюме.