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

В чём разница между continuous integration, delivery и deployment?

Continuous integration означает, что каждый коммит вливается и проверяется автоматической сборкой и тестами, поэтому ветка не расходится с main. Continuous delivery означает, что каждая зелёная сборка даёт артефакт, готовый к продакшену, а финальный выкат остаётся человеческим решением. Continuous deployment убирает это решение — каждая зелёная сборка едет в прод. Различие важно на собеседовании, потому что большинство команд, заявляющих CD, на деле практикуют delivery.

Как устроены слои Docker и как держать образ маленьким?

Каждая инструкция создаёт read-only слой, слои кешируются и переиспользуются, пока не менялось всё, что было до них, — поэтому манифест зависимостей копируют и ставят зависимости до копирования исходников. Размер снижают многоступенчатой сборкой, которая оставляет компилятор позади, slim- или distroless-базой и объединением команд, чтобы промежуточные файлы вообще не попали в слой. Удаление файла в более позднем слое образ не уменьшает — он всё ещё лежит в раннем слое.

Объясните связь между Pod, Deployment и Service.

Pod — минимальная планируемая единица: один или несколько контейнеров с общим сетевым пространством и жизненным циклом. Deployment управляет ReplicaSet, который держит заявленное число одинаковых подов и обеспечивает роллинг-обновления и откаты. Service даёт этому меняющемуся набору подов стабильный виртуальный IP и DNS-имя, балансируя между теми подами, которые сейчас подходят под селектор, так что вызывающей стороне не нужно следить за адресами отдельных подов.

В чём разница между liveness и readiness пробами?

Readiness-проба решает, идёт ли на под трафик; её провал убирает под из эндпоинтов сервиса, но оставляет его работать. Liveness-проба решает, перезапускать ли контейнер. Их путаница — классическая авария: если направить liveness на зависимость, то медленная база перезапустит все реплики одновременно, превратив деградацию в полный простой. Liveness должна проверять только «не завис ли процесс», readiness — «могу ли я обслуживать прямо сейчас».

Что такое Terraform state и чем он опасен?

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

Когда использовать Terraform, а когда Ansible?

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

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

SLI — измеряемый показатель здоровья сервиса, например доля запросов, обслуженных успешно быстрее 300 мс. SLO — цель по этому показателю на окне, скажем 99,9% за 30 дней. Error budget — допустимый недобор, те самые 0,1% запросов, и он превращает надёжность в расходуемый ресурс: пока бюджет цел, можно катить быстрее, а когда исчерпан, фичи замораживают и чинят надёжность. Именно это превращает спор «надёжность против скорости» из вкусовщины в арифметику.

В чём разница между метриками, логами и трейсами?

Метрики — дешёвые числовые агрегаты во времени, отвечают на вопрос «что-то сломалось?» и именно на них ставят алерты. Логи — дискретные события с деталями, отвечают «что именно произошло» в конкретном запросе или компоненте. Трейсы прослеживают один запрос через сервисы и отвечают «куда ушло время» в распределённой цепочке вызовов. Алертить по логам дорого и шумно, а отлаживать по одним метрикам — гадание. Нужны все три, каждый по своему назначению.

Сравните rolling, blue-green и canary выкаты.

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

Как правильно обращаться с секретами в пайплайне?

Секреты не живут ни в репозитории, ни в слоях образа, ни в обычных переменных окружения, зашитых на этапе сборки. Они приходят из выделенного хранилища — Vault, облачный secret manager или зашифрованные секреты CI — и подставляются в рантайме с минимально возможной областью действия и сроком жизни. Короткоживущие креды через OIDC-федерацию лучше долгоживущих ключей, потому что главный риск не в краже секрета, а в секрете, который остаётся валидным годами.

Под в состоянии CrashLoopBackOff. Разберите ход диагностики.

Начинают с kubectl describe pod и смотрят события — там видны ошибки скачивания образа, неудавшиеся монтирования, OOMKilled и проваленные пробы. Затем kubectl logs с --previous, потому что текущий контейнер может быть слишком молод, чтобы успеть что-то записать. Проверяют код выхода на предмет OOM и сравнивают лимит памяти с реальным потреблением. Если контейнер стартует и сразу умирает, обычные причины — отсутствующий конфиг или секрет, падающая на старте миграция, либо liveness-проба со слишком коротким начальным ожиданием.

Что делает постмортем полезным, а не ритуальным?

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