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

Что хотим услышать

• Жёсткая ссылка: ещё одно имя того же inode, равноправное с оригиналом
• Данные живут, пока счётчик ссылок больше нуля и файл никто не держит открытым
• Жёсткую нельзя на каталог и между разными ФС
• Символьная: отдельный файл, внутри которого путь к цели
• Символьная ломается при удалении или переносе цели, зато работает с каталогами и через ФС
• Пример: symlink на текущий релиз current -> releases/42 для атомарного переключения

Если ответил, копните глубже

Что хотим услышать

• Контейнер это процесс (или группа) на ядре хоста, а не отдельная ОС
• Namespaces изолируют видимость: PID, сеть, ФС, hostname, пользователи
• Cgroups ограничивают ресурсы: память, CPU, число процессов
• Файловая система из слоёв образа плюс записываемый слой (overlay2, copy-on-write)
• ВМ эмулирует железо и запускает своё ядро: изоляция сильнее, старт медленнее, накладные расходы больше
• Следствия: общее ядро, быстрый старт, данные в контейнере эфемерны

Если ответил, копните глубже

Что хотим услышать

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

Если ответил, копните глубже

Что хотим услышать

• RED на входе: запросы, ошибки, перцентили задержки
• RED на исходящих вызовах к базе, Redis и внешним API
• USE ресурсов: CPU, память, пулы соединений, диски
• Внешняя проверка доступности и сертификата
• Логи с trace_id и трейсы ключевых запросов
• Несколько алертов по симптомам, а не на всё подряд

Если ответил, копните глубже

Что хотим услышать

• Same-origin policy: скрипт не может читать ответы другого origin (схема, хост, порт)
• CORS: сервер заголовками Access-Control-Allow-* разрешает конкретным origin читать ответы
• Проверяет браузер, сервер отвечает всегда; вне браузера CORS не действует
• Простые запросы уходят сразу, остальные после preflight OPTIONS
• С куками нужен credentials: 'include', Allow-Credentials: true и точный origin вместо *

Если ответил, копните глубже

Что хотим услышать

• Внешняя функция принимает func, возвращает обёртку
• Обёртка принимает *args, **kwargs и передаёт их дальше
• Возвращает результат func
• functools.wraps сохраняет имя и docstring
• Время через time.perf_counter, вывод в finally или после вызова
• Код декоратора выполняется при определении, обёртки при каждом вызове

Если ответил, копните глубже

Что хотим услышать

• граф зависимостей от точки входа
• трансформация: TS, JSX, современный синтаксис, CSS
• резолв пакетов из node_modules
• склейка в чанки, минификация, tree shaking
• хеши в именах для долгого кеша
• dev-сервер с HMR и source maps

Если ответил, копните глубже

Что хотим услышать

• Вертикальное: мощнее машина, код не меняется, есть предел и единая точка отказа
• Горизонтальное: больше узлов, нужен stateless или распределённое состояние
• Stateless-сервисы приложения масштабируют горизонтально в первую очередь
• БД часто сначала масштабируют вертикально и репликами, шардирование позже
• Горизонтальное даёт отказоустойчивость, но добавляет сложность

Если ответил, копните глубже

Что хотим услышать

• Две-три стороны, а не список из десяти
• Каждая подкреплена примером
• Стороны связаны с вакансией
• Нет пустых слов вроде «стрессоустойчивый, коммуникабельный» без доказательств
• Уверенно, без хвастовства

Если ответил, копните глубже

Что хотим услышать

• Три дескриптора: 0 stdin, 1 stdout, 2 stderr
• > перезаписывает, >> дописывает, 2> для ошибок, < для ввода
• > file 2>&1 объединяет потоки, порядок важен: перенаправления слева направо
• Пайп передаёт только stdout, для ошибок нужен 2>&1 |
• sudo cmd > /etc/x не работает: файл открывает shell без прав, используют | sudo tee
• /dev/null для выбрасывания ненужного вывода

