Вопросы DevOps на собеседовании

DevOps-собеседование редко ограничивается одной темой. Обычно проверяют Linux, сети, Git, CI/CD, Docker, Kubernetes, мониторинг, безопасность и умение спокойно разбирать инциденты

Сильный ответ в DevOps — это не набор команд наизусть. Это объяснение: что вы проверяете, почему именно это, какой результат ожидаете и что будете делать после

Как отвечать на DevOps-вопросы

Для любого вопроса используйте простой порядок:

1. Что происходит
2. Где это может сломаться
3. Как проверить
4. Как исправить
5. Как не допустить повторения

Пример:

Если сервис недоступен, я сначала проверю, жив ли процесс и порт, затем логи приложения, потом сеть, DNS, балансировщик и зависимости. После восстановления важно понять причину: релиз, конфиг, ресурс, внешняя зависимость или ошибка инфраструктуры

Такой ответ показывает системное мышление

По этой теме полезно отдельно посмотреть Какие вопросы задать работодателю на собеседовании, чтобы расширить контекст и сравнить подходы

По этой теме полезно отдельно посмотреть Частые вопросы на собеседовании и как отвечать, чтобы расширить контекст и сравнить подходы

Linux

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

• как посмотреть процессы
• как проверить свободное место
• как найти большой файл
• как посмотреть открытые порты
• чем отличаются права 644 и 755
• как прочитать последние строки лога
• что такое systemd unit

Примеры команд:

