Тестовое задание DevOps: какие дают, как оценивают и как сделать хорошо

Тестовое задание DevOps — это небольшая рабочая задача: собрать пайплайн, написать Dockerfile, описать инфраструктуру в Terraform или починить сломанный стенд. Проверяют не только, работает ли результат, но и можно ли запустить его по README на чистой машине, как вы обращаетесь с секретами и можете ли объяснить свои решения.

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

Какие тестовые задания дают

Часто задания комбинируют: например, упаковать приложение в Docker, написать пайплайн, который собирает образ, и манифесты для деплоя в Kubernetes.

Как оценивают тестовое

Критерии у компаний разные, но почти везде проверяют одно и то же:

• Запускается ли решение по README. Проверяющий клонирует репозиторий и идёт по инструкции. Если на третьем шаге нужна переменная, о которой README молчит, дальше он может не пойти.
• Воспроизводимость. Зафиксированы ли версии, запускается ли всё одной-двумя командами, получится ли тот же результат через месяц.
• Секреты. Нет ли паролей и ключей в коде, в истории коммитов и в образах.
• Качество. Проходят ли линтеры, обрабатываются ли ошибки, безопасен ли повторный запуск.
• Безопасность по умолчанию. Контейнер не от root, минимальные права, наружу открыто только нужное.
• Объяснения. Почему выбран такой подход, что не сделано и как бы вы сделали это в проде.
• Соразмерность. Решение не переусложнено и не упрощено до потери смысла.

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

Как сделать тестовое хорошо

README — для коллеги, который видит проект впервые

README — первое, что откроет проверяющий, и часто единственное, что он прочтёт до запуска. Удобная структура:

# <Что сделано — одной строкой>

## Что внутри
- Dockerfile (multi-stage, запуск не от root)
- docker-compose.yml: приложение + PostgreSQL
- .github/workflows/ci.yml: линтеры, тесты, сборка и публикация образа

## Как запустить
Нужно: Docker с Compose, make.
cp .env.example .env    # заполнить значения
make up                 # поднимает приложение и базу
make test               # проверки
Приложение: http://localhost:8080/health

## Как проверить, что всё работает
<команды и ожидаемый вывод>

## Решения и компромиссы
- Почему выбран X, а не Y
- Что сделал бы иначе в проде: мониторинг, бэкапы, отказоустойчивость

## Что не сделано
- <пункт> — почему и как бы я это сделал

## Как всё удалить
make down    # или terraform destroy, если создавались облачные ресурсы

Раздел «Что не сделано» работает в вашу пользу: честный список с планом выглядит сильнее, чем молча недоделанное.

Воспроизводимость

• Фиксируйте версии. Документация Docker напоминает, что теги образов изменяемы: alpine:3.21 через три месяца может указывать на другой образ. Для строгой воспроизводимости базовый образ фиксируют по digest. В Terraform задают версии провайдеров и коммитят .terraform.lock.hcl — HashiCorp прямо рекомендует хранить этот файл в репозитории.
• Одна команда на запуск. make up, docker compose up или скрипт. Не больше пары шагов, и все описаны.
• Проверьте на чистой машине. Склонируйте репозиторий в новую виртуальную машину или контейнер и пройдите README буквально. Ещё лучше, если ваш же пайплайн прогоняет проверки при каждом пуше: зелёный CI в репозитории — сильный сигнал.
• Повторный запуск ничего не меняет. Второй terraform apply должен показать No changes, второй прогон Ansible — changed=0. Это и есть идемпотентность, её часто проверяют отдельно.
• Уборка. Опишите, как всё удалить. Облачные ресурсы, которые продолжают работать после проверки, — ваши деньги или деньги компании.

Секреты

Ни одного настоящего секрета в репозитории, даже «тестового» ключа облака. Методология The Twelve-Factor App предлагает простую проверку: можно ли прямо сейчас открыть репозиторий всем и не скомпрометировать ни одного пароля. Если нельзя — конфигурация и секреты смешаны с кодом.

Как это выглядит в тестовом:

• .env.example с заглушками вместо значений и .env в .gitignore;
• секреты пайплайна — в переменных CI, помеченных как защищённые и маскированные;
• для сборки образа — secret mounts BuildKit, а не ARG: аргументы сборки остаются в истории образа. К чему это приводит, видно по взлому Codecov, где ключ достали из слоя публичного образа;
• сканер секретов, например gitleaks, как pre-commit хук и шаг пайплайна.

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

Качество кода

