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

Linux

1. Как найти, что нагружает сервер?

   top или htop — CPU, память, load average и процессы; free -h — память; df -h и du — диск; iostat или iotop — ввод-вывод; ss -tulpn — открытые порты и процессы; journalctl и dmesg — логи, в том числе срабатывания OOM killer.

2. Что такое load average?

   Среднее число процессов, которые выполняются или ждут процессор, за 1, 5 и 15 минут; в Linux сюда входят и процессы в непрерываемом ожидании, обычно диска. Сравнивают с числом ядер: если LA стабильно выше, задачи стоят в очереди. Высокий LA при низкой загрузке CPU часто указывает на проблемы с вводом-выводом.

3. Места на диске нет, хотя больших файлов не видно. В чём дело?

   Частая причина — файл удалён, но процесс держит его открытым, например лог, в который приложение продолжает писать. Место освободится после перезапуска процесса, найти такие файлы помогает lsof +L1. Другой вариант — закончились inode из-за множества мелких файлов: ошибка «No space left on device» при свободном месте в df -h, проверяют через df -i.

4. Чем SIGTERM отличается от SIGKILL?

   SIGTERM (15) просит процесс завершиться: его можно перехватить, закрыть соединения и дописать данные. SIGKILL (9) перехватить нельзя — ядро завершает процесс сразу, поэтому без крайней нужды им не пользуются. Зомби-процесс уже завершился, но родитель не забрал его код возврата; убивать зомби бесполезно, разбираться нужно с родителем.

5. Как читать права доступа, например 750?

   Три цифры — владелец, группа, остальные; каждая — сумма r = 4, w = 2, x = 1. 750 — владельцу можно всё, группе читать и запускать, остальным ничего. У каталога x означает право войти в него. Ещё спрашивают про setuid и sticky bit: последний стоит на /tmp, чтобы удалять файлы мог только их владелец.

6. Чем жёсткая ссылка отличается от символической?

   Жёсткая — ещё одно имя того же inode: работает в пределах одной файловой системы, на каталог её не создать, файл живёт, пока есть хоть одно имя. Символическая — отдельный файл с путём к цели: может указывать на каталог и на другую файловую систему, но ломается, если цель удалить.

Сети: DNS, TCP/UDP, TLS

7. Что происходит, когда вы открываете сайт в браузере?

   DNS: имя превращается в IP через кэши и резолвер, который при необходимости проходит корневые серверы, серверы зоны и авторитативный сервер домена. Затем TCP-соединение (SYN, SYN-ACK, ACK) или QUIC для HTTP/3, TLS-рукопожатие с проверкой сертификата, HTTP-запрос и ответ — часто через балансировщик и обратный прокси, — и отрисовка страницы.

8. Чем TCP отличается от UDP?

   TCP устанавливает соединение, гарантирует доставку и порядок, управляет скоростью передачи — на нём работают HTTP/1.1 и HTTP/2, SSH, базы данных. UDP отправляет датаграммы без соединения и гарантий, зато с меньшей задержкой: DNS-запросы, видео и голос, QUIC, на котором построен HTTP/3.

9. Какие записи DNS нужно знать?

   A — IPv4-адрес, AAAA — IPv6, CNAME — псевдоним другого имени (на корне домена его ставить нельзя), MX — почтовые серверы, TXT — произвольный текст, например SPF или подтверждение владения доменом, NS — серверы зоны, PTR — обратная запись «IP → имя». TTL — сколько секунд ответ можно держать в кэше.

10. Как работает TLS?

    Клиент и сервер договариваются о версии и шифрах, сервер присылает сертификат, клиент проверяет цепочку до доверенного корневого центра, срок действия и имя хоста. Затем стороны получают общий ключ через обмен Диффи — Хеллмана (ECDHE), и дальше трафик шифруется симметрично. В TLS 1.3 рукопожатие занимает один обмен туда и обратно.

11. Сервис недоступен по сети — как будете искать причину?

    По уровням: резолвится ли имя (dig), доступен ли хост (ping, traceroute или mtr — помня, что ICMP могут закрыть), открыт ли порт (nc -zv host 443, curl -v), слушает ли сервис нужный адрес (ss -tlnp: 127.0.0.1 вместо 0.0.0.0 — частая ошибка), правила файрвола и группы безопасности, логи сервиса.