Если ответил, копните глубже

Что хотим услышать

• Deployment: stateless-сервисы, rolling update и откаты
• StatefulSet: стабильные имена, порядок запуска и собственный том на реплику (базы, брокеры)
• DaemonSet: по поду на узел (агенты логов и метрик, сетевые плагины)
• Job: задача до успешного завершения с повторами
• CronJob: Job по расписанию, concurrencyPolicy
• ReplicaSet напрямую не используют, им управляет Deployment

Если ответил, копните глубже

Что хотим услышать

• Общая ответственность разработки и эксплуатации за сервис в проде
• Автоматизация сборки, тестов, деплоя и инфраструктуры
• Маленькие частые изменения вместо больших релизов
• Измерения: метрики DORA или аналогичные
• Пример из опыта: что поменялось после внедрения

Если ответил, копните глубже

Что хотим услышать

• Воспроизвести и уточнить симптом: таймаут, refused, ошибка TLS, 5xx
• DNS: dig +short, правильный ли IP, не истёк ли домен
• Сеть и порт снаружи: curl -v, nc -zv host 443; refused или timeout
• На сервере: слушает ли процесс и на каком адресе (ss -tlnp), отвечает ли локально
• Фаервол на хосте и в облаке, балансировщик и его health checks
• Логи прокси и приложения, сертификат и его срок

Если ответил, копните глубже

Что хотим услышать

• Подтвердить: describe (Reason OOMKilled, 137), не путать с Evicted
• Посмотреть график памяти контейнера до падения: резкий пик или постоянный рост (утечка)
• Сравнить лимит с реальным пиком; проверить лимит кучи рантайма (JVM, Node, Go) относительно лимита контейнера
• Учесть всю память процесса: нативные буферы, потоки, page cache в cgroup
• Утечка: профилирование кучи, heap dump, сравнение снимков
• Решение: исправить утечку или ограничить кучу, выставить лимит по данным, requests = limits для памяти

Если ответил, копните глубже

Что хотим услышать

• Партии через serial (например, 1, затем 10%, затем 25%) и max_fail_percentage
• Вывод хоста из балансировщика через delegate_to, ожидание дренирования
• Конкретная версия артефакта, миграции один раз через run_once и совместимые
• Health check перед возвратом в балансировщик
• Остановка выкатки при ошибке и откат на прошлую версию тем же плейбуком
• Наблюдение за метриками между партиями

Если ответил, копните глубже

Что хотим услышать

• Быстро понять, что растёт: WAL, таблицы, временные файлы, логи
• Проверить частые причины: отставшая или мёртвая реплика держит слот репликации, сломан архив WAL, долгая транзакция
• Смягчить безопасно: расширить диск, починить архивирование, удалить мёртвый слот после проверки
• Не удалять файлы базы руками
• Сообщить и эскалировать на владельца базы при необходимости
• Постмортем: почему алерт пришёл так поздно, мониторинг слотов и архива

Если ответил, копните глубже

Что хотим услышать

• Реконнект с экспоненциальной задержкой и джиттером, сброс задержки после успеха
• Heartbeat: ping/pong с таймаутом, при пропуске закрыть и переподключиться
• Нумерация сообщений: после реконнекта клиент сообщает последний id, сервер досылает пропущенное
• Очередь исходящих сообщений с клиентскими id, идемпотентность на сервере против дублей
• Реакция на online/offline и видимость вкладки, повторная авторизация при истёкшем токене

Если ответил, копните глубже

Что хотим услышать

• Метрики и трейсы: какой эндпоинт, p95/p99, где время (БД, внешние API, CPU)
• Профилирование: py-spy на живом процессе, cProfile локально
• Типичные причины: N+1 запросы, отсутствие индексов, синхронные вызовы в async, неверные структуры данных
• Исправления: батчи и prefetch, кеш, индексы, перенос тяжёлого в фон
• CPU-bound: алгоритм, встроенные функции, numpy, процессы
• Проверка результата нагрузочным тестом

