Вопросы для собеседования DevOps-инженера

DevOps-специалист отвечает за стабильность, автоматизацию и масштабируемость инфраструктуры. На собеседованиях проверяют не только знание инструментов, но и понимание принципов, архитектуры и практических сценариев. Ниже – подборка из 70 типовых вопросов для собеседования DevOps-специалиста с примерными ответами.

1. Что такое DevOps?
DevOps – это набор практик и культурных принципов, которые сокращают разрыв между разработкой и эксплуатацией. На практике это означает: автоматизация сборки/деплоя, единые стандарты, прозрачность метрик, совместная ответственность за релизы и стабильность. DevOps – не “должность”, а способ организовать поставку изменений быстро и безопасно.

2. Основная цель DevOps?
Сократить время от изменения кода до продакшена (lead time), увеличив частоту релизов без ухудшения стабильности. Если говорить метриками: ускорить deployment frequency, сократить change failure rate и MTTR, удерживая качество.

3. Чем DevOps отличается от SysAdmin?
SysAdmin часто фокусируется на поддержке и администрировании. DevOps – на воспроизводимости и автоматизации: инфраструктура как код, CI/CD, наблюдаемость, системный подход к релизам. Плюс DevOps тесно взаимодействует с разработкой и влияет на архитектурные решения.

4. Что такое CI/CD?
CI (continuous integration) – частая интеграция кода в общий репозиторий с автоматическими тестами/линтингом/сборкой. CD – автоматическая доставка: либо continuous delivery (готовность к релизу кнопкой), либо continuous deployment (автовыкат в прод). Важно: CD не равно “катим без контроля”, там всё держится на тестах, этапах, approvals и наблюдаемости.

5. Какие проблемы решает DevOps?
Ручные деплои и человеческие ошибки, долгие релизы, нестабильные окружения, “работает у меня”, отсутствие видимости (метрик/логов), конфликт интересов Dev vs Ops. В итоге – ускорение разработки при снижении риска инцидентов.

6. Как посмотреть нагрузку на систему?
top/htop показывают процессы, CPU/RAM. uptime – load average (важно понимать: load ≠ CPU, это “очередь” задач, включая I/O). vmstat помогает увидеть I/O wait, swap. iostat – дисковую подсистему. На собесе круто: “смотрю CPU steal в облаке, iowait, run queue и память (RSS, page cache)”.

7. Что такое inode?
Это запись файловой системы с метаданными: права, владелец, размер, ссылки, указатели на блоки. Имя файла хранится в каталоге, а inode – отдельно. Поэтому можно “закончить inode” при наличии свободного места – типичная проблема на маленьких файлах.

8. Hard link vs soft link?
Hard link – ещё одно имя того же inode; файл “существует”, пока есть ссылки. Soft link (symlink) – файл-ссылка на путь; если цель удалена – будет “битая” ссылка. Hard link обычно не работает через разные FS и для директорий.

9. Как найти процесс по порту?
ss -lntp | grep :443 или lsof -i :443. Затем PID → ps -fp PID. Для исходящих соединений – ss -antp. Хорошо упомянуть, что на контейнерах и в k8s бывает NAT, и порт виден на ноде иначе.

10. Что такое systemd?
Система инициализации и менеджер сервисов: unit-файлы, зависимости, рестарты, таймеры, journald. Важно: можно настроить Restart=always, LimitNOFILE, ExecStartPre, health-логика через watchdog.

11. TCP vs UDP?
TCP гарантирует порядок и доставку (ACK, ретрансляции), подходит для веба и API. UDP не гарантирует доставку/порядок, зато ниже задержки – полезно для стриминга, VoIP, игр, DNS. На собесе: “если приложению нужна надёжность – реализуем поверх UDP (QUIC) или берём TCP”.

