Не можем найти DevOps-инженера: почему поиск затягивается и что делать

Вакансия DevOps-инженера открыта уже несколько недель. Отклики приходят, резюме просматриваются, технические интервью идут — но подходящего человека всё равно нет. Один кандидат силён в Linux и автоматизации, но почти не работал с Kubernetes. Другой хорошо знает облака, но не сталкивался с нужным production-контуром. Третий формально выглядит как Senior, однако его опыт построен вокруг совсем другого инфраструктурного стека.

Через некоторое время поиск начинает повторяться. На job-сайтах появляются те же специалисты, новые отклики мало меняют картину, а требования проекта остаются прежними.

В этот момент легко сделать вывод, что «DevOps на рынке нет». Но чаще проблема сложнее. Под названием DevOps разные компании понимают разные роли, инфраструктурный контекст сильно меняет требования, а сочетание Kubernetes, cloud, Terraform, CI/CD, сетей, security и production-опыта может превратить внешне широкую вакансию в очень узкий профиль.

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

Почему вакансия DevOps может долго не закрываться

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

Но уже после первых резюме становится видно, что реальный профиль значительно уже.

Компания может одновременно ожидать, что специалист:

• глубоко знает Linux;
• уверенно работает с Kubernetes и контейнеризацией;
• использует Terraform или другие IaC-инструменты;
• строит и поддерживает CI/CD;
• понимает облачную инфраструктуру;
• разбирается в сетях;
• умеет работать с мониторингом, логами и observability;
• понимает требования к security;
• имеет опыт именно с production-системами сопоставимого масштаба;
• способен самостоятельно проектировать инфраструктурные изменения.

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

Поэтому проблема часто не в количестве DevOps-инженеров вообще, а в количестве людей, чей опыт совпадает именно с инфраструктурой и задачами конкретной компании.

Под названием DevOps компании ищут разные профили

DevOps — одна из тех ролей, где одинаковое название вакансии ещё меньше говорит о фактической работе, чем во многих других IT-профессиях.

В одной компании DevOps-инженер в основном развивает CI/CD и автоматизацию. В другой отвечает за Kubernetes-кластеры. В третьей много работает с облачной инфраструктурой. В четвёртой значительная часть роли связана с эксплуатацией, инцидентами и надёжностью production.

Где-то DevOps тесно работает с разработчиками и внутренней платформой. Где-то роль ближе к инфраструктурному инженеру. Где-то от него ожидают одновременно функции DevOps, SRE, cloud engineer и части security.

В резюме у всех этих специалистов может стоять одинаковое «DevOps Engineer».

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

Количество найденных DevOps-профилей и количество кандидатов, подходящих именно под вашу инфраструктуру, — разные величины.

Почему DevOps и системный администратор — не одно и то же

Часть сложностей возникает, когда компания фактически пытается найти современного системного администратора под названием DevOps — или, наоборот, ожидает от DevOps-инженера преимущественно классического администрирования.

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

Но если ключевая задача вакансии — автоматизация инфраструктуры, Infrastructure as Code, контейнерная оркестрация, CI/CD, взаимодействие с командами разработки и воспроизводимые процессы развертывания, одного сильного опыта системного администрирования может быть недостаточно.

Обратная ситуация тоже встречается. Кандидат с сильным cloud-native и Kubernetes-опытом может быть не лучшим выбором для компании, где основная работа связана с большой legacy-инфраструктурой, физическими серверами, специфическими сетями и ручным сопровождением большого on-prem-контура.

Если граница роли не определена, на вакансию начинают приходить два разных рынка кандидатов — и большая часть откликов оказывается «почти подходящей».

Почему DevOps и SRE не всегда взаимозаменяемы

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

В DevOps-вакансии фокус может быть на автоматизации инфраструктуры, CI/CD, платформенных инструментах и ускорении delivery.

В SRE-контексте сильнее проявляются эксплуатационная надёжность, SLI/SLO, observability, управление инцидентами, on-call, postmortem-практики и системная работа с доступностью сервисов.

У опытного инженера компетенции могут пересекаться. Но если компания ищет DevOps, а фактически ожидает зрелого SRE с сильным production-опытом и ответственностью за доступность критичных сервисов, рынок кандидатов становится заметно уже.

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

При затянувшемся поиске важно смотреть не на название профессии, а на то, какие задачи действительно будут занимать основную часть рабочего времени.

Как Kubernetes, cloud, Terraform, CI/CD, сети и security сужают рынок

Основная сложность DevOps-подбора появляется не из-за одного конкретного инструмента. Рынок сужает сочетание технологий и требуемая глубина их использования.

Kubernetes и контейнерная платформа

