После релиза на проде нашли серьёзный баг, который вы пропустили. Что делаете сразу и что потом?
Короткий ответ
- Сначала минимизация ущерба, разбор виноватых — потом
- Оценить масштаб: кто затронут, что с данными и деньгами
- Помочь с решением: откат, хотфикс или фиче-флаг
- Проверить хотфикс быстро, но по чек-листу
- Блэймлес-разбор: почему тесты не поймали дефект
- Закрыть дыру: новый тест-кейс, автотест, правка процесса
- Открыто признать пропуск — зрелость, а не слабость
Сначала погасить инцидент, затем блэймлес-разбор причины пропуска и конкретное изменение в тестах или процессе, чтобы класс дефектов не повторился.
Как сказать вслух
пример ответаПервая фаза — инцидент: не ищем виноватых, а гасим пожар. Помогаю оценить масштаб — кого задело, что с данными, участвую в решении: откат, хотфикс или выключение фичи флагом. Хотфикс проверяю быстро, но по чек-листу, чтобы не привезти второй инцидент. Вторая фаза — разбор без обвинений: почему дефект прошёл — не было кейса, не та среда, редкая комбинация данных? И третья — закрываю дыру конкретикой: добавляю кейс в регресс, автоматизирую, правлю процесс. Пропуск признаю открыто — важно, чтобы один класс багов не повторялся дважды.
Подробный ответ
Основной ответ
Ответ должен показать зрелое отношение к инцидентам: сначала стабилизация, потом обучение. Фаза инцидента: оценка масштаба (сколько пользователей затронуто, есть ли потеря или порча данных, финансовые последствия), участие в выборе решения — откат на предыдущую версию, срочный хотфикс или отключение функциональности фиче-флагом; тестирование хотфикса в сжатое время по заранее существующему смоук-чек-листу; проверка данных, испорченных за время жизни дефекта. Фаза разбора — блэймлес-постмортем: честный ответ, почему дефект не был пойман. Типичные причины: сценария не было в тест-модели (пробел тест-анализа), сценарий был, но не попал в регресс (пробел приоритизации), окружение или данные теста не соответствовали проду, дефект проявляется только под нагрузкой или на реальных объёмах. Фаза улучшения — конкретное действие по причине: новый кейс в регрессионный набор и автотест на этот класс сценариев, синхронизация тестовых данных с продом, добавление мониторинга и алертов, правка definition of done. Признак силы ответа — отсутствие оборонительной позиции: качество — ответственность всей команды, но QA ведёт разбор именно пропуска тестами.
Ключевые моменты
- Инцидент прежде разборов. Во время пожара ищут не виноватого, а решение: откат, хотфикс, фиче-флаг.
- Хотфикс тоже тестируется. Паническая правка без смоука — классический способ получить второй инцидент за вечер.
- Блэймлес-постмортем. Разбирается процесс, а не человек: где именно тест-модель, данные или регресс дали пробел.
- Улучшение измеримо. Итог разбора — конкретный тест, автотест или правило процесса, а не обещание «быть внимательнее».
Практический контекст
Обязательный вопрос для сеньоров и лидов: проверяется поведение под давлением, отсутствие оборонительной реакции и системное мышление. Интервьюеры настораживаются от ответов «такого не случалось» и «виноват разработчик». Сильный ход — реальная история: какой баг пропустили, что за причина вскрылась на постмортеме, какое изменение внедрили и как оно позже поймало похожий дефект.
Частые ошибки
- Начинают с оправданий и поиска виноватых вместо действий по минимизации ущерба
- Заканчивают ответ на хотфиксе, не доходя до разбора причины и изменения процесса
- Предлагают «тестировать всё тщательнее» вместо конкретного закрытия пробела тестом или автотестом