12. Что такое DNS?
Система именования. Клиент спрашивает резолвер → тот получает записи (A/AAAA/CNAME/MX/TXT/NS) с TTL. Важны кеш и propagation. Частые проблемы: неправильный TTL, split-horizon, stale cache, NXDOMAIN из-за DNSSEC/делегации.

13. Что такое NAT?
Трансляция адресов (и иногда портов). SNAT – когда внутренний трафик выходит наружу с публичного IP. DNAT – когда входящий трафик перенаправляется на внутренний адрес. Минусы: усложняет трассировку, ломает end-to-end, влияет на P2P. 

14. Как работает HTTPS?
HTTP поверх TLS. В TLS handshake клиент проверяет сертификат (цепочка CA), согласуют шифры, устанавливают ключи, затем данные шифруются. Важно: SNI, ALPN (HTTP/2), OCSP stapling. Частый кейс: истёкший сертификат/неверная цепочка.

15. Что такое load balancer?
Компонент распределения трафика между бэкендами. Бывает L4 (TCP/UDP) и L7 (HTTP). Поддерживает health checks, sticky sessions, TLS termination, rate limiting. В k8s роль могут играть Service/Ingress + внешний LB.

16. Что такое контейнер?
Изоляция на уровне ОС через namespaces (процессы, сеть, FS) и cgroups (ресурсы). Контейнер использует ядро хоста, поэтому быстрее VM. Но важно: это не “полная безопасность”, нужен hardening.

17. Контейнер vs VM?
VM – отдельная ОС, лучше изоляция, тяжелее. Контейнер – лёгкий, быстрый старт, идеально для микросервисов. Часто используют вместе: контейнеры внутри VM в облаке.

18. Что такое Dockerfile?
Сценарий сборки образа: FROM, RUN, COPY, ENTRYPOINT. Хорошие практики: фиксировать версии, использовать multi-stage, минимизировать слои, не хранить секреты в образе, использовать non-root.

19. Что такое image?
Набор read-only слоёв. Контейнер добавляет write-layer сверху. Поэтому данные контейнера исчезают при пересоздании – для данных нужны volume/база/объектное хранилище.

20. Как уменьшить размер образа?
alpine/slim (с осторожностью), multi-stage (builder → runtime), очистка кешей (apt-get clean, remove /var/lib/apt/lists), не тянуть лишнее, .dockerignore. И не забыть про безопасность: slim-образ часто проще сканировать.

21. Что такое Kubernetes?
Платформа оркестрации: планирует поды на ноды, следит за состоянием, масштабирует, обновляет. Дает declarative model: “я хочу 3 реплики”, кластер поддерживает.

22. Что такое Pod?
Одна или несколько контейнерных задач с общей сетью и томами. Обычно один контейнер = один pod, но бывают sidecar (логгер, proxy).

23. Deployment vs StatefulSet?
Deployment – stateless: реплики взаимозаменяемы. StatefulSet – стабильные идентификаторы, порядок запуска/обновления, обычно с PVC, подходит для БД/очередей.

24. Что такое Service?
Стабильная точка доступа к подам. Type ClusterIP/NodePort/LoadBalancer. Селектор связывает Service с подами. Внутри – kube-proxy/iptables/ipvs.

25. ConfigMap и Secret?
ConfigMap – конфиги (не секретные). Secret – чувствительные данные, но по умолчанию это base64, не шифрование. Лучше включать encryption-at-rest и/или использовать внешние Secret Manager.

26. Что такое pipeline?
Цепочка этапов: build → test → security scan → package → deploy → smoke tests. Хороший pipeline умеет “быстро падать” (fail fast), кэшировать зависимости, разделять окружения (dev/stage/prod).

27. Инструменты CI?
GitHub Actions, GitLab CI, Jenkins, CircleCI. Важно не название, а принципы: repeatable builds, gated deploy, artifacts, approvals, secrets management.