Одно дело — иметь опыт развертывания приложений в Kubernetes. Другое — самостоятельно проектировать и сопровождать кластеры, решать сетевые проблемы, строить обновления без простоев, работать с ingress, storage, secrets, policy, observability и производительностью.

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

Cloud и on-prem

Опыт AWS, Azure, GCP или российского облака не всегда переносится один к одному на крупную on-prem-инфраструктуру. И наоборот, сильный инженер из традиционного дата-центра может не иметь достаточной практики управления облачными сервисами.

Гибридная среда ещё сильнее повышает требования: специалисту приходится понимать оба мира и взаимодействие между ними.

Terraform и Infrastructure as Code

Фраза «знает Terraform» тоже может означать разные уровни. Один инженер использовал готовые модули, другой строил инфраструктурную кодовую базу, проектировал state-management, reusable-модули, процессы review и изменения инфраструктуры через Git.

Для сложного проекта эта разница критична.

CI/CD

Запустить несколько пайплайнов и проектировать устойчивую систему delivery для десятков или сотен сервисов — разные задачи.

Если компании нужен человек, способный менять сам подход к сборке, тестированию, deployment и rollback, простого опыта работы с GitLab CI, Jenkins или аналогичным инструментом недостаточно.

Сети и security

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

Чем больше таких областей объявлены обязательными одновременно, тем реже становится профиль кандидата.

Почему слишком большое число технологий создаёт редкий профиль

Типичная DevOps-вакансия со временем начинает собирать требования от нескольких участников.

Разработке нужен Kubernetes и CI/CD. Инфраструктурной команде — Linux, сети и виртуализация. Security добавляет свои требования. Архитектор хочет сильный cloud и IaC. Руководитель ожидает самостоятельность уровня Senior и способность вести изменения целиком.

В итоге появляется вакансия, где обязательны Kubernetes, Helm, Terraform, Ansible, GitLab CI, несколько облаков, VMware, Linux, Python, Bash, PostgreSQL, Kafka, Prometheus, Grafana, ELK, Vault, сетевые технологии и опыт highload.

Каждый инструмент может быть нужен компании. Но необязательно, чтобы один кандидат был одинаково глубоким экспертом во всём списке.

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

Middle, Senior и Lead — разные рынки

Грейд DevOps-инженера определяется не только стажем.

Middle обычно уверенно работает в существующем инфраструктурном контуре и самостоятельно решает понятные задачи. Senior способен проектировать изменения, видеть риски на уровне системы, разбираться с неопределённостью и брать ответственность за сложные production-сценарии.

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

При этом уровни между компаниями сильно отличаются. Senior в одной команде может соответствовать Middle+ в другой, а инженер без слова Lead в должности фактически несколько лет выполнять лидерскую функцию.

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

Почему откликов может быть много, а релевантных кандидатов мало

DevOps-вакансия может получать заметное количество откликов и всё равно оставаться незакрытой.

Кто-то работал преимущественно системным администратором. Кто-то силён в cloud, но почти не сталкивался с on-prem. Кто-то использовал Kubernetes только как пользователь платформы. Кто-то хорошо автоматизирует инфраструктуру, но не работал с production сопоставимого масштаба.

В результате HR или технический руководитель тратит время на десятки резюме, а до финальных этапов доходят единицы.

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

Что происходит после исчерпания job-сайтов

Job-сайты показывают прежде всего специалистов, которые сейчас активно рассматривают предложения, обновили резюме или регулярно просматривают вакансии.

Для массовых и средних по сложности позиций этого может быть достаточно.

При поиске Senior DevOps, инженера под сложный Kubernetes-контур, hybrid infrastructure, highload или редкое сочетание cloud и on-prem ситуация другая.

После нескольких недель работодатель начинает видеть повторяющуюся выборку. Новые резюме появляются, но редко меняют качество воронки.

Ещё одно поднятие вакансии может дать несколько откликов, но не открывает новый рынок.

На этом этапе поиск должен меняться: вместо ожидания кандидатов нужно определять, где работают люди с подходящим инфраструктурным опытом, и выходить на них напрямую.

Почему сильные DevOps часто находятся на пассивном рынке

Опытному DevOps-инженеру необязательно активно искать работу, чтобы быть готовым рассмотреть сильное предложение.

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

При этом интересная инфраструктурная задача, технически зрелая команда, больший масштаб систем, возможность влиять на архитектуру или более подходящий формат работы могут заинтересовать человека, который формально «не ищет».

Именно поэтому при сложном поиске важно учитывать пассивных кандидатов.

Это уже не работа с входящими откликами. Нужно искать инженеров по компаниям, инфраструктурному контексту, прошлым проектам и реальному масштабу ответственности.

Почему инфраструктурный контекст компании критичен

