Разбор: как отвечать на собеседовании DevOps-инженера — от «расскажите о себе» до CrashLoopBackOff

Собеседование на DevOps-инженера проваливают не на kubectl. Проваливают на структуре: человек помнит, что такое IRSA, и не может за пару минут объяснить, что он сделал и чем это закончилось. Дальше — разбор реального интервью: вопросы, короткие ответы и то, как их лучше подать.

«Расскажите о себе» — это не биография

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

Рабочий пример: «DevOps-инженер, фокус на AWS, Kubernetes и автоматизации. Образование финансовое, поэтому понимаю бюджеты и стоимость. Дальше ушёл в технологии, потому что нравится разбирать проблемы и автоматизировать». Потом одна фраза про суть работы: Terraform-модули для команд, CI/CD на GitHub Actions и Jenkins, Helm и Argo CD для GitOps на EKS, мониторинг в Prometheus, Grafana, CloudWatch и Datadog. И сертификаты — AWS Solutions Architect Associate, Terraform Associate.

Финальный абзац — про компанию. В исходном интервью он звучал конкретно: переход на Salesforce, platform engineering, quality engineering, ставка на безопасную доставку и надёжность. Не «мне интересно расти», а «вот работа, которую я люблю и которую у вас делают».

Проект: проблема → что сделал → результат → твоя зона

Четвёртая часть — та, которую забывают. Именно она отличает инженера от исполнителя.

Пример с EKS: больше 100 микросервисов, команды деплоили по-разному — кто через Jenkins-скрипты, кто руками через kubectl. Деплой занимал 40–45 минут, часто падал, и никто не мог сказать, какая версия сейчас в проде.

Что сделал: кластеры EKS через Terraform-модули (VPC, node groups, IAM-роли, add-ons), единый шаблон Helm-чарта для всех сервисов, Argo CD как GitOps — merge в Git означает автоматический деплой. Плюс кеширование слоёв Docker, multi-stage сборки, параллельные тесты, Trivy и SonarQube, HPA, RBAC, секреты в AWS Secrets Manager, Prometheus и Grafana с алертами.

Результат: 40 минут превратились в 12, примерно на 70% быстрее. Откат стал одним git revert, команды перестали ждать DevOps.

Разграничение зон: платформа и путь доставки на мне, код, Dockerfile и Helm-values — на разработчиках, тесты — на QA, результаты сканов и политики — на безопасности. Без этой части рассказ про 70% звучит как хвастовство.

Цифры с разграничением ответственности читаются как опыт. Цифры без него — как реклама себя.

Технический блок: как строить короткий ответ

Схема одна: определение, как применяешь на практике, где подводный камень. Три предложения лучше трёх минут.

AWS и сети

• Отказоустойчивое приложение: VPC с публичными и приватными подсетями в двух-трёх AZ, ALB в публичных, приложение в приватных на EKS или EC2 с автоскейлом, RDS Multi-AZ, NAT gateway для исходящего трафика, Route 53, бэкапы и алармы CloudWatch.
• Публичная подсеть отличается наличием маршрута в internet gateway. Приватная выходит наружу только через NAT.
• Доступ из pod к S3 — через IRSA или EKS Pod Identity: pod получает IAM-роль с минимальными правами, ключей в коде нет.
• Стоимость режут right sizing, автоскейл, savings plans и reserved instances, spot для некритичных нагрузок, удаление неиспользуемого, lifecycle-правила в S3 и теги по командам с отчётом из Cost Explorer.

Terraform

• State — файл соответствия кода и реальных ресурсов. Держу в S3 с шифрованием и версионированием, блокировки через DynamoDB или нативный лок в S3, чтобы двое не меняли одно и то же.
• Окружения: переиспользуемые модули VPC, EKS, RDS, S3 и отдельные папки или workspace под dev, stage, prod. У каждого свой state и свои переменные, модули версионируются в Git.
• Drift: если кто-то поправил ресурс в консоли, terraform plan это покажет — либо импортировать изменение в код, либо применить и вернуть как было. Профилактика: ограничить запись в консоли и гонять plan в пайплайне регулярно.
• На PR — fmt, validate, tflint, Checkov или tfsec, plan и комментарий с планом в пулл-реквесте. Apply после апрува и мержа, прод только с ручным подтверждением.

Kubernetes