12. Чем балансировщик L4 отличается от L7?

    L4 распределяет TCP- и UDP-соединения по адресу и порту и не видит содержимое. L7 понимает HTTP: маршрутизирует по пути, заголовкам и cookie, может завершать TLS, переписывать запросы и проверять здоровье бэкендов HTTP-запросами.

Docker

13. Чем контейнер отличается от виртуальной машины?

    Контейнер — изолированный процесс на ядре хоста: пространства имён (namespaces) отделяют процессы, сеть и файловую систему, cgroups ограничивают ресурсы. Он быстро стартует и весит мало. Виртуальная машина запускает свою ОС со своим ядром поверх гипервизора: изоляция сильнее, накладные расходы больше.

14. Чем образ отличается от контейнера?

    Образ — неизменяемый шаблон из слоёв: инструкции Dockerfile, которые меняют файлы (RUN, COPY, ADD), добавляют по слою. Контейнер — запущенный экземпляр образа с тонким записываемым слоем сверху. Всё, что записано в этот слой, пропадает при удалении контейнера, поэтому данные хранят в томах.

15. Как уменьшить образ и ускорить сборку?

    Лёгкий базовый образ (slim, alpine, distroless) и многоэтапная сборка: компилируем в одном этапе, в финальный копируем только артефакт. Установку пакетов и очистку кэша — в одном RUN, плюс файл .dockerignore. Порядок инструкций под кэш слоёв: сначала файлы зависимостей и их установка, потом код — тогда правка кода не пересобирает зависимости.

16. Чем CMD отличается от ENTRYPOINT?

    ENTRYPOINT задаёт исполняемый файл, CMD — аргументы по умолчанию или команду, если ENTRYPOINT нет; аргументы docker run заменяют CMD. Exec-форму (["app", "--port", "8080"]) предпочитают shell-форме: в shell-форме процессом с PID 1 становится /bin/sh, и SIGTERM может не дойти до приложения.

17. Где хранить данные контейнера?

    В томах (volumes), которыми управляет Docker, или в bind mount — каталоге хоста, примонтированном в контейнер. Тома переживают удаление и пересоздание контейнера, их проще бэкапить и переносить. Базе данных в контейнере том нужен обязательно.

18. Как контейнеры в Docker Compose находят друг друга?

    Compose создаёт для проекта сеть, в которой сервисы доступны по имени: приложение подключается к базе по адресу db:5432, а не по IP. depends_on управляет только порядком запуска; чтобы дождаться готовности базы, нужен healthcheck и condition: service_healthy.

Kubernetes

19. Какие основные объекты Kubernetes вы знаете?

    Pod — один или несколько контейнеров с общей сетью и томами. Deployment — нужное число реплик и обновления через ReplicaSet. Service — постоянный адрес и балансировка на поды (ClusterIP, NodePort, LoadBalancer). Ingress — HTTP-маршрутизация снаружи. ConfigMap и Secret — конфигурация. StatefulSet — для сервисов с состоянием, DaemonSet — по поду на каждой ноде, Job и CronJob — разовые и периодические задачи.

20. Чем liveness-проба отличается от readiness?

    Readiness отвечает, готов ли под принимать трафик: при провале его убирают из балансировки Service, но не перезапускают. Liveness проверяет, жив ли контейнер: при провале kubelet его перезапускает. Startup-проба нужна медленно стартующим приложениям — пока она не пройдёт, две другие не проверяются. Частая ошибка — liveness, зависящая от базы: база недоступна, и перезапускаются все поды.

21. Что такое requests и limits?

    Requests — сколько ресурсов контейнеру гарантировано; по ним планировщик выбирает ноду. Limits — потолок: при превышении лимита памяти контейнер убивают (OOMKilled), CPU сверх лимита ограничивают (троттлинг). Без requests планирование непредсказуемо, а под без лимита памяти может вытеснить соседей с ноды.

22. Под в состоянии CrashLoopBackOff — что делать?

    Контейнер стартует и падает, а Kubernetes перезапускает его с растущей паузой. Смотрим kubectl describe pod — события, код выхода, OOMKilled — и kubectl logs --previous — логи упавшего экземпляра. Дальше проверяем конфигурацию и секреты, команду запуска, лимит памяти и не убивает ли контейнер слишком строгая liveness-проба.

