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