28. Blue-green deployment?
Есть две среды: blue (текущая) и green (новая). Выкатываем green, прогоняем проверки, затем переключаем трафик. 
Плюс – быстрый rollback. 
Минус – удвоение ресурсов.

29. Canary release?
Постепенный выкат: 1% → 10% → 50% → 100%. Следим за метриками (ошибки, latency). 
Плюс – риск ограничен. 
Минус – сложнее мониторинг и управление версиями.

30. Где хранить секреты в CI?
В защищённых переменных CI, Vault/Secret Manager, OIDC/short-lived tokens. Никогда не коммитить в репо и не печатать в логах. Для k8s – external secrets, sealed secrets, vault injector.

31. Что такое IaC?
Управление инфраструктурой как кодом: изменения через pull request, ревью, историю, повторяемость. Это снижает дрейф и ускоряет создание окружений.

32. Инструменты IaC?
Terraform – provisioning ресурсов (cloud, сети, DB). Ansible – конфигурация и orchestration на ОС/сервисах. Часто Terraform создаёт ресурсы, а Ansible “докручивает”.

33. Разница Ansible vs Terraform?
Terraform декларативный и хранит state, ориентирован на “ресурсы”. Ansible чаще императивный (хотя идемпотентный), ориентирован на “действия/конфиг”. На практике их комбинируют.

34. Что такое Terraform state?
Файл состояния соответствия “ресурс в облаке ↔ ресурс в коде”. Без него Terraform не понимает, что создано. Поэтому state нужно защищать и блокировать (lock) для избежания гонок.

35. Как хранить state?
Удалённо: S3 + DynamoDB lock, или аналоги в облаке. Права доступа строго ограничить. Версионирование включить. Секреты в state – проблема: лучше использовать внешние секреты.

36. IaaS, PaaS, SaaS?
IaaS – вы управляете VM/сетями. PaaS – платформа (managed DB, k8s), меньше операционки. SaaS – готовое ПО (почта, CRM). Чем выше уровень, тем меньше контроля, но меньше поддержки.

37. Что такое VPC/VNet?
Логическая сеть в облаке: подсети, маршруты, security groups. Правильная сегментация (public/private) – база безопасности.

38. Что такое autoscaling?
Автоскейлинг увеличивает/уменьшает ресурсы по метрикам. В k8s есть HPA (pods) и Cluster Autoscaler (ноды). Важно: настроить лимиты и правильные метрики.

39. Availability zone?
Изолированные дата-центры внутри региона. Для HA размещают ресурсы минимум в двух AZ, иначе отказ AZ = простой.

40. Cloud-native?
Подход, где приложение рассчитано на масштабирование и отказоустойчивость: контейнеры, stateless, внешние зависимости, наблюдаемость, immutable deployments.

41. Что такое мониторинг?
Сбор метрик и их анализ для понимания состояния системы. Цель – обнаружить отклонения и предотвратить инциденты, а не просто “рисовать графики”.

42. Примеры метрик?
RED (rate, errors, duration) для сервисов, USE (utilization, saturation, errors) для ресурсов. Для API: rps, p95 latency, 5xx rate.

43. Алертинг?
Уведомления по условиям. Хорошие алерты: actionable, с приоритетом и контекстом. Плохие: “шум” без действий.

44. Логи vs метрики vs трейсы?
Логи – события, метрики – числа во времени, трейсы – путь запроса по сервисам. В микросервисах часто без tracing тяжело найти источник p95 задержек.

45. Инструменты?
Prometheus+Grafana, ELK/Opensearch, Loki, Jaeger/Tempo. Главное – единые labels, корреляция request-id, централизованный сбор.

46. Least privilege?
Права выдаются минимально необходимые. Это снижает ущерб при компрометации. Реализация: RBAC, отдельные роли, временные доступы.

47. Secrets rotation?
Регулярная смена секретов и ключей. В идеале – автоматическая ротация, short-lived токены, аудит использования.

