Кто занимался продакшеном
Что проверяют
Как вы соприкасались с продакшеном: заканчивалась ли ваша работа на тестовом стенде или вы участвовали в выпуске и следили за релизом после. Интервьюер хочет понять, как устроена ответственность за прод в ваших командах и где в ней QA. Следом обычно просят рассказать о дефекте, который всё-таки доехал до пользователей.
Как отвечать
Сначала назовите роли, как они были у вас:
- DevOps или SRE: инфраструктура, выкатка, мониторинг и доступы к проду;
- релиз-менеджер, тимлид или продакт: решение о выпуске;
- дежурный разработчик: хотфиксы и первичный разбор инцидентов;
- QA: регресс на стейдже, участие в решении «выпускаем или нет», смоук после выкатки, проверка хотфиксов.
Потом конкретно про себя. Сильный ответ показывает, что вы видели прод своими глазами:
- после релиза: смоук по критичным сценариям на проде на тестовых аккаунтах, без изменения реальных данных;
- наблюдение: ошибки в Sentry, логи в Kibana или Grafana Loki, графики ключевых метрик после выкатки;
- дефекты с прода: воспроизведение по логам, оценка серьёзности и приоритета, ретест исправления;
- выводы: каждый пропущенный дефект превращается в тест-кейс или автотест в регрессе.
Приведите свой случай с цифрами из реального проекта: что пропустили, почему, как нашли и что поменяли в процессе. Если доступа к проду у вас не было, скажите прямо и расскажите, как получали информацию: через поддержку, выгрузки логов, отчёты разработчиков.
Где спотыкаются
Говорят «прод не наша зона». Для QA это сигнал, что вам неинтересно, как продукт ведёт себя у пользователей.
Проверяют на проде что-то разрушающее, например создают и отменяют реальные заказы или шлют уведомления клиентам. Такое делается только на тестовых учётках и по договорённости.
Ищут виноватого в рассказе о пропущенном дефекте. Интервьюеру важно, что изменилось в процессе, а не кто ошибся.