23. Как устроено обновление Deployment и откат?

    Deployment создаёт новый ReplicaSet и постепенно поднимает новые поды, гася старые, в пределах maxSurge и maxUnavailable. Трафик идёт только на поды, прошедшие readiness, поэтому без неё обновление может отправить запросы в неготовое приложение. Откат — kubectl rollout undo deployment/<имя>.

24. Secret в Kubernetes — это шифрование?

    Нет: значения хранятся в base64, а это кодирование, не шифрование. Нужно включить шифрование etcd, ограничить доступ к секретам через RBAC, а чувствительные данные часто держат во внешнем хранилище секретов и подтягивают в кластер оператором.

CI/CD

25. Чем CI отличается от CD?

    CI — каждое изменение автоматически собирается и проходит тесты, чтобы ошибки находились сразу. Continuous delivery — после пайплайна артефакт всегда готов к выкатке, а в прод он уходит по кнопке. Continuous deployment — каждое изменение, прошедшее проверки, уходит в прод автоматически.

26. Из каких этапов состоит пайплайн?

    Линтеры и юнит-тесты → сборка образа с тегом по коммиту или версии → сканирование на уязвимости → публикация в registry → деплой на тестовый стенд и интеграционные или смоук-тесты → выкатка в прод, часто с ручным подтверждением → проверка метрик после релиза. Секреты хранят в хранилище CI, а не в репозитории.

27. Какие бывают стратегии деплоя?

    Rolling — поды заменяются постепенно. Blue-green — рядом поднимается вторая среда, трафик переключается целиком, откат — переключение обратно. Canary — новую версию получает небольшая доля трафика, и её увеличивают, если метрики в норме. Recreate — сначала гасим старую версию, потом поднимаем новую, с простоем.

28. Почему в проде не используют тег latest?

    По latest не понять, какая версия запущена, и не откатиться на известную. При imagePullPolicy: IfNotPresent разные ноды могут запустить разные закэшированные образы с одним тегом. Образы тегируют версией или хешем коммита, а самые строгие — указывают digest.

Инфраструктура как код: Terraform и Ansible

29. Чем Terraform отличается от Ansible?

    Terraform декларативно описывает инфраструктуру — сети, виртуальные машины, DNS, управляемые сервисы — и хранит её состояние: terraform plan показывает изменения, terraform apply их применяет. Ansible управляет конфигурацией: по SSH, без агентов, выполняет плейбуки на YAML — ставит пакеты, раскладывает конфиги, деплоит. Их часто используют вместе: Terraform создаёт машины, Ansible их настраивает.

30. Что такое state в Terraform и где его хранить?

    Файл соответствия между ресурсами в коде и реальными объектами. Его хранят в удалённом бэкенде, например в S3-совместимом хранилище, с блокировкой, чтобы два apply не шли одновременно. В git state не коммитят: в нём могут оказаться пароли и ключи в открытом виде.

31. Что такое идемпотентность в Ansible?

    Повторный запуск плейбука ничего не меняет, если система уже в нужном состоянии: модули описывают состояние (state: present), а не действие. Модули command и shell сами по себе не идемпотентны — для них задают creates, removes или условия запуска, а changed_when — чтобы честно показывать, менялось ли что-то.

32. Что такое drift и как с ним быть?

    Расхождение реальной инфраструктуры и кода, обычно из-за ручных правок. terraform plan покажет разницу. Правило — все изменения через код и ревью; ручные правки — только при аварии и с последующим переносом в код.

Мониторинг, логи и инциденты

33. Чем метрики отличаются от логов и трейсов?

    Метрики — числа во времени: запросы в секунду, ошибки, задержка; их собирает, например, Prometheus по pull-модели, а показывает Grafana. Логи — отдельные события с подробностями (ELK, Loki). Трейсы — путь одного запроса через сервисы со временем каждого шага (OpenTelemetry, Jaeger). Метрики говорят, что сломалось, логи и трейсы — где и почему.

34. Какие метрики смотреть у сервиса?

    Четыре золотых сигнала: задержка, трафик, ошибки, насыщение. Для сервисов удобен метод RED — частота запросов, ошибки, длительность, — для ресурсов вроде CPU и дисков метод USE: утилизация, насыщение, ошибки. Алертить лучше по симптомам, которые видит пользователь, а не на каждый всплеск CPU.

35. Что такое SLI, SLO, SLA и error budget?

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