48. Как защитить Docker?
Non-root, read-only FS, drop capabilities, seccomp/apparmor, ограничение ресурсов, сканирование образов, подписанные образы. И контроль registry.

49. Firewall?
Сетевые правила allow/deny. В облаках это security groups/NACL. В k8s – network policies. Важно: default deny и явные разрешения.

50. Zero Trust?
Не доверяем по умолчанию ни сети, ни устройству. Проверка identity, mTLS, сегментация, постоянная валидация запросов.

51. SLA/SLO/SLI?
SLI – метрика (например, % успешных запросов). SLO – целевое значение (99.9%). SLA – контрактная гарантия и последствия. В DevOps важно управлять через SLO.

52. Single point of failure?
Компонент, отказ которого ломает сервис: одна БД без реплики, один LB, один AZ. Убирают через дублирование и распределение.

53. Как повысить отказоустойчивость?
Репликация, многозонность, health checks, circuit breaker, очереди, graceful degradation, автоматический rollback. И обязательно тестировать отказ.

54. Backup?
Резервные копии данных и/или конфигураций. Важно: бэкап без восстановления – не бэкап. Нужны регулярные restore-тесты.

55. RPO/RTO и частота backup?
RPO – допустимая потеря данных, RTO – время восстановления. Частота бэкапа определяется RPO: если RPO 15 минут – нужны частые snapshots/лог-архивы.

56. Что делать, если сервис упал ночью?
Сначала стабилизировать: понять масштаб, при необходимости откат/перезапуск. Затем диагностика: метрики (CPU/RAM/latency), логи, последние деплои, зависимости (DB/queue). После – postmortem и задачи на предотвращение.

57. Как диагностировать медленный API?
Смотрю p95/p99 latency, error rate, время в БД, очередь, сеть, GC, throttling. Добавляю tracing, определяю где задержка: приложение, БД, внешний сервис или LB.

58. Как уменьшить downtime при релизе?
Rolling update с readiness/liveness probes, blue-green, canary. Обязательно: миграции БД совместимые (expand/contract), feature flags.

59. Что делать при утечке секретов?
Немедленно отозвать/ротация, ограничить доступ, определить scope (где использовался), проверить логи на злоупотребления, обновить pipeline, чтобы больше не утекало. Затем – расследование и улучшения.

60. Как документировать инфраструктуру?
README в репозитории IaC, диаграммы (C4), runbooks, инструкции для инцидентов, описание SLO/алертов. Документация должна быть живой частью процесса (PR-обновления).

61. Почему DevOps – культура?
Инструменты не решают проблему без совместной ответственности и процессов. Если Dev “кидает” релиз, а Ops “запрещает”, никакой CI не спасёт.

62. Как работать с разработчиками?
Через общие цели (SLO, скорость релизов), удобные пайплайны, хорошие среды, прозрачные алерты. Обсуждать архитектуру вместе, а не “после факта”.

63. Скорость или стабильность?
Нужен баланс. Стабильность измеряется error rate/latency, скорость – lead time и deployment frequency. Через SLO и error budget можно регулировать темп релизов.

64. Отношение к дежурствам?
Дежурства – часть ответственности за прод. Важно: уменьшать частоту инцидентов через автоматизацию, улучшение алертов и postmortem, иначе выгорание.

65. Что делать, если нет документации?
Начать с минимального: как деплоить, как откатить, где логи/метрики, контакты. Далее – runbooks по типовым инцидентам.

66. Как масштабировать stateful-приложение?
Вынос состояния (DB/redis), репликация/шардинг, горизонтальное масштабирование чтения, правильное хранилище (PVC/CSI), careful updates (StatefulSet). Часто важнее выбрать managed DB, чем “таскать БД в k8s”.

67. Как снизить cloud-costs?
Rightsizing, выключение неиспользуемого, autoscaling, spot/preemptible, оптимизация storage и egress, reserved instances. Также – наблюдаемость затрат по тегам и бюджетам.