Если ответил, копните глубже

Что хотим услышать

• начать с самого рискованного и ценного для бизнеса: оплата, вход, ключевые сценарии
• несколько e2e smoke-тестов на критичные пути
• unit-тесты на чистую логику: расчёты, форматирование, утилиты
• интеграционные тесты компонентов и API на новых и изменяемых местах
• тесты в CI как обязательная проверка PR
• регрессионный тест на каждый найденный баг, борьба с флаки

Если ответил, копните глубже

Что хотим услышать

• Требования: личные и групповые чаты до 1 000 участников, доставка онлайн и офлайн (push), история, статусы «доставлено» и «прочитано»; порядок сообщений в чате; медиа и сквозное шифрование вне рамок
• Оценка нагрузки: 50 млн DAU по 40 сообщений ≈ 2 млрд в сутки ≈ 20 000 RPS записи, в пике ~60 000; 10 млн одновременных соединений, ~100 000 на gateway → ~100 gateway; 2 млрд × 200 байт ≈ 400 ГБ в сутки, ~150 ТБ в год без реплик
• API: WebSocket: send {chat_id, client_msg_id, text}, ack {msg_id}, события new_message, read; HTTP: GET /chats/{id}/messages?before=...
• Данные: чаты и участники в PostgreSQL, сообщения в Cassandra/ScyllaDB с ключом партиции chat_id и сортировкой по msg_id, реестр user_id → gateway в Redis с TTL
• Компоненты: gateway-серверы с соединениями, сервис сообщений (сохранить, присвоить id, разослать), сервис присутствия, push-сервис для офлайн, очередь для фан-аута в группах
• Узкие места: большие группы (фан-аут через очередь), дубли при переотправке (client_msg_id для идемпотентности), переподключения и догрузка пропущенного, горячие чаты, падение gateway

Если ответил, копните глубже

Что хотим услышать

• Назван масштаб: команда, нагрузка, пользователи или деньги
• Есть решения, которые повлияли дальше своего кода
• Есть метрики результата
• Упомянуто влияние на команду: менторинг, процессы, ревью
• Уложился в 2 минуты, не утонул в деталях

Если ответил, копните глубже

Что хотим услышать

• Сначала SIGTERM, затем ожидание (таймаут), и только потом SIGKILL
• Приложение ловит SIGTERM: перестаёт принимать новые запросы, дожидается текущих, закрывает соединения с БД
• SIGKILL нельзя перехватить, поэтому после него остаются lock-файлы и незавершённые операции
• systemd делает так же: KillSignal, TimeoutStopSec, затем SIGKILL
• В контейнере процесс должен быть PID 1 или запускаться через init (tini), иначе сигнал не дойдёт
• Код выхода 143 после SIGTERM и 137 после SIGKILL помогают понять, как завершился процесс

Если ответил, копните глубже

Что хотим услышать

• Namespace на команду или сервис, права через группы из SSO (OIDC), а не через персональные сертификаты
• Стандартные роли (view, edit) через RoleBinding в своих namespace, cluster-admin только у платформенной команды
• Для прода разработчикам чтение и логи, изменения через CI/GitOps
• Приложениям отдельные ServiceAccount с минимальными правами, без токена, если API не нужен
• Ограничения на поды: Pod Security Admission, политики Kyverno/Gatekeeper, квоты
• Аудит: audit log API server, регулярный пересмотр прав (kubectl auth can-i --list)

Если ответил, копните глубже

Что хотим услышать

• Секреты в хранилище CI или Vault, не в репозитории, masked и protected
• Короткоживущие учётки через OIDC вместо долгих токенов
• Минимальные права токенов и раздельные учётки на окружения
• Сторонние actions и образы зафиксированы по SHA или digest
• Недоверенный код (PR из форков) без секретов и на одноразовых раннерах
• Защищённые ветки, обязательное ревью, подпись артефактов

Если ответил, копните глубже