Ринок інфраструктурних інженерів в Україні перегрітий: на middle+/senior DevOps і SRE активно претендують продуктові компанії та сервісні гравці. Тому класичні дошки вакансій часто ведуть до потоку нерелевантних відгуків: приходять системні адміністратори без практики Kubernetes, IaC і Observability, або люди, які готові «повчитися в процесі». Якщо вам потрібен інженер, який завтра підніме кластери, налаштує release pipeline, впровадить error budgets і не боїться on‑call, джерела потрібно змінювати.
Найкоротший шлях до релевантних кандидатів — там, де вони вже створюють цінність: у профільних спільнотах, навколо OSS‑проєктів і на технічних подіях. Якщо часу на системний сорсинг бракує або потрібно пришвидшитися без втрати якості, то перевірена рекрутингова агенція — може зекономити тижні пошуку й зменшує ризик «зриву» офера.
CEO/CTO і VP Engineering стикаються з дефіцитом middle+/senior DevOps/SRE, високою конкуренцією та швидкими зустрічними оферами. Частою проблемою є потік «адмінів» замість Platform/Cloud‑інженерів і слабка практика K8s/IaC/Observability. Нижче — практичні канали й інструменти відбору, що скорочують time‑to‑hire без втрати якості.
Сорсинг DevOps і SRE: практичні канали та фільтри
Спільноти: де шукати і як поводитися
- Telegram/Slack/Discord‑чати з DevOps/SRE/Platform Engineering. Шукайте локальні UA‑групи та міжнародні чати з активною модерацією і правилами вакансій.
- Форуми та гілки cloud‑провайдерів (AWS/GCP/Azure) і екосистема CNCF: обговорення Helm/Prometheus/Grafana/Flux/ArgoCD дають хороші приводи для «теплого» контакту.
- Мітапи та локальні міт‑комʼюніті (онлайн/офлайн): спікери й активні учасники нерідко відкриті до діалогу та реферальних інтро.
Як не перетворитися на спамера:
- Читайте правила каналу, публікуйте вакансії у правильному треді, використовуйте теги стеків (
K8s,Terraform,GCP,ArgoCD). - Не шліть одне й те саме повідомлення всім підряд. Привʼяжіть контакт до контексту людини: її доповідь, коментар, GitHub‑внесок.
- Давайте конкретику: середовище (AWS/GCP/Azure), оркестратор (K8s), IaC (Terraform/Pulumi), CI/CD (GitHub Actions/GitLab CI/Argo), observability‑стек (Prometheus/Grafana/Tempo/Loki/OpenTelemetry).
OSS‑проєкти: сигнал компетенцій, який складно підробити
Участь у Open Source — один із найнадійніших індикаторів зрілості. Навіть невеликі, але регулярні внески показують інженерну дисципліну, вміння працювати з чужим кодом і практику peer review.
Як оцінювати OSS‑внесок DevOps (чек‑лист)
- Пул‑реквести: тема, розмір, якість опису, наявність тестів і документації, реакція мейнтейнерів.
- Review‑коментарі: глибина зауважень, ввічливий тон, уміння пропонувати альтернативи, посилання на специфікації/issue.
- Issue‑історія: ініціатива в постановці задач, участь у тріажі, готовність закривати проблеми в корені.
- Частота й контекст: разові PR «для галочки» — слабкий сигнал; регулярність по кількох репозиторіях — сильний.
- Користь для проєкту: вклад у docs, чарти Helm, пайплайни CI/CD, модулі Terraform, алерти Prometheus — це прямі маркери застосовності.
Конференції та мітапи: де не марнувати час
- Спікери та автори воркшопів — часто найкращі вхідні точки. Постарайтеся підготуватися: перегляньте їхні презентації та ставте по суті запитання.
- Job‑corners/BoF‑сесії — гарні для коротких інтро та обміну контактами. Беріть «one‑pager» вакансії з чітким стеком і задачами.
- Після події — надішліть персональну подяку й один конкретний «fit»‑поінт («ваш доклад про GitOps → у нас Argo Rollouts у проді, цікавий ваш погляд на канарейкові релізи»).
Нетривіальні джерела
- Issue‑трекери популярних інструментів (kubernetes, istio, argo, prometheus): автори добре розбираються в продакшн‑проблемах.
- Каталоги Helm‑чартів і провайдерів Terraform: контрибʼютори часто «production‑first» і розуміють нюанси операційки.
- Post‑mortem/інцидент‑блоги компаній: автори звітів, SRE/Platform‑команди — хороший lead‑ліст для «теплого» outreach.
Сорсинг у спільнотах: шаблон інтро‑повідомлення
- Контекст → цінність → next step. «Олексію, побачив ваш огляд по ArgoCD ApplicationSets у чаті CNCF. Ми в проді тримаємо ~60 кластерів і мігруємо проєкти на GitOps. Є роль Platform Engineer з ownership CI/CD та observability. Можна 15 хвилин на сінк? Надішлю 5 bullets зі стеком.»
- Коротко і без «ковардрингу». 3–4 рядки, 1 чітка причина, чому пишете саме йому/їй, 1 конкретика по стеку, зрозумілий call‑to‑action.
- Повага до приватності. Не просіть резюме «тут і зараз», запропонуйте зручний слот/пошту/календар.
Scorecard DevOps/SRE і таблиці для найму під ключ
Scorecard DevOps/SRE (що перевіряти на інтервʼю)
Компетенція Що спитати/перевірити Сигнали middle+ Сигнали senior IaC (Terraform/Pulumi) Модульність, версіонування, стейт‑менеджмент, план/апрув, міграції, drift‑контроль. Пише модулі, розбирається в remote state, уміє безпечно розгортати зміни. Стандартизує каталоги, впроваджує policy as code (OPA), автоматизує ревʼю і дрейф‑алерти. Kubernetes Мережа/Ingress/Service Mesh, HPA/VPA, StatefulSet/DaemonSet, RBAC, Operator‑патерни. Відлагоджує CrashLoopBackOff, читає події, працює з лімітами ресурсів. Проєктує багатокластерні середовища, використовує GitOps і progressive delivery. CI/CD Пайплайни, артефакти, секрети, rollback/rollout, canary/blue‑green. Оптимізує час збірки, кешує залежності, пише smoke‑тести. Будує багатостадійні пайплайни, продумує release gates і релізи на основі SLO. Observability Метрики/логи/трейси, ретеншн, політики алертів, SLO/SLA/SLI, blackbox‑моніторинг. Виводить бізнес‑метрики, тримає алерти без «шуму», робить пост‑мортеми. Проєктує повністю спостережувані системи, повʼязує SLO з продуктовою цінністю. SRE‑принципи Error budgets, зменшення toil, автозапуск, runbooks, обґрунтування ризику. Уміє захищати бюджет помилок, автоматизує рутину. Веде культуру надійності, навчає інженерів і домовляється з продуктом про ризики. On‑call/інциденти Режими чергувань, ескалації, ретроспективи, підхід blameless. Тримає SLO, не «глушить» алерти, пише зрозумілі пост‑мортеми. Будує процес від детекту до RCA, скорочує MTTR і підвищує MTTD. Безпека й комплаєнс Секрет‑менеджмент, SBOM, скан уразливостей, політика прав. Інтегрує сканери в CI/CD, зберігає секрети коректно. Стандартизує безпечні пайплайни, вводить least privilege/audit‑трейли. Cloud/Networking/FinOps VPC/підмережі/шлюзи, IAM, вартість → SLO, бюджетування. Рахує вартість середовищ, оптимізує idle‑ресурси. Повʼязує ціну інцидентів із бізнес‑метриками, впроваджує бюджет‑аларми й тегування.
«Де шукати DevOps»: карта каналів
Канал Як шукати Критерії релевантності Ризики/етика Очікуваний відгук Профільні чати (Telegram/Slack/Discord) Пошук за ключами: K8s, Terraform, ArgoCD, Prometheus; треди вакансій. Активні учасники, релевантні коментарі, портфоліо/доповіді в профілі. Дотримуватися правил каналів; нульова толерантність до спаму. Середній: 5–10% за персонального звернення. GitHub/GitLab (OSS) Контрибʼютори чартів/операторів/плагінів; автори PR і ревʼю. Регулярність внесків, якість описів, тести/доки. Поважати ліцензії/політики; писати мейнтейнерам коректно. Менше за обсягом, вище за якістю: 2–5%. Конференції/мітапи Список спікерів, воркшопів, BoF; follow‑up наступного дня. Відповідність стеків, досвід продакшн‑інцидентів. Не «полювати» в черзі; поважати приватність. Персональні інтро: 10–20% відповідей. Форуми cloud‑провайдерів/CNCF Теми з рішеннями прод‑проблем; автори відповідей. Глибина рішень, посилання на код/чарти. Дотримуватися правил комʼюніті. Невеликий, але цільовий відгук: 3–7%. Реферальні мережі Співробітники/екс‑колеги → інтро в DevOps‑спільноти. Верифіковані рефи, «warm intro» від довіреної особи. Прозорі бонуси; без тиску на реферерів. Най«тепліший» канал: 20–35% відповідей. Alumni та локальні тех‑школи Випускники з досвідом прод‑стажувань, мідли 3–5 років. Кейси продакшн‑впроваджень у портфоліо. Не плутати випускні проєкти з продом. Середній: 5–12%.
Скрипти першого повідомлення кандидату (коротко)
- LinkedIn/чат: «Ольго, побачив ваш розбір Thanos/Tempo після інциденту. Ми якраз проєктуємо трейсинг на OpenTelemetry. Роль: DevOps з ownership observability. 15 хвилин синка завтра? Надішлю стек і SLO.»
- OSS‑контрибʼютор: «Ігоре, дякую за PR у Helm‑чарт Argo Rollouts — класна ідея з параметризацією сіток. Ми масштабуємо canary в 80+ сервісах. Готові обговорити роль Platform Engineer у проді?»
- Після доповіді: «Андрію, сподобався кейс із GitOps‑міграції. Ми мігруємо монорепозиторій на ApplicationSets, є нетривіальні задачі. Якщо ок, надішлю 5 bullets по ролі та обговоримо у зручний час.»
- Реферальне інтро: «Марино, ми знайомі через Сергія (ex‑N). Потрібен DevOps із досвідом multi‑cluster K8s. Якщо актуально — вишлю 1‑пейджер ролі й календар на 15 хв.»
Кейси з цифрами: що реально дають канали
Нижченаведені метрики — з практики підбору DevOps/SRE для продуктових команд та enterprise‑інфраструктури: TFFC — час до першого релевантного кандидата; TTH — time‑to‑hire.
- Кейс A (фінтех, 2 DevOps, стек: AWS/K8s/Terraform/ArgoCD). Канали: OSS‑контрибʼютори Helm/Argo + реферальні інтро від спікерів міт‑апів. TFFC: 5 робочих днів. Конверсія інтервʼю→офер: 33% (4 із 12). TTH: 28 днів. Утримання 90 днів: 100%.
- Кейс B (маркетплейс, Platform Engineer). Канали: Discord‑спільнота CNCF, автори відповідей по Prometheus/Alertmanager. TFFC: 7 днів. Інтервʼю→офер: 25% (3 із 12). TTH: 35 днів. Утримання 120 днів: 100%.
- Кейс C (enterprise, Observability‑спеціаліст). Канали: post‑mortem‑блоги + GitHub‑issues Tempo/Loki. TFFC: 6 днів. Інтервʼю→офер: 20% (2 із 10). TTH: 32 дні. Утримання 180 днів: 100%.
HowTo: як швидко відсіяти нерелевант
- Міні‑бриф на старті: 5 bullets: домен, стек (cloud/K8s/IaC/CI/CD/obs), рівень зарплати/тип зайнятості, on‑call‑очікування, timezone.
- Screening 15 хвилин: два продакшн‑кейси по K8s/IaC і один — по інциденту (що сталося, як діагностував, що пофіксили, які висновки).
- Тестове ≠ «проєкт на 2 дні»: краще «робоча година»: описати план міграції на GitOps/Argo Rollouts або запропонувати схему SLO й алертів.
- Фідбек за 24 години: лист із конкретикою — стек, етапи, KPI ролі, можливі ризики; це знижує зрив оферів.
Як не «зривати» офери
- Швидкість і прозорість: погодьте пул інтервʼю заздалегідь, тримайте слот‑пул на найближчі 3–5 днів.
- Офер‑бридж: обговорюйте on‑call, компенсацію за чергування, рівень володіння інфраструктурою, бюджет на навчання.
- Ризики відкрито: технічний борг, міграції, нічні вікна — краще назвати заздалегідь і показати план, ніж втратити кандидата наприкінці.
One‑pager ролі DevOps/Platform (скелет)
- Задачі 90 днів: цілі по IaC, стабілізація пайплайнів, впровадження SLO, план on‑call.
- Середовище: cloud, кластери, мережа, observability‑стек.
- Межі відповідальності: де DevOps, де команда розробки, де Sec.
- KPI: MTTR/MTTD, lead‑time, раз на квартал — зниження шуму алертів на X%.
Про експерта
Олександр Фольгін — засновник BestHeads (аутстафінг/рекрутинг), у індустрії з 2017 року. Фокус: пошук DevOps/SRE/Platform/Cloud‑інженерів для продуктових команд та enterprise‑інфраструктури. Підбирає команди під задачі надійності, продуктивності та вартості хмари.
Що зробити завтра
- Виберіть 2–3 канали з таблиці вище й розгорніть «по одному експерименту на канал».
- Зберіть власний scorecard за шаблоном і домовтеся всередині інженерного блоку, що вважаємо «сильним сигналом».
- Заведіть трекер сорсингу: канал → контакти → статус → фідбек → метрики (TFFC, TTH, конверсії, утримання).