68. Как проверить надёжность?
Chaos engineering: отключение нод, задержки сети, падение зависимостей. Но обязательно контролируемо: на стейдже или малым канареечным процентом, с метриками.

69. Как выбрать стек DevOps?
От задач: размер команды, требования безопасности, регуляторика, зрелость. Лучше брать стандартные и поддерживаемые решения, чем “зоопарк”. Важно: стоимость владения.

70. Главная ошибка начинающих DevOps на ваш взгляд?
Учить инструменты без понимания систем: сети, Linux, архитектуры, SRE-подхода. Вторая ошибка – недооценка наблюдаемости и безопасности.

71. Как вы управляете конфигурациями между разными окружениями (dev / stage / prod)?
Обычно используется принцип config separation: код и конфигурации разделены. Конфигурации хранятся в ConfigMap/Secrets (в Kubernetes), переменных окружения или внешних Secret Manager. Для IaC применяются разные variables/overlays, а изменения проходят через pull request, чтобы избежать ручных правок.

72. Что такое idempotency и почему она важна в DevOps?
Idempotency означает, что повторное выполнение операции даёт тот же результат. Это критично для Ansible, Terraform и CI/CD: повторный запуск не должен ломать систему. Идемпотентность снижает риски при автоматизации и восстановлении после сбоев.

73. Как вы определяете, что алерт действительно нужен?
Алерт должен быть actionable: по нему должно быть понятно, что делать. Хороший алерт указывает на нарушение SLO или деградацию пользовательского опыта. Если алерт не требует действий – это метрика, а не алерт, и он создаёт шум.

74. Что такое error budget и как вы его используете?
Error budget – допустимый уровень ошибок, вычисляемый из SLO. Если бюджет не исчерпан, команда может чаще релизить. Если исчерпан — фокус смещается на стабильность. Это инструмент баланса между скоростью и надежностью.

75. Как вы подходите к миграциям базы данных при CI/CD? 
Используется подход backward-compatible migrations: сначала расширение схемы, затем деплой приложения, потом удаление старых полей. Миграции автоматизируются, но не выполняются “вслепую” без тестирования на stage.

76. Как понять, что проблема в приложении, а не в инфраструктуре?
Сравниваются метрики разных уровней: если инфраструктура стабильна (CPU, RAM, сеть), но растёт latency и ошибки – вероятно, проблема в коде. Distributed tracing помогает быстро локализовать источник.

77. Как вы работаете с техническим долгом в DevOps? 
Технический долг фиксируется как задачи: устаревшие образы, небезопасные конфиги, ручные операции. Его нельзя “закрыть сразу”, но он должен быть видимым и планируемым, иначе страдает стабильность.

78. Что вы делаете, если разработчики игнорируют требования инфраструктуры? 
DevOps не “запрещает”, а объясняет последствия: влияние на SLO, стоимость, безопасность. Лучший подход — автоматические ограничения (policies, checks в CI), а не ручной контроль.

79. Как вы оцениваете зрелость DevOps в компании?
По метрикам: частота релизов, MTTR, change failure rate, степень автоматизации, наличие мониторинга и postmortem. Если всё держится на “ручном герое” — зрелость низкая, даже при наличии CI/CD.

80. Что бы вы улучшили в DevOps-процессах в первую очередь? 
Обычно это наблюдаемость и автоматизация рутинных операций. Без метрик и логов невозможно принимать решения, а без автоматизации команда быстро упирается в масштаб.

Вопросы для собеседования DevOps охватывают широкий круг тем: от базовых принципов работы Linux и сетей до контейнеризации, CI/CD, Kubernetes, облачной инфраструктуры и обеспечения надежности систем. Успешное прохождение интервью требует не столько заучивания инструментов, сколько понимания архитектуры, причинно-следственных связей и практических сценариев работы с продакшен-системами.

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