Как составить резюме DevOps-инженера

На что рекрутер смотрит в первую очередь

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

Это отличается от резюме разработчика, где ищут языки программирования и проектирование систем. Рекрутер DevOps или SRE хочет видеть конкретные инструменты оркестрации и провижининга (Kubernetes, Terraform, Ansible, Pulumi), какое облако (AWS, Azure, GCP — и какие именно сервисы, потому что просто «AWS» мало что говорит), инструменты CI/CD (Jenkins, GitLab CI, GitHub Actions, CircleCI, ArgoCD) и несли ли вы дежурство. Если ваше резюме начинается с общей фразы о том, что вы «профессионал, ориентированный на результат», вы потратили свои шесть секунд на то, что ничего не сообщает.

Укажите стек, который вы использовали, и вашу конкретную зону ответственности в первой записи о работе, в первых двух строках. «Владел Terraform-модулями для провижининга EKS-кластеров в трёх AWS-аккаунтах» — подходит. «Отвечал за инфраструктуру и процессы развёртывания» — нет, потому что эта фраза одинаково подойдёт для резюме системного администратора или релиз-инженера. Вот тест: если предложение одинаково хорошо ляжет в резюме другой профессии, удалите его.

Сертификаты и насколько они важны

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

Сертификаты, которые реально признаются в этой области, узкий круг: AWS Certified DevOps Engineer – Professional, AWS Certified Solutions Architect, Microsoft Azure Administrator (AZ-104) или Azure DevOps Engineer Expert (AZ-400), Google Professional Cloud DevOps Engineer, Certified Kubernetes Administrator (CKA) и Certified Kubernetes Application Developer (CKAD) от CNCF, и HashiCorp Terraform Associate. Если у вас есть один из них, укажите его с годом получения — сертификаты в этой области стареют, потому что сервисы и содержание экзаменов меняются каждый год-два, и сертификат базового уровня 2019 года читается иначе, чем полученный в 2025.

Что не помогает: перечисление всех курсов Udemy или Coursera, которые вы прошли. Рекрутер, которому придётся разбираться, является ли «Docker & Kubernetes: The Complete Guide» признанным вендором сертификатом или курсом выходного дня, предположит второе и двинется дальше. Если самостоятельное обучение действительно релевантно, поместите его в короткую строку «сейчас изучаю», а не выдавайте за эквивалент сертификации — разница сразу видна любому в этой области, и притворство стоит вам доверия ко всему остальному на странице.

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

Как обычно подтверждают опыт в этой области

Работа DevOps не создаёт портфолио, на которое может указать дизайнер или писатель. Никто не может посмотреть на ваш Terraform state file. Поэтому резюме должно само выполнить работу по подтверждению, через конкретику, которую в принципе можно проверить, даже если читатель этого не делает.

Конкретика, которая имеет вес:

• Масштаб: количество нод, кластеров, сервисов или окружений, за которые вы отвечали. «Управлял Kubernetes-платформой» — расплывчато; «управлял 40-нодовым EKS-кластером, обслуживающим 12 продакшен-сервисов» — нет.
• Операционные метрики до и после, которые вы реально можете отнести к своей работе: частота развёртываний, время от коммита до продакшена, среднее время восстановления (MTTR), процент неудачных изменений — четыре метрики DORA — это ближайшее к общему языку измерений в этой области, и указание, какую из них вы сдвинули и примерно насколько, гораздо сильнее, чем «улучшил эффективность развёртывания».
• Владение инцидентами: были ли вы тем человеком, которого разбудили, а не просто кем-то в команде, у которой было дежурство. «Основной дежурный для платёжной инфраструктуры, одна неделя из четырёх» — конкретно. «Участвовал в реагировании на инциденты» — нет.
• Миграция и платформенная работа: переход с EC2 на контейнеры, с монолита на микросервисы, с самоуправляемого Kubernetes на управляемую control plane, с Jenkins на GitOps с ArgoCD. Миграции — естественный материал для резюме, потому что у них есть чёткие состояния до, после и длительность.
• Стоимость: оптимизация стоимости облака — то, что специально ищут рекрутеры с пониманием FinOps, и об этом редко упоминают. Если вы подобрали размер инстансов, перенесли нагрузки на spot или пересмотрели резервные мощности, и это снизило расходы, скажите об этом — это одно из немногих мест, где уместна цифра, при условии, что вы можете её защитить на собеседовании.

Что не подтверждает опыт: голый список названий инструментов без контекста. «Навыки: AWS, Docker, Kubernetes, Terraform, Jenkins, Prometheus, Grafana» вверху страницы говорит рекрутеру, что вы слышали об этих инструментах. Не говорит, что вы с ними делали. Каждый названный инструмент должен появиться снова, привязанный к задаче, где-то в разделе опыта — если этого нет, рекрутер обоснованно предполагает знакомство, а не владение.

Что должно быть на странице конкретно

• Облачный провайдер и глубина работы с ним. Не просто AWS — какие сервисы. EC2 и S3 — базовый уровень; EKS, RDS, проектирование IAM-политик, VPC peering и Lambda для автоматизации — другой уровень платформы.
• Инструменты infrastructure-as-code и писали ли вы модули или использовали готовые. Есть реальная разница между написанием переиспользуемого Terraform-модуля, который используют другие команды, и применением чужого.
• Конкретика оркестрации контейнеров: дистрибутивы Kubernetes имеют значение (vanilla, EKS, GKE, AKS, OpenShift), как и окружающие инструменты — Helm, Kustomize, service mesh'и вроде Istio или Linkerd, если вы их использовали.
• Стек observability: Prometheus, Grafana, Datadog, стек ELK/EFK, OpenTelemetry. Скажите, что вы инструментировали, а не просто на какой дашборд смотрели.
• Платформа CI/CD и дизайн пайплайнов, включая то, настраивали ли вы пайплайны в рамках существующего шаблона или проектировали с нуля, включая управление артефактами и стратегию отката.
• Точки касания безопасности и комплаенса, релевантные этой роли: управление секретами (Vault, AWS Secrets Manager), поддержка аудита SOC 2 или ISO 27001, работа с IAM по принципу наименьших привилегий. Если вы прошли через аудит комплаенса как инженер, который должен был предоставить доказательства, это стоит строки — и аудиторы, и рекрутеры признают это как особый вид давления.
• Язык, используемый для автоматизации и инструментария — Python, Go, Bash — названный как инструмент для цели (написание кастомных операторов, скриптов автоматизации, внутренних CLI), а не как общий список «языки программирования».

Что кандидаты с таким бэкграундом регулярно упускают

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

Второй пробел — провалы. Инженеры в этой области часто не хотят указывать падение в резюме, но хорошо обработанный инцидент с чётким описанием того, что сломалось, что вы сделали и что изменилось после, — более сильное доказательство старшинства, чем ещё одна строка про «поддержание uptime». Любой может заявить о высокой доступности; не каждый может описать, что он сделал в тот единственный раз, когда её не было.

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

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

Что делать дальше

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

Если вы отправляете заявки и не получаете ответа, стоит проверить, в чём пробел — в резюме или в соответствии — многие роли DevOps, рекламируемые под одним названием, покрывают совершенно разную реальную работу, от платформенной инженерии до управления релизами и чистого SRE, и резюме, настроенное на одно, читается как несоответствие для другого. jobmarket.pro читает каждое объявление полностью и готовит заявку из вашего реального опыта, сопоставленного с тем, что конкретно требует эта роль, вместо отправки одного и того же резюме на каждую вакансию с изменённым названием должности.