36. Как действовать во время инцидента?

    Сначала восстановить сервис, потом искать первопричину. Оценить влияние, назначить ответственного и канал связи, проверить последние изменения — деплой, конфиг, инфраструктуру — и откатить, если они совпадают по времени. Регулярно сообщать статус. После — постмортем без поиска виноватых: хронология, причины и задачи, чтобы не повторилось.

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

37. Как хранить секреты?

    Не в git и не в образе. Используют менеджер секретов или KMS облака, секреты CI, Kubernetes Secrets с шифрованием etcd. Плюс минимальные права для сервисов и людей, ротация ключей и журнал доступа. Если секрет попал в репозиторий, его считают скомпрометированным и меняют — удалить коммит недостаточно.

38. Как защитить сервер и SSH?

    Вход только по ключам, без паролей и без прямого входа под root (PasswordAuthentication no, PermitRootLogin no), доступ через VPN или bastion-хост, файрвол, где открыты только нужные порты, своевременные обновления, защита от перебора вроде fail2ban.

39. Как сделать контейнеры безопаснее?

    Запускать не от root (USER в Dockerfile), брать минимальный базовый образ, сканировать образы на уязвимости в CI, не использовать --privileged и лишние capabilities, где можно — монтировать файловую систему только для чтения, тянуть образы только из доверенного registry.

Типовые задачи

40. Диск на сервере заполнен на 100%

    Найти, что занимает место, — чаще всего это логи. Если файл удалён, а место не освободилось, ищем процесс, который его держит, и перезапускаем. Журнал systemd ужимают через journalctl --vacuum-size, для логов приложений настраивают logrotate. В конце — алерт на заполнение диска заранее, условно на 80%.

    df -h
    du -xh --max-depth=1 / | sort -h | tail
    lsof +L1
    journalctl --vacuum-size=500M

41. Сайт отдаёт 502 Bad Gateway

    502 возвращает прокси или балансировщик, когда бэкенд не отвечает на соединение или отвечает некорректно. Проверяем, жив ли бэкенд (процесс, под, health check), смотрим error.log nginx — там будет, например, connect() failed (111: Connection refused) или upstream prematurely closed connection, — сверяем адрес и порт upstream, недавний деплой и лимиты памяти. Если бэкенд просто не успевает ответить, nginx обычно вернёт 504.

42. Написать Dockerfile для Go-сервиса

    Многоэтапная сборка: в первом этапе зависимости и компиляция, во втором — только бинарник на минимальном образе без компилятора и оболочки, с запуском не от root. Файлы зависимостей копируются раньше кода, чтобы кэш слоёв не сбрасывался при каждой правке.

    FROM golang:1.23 AS build
    WORKDIR /src
    COPY go.mod go.sum ./
    RUN go mod download
    COPY . .
    RUN CGO_ENABLED=0 go build -o /app ./cmd/server
    
    FROM gcr.io/distroless/static-debian12:nonroot
    COPY --from=build /app /app
    ENTRYPOINT ["/app"]

43. Под висит в Pending

    Планировщик не может найти для него ноду. В kubectl describe pod, в разделе Events, будет причина: не хватает CPU или памяти под requests, не подходят nodeSelector, affinity или taints, не может привязаться PersistentVolumeClaim. Решение — поправить requests, добавить ноды или исправить правила размещения и хранилище.

На практических вопросах интервьюер смотрит на порядок действий: с чего начнёте, какие команды запустите, как поймёте, что проблема решена, и что сделаете, чтобы она не повторилась. Начинайте с простых проверок и проговаривайте гипотезы. План подготовки по дням — в материале «Как подготовиться к собеседованию», а вопросы по базам данных — в подборке вопросов по SQL.

Как отрепетировать ответы

Вопросы по эксплуатации редко проверяют знание определений: чаще просят рассказать, как вы будете действовать. Разберите задачи выше вслух, по шагам и с таймером, чтобы каждый ответ укладывался в пару минут. Почувствовать темп живого собеседования поможет бесплатное трёхминутное демо «Первый звонок» в Суфлер AI: ИИ-интервьюер Анна задаёт теоретический вопрос, даёт задачу на live coding и код-ревью, а приложение показывает 2–3 тезиса ответа в окне, которого не видно при демонстрации экрана. Подробнее — на странице скрытого помощника на собеседовании.