Koddo
начать бесплатно

// devops interview / reliability-security

Вопросы на собеседовании: Надёжность и безопасность эксплуатации

Инциденты, восстановление, защита доступа и цепочки поставки — как сохранять сервис и данные при сбоях и атаках. Здесь — топ-12 по частоте на реальных собесах: у первых вопросов открыт полный разбор, у остальных — устный эталон. Весь банк темы (12 вопросов) с разборами — в приложении.

Открыть тему в приложении каждый день бесплатно: 3 эталона и 3 проверки арбитром

junior: база, с которой начинают

Тебя разбудил алерт: у API резко выросли ошибки. Что делаешь в первые минуты дежурства и чего точно не стоит делать?

как ответить Подтверждаю получение, проверяю реальное влияние и масштаб, назначаю тяжесть инцидента и открываю общий канал с журналом действий. Иду по runbook, проверяю недавние изменения и сначала выбираю обратимое смягчение — rollback, отключение флага или ограничение трафика. Не делаю неподтверждённые массовые перезапуски и не расследую в одиночку серьёзный сбой без эскалации.

разбор

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

Минимальный порядок:

  • открыть incident channel и зафиксировать время, симптомы и текущего координатора;
  • проверить известные изменения и зависимости по runbook;
  • выбрать действие с понятным откатом и наблюдаемым ожидаемым эффектом;
  • записывать команды, решения и результат, не полагаясь на память;
  • сообщать статус заинтересованным сторонам с согласованным ритмом.

Опасны хаотичные одновременные изменения: после них непонятно, что помогло, а состояние может ухудшиться. Массовый рестарт способен усилить перегрузку, очистить полезные данные и уронить оставшиеся здоровые реплики. Глубокий root-cause анализ можно продолжить после стабилизации; сначала нужно остановить рост ущерба и вернуть ключевую функцию.

чтобы прозвучать сильнее Раздели роли incident commander, технического исполнителя, коммуникаций и секретаря, чтобы один человек не координировал, не чинил и не писал обновления одновременно.

devops-reliability-security-001 · junior · high

Объясни разницу между RTO и RPO. Как эти цели влияют на архитектуру и план восстановления?

как ответить RTO задаёт, сколько времени бизнес может ждать восстановления функции после сбоя. RPO задаёт точку, до которой должны восстановиться данные, то есть максимально допустимую потерю изменений во времени. Более жёсткие цели требуют другой частоты копирования, репликации, автоматизации и резервной инфраструктуры, поэтому их задаёт не только IT.

разбор

RTO отвечает на вопрос «к какому сроку сервис снова должен выполнять критичную функцию». В него входят обнаружение, принятие решения, подготовка окружения, восстановление данных, проверка и возврат трафика — не только длительность команды restore.

RPO отвечает на вопрос «насколько старым может быть восстановленное состояние». Если последняя пригодная точка восстановления заметно старше допустимого RPO, быстрый запуск сервиса всё равно не выполняет требование бизнеса. Репликация уменьшает потенциальную потерю данных, но не является резервной копией: логическая ошибка или удаление может быстро реплицироваться.

Цели определяют решение:

  • частоту и тип снимков или журналов;
  • необходимость тёплой резервной площадки и автоматического failover;
  • порядок запуска зависимостей и допустимый ручной труд;
  • стоимость, которую организация готова платить за простой и потерю данных.

RTO и RPO назначают отдельно для функций и наборов данных после business impact analysis. Одинаково жёсткая цель для всего либо неоправданно дорога, либо остаётся декларацией, которую никто не проверял упражнением.

чтобы прозвучать сильнее Разложи общий RTO по этапам и зависимостям, а затем докажи тренировочным восстановлением, что сумма реальных этапов укладывается в цель.

devops-reliability-security-003 · junior · high

Почему сообщение «бэкап успешно создан» ещё не означает, что система восстановится? Как проверишь резервное копирование на практике?

как ответить Бэкап полезен только после доказанного restore: файл может быть неполным, повреждённым, недоступным без утраченного ключа или несогласованным между компонентами. Я регулярно восстанавливаю копию в изолированное окружение, проверяю целостность и бизнес-инварианты, измеряю фактические RPO и RTO. Копии отделяю по доступу и failure domain от основной системы.

полный разбор и проверка ответа арбитром — в приложении devops-reliability-security-004 · junior · high

Как применить least privilege в Kubernetes RBAC? Почему роль только с list для Secrets или правом создавать Pod может оказаться совсем не безобидной?

как ответить Выдаю субъекту только нужные verbs над конкретными resources в минимальном namespace и на ограниченный срок, используя отдельные service accounts для разных workload. list и watch Secrets возвращают их содержимое, а создание Pod часто позволяет смонтировать доступные namespace-секреты или использовать более привилегированный service account. Поэтому проверяю не только текст Role, но и пути косвенного повышения привилегий.

полный разбор и проверка ответа арбитром — в приложении devops-reliability-security-005 · junior · high

Что должно быть в хорошем постмортеме и что на практике означает blameless-подход?