• Линтеры в пайплайне: shellcheck для Bash, hadolint для Dockerfile, terraform fmt и terraform validate, ansible-lint, yamllint.
• Скрипты падают громко: set -euo pipefail, переменные в кавычках, понятные сообщения об ошибках.
• Dockerfile по рекомендациям Docker: multi-stage, .dockerignore, зафиксированный базовый образ, USER без root, exec-форма CMD. Подробно о подводных камнях — в вопросах по Docker.
• Kubernetes: requests и limits, пробы, никаких latest.
• Terraform: переменные с описаниями, outputs, удалённый state или объяснение, почему он локальный в учебном задании.

Коммиты и объяснения

История коммитов показывает, как вы работаете. Один коммит «initial» со всем проектом говорит меньше, чем десяток осмысленных шагов: «добавил multi-stage сборку», «вынес конфигурацию в переменные». В сопроводительном письме или README коротко объясните главные решения: проверяющему интереснее ваш ход мысли, чем ещё один идеальный YAML.

Частые ошибки

• Не запускается по README. Забытый шаг, абсолютные пути с вашей машины, зависимость от локальных файлов.
• Секреты в репозитории или в истории. Даже если файл удалён следующим коммитом.
• latest и незафиксированные версии. Сегодня работает, через месяц — нет.
• Образ на гигабайт от root. Всё в одном слое, компилятор и кэши внутри.
• Жёстко прописанные адреса, регионы и идентификаторы аккаунтов. Решение работает только у вас.
• Переусложнение. Кластер Kubernetes с сервис-мешем там, где просили Compose. Обратная крайность — сделать половину и промолчать об остальном.
• Решение, которое не можете объяснить. На встрече спросят, почему здесь serial: 2 или зачем эта строка в Dockerfile. Скопированный из интернета или сгенерированный код без понимания выдаёт себя за пару вопросов.
• Забытые облачные ресурсы после проверки.

Тестовое «почини стенд»: как действовать

Такие задания часто дают вживую: вам открывают доступ к машине или кластеру, где что-то сломано, и смотрят, как вы ищете причину. Рабочий порядок:

1. Уточните, что считается «починено» и что можно трогать.
2. Соберите симптомы: что именно не работает и как это проверить.
3. Идите от быстрых безопасных проверок к глубоким: статус сервиса, логи, диск, сеть, конфиги.
4. Проговаривайте гипотезы вслух и меняйте по одной вещи за раз.
5. Записывайте, что сделали, чтобы любое изменение можно было откатить.
6. После починки скажите, как не допустить повторения: алерт, автоматизация, изменение процесса.

Типовые поломки — те же, что в вопросах-ситуациях: занятый порт, кончившееся место, сервис без автозапуска, DNS. Их удобно разобрать заранее по подборкам 15 вопросов по Linux и 41 ситуации DevOps.

Потренироваться можно и в симуляторе DevOps KAI Lab: его тикеты устроены похоже на реальные тестовые — коллега присылает задачу, а ответ ищешь в консоли, логах и конфигах, а не в списке определений. Начать можно с бесплатного теста навыков DevOps: 18 рабочих ситуаций, 10–15 минут, без регистрации.

Частые вопросы

Сколько времени тратить на тестовое задание? Столько, сколько указала компания, плюс небольшой запас. Если срок не указан — спросите. Лучше сдать работающее ядро и честный список «что сделал бы дальше», чем всё сразу, но наполовину.

Можно ли использовать ChatGPT и другие ИИ-помощники? Уточните правила у компании. В любом случае вы должны понимать каждую строку решения: на встрече попросят объяснить выбор и поменять что-нибудь на ходу.

Что делать, если не успел? Сдать то, что работает, и описать в README, что осталось, почему и как бы вы это доделали. Молча недоделанное задание оценивают хуже, чем честно ограниченное.

Задание требует облако, а своего аккаунта нет. Как быть? Спросите, есть ли у компании песочница. Если нет, часть заданий можно сделать локально: кластер Kubernetes в kind или minikube, приложение в Compose. Опишите в README, что поменялось бы при запуске в облаке.

Где набраться опыта, если реальных задач пока нет? На домашнем стенде, где вы собираете сервис от коммита до деплоя и специально его ломаете, и на учебных задачах, похожих на рабочие. Об этом — в статье как попасть в DevOps без опыта.

Источники

• Docker. Building best practices — multi-stage, .dockerignore, фиксация версий базового образа, запуск не от root.
• Docker. Build secrets — почему секреты не передают через аргументы сборки.
• HashiCorp. Dependency Lock File — хранить .terraform.lock.hcl в репозитории.
• The Twelve-Factor App. III. Config — отделение конфигурации от кода.
• GitHub. Removing sensitive data from a repository — сначала отозвать секрет, потом чистить историю.
• Codecov. Post-Mortem / Root Cause Analysis (April 2021) — ключ из промежуточного слоя публичного образа.