Релиз через неделю, QA нашел критичный баг, а единственный разработчик модуля ушел в отпуск — ваши действия?
Валерия · Карьерный консультант
Проверил Станислав Худяков
Короткий ответ
Сначала оцените, насколько баг опасен: кого он задевает, теряются ли деньги и данные, есть ли обходной путь. Затем назовите варианты: отдать починку другому разработчику, спрятать модуль за фича-флагом, сдвинуть дату. Выбирайте, сравнивая риск для пользователей с ценой задержки, и заранее обсудите решение со стейкхолдерами.
Почему этот вопрос задают
Вопрос про то, как вы доводите работу до релиза и не теряете голову под давлением. Интервьюер проверяет, думаете ли вы перед тем, как действовать, и видите ли несколько вариантов вместо первого, что пришел в голову.
Как отвечать
- Оцените, насколько баг опасен — сколько пользователей он задевает, страдают ли деньги и данные, есть ли обходной путь
- Назовите варианты — спрятать модуль за фича-флагом, отдать починку другому разработчику, сдвинуть дату
- Выберите вариант и объясните почему — сравните риск для пользователей с ценой задержки
- Предупредите стейкхолдеров заранее и сразу предложите решение
- Сделайте так, чтобы это не повторилось — введите ревью и парную работу, чтобы модуль не зависел от одного человека
Уточняющие вопросы
- По чьей шкале баг критичный и что именно ломается?
- Сколько пользователей задевает сценарий и теряются ли деньги или данные?
- Можно ли отключить модуль флагом или он встроен в основной сценарий?
Пример сильного ответа
Ситуация
Я вел продукт в сервисе брони столиков в ресторанах, около 7 тысяч броней в неделю. За шесть дней до релиза QA нашел баг: если гость вносил депозит за банкет и потом отменял бронь, деньги иногда не возвращались. Платежный модуль знал только один разработчик, и он был в отпуске.
Пример ответа и частые ошибки
Открываются на любом тарифе подписки
Сигналы для интервьюера
Сильный ответ
Сначала оценивает опасность бага, называет несколько вариантов и критерий выбора, предупреждает стейкхолдеров, думает, как не зависеть от одного человека
Тревожный сигнал
Не готовит план отката и не следит за релизом, выкатывает исправление другого разработчика без повторной проверки
Красный флаг
Перекладывает выбор на QA или разработчиков и не берет ответственность за решение
Частые ошибки
«Перенесем релиз, пока баг не починят»
«Вижу три варианта: спрятать модуль за флагом, отдать починку другому разработчику или сдвинуть дату. Выбираю по риску для пользователя и цене задержки»
Пример ответа и частые ошибки
Открываются на любом тарифе подписки
Источники
Пит Ходжсон на сайте Мартина Фаулера: флаги релиза отделяют включение функции от выкладки кода, и недоделанный код может уехать в прод выключенным.
Pete Hodgson, martinfowler.com — Feature Toggles (aka Feature Flags)Авелино и соавторы изучили 133 популярных проекта на GitHub: в 65% из них достаточно потерять одного-двух разработчиков, чтобы проект встал.
Avelino et al. — A Novel Approach for Estimating Truck Factors (ICPC 2016)Google SRE: разбор инцидента ищет причины в системе и процессах и не обвиняет конкретного человека или команду.
Google — Site Reliability Engineering, Postmortem Culture
