Тест DevOps инженера: примеры вопросов и шаблон оценки
Почему общие вопросы про инфраструктуру не работают
Большинство DevOps оценок задают учебниковые вопросы: "Что такое контейнер?" или "Определи CI/CD." Эти вопросы измеряют повторение фактов, а не умеет ли человек спроектировать устойчивую систему под давлением или отладить production incident в 2 ночи.
Реальный DevOps тест должен измерять суждение, а не факты. Он должен проверить, понимает ли человек компромиссы между автоматизацией и работаемостью, знает ли, когда масштабировать горизонтально против вертикально, и может ли рассуждать о режимах отказа.
Вот как выглядит тест DevOps, который несёт сигнал.
Категория 1: Дизайн инфраструктуры под ограничениями
Вопрос, основанный на сценарии:
"У вас есть приложение на одном EC2 инстансе. Оно обрабатывает 1000 RPS, использует 70% CPU и 4GB RAM с 60% утилизацией. Ваш SLA — 99,9% uptime. Приложение stateless. Какие изменения вы сделаете и в каком порядке? Какие компромиссы вы делаете?"
Это проверяет:
- Понимание масштабируемости против избыточности (оба нужны для 99,9%)
- Осознание затрат (прыгают ли они на дорогие решения)
- Знание последовательности (failover до оптимизации)
- Выражение компромиссов (EBS gp3 против локального NVMe, например)
Кандидат, который говорит "добавить load balancer и запустить ещё два инстанса в другом AZ", думает ясно. Кандидат, который говорит "переходить на Kubernetes", может сопоставлять паттерны без понимания ограничения (высокая доступность, не мультитенантность).
Категория 2: Реагирование на инциденты и отладка
Вопрос, основанный на сценарии:
"Ваш CI/CD pipeline не работает на случайных сборках. Ошибка — 'connection timeout к Docker registry.' Проблема случается примерно раз на 20 сборок. Что вы проверите в первую очередь и какую инструментацию вы добавили бы?"
Это проверяет:
- Систематическую методологию отладки
- Понимание сетевой изоляции и аутентификации
- Мышление об observability (какую инструментацию добавили бы вы, чтобы предотвратить это в следующий раз?)
- Приоритизацию (им не нужен идеальный анализ root-cause, им нужна стабильная сборка сейчас)
Кандидат, который начинает с "проверить статус страницу Docker registry", менее внимателен, чем тот, кто говорит "сначала: переиспользуемо ли это и добавили ли мы rate limiting? второе: проверить, истекает ли токен registry во время сборки или изменилась ли наша сетевая конфигурация."
Категория 3: Код и обзор конфигурации
Живое упражнение:
Предоставьте 30-строчный фрагмент Terraform или Docker Compose конфиг с намеренными ошибками. Попросите кандидата определить проблемы и объяснить исправления.
Примеры Terraform проблем:
- Security group разрешает 0.0.0.0/0 на порт БД
- Отсутствует политика хранения бэкапов на RDS
- Пароль БД hardcoded в переменных
- Нет тегов для распределения затрат
Примеры Compose проблем:
- Привилегированные контейнеры без оправдания
- Отсутствуют health checks
- Логирование в stdout без лимитов (риск заполнения диска)
- Нет ограничений ресурсов (CPU/memory)
Это проверяет, отправляли ли они production системы и чему они научились. Учебниковые инженеры не ловят это; опытные операторы ловят.
Категория 4: Архитектура и выбор инструментов
Разговор:
"Нам нужно координировать джобы на 50 микросервисах. Каждый джоб длится 2–30 минут. Мы хотим сильные гарантии порядка. Что бы ты использовал? Пройди меня через компромиссы."
Валидные ответы:
- Temporal (оркестрация workflows, сильный порядок, сложно оперировать)
- Step Functions (управляемый, ограничен AWS, менее гибкий)
- Pub/Sub + consumer приложение (слабая связанность, слабый порядок, проще оперировать)
- Kubernetes Jobs + custom controller (гибкий, больше операционных издержек)
Интервьюер должен возражать: "Step Functions звучит проще." Кандидат должен защищать: "Пока вам не нужно повторить джоб, который уже частично выполнился, или пока у вас нет 2-минутного джоба, выполняющегося на 10-минутном SLA, тогда вам нужна state machine workflow. Но это истинная стоимость — компромисс сложности."
Это проверяет суждение и опыт, а не знание.
Категория 5: Наблюдаемость и мониторинг
Короткий сценарий:
"Вы развернули изменение и ваш error rate прошёл с 0,1% на 0,5%. Latency p99 тот же. Изменение коснулось логирования и tracing, а не обработки запросов. Куда вы смотрите?"
Слабый ответ: "Проверить логи." Сильный ответ: "Сначала я проверил бы, изменилась ли трассировка инструментации или уровень логирования — это может увеличить видимость ошибок без увеличения реальных ошибок. Затем я посмотрел бы на cardinality логов. Затем я проверил бы, логируем ли мы новые случаи ошибок, которые не были обнаружены раньше."
Это отделяет операторов от инженеров, которые только читали Kubernetes документы.
Как структурировать оценку
- 30-минутный take-home: Сценарий дизайна инфраструктуры + обзор конфигурации. Попросите объяснить решения.
- 30-минутный синхронный интервью: Живой разговор об отладке + обсуждение архитектуры. Запишите их рассуждения.
- Соедините оценку с сигналами целостности нажатия клавиш. DevOps кандидаты, копирующие целые решения из ChatGPT или StackOverflow, покажут необычные паттерны редактирования. ClarityHire захватывает это по умолчанию.
Честная контрпозиция
Не каждая роль нуждается в такой глубине. Junior DevOps или SRE роли выигрывают от более простого фильтра: могут ли они читать Terraform, могут ли они развернуть приложение, могут ли они понять диаграмму сети? Для senior+ найма эта рубрика применяется. Для mid-level уменьшите сложность, но держите структуру на основе сценариев.
Дальнейшие шаги
Готовы оценивать ваших DevOps кандидатов с реальными тестами? Проверьте наш DevOps и Cloud Engineering hub по оценкам для шаблонов и руководства по оценке навыков DevOps инженеров.