Приходилось ли выступать третьей линией поддержки при проблемах на проде

Что проверяют

Видели ли вы прод в момент, когда он сломан, и умеете ли разделять «починить сейчас» и «починить навсегда». Третья линия это не более грамотный саппорт, а разработчик, к которому приходят, когда первые две уже не справились.

Как отвечать

Опишите устройство дежурства: в какой очереди вы были, как до вас доходил инцидент, был ли договорённый срок реакции. Дальше разберите один случай по шагам.

Сначала восстановление, потом расследование. Откат релиза, выключение фичи флагом, перезапуск, добавление воркеров: всё, что возвращает сервис, делается до того, как вы поняли причину.

Потом локализация. Полезно назвать, чем смотрели: структурированные логи с идентификатором запроса, сквозная трассировка, метрики задержки и ошибок по ручкам, pg_stat_statements для тяжёлых запросов. Для зависшего питоновского процесса отдельно упомяните py-spy dump, он снимает стек живого процесса, ничего не останавливая и не требуя заранее вшитого отладчика.

Финал истории это не «починили», а разбор: что сделали, чтобы случай не повторился, и какой сигнал добавили в мониторинг, чтобы в следующий раз узнать о проблеме раньше пользователей.

Где спотыкаются

Начинают с поиска корневой причины, пока сервис лежит. Копаться в горячих логах выглядит героически, но простой считают минутами, и правильный первый шаг это вернуть работу любым грубым способом.

Второе: история заканчивается словами «проблему решили». Без разбора, задачи в бэклоге и нового оповещения это означает, что тот же сбой повторится, и интервьюер обязательно про это спросит.

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