DevOps — роль, в которой прошлый контекст кандидата особенно важен.

Два инженера могут знать одинаковые инструменты, но решать принципиально разные задачи.

Cloud

В cloud-native компании большая часть инфраструктуры может строиться вокруг managed services, Kubernetes, IaC и автоматического масштабирования.

On-prem

В on-prem-среде важнее могут быть виртуализация, физическая инфраструктура, сети, storage, особенности дата-центра и ограничения, которых нет в публичном облаке.

Hybrid

В гибридном контуре требуется понимание сразу обоих подходов и того, как они связаны между собой.

Production и highload

Опыт работы с внутренними тестовыми средами и ответственность за высоконагруженный production также дают разный профессиональный опыт.

Там, где цена ошибки высока, особенно важны мониторинг, отказоустойчивость, rollback, управление изменениями и способность действовать во время инцидентов.

Поэтому при поиске DevOps недостаточно сопоставить список технологий. Нужно сопоставлять масштаб и характер инфраструктуры.

Как слишком широкий профиль вакансии мешает поиску

Одна из самых частых причин долгого поиска — попытка собрать в одной позиции несколько самостоятельных ролей.

От кандидата одновременно ждут DevOps, SRE, cloud engineer, network engineer, DBA, security engineer и иногда ещё части функций разработчика.

На бумаге это выглядит как подробное описание сильного специалиста. На рынке — как профиль, которому соответствуют единицы.

При затянувшемся поиске полезно разделить требования на три группы:

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

Это не означает снижать требования к качеству. Задача — перестать требовать идеального совпадения по каждому инструменту, если реальная работа этого не требует.

Почему незакрытая DevOps-позиция может тормозить бизнес

DevOps-вакансия редко существует отдельно от работы других технических команд.

Если инженера не хватает, последствия могут проявляться в скорости релизов, стабильности production, очереди инфраструктурных задач и способности команды менять платформу.

Разработчики могут дольше ждать окружения. CI/CD остаётся неудобным или нестабильным. Миграция в Kubernetes или облако откладывается. Инфраструктурные изменения концентрируются на одном перегруженном сотруднике. Технический долг продолжает расти.

При критичной роли появляется и риск зависимости от одного специалиста, который единственный знает определённый участок инфраструктуры.

Поэтому через некоторое время стоимость незакрытой вакансии начинает измеряться уже не количеством часов рекрутера, а задержанными релизами, инфраструктурными проектами и рисками эксплуатации.

Когда нужен прямой поиск

Прямой поиск становится логичным, когда открытый рынок перестал давать новые релевантные профили.

Признаки обычно хорошо заметны:

• job-сайты несколько недель показывают примерно одних и тех же инженеров;
• на вакансию откликаются, но сильных кандидатов среди откликов почти нет;
• нужен Senior или Lead с конкретным infrastructure background;
• важен редкий опыт — например, hybrid, highload или сложная Kubernetes-платформа;
• подходящие специалисты находятся, но сами работу не ищут;
• внутренняя команда уже исчерпала очевидные источники.

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

Когда внешний IT-рекрутер становится разумным решением

Передавать DevOps-вакансию подрядчику нужно не всегда.

Если у компании есть опытная внутренняя IT-рекрутинговая команда, достаточно времени и доступ к нужному сегменту кандидатов, поиск можно продолжать самостоятельно.

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

Например, когда несколько недель повторяется одна и та же выборка, нужен редкий Senior-профиль, инфраструктурные проекты начинают зависеть от закрытия позиции или внутренний рекрутер физически не может вести полноценный direct search.

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

Если поиск дошёл именно до этой стадии, подробнее о профессиональной работе с вакансией можно посмотреть на странице подбор DevOps-инженера.

Что менять, если обычный поиск перестал давать новых кандидатов

Если DevOps-инженера долго не удаётся найти, бесконечное повторение одного и того же поиска редко меняет результат.

Сначала нужно определить, где именно возникло ограничение.

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

Если кандидаты подходят по технологиям, но проваливаются на реальном опыте — возможно, важнее искать по инфраструктурному контексту, а не по списку инструментов.

Если требуются одновременно DevOps, SRE, cloud, network и security-компетенции — стоит проверить, действительно ли всё это должно быть глубоко представлено в одном человеке.

Если активный рынок уже просмотрен — поиск нужно расширять на пассивных специалистов.

А если незакрытая позиция уже тормозит релизы, production-изменения и инфраструктурные проекты, стоимость продолжения прежней тактики может быть выше стоимости перехода к прямому поиску.

Главный вопрос в такой ситуации — не «где ещё разместить DevOps-вакансию», а «какой сегмент сильных инженеров мы пока не охватили и почему».