Два вопроса дают чаще всего, и оба проверяют не память, а ход мысли.

• CrashLoopBackOff: kubectl describe pod показывает события, kubectl logs и logs --previous — причину. Обычно это неверный config или секрет, падение приложения, сломанный health probe либо OOMKilled из-за низкого лимита памяти.
• Pending: на нодах нет CPU или памяти, не совпали node selector или taints, либо PVC не забиндился.

Пары понятий, которые спрашивают чаще всего

GitOps и хороший пайплайн

Git — единственный источник правды, Argo CD следит за репозиторием и приводит кластер к его состоянию. У любого изменения есть история, откат — revert коммита или возврат к предыдущей синхронизированной версии. С Helm это helm rollback, с canary — остановка раскатки.

Пайплайн по шагам: сборка, юнит-тесты, скан кода, скан зависимостей, сборка образа, скан образа, push в ECR, обновление Helm values в Git, деплой в dev через Argo CD, интеграционные и smoke-тесты, апрув, stage и prod. Секреты в GitHub Actions — не долгоживущие ключи AWS, а OIDC с получением роли.

Безопасность без тормозов для команд: быстрые сканы на каждом PR, глубокие — ночью, блокировка только по critical и high, остальное отчётом в пулл-реквесте.

Наблюдаемость и SRE

SLI — измерение (доля успешных запросов), SLO — внутренняя цель вроде 99,9%, SLA — обещание клиенту с последствиями, error budget — сколько сбоев допустимо. Бюджет кончился — релизы притормаживают и команда занимается надёжностью.

От усталости от алертов спасает одно правило: алертить на симптомы, которые чувствует пользователь (error rate, задержки), а не на каждый скачок CPU. У каждого алерта должно быть действие и runbook, маршрутизация по критичности в PagerDuty или Opsgenie. Golden signals — latency, traffic, errors, saturation.

Поведенческие вопросы: одна история, рассказанная до конца

Про инцидент: после деплоя приложение начало отдавать ошибки. Зашёл на созвон, увидел рост error rate в Grafana, нашёл причину — в новом релизе использовалось неверное имя секрета. Откатились через Argo CD за несколько минут, потом добавил проверку в пайплайн и написал разбор причин, чтобы не повторилось.

Про конфликт: разработчик просил прямой доступ kubectl в прод, чтобы «чинить быстро». Аргумент был про риск, договорились на GitOps плюс break glass процесс для аварий. Скорость и безопасность остались у обоих.

Про внедрение инструмента: Argo CD начинал с пилотной команды, показал результат, написал гайды, провёл демо, дальше команды переезжали по одной. Большинство перешло за несколько месяцев.

Чего не знаешь: схема вместо «не знаю»

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

• Azure и Azure DevOps — основной опыт AWS, но концепции те же: YAML-стадии, джобы, апрувы, service connections.
• New Relic и Splunk — был Datadog, Prometheus и Grafana, идея та же: APM, метрики, логи, алерты.
• HashiCorp Vault — использовал AWS Secrets Manager, задача одна и та же.
• Salesforce — опыт ограничен, но CI/CD там понятный: метаданные в Git, Salesforce CLI в GitHub Actions, валидация и деплой в sandbox, Apex-тесты, потом прод с апрувом.

Про AI стоит отвечать честно и по делу: AIOps ищет аномалии и группирует связанные алерты, а Copilot и Claude ускоряют написание Terraform и скриптов, помогают разобрать ошибку и сжать логи. С оговоркой — результат всегда проверяется перед использованием.

Что спросить у них

Вопросы выдают уровень кандидата не хуже ответов. Как выглядит успех за первые 90 дней. Какой облак основной — AWS, Azure или оба. Как сейчас деплоят изменения в Salesforce. Есть ли SLO и on-call, в каких инструментах. Как DevOps взаимодействует с безопасностью и quality engineering. Какие AI-инструменты уже используют. И самый полезный: что сейчас болит сильнее всего.

Ошибки, которые видно сразу

• Пересказ резюме вместо истории с результатом.
• Успех без цифры: «ускорили деплой» вместо «с 40 минут до 12».
• Ответ «я делал всё» — значит, непонятно, что именно ты.
• Молчание на незнакомый инструмент вместо схемы «не работал, но вот похожий опыт».
• Ноль вопросов в конце — читается как безразличие к тому, куда идёшь.

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