Собеседование на DevOps-инженера: вопросы, ответы и разбор

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

На прошлом проекте деплой занимал около часа и включал ручные шаги: сборку на машине разработчика и копирование артефакта на сервер по SSH. Я перенёс всё в GitLab CI и разбил на стадии: сборка образа, юнит-тесты, линтеры и проверка конфигов, выкатка в стейджинг, выкатка в прод по ручному подтверждению. Добавил кеш зависимостей и параллельный запуск тестовых наборов, за счёт этого сборка стала заметно короче. Отдельно сделал откат на предыдущий образ одной джобой, чтобы дежурный не собирал старую версию заново.

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

Terraform описывал облачную часть: сети и подсети, группы безопасности, виртуальные машины, балансировщики, управляемые базы. Общие куски вынес в модули, окружения разделил по отдельным стейтам, состояние хранил удалённо с блокировкой, чтобы двое не применяли изменения одновременно. Все правки шли через merge request с обязательным plan в пайплайне, apply запускался только после ревью. Конфигурацию внутри виртуальных машин делал Ansible, потому что Terraform там неудобен. В итоге копия окружения для нагрузочных тестов поднималась командой из пайплайна, а не собиралась руками несколько дней.

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

Кластер был разделён на неймспейсы по окружениям и командам, у каждого стояли квоты, чтобы стейджинг не отъедал ресурсы у прода. Для каждого деплоймента задавали requests и limits по CPU и памяти, иначе один сервис вытеснял соседей с ноды. Сервисы с переменной нагрузкой скейлились через HPA по метрике загрузки, снаружи трафик заходил через ingress-контроллер, сертификаты обновлял cert-manager. Логи и метрики собирал отдельный стек вне кластера, чтобы при проблемах с кластером было куда посмотреть. Чаще всего ломалось на нехватке памяти: под уходил в OOMKilled, приходилось смотреть реальное потребление и пересматривать лимиты, а не просто поднимать их вслепую.

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

Сначала смотрю kubectl describe pod: события, причину последнего завершения, exit code, не ловил ли под OOMKilled и проходят ли пробы. Дальше kubectl logs с флагом previous, чтобы увидеть вывод упавшего контейнера. Если приложение стартует и сразу падает, обычно дело в конфиге или в недоступной зависимости: проверяю переменные окружения, смонтированные ConfigMap и Secret, доступность базы и очереди из соседнего пода. Если exit code про нехватку памяти, сравниваю limits с реальным потреблением по метрикам. Если проблема появилась после релиза, откатываю на предыдущую ревизию и разбираюсь уже без давления пользователей.

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

Метрики собирал Prometheus с сервисов и с нод, визуализация в Grafana, алерты через Alertmanager с маршрутизацией: часть в чат, часть в пейджер дежурному. Алерты держал на симптомах, которые видит пользователь: рост доли ответов 5xx, время ответа по перцентилю, длина очереди, отставание реплики базы, свободное место на дисках. Пороги подбирал по историческим данным и добавлял ожидание, чтобы кратковременный всплеск не будил человека. Логи собирали через Fluent Bit в Elasticsearch с общим trace id, чтобы пройти запрос по всем сервисам. Раз в месяц просматривали, какие алерты сработали впустую, и убирали шум, иначе на них перестают реагировать.

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

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

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

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

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

Блю-грин беру, когда нужен мгновенный откат переключением трафика и есть возможность держать два полных окружения: удобно для сервисов с редкими, но крупными релизами. Ограничение в том, что схема базы должна быть совместима с обеими версиями, иначе откат ничего не спасёт. Канареечный релиз применял для высоконагруженного API: сначала небольшая доля трафика на новую версию, смотрим долю ошибок и время ответа по перцентилям, потом расширяем. Это дороже по настройке маршрутизации и требует нормальных метрик, зато проблема видна на малой доле пользователей. Для сервисов без состояния и с быстрым откатом часто хватает обычного rolling update.

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

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

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

Смотрю load average и распределение нагрузки: top или htop, отдельно iowait, потому что высокий load при низком CPU обычно означает диск. Дальше df и du на предмет заполненного диска и inode, free и dmesg на предмет работы OOM killer. По сети проверяю ss на количество соединений и состояние TIME_WAIT, а также доступность зависимостей: DNS через dig, доступ до порта через curl или nc, потери на маршруте. Параллельно смотрю логи сервиса и системный журнал вокруг момента, когда началась деградация. Если нашёл процесс-виновника, фиксирую состояние и метрики до того, как что-то перезапускать, иначе причина пропадёт вместе с проблемой.

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

В AWS держал приложения на EC2 и ECS, базу в RDS с мультизонной репликацией, статику и бэкапы в S3 с политиками жизненного цикла, метрики и часть алертов в CloudWatch, доступы через IAM-роли без долгоживущих ключей. Управляемые сервисы брал там, где не хотел тратить время команды на рутину: базу, очереди, балансировщики. Kafka в своё время решили держать сами, потому что нужны были настройки, которых не давал управляемый вариант, и мы понимали, кто будет её обслуживать. Отдельно следил за расходами: теги на ресурсы, разбор счёта по сервисам, выключение тестовых окружений на ночь.

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

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

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

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