ps aux | grep nginx
df -h
du -sh /var/log/*
ss -tulpen
journalctl -u nginx -n 100

Ответ должен быть не просто списком команд. Объясняйте, зачем команда нужна. Например, df -h покажет заполнение файловых систем, а du -sh поможет найти, какая папка съела место

Сети

Что могут спросить:

• что происходит при открытии сайта в браузере
• чем TCP отличается от UDP
• что такое DNS
• как проверить доступность порта
• что такое reverse proxy
• зачем нужен load balancer
• чем HTTP отличается от HTTPS

Пример ответа про DNS:

DNS переводит доменное имя в IP-адрес. Если сервис недоступен по домену, но доступен по IP, я проверю DNS-запись, кеш, настройки зоны и то, какой resolver использует сервер

Команды:

dig example.com
curl -I https://example.com
nc -vz example.com 443

Git и релизы

DevOps часто работает рядом с разработкой, поэтому Git нужен не только разработчикам

Вопросы:

• чем merge отличается от rebase
• что такое tag
• как откатить релиз
• зачем нужны protected branches
• как устроить release branch
• что делать, если секрет попал в репозиторий

Пример ответа:

Тег удобно использовать как точку релиза. Если нужно понять, что именно уехало на production, тег дает фиксированную ссылку на commit. Но откат должен быть описан заранее: образ, миграции, конфиг, совместимость данных

Такой ответ показывает, что релиз — не только git push

CI/CD

Что могут спросить:

• какие этапы есть в pipeline
• зачем нужны lint и tests
• где собирать Docker image
• как хранить секреты
• что делать, если pipeline падает только иногда
• как ускорить сборку

Пример хорошего ответа:

Обычный pipeline включает проверку кода, тесты, сборку артефакта или Docker image, сканирование, публикацию и деплой. Если шаг падает нестабильно, я смотрю зависимость от времени, сети, порядка тестов, внешних сервисов и кеша

Добавьте, что секреты не должны храниться в репозитории и логах

Docker

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

• чем образ отличается от контейнера
• что такое Dockerfile
• зачем нужен .dockerignore
• как посмотреть логи контейнера
• как зайти внутрь контейнера
• чем volume отличается от bind mount
• как уменьшить размер образа

Примеры команд:

docker ps
docker logs app
docker exec -it app sh
docker inspect app

Пример ответа:

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

Kubernetes

Для junior могут спросить базу, для middle — диагностику

Повторите:

• pod
• deployment
• service
• ingress
• configmap
• secret
• namespace
• readiness и liveness probes

Команды:

kubectl get pods
kubectl describe pod app-123
kubectl logs app-123
kubectl get events

Пример ответа:

Если pod не стартует, я проверю статус, events, describe, логи, image pull, переменные окружения, secret, configmap и ресурсы. Если pod перезапускается, отдельно смотрю probes и причину завершения контейнера

Мониторинг и логи

Что могут спросить:

• какие метрики важны для сервиса
• чем метрики отличаются от логов
• зачем нужны алерты
• что такое SLI, SLO
• как понять, что проблема началась после релиза
• что смотреть при росте latency

Пример:

Для web-сервиса я смотрю latency, error rate, traffic, saturation ресурсов, статус зависимостей и бизнес-метрики. Логи помогают увидеть детали конкретной ошибки, а метрики показывают масштаб проблемы

Хорошо, если вы можете назвать не только CPU и память, но и ошибки, задержки, очереди, базу данных, внешние API

Безопасность

DevOps не обязан быть security engineer, но базовые вещи нужны

Вопросы:

• как хранить секреты
• почему нельзя писать токены в логи
• зачем нужен principle of least privilege
• как обновлять base images
• что делать с открытым портом наружу
• зачем нужен HTTPS

Сильный ответ:

Секреты должны храниться в отдельном хранилище или secret manager, доступ к ним должен быть ограничен. Если секрет утек, его нужно отозвать, заменить, проверить логи доступа и убрать причину утечки

Разбор аварии

Работодатели любят вопросы про падение сервиса, потому что они показывают порядок мышления

Пример вопроса:

После релиза пользователи жалуются, что сайт работает медленно. Что будете делать?

Сильный ответ:

Сначала проверю масштаб: все пользователи или часть, какие endpoint, когда началось. Потом сравню время с релизом, посмотрю метрики latency и error rate, логи приложения, базу данных, внешние зависимости и ресурсы. Если проблема критичная, сначала стабилизирую сервис: rollback, отключение проблемной функции или масштабирование. Потом разбираю причину

Не начинайте сразу с одной любимой команды. Покажите порядок

Встречные вопросы работодателю

DevOps-кандидату полезно спрашивать:

• какие системы сейчас в production
• что чаще всего ломается
• как устроены дежурства
• есть ли мониторинг и алерты
• как проходят релизы
• есть ли инфраструктура как код
• как хранятся секреты
• что будет главной задачей в первые месяцы

Эти вопросы помогают понять зрелость инфраструктуры и уровень ответственности

Как разбирать падение сервиса

Работодатель может спросить:

Сервис недоступен. Что будете делать?

Не называйте одну команду. Дайте порядок:

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

Дальше можно назвать команды:

systemctl status app
journalctl -u app -n 100
curl -I https://service.example.com
ss -tulpen
df -h

Такой ответ показывает и практику, и приоритет: сначала восстановить, потом разбираться глубже

Как отвечать про Docker в реальной работе

Частый вопрос:

Контейнер перезапускается. Что проверите?

Хороший ответ:

Я посмотрю логи контейнера, exit code, переменные окружения, доступность зависимостей, права на volume и команду запуска. Если контейнер падает сразу после старта, часто причина в конфиге, секрете, подключении к базе или ошибке entrypoint

Команды:

docker ps -a
docker logs app
docker inspect app
docker exec -it app sh

Не ограничивайтесь фразой «посмотрю логи». Объясните, что именно будете искать в логах

Как отвечать про Kubernetes

Вопрос:

Pod в CrashLoopBackOff. Что делать?

Сильный ответ:

Я проверю describe pod, events, logs текущего и предыдущего контейнера, переменные, secret, configmap, probes и ресурсы. CrashLoopBackOff означает, что контейнер стартует и падает, поэтому важны именно причина завершения и последние логи перед падением

Команды:

kubectl describe pod app-123
kubectl logs app-123
kubectl logs app-123 --previous
kubectl get events

Такой ответ сразу выглядит рабочим

Что показать, если опыта DevOps мало

Если вы junior, не изображайте senior. Покажите уверенную базу и порядок мышления

Пример:

С Kubernetes я пока работал на учебном уровне, но умею смотреть pods, logs, describe и events. Лучше понимаю Docker, Linux и базовый CI/CD. Если вижу проблему, иду от простого: статус, логи, конфиг, сеть, ресурсы

Это честнее и сильнее, чем перечислить инструменты, с которыми вы почти не работали

Часто задаваемые вопросы

Что повторить перед DevOps-собеседованием?

Linux, сети, Git, CI/CD, Docker, Kubernetes basics, мониторинг, безопасность и разбор аварий

Нужно ли знать Kubernetes глубоко?

Зависит от вакансии. Если Kubernetes указан в ключевых требованиях, нужно уверенно читать pod status, events, logs и понимать deployment, service, ingress

Как отвечать, если не работал с инструментом?

Честно обозначьте опыт и свяжите с похожей темой. Например: «С GitLab CI работал, с GitHub Actions меньше, но понимаю общую логику pipeline»