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

Пример сильного ответа

Обычно иду от общего к частному. Сначала uptime и top или htop — понять среднюю нагрузку и кто ест процессор. Дальше vmstat для контекстных переключений и очередей, free -h для памяти и swap, iostat и iotop для дисковых задержек. Сеть — ss -s, ss -tnp, netstat при необходимости, плюс sar за историей. По процессам — pidstat, ps aux --sort=-%cpu. Если подозрение на открытые файлы или сокеты — lsof, df -h и df -i для места и инодов. В одном случае узким местом оказались иноды при свободном месте — это выяснилось через df -i, после чего время реакции сервиса сократилось примерно на треть.

• Названы конкретные команды, а не общие слова
• Видна логика: от общего к частному
• Есть пример инцидента с измеримым результатом

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Действую по порядку, чтобы не гадать. Сначала проверяю, жив ли процесс: systemctl status, ps, слушает ли порт через ss -tlnp. Потом доступность снаружи: curl с таймаутом, состояние балансировщика и DNS. Дальше ресурсы: top, free, df, iostat — не упёрлось ли в процессор, память или диск. Затем логи приложения и journalctl: ошибки часто сразу указывают причину. Если сервис зависит от базы или внешнего API, проверяю связность и задержки. Смотрю метрики и графики, чтобы понять, что изменилось перед сбоем: деплой, рост трафика, конфиг. В похожем случае причиной оказался исчерпанный пул соединений, и после настройки простой сократился с минут до секунд.

• Показан системный порядок действий вместо паники
• Учтены процесс, сеть, ресурсы и логи
• Финал — причина сбоя и измеримое улучшение

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Права 755 означают: владелец может читать, писать и выполнять, а группа и остальные — читать и выполнять, но не менять. Это типовой режим для каталогов и исполняемых файлов, потому что каталогу нужно право на выполнение, чтобы внутрь можно было заходить. chmod меняет сами права — можно цифрами, как 644 или 750, можно символами, например u+x. chown меняет владельца и группу, для каталогов есть ключ рекурсии. При деплое я выставляю владельца под сервисного пользователя и минимально нужные права: так меньше риска, что приложение или чужой процесс что-то испортит. В одном проекте такая практика убрала часть инцидентов после релизов.

• Точное объяснение цифр без лишней теории
• Показано применение на практике, а не заучивание
• Ответ связывает права с безопасностью деплоя

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Мой подход такой: сервис описываю отдельным юнитом в /etc/systemd/system — обязательно с Restart=on-failure, лимитами по памяти и CPU, отдельным непривилегированным пользователем и зависимостями After и Requires от сети и базы. Управляю штатно: daemon-reload, enable --now, status, restart, без ручных запусков в screen или tmux. Журналы смотрю через journalctl: по конкретному юниту, с ключом follow для живого хвоста, с фильтром по времени и уровню ошибок при разборе инцидента, плюс настраиваю ротацию и лимиты, чтобы диск не забивался. На одном проекте за счёт Restart и health-check время восстановления сервиса удаётся держать в пределах минуты вместо ручных перезапусков.

• Конкретика: параметры юнита и команды journalctl
• Показан системный подход вместо ручного управления
• Есть измеримый результат — минута на восстановление

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

DNS — это иерархия: клиент спрашивает резолвер, тот идёт по цепочке от корневых зон к авторитативным серверам, а ответы кэшируются на время TTL. «Это всегда DNS» потому, что любая ошибка на этом слое выглядит одинаково — приложение просто не находит адрес, — а причина может быть в TTL, в рассинхроне зон, в поиске по search-домену, в переполненной таблице соединений для UDP или в недоступном резолвере. В разборе иду по шагам: dig по конкретному серверу, проверка разных типов записей, сверка ответа на двух резолверах, замер времени ответа. Один раз расхождение TTL в кэшах дало всплеск ошибок примерно на 15% запросов.