как ответить Постмортем фиксирует воздействие, временную шкалу, технические и организационные факторы, обнаружение, реакцию и восстановление, а заканчивается проверяемыми action items с владельцами. Blameless означает разбирать условия и решения в доступном тогда контексте, а не искать виновного. Это не отменяет ответственности за выполнение улучшений и сознательное нарушение правил.

полный разбор и проверка ответа арбитром — в приложении devops-reliability-security-002 · junior · medium

middle: где отделяют уверенных

Очередь запросов растёт, latency увеличивается, autoscaling не успевает. Как защитишь сервис от каскадного отказа и что здесь означают backpressure и graceful degradation?

как ответить Не позволяю очереди расти без границы: ограничиваю concurrency и backlog, передаю перегрузку upstream через явный отказ или замедление и отбрасываю работу, которая уже не уложится в deadline. Критичные операции сохраняю, а необязательные функции удешевляю или отключаю — это graceful degradation. Autoscaling помогает только при наличии резерва и достаточной скорости запуска, поэтому не заменяет защиту от перегрузки.

полный разбор и проверка ответа арбитром — в приложении devops-reliability-security-007 · middle · high

Как организуешь patch management для серверов, контейнерных образов и платформы, чтобы не выбирать между уязвимостью и аварией от поспешного обновления?

как ответить Начинаю с полного инвентаря и связываю уязвимость с реально используемым компонентом, экспозицией и доступными мерами снижения риска. Обновление тестирую, выкатываю поэтапно с контролем здоровья и готовым rollback, затем проверяю фактическую версию на всех активах. Исключения имеют владельца, компенсирующую меру и срок пересмотра, а не живут бессрочно.

полный разбор и проверка ответа арбитром — в приложении devops-reliability-security-006 · middle · medium

Клиент не получил ответ после создания платежа и повторяет запрос. Как сделать операцию идемпотентной и почему обычный retry с backoff недостаточен?

как ответить Клиент передаёт стабильный idempotency key для одной бизнес-операции, а сервер атомарно связывает ключ, отпечаток запроса и сохранённый результат. Повтор с тем же ключом и тем же payload возвращает прежний результат, а с другим payload отклоняется. Backoff снижает нагрузку, но не знает, успел ли первый запрос совершить побочный эффект.

полный разбор и проверка ответа арбитром — в приложении devops-reliability-security-008 · middle · medium

Секрет базы данных утёк. Как ротировать его без простоя и как сделать следующую ротацию штатной, а не ручной спецоперацией?

как ответить Считаю старый секрет скомпрометированным: выпускаю новый с минимальными правами, обеспечиваю короткий период совместимости, обновляю consumers и проверяю их переход, после чего быстро отзываю старый. Секрет хранится в специализированном хранилище, не попадает в git и логи, а доставка и ротация автоматизированы и аудируются. Для следующего раза заранее тестирую dual-secret или динамические credentials.

полный разбор и проверка ответа арбитром — в приложении devops-reliability-security-009 · middle · medium

Контейнер запускается от root с privileged, монтирует hostPath и просит все Linux capabilities. Какие здесь риски и как ужесточишь workload и сам узел?

как ответить Контейнер разделяет ядро с хостом, а privileged снимает многие ограничения, возвращает capabilities и может дать доступ к устройствам и данным узла; hostPath расширяет последствия компрометации. Запущу процесс как non-root, запрещу privilege escalation, сброшу capabilities и верну только необходимые, включу seccomp и профиль LSM, ограничу mounts и сделаю root filesystem read-only, где возможно. Узел тоже минимизирую, обновляю и отделяю по уровню доверия workload.

полный разбор и проверка ответа арбитром — в приложении devops-reliability-security-010 · middle · medium

senior: глубина и продакшн

Как построить защищённую цепочку поставки контейнерного образа — от исходников и зависимостей до допуска артефакта в прод? Что дают SBOM, подпись и provenance по отдельности?

как ответить SBOM перечисляет заявленные компоненты. Проверенная подпись связывает digest артефакта с ожидаемым ключом или identity в рамках заданной trust policy. Provenance описывает builder, исходные inputs и способ сборки; само наличие provenance ещё не делает процесс доверенным — нужно проверить подлинность и ожидания по builder, source и build type. Ни один из этих артефактов сам по себе не доказывает отсутствие уязвимостей или вредоносного кода.

полный разбор и проверка ответа арбитром — в приложении devops-reliability-security-011 · senior · low

Одновременно идёт массовый отказ сервиса и есть признаки компрометации. Как организуешь incident command, если быстрое восстановление может уничтожить доказательства или вернуть атакующего?

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

полный разбор и проверка ответа арбитром — в приложении devops-reliability-security-012 · senior · low

Соседние темы того же собеса

  • CI/CD — Надёжные pipeline, воспроизводимые сборки, безопасные релизы и управляемый откат.
  • Контейнеры — Образы, runtime-изоляция, ресурсы, хранение и безопасная сборка контейнеров.
  • Infrastructure as Code — Terraform state, планы изменений, модули, drift и безопасное применение инфраструктурного кода.
  • Все темы DevOps-собеседования — хаб с подборками под роль