• Объяснена механика резолвинга, а не только симптомы
• Названы реальные причины инцидентов
• Есть цифра из своего опыта

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

TCP — это соединение с подтверждениями, порядком доставки и повторной передачей, поэтому даёт надёжный поток, но платит задержкой и состоянием на балансировщиках. UDP — датаграммы без гарантий, зато минимальная задержка и никакого рукопожатия. В инфраструктуре это важно буквально везде: HTTP и API живут на TCP, DNS и часть метрик — на UDP, а QUIC сознательно строит надёжность поверх UDP. Практический вывод: для UDP иначе устроены health-check и балансировка, а потери пакетов ловятся не ретрансмитами, а метриками на источнике. При переводе части метрик на UDP нагрузка на сборщик снизилась примерно на треть.

• Сравнение по свойствам, а не заучивание определений
• Показано влияние на балансировку и мониторинг
• Есть измеримый результат — треть нагрузки

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Образ — это неизменяемый слоёный шаблон: файловая система, метаданные и инструкции запуска, собранный по Dockerfile и хранящийся в registry. Контейнер — запущенный экземпляр образа: к слоям добавляется тонкий записываемый слой, появляются свои процессы, сеть, лимиты и своя жизнь. Отсюда практика: образ версионируется по тегу или digest, а контейнеры одноразовые и пересоздаются, а не лечатся руками. Значит, состояние нельзя держать внутри контейнера — только в volume или во внешнем сервисе. В парке примерно из 40 сервисов пересоздание вместо ручных правок заметно снизило расхождения между стендами.

• Чёткое разделение двух сущностей
• Из теории следуют практические правила
• Есть цифра про масштаб парка сервисов

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Сначала смотрю на порядок слоёв: в начало — манифесты зависимостей, потом код, чтобы кэш не сбрасывался на каждой правке. Дальше multi-stage: сборка в одном образе, рантайм в минимальном, плюс .dockerignore, точные версии базовых образов, slim-варианты, установка пакетов и очистка кэша в одном слое, отсутствие лишних утилит и документации. Для скорости сборки помогают BuildKit-кэш и параллельные стадии. В результате образ сервиса удаётся уменьшить с 1,2 ГБ до 180 МБ, а сборку сократить с восьми минут до двух.

• Названы конкретные приёмы оптимизации
• Отдельно про размер и про время сборки
• Сильный измеримый результат в цифрах

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Простыми словами: под — минимальная единица запуска, один или несколько контейнеров с общей сетью и томами. Deployment описывает желаемое состояние приложения: сколько реплик, какой образ, как обновлять, и управляет подами через ReplicaSet. Service даёт стабильную точку доступа и балансировку, потому что адреса подов меняются. В моей практике на кластер, где около 40 сервисов, приходилось объяснять это команде разработки, и лучше всего работает схема: Deployment создаёт поды, Service находит их по лейблам. Отдельно подчёркиваю, что под одноразовый: его пересоздают, а не чинят вручную.

• Определения даны простыми словами и связаны между собой
• Есть пример из практики с числом сервисов
• Подчёркнута идея одноразовости пода

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Я работаю с Kubernetes в продакшене. Самовосстановление строится на контроллерах: ReplicaSet следит, чтобы число подов соответствовало желаемому, и при падении пода создаёт новый. Liveness-пробы перезапускают зависшие контейнеры, readiness — исключают неготовые поды из балансировки, а планировщик переносит поды с упавших нод. Для масштабирования использую HPA: он добавляет поды по CPU, памяти или кастомным метрикам, а cluster autoscaler добавляет ноды. В проекте с 50 микросервисами это сократило ручные операции на 70% и убрало простои при пиках.

• Показано понимание самовосстановления через контроллеры и пробы.
• Упомянуты HPA и cluster autoscaler — ключевые инструменты масштабирования.
• Приведены конкретные цифры: 50 микросервисов и 70% сокращения ручных операций.

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Типичный пайплайн строится так: на пуш срабатывает сборка, прогоняются линтеры и unit-тесты, затем сборка контейнерного образа и пуш в registry, потом деплой в dev или staging, автотесты и подтверждение на прод. Инструменты — GitLab CI или Jenkins, Kubernetes, Helm, Argo CD для GitOps-доставки. Однажды моя задача была перевести релизы с ручных выкаток: время от коммита до прода сократилось с пары дней до примерно 40 минут, а откат стал одной кнопкой. Стараюсь держать пайплайн одинаковым для всех сервисов.

• Этапы пайплайна перечислены в логичном порядке
• Названы конкретные инструменты, а не общие слова
• Есть цифра: от пары дней до 40 минут

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Секреты держу вне репозитория и вне образа. В CI это защищённые переменные и маскирование в логах, доступ выдаётся только нужным веткам и окружениям. Для прода лучше внешнее хранилище секретов, а под получает их через переменные окружения или смонтированные файлы. В образах секретам не место: они остаются в слоях и оттуда их уже не вычистить. Из практики: инвентаризация доступов и замена долгоживущих ключей на короткоживущие токены убрала из пайплайнов больше двадцати ключей. Плюс ротация и аудит доступа.

• Сформулировано чёткое правило: секреты вне репозитория и образа
• Есть результат с числом убранных ключей
• Упомянуты ротация и аудит доступа

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

State — это файл, где Terraform хранит сопоставление ресурсов из конфигурации с реальными объектами у провайдера и их атрибуты. Без него непонятно, что создавать, что менять, что удалять. Основные проблемы: расхождение state с реальностью, когда ресурсы изменили руками; блокировки при параллельном запуске; потеря или порча файла, особенно если он лежит локально у одного человека. Поэтому state храню в удалённом бэкенде с блокировками и версионированием, разнесённым по окружениям. В одном проекте такое разнесение убрало конфликты при параллельных запусках, и планирование стало занимать единицы секунд вместо минут.

• Суть state объяснена без лишней теории
• Перечислены типовые проблемы на практике
• Есть эффект: конфликты ушли, планирование быстрее

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Для меня это инструменты под разные задачи. Terraform — про жизненный цикл инфраструктуры: он декларативный, хранит состояние и умеет корректно создавать, изменять и удалять ресурсы в облаке, поэтому именно на нём описываю сети, кластеры, базы и балансировщики. Ansible — про конфигурацию уже существующих машин: работает по SSH без агента, удобен для установки пакетов, раздачи конфигов и деплоя. На практике веду Terraform как основной слой, а Ansible подключаю после создания инстансов. В одном проекте это сократило подъём окружения с двух дней ручной работы до сорока минут.

• Чётко разводит инструменты по задачам
• Есть практический пример с цифрой
• Звучит как опыт, а не теория из книги

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

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

• Сначала определение, потом практика
• Эффект показан измеримыми цифрами
• Ревью и воспроизводимость — признак зрелого подхода

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Мониторинг строю по уровням. Метрики инфраструктуры собираю через экспортёры, приложения отдают свои метрики по стандартному эндпоинту, а список целей держу в репозитории и раскатываю автоматически. Обязательный набор: доступность и время ответа сервисов, доля ошибок и задержки по эндпоинтам, нагрузка на процессор, память и диск, состояние кластера и очередей, плюс бизнес-метрики вроде числа заказов. В Grafana собираю дашборды по каждому сервису и один общий обзор для дежурного, чтобы за минуту было понятно, что и где сломалось. Это сократило время диагностики примерно с часа до пятнадцати минут.

• Структура по уровням, легко слушать
• Перечислен обязательный набор метрик
• Есть цифра по ускорению диагностики

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Главный принцип — алерт нужен только там, где человеку надо действовать. Опираюсь на симптомы, а не на причины: не «высокая загрузка процессора», а «пользователи видят ошибки» или «растёт время ответа». Для каждой тревоги фиксирую порог, окно и владельца, обязательно прикладываю короткую инструкцию по первым шагам. Использую группировку, подавление зависимых алертов и дежурные окна. Отдельно занимаюсь шумом: если тревога срабатывает и гаснет самостоятельно без действий, её убираю или перевожу в дашборд. В итоге ложных срабатываний стало примерно вдвое меньше — несколько в неделю вместо десятков.

• Опирается на принцип «алерт равно действие»
• Снижение шума подтверждено цифрами
• Виден системный подход, а не разовые настройки

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

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

• Подчёркнут подход без поиска виноватых
• Понятный формат и сроки проведения
• Цикл замкнут на предотвращение повторов

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Первым делом подтверждаю инцидент и открываю канал связи: собираю дежурных разработчиков и пишу в статус-канал, что сервис недоступен и кто ведёт разбор. Дальше смотрю мониторинг и логи, чтобы понять масштаб: одна нода, зона или весь сервис. Если есть быстрый откат или переключение на резервный контур, делаю это сразу, до выяснения причин: стабильность важнее первопричины. Параллельно фиксирую таймлайн действий. В похожем случае откат вернул сервис за 12 минут, а потерю заказов удалось удержать в пределах нескольких процентов. Утром — спокойный разбор без поиска виновных и задачи на устранение.

• Показан приоритет: сначала восстановление, потом причина
• Есть таймлайн, эскалация и роль ведущего
• Конкретная цифра восстановления добавляет убедительности

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Начинаю с требований: профиль нагрузки, целевой SLA, чувствительность данных, бюджет и владелец сервиса. Дальше рисую схему: контейнеры в оркестраторе, манифесты и Helm-чарт в репозитории, вся инфраструктура как код, чтобы окружения поднимались одной командой. Закладываю автомасштабирование, health-проверки, лимиты ресурсов, секреты в менеджере секретов, отдельные сети для баз данных. Обязательно продумываю наблюдаемость: метрики, логи, трассировки и алерты на SLO. В одном проекте такой шаблон сократил запуск нового сервиса с двух недель до трёх дней.

• Виден порядок: требования, потом архитектура
• Упомянуты безопасность и наблюдаемость
• Цифра ускорения делает результат измеримым

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Предлагаю не бороться за скорость, а построить конвейер, который делает частые релизы безопасными. Начинаю с метрик: сколько релизов, какая доля откатов, где чаще ломается. Дальше — обязательные проверки в CI, автотесты на критичные сценарии, сканирование зависимостей и один неизменяемый артефакт, который проходит все окружения. Внедряю постепенный выкат: канареечный релиз на малой доле трафика, автоматический откат по метрикам, фича-флаги и миграции базы, совместимые с обеими версиями. Когда откаты упали примерно втрое, десять деплоев в день перестали быть риском.

• Ответ опирается на метрики, а не на мнение
• Названы канареечный выкат и автооткат
• Есть измеримый результат по откатам

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

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

• Чёткая структура: ситуация, задача, действия, итог
• Есть цифра простоя и восстановления
• Показана работа над причинами, а не только тушение

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Для меня это не спор, а сигнал, что окружения расходятся. Предлагаю воспроизвести проблему вместе и сравнить: версии зависимостей, конфиги, переменные окружения, доступы, различия между локальной машиной и кластером. Обычно помогает контейнеризация локальной разработки и dev-контур, максимально похожий на прод, чтобы «у меня работает» перестало быть аргументом. Важен тон: цель — общий результат, а не доказать чью-то неправоту. В одной команде после перевода локального запуска в контейнеры поток таких обращений снизился примерно на треть, и время на разбор сократилось.

• Конфликт переводится в техническую плоскость
• Предложено системное решение, а не разовая помощь
• Подчёркнута уважительная коммуникация и результат

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.