Приходилось ли участвовать в разборе инцидентов
Что проверяют
Были ли вы рядом с продом в момент аварии и отличаете ли смягчение последствий от устранения причины. Заодно проверяют культуру разбора: ищете причину или виноватого.
Как отвечать
Расскажите один случай по хронологии.
- Как узнали. Алерт, дежурный, жалоба пользователя. Если о проблеме сообщил клиент, скажите, какой мониторинг завели после.
- Как локализовали. Логи со сквозным идентификатором запроса, сборщик ошибок с трассировками, метрики очередей и воркеров, профилирование горячего участка. Питоновая специфика обычно тут и всплывает: блокирующий вызов внутри асинхронного кода, зависшая задача без таймаута, выборка, которая тянет связанные объекты по одному.
- Чем смягчили. Откат релиза, выключение фичи флагом, ограничение входящей нагрузки, перезапуск воркеров. Важно сказать, что смягчение и починка это разные шаги, и первым идёт возврат сервиса в строй.
- Что сделали после. Разбор без поиска виноватого, найденная причина, действия с ответственными: алерт на симптом, тест на конкретный сценарий, таймаут и ограничение по умолчанию.
Участвовали рядовым исполнителем, так и скажите. Честное «я собирал логи и вёл хронологию» лучше выдуманной роли ведущего разбора.
Где спотыкаются
Рассказывают только про исправление кода и ни слова про то, сколько сервис лежал и как его подняли. Интервьюера в первую очередь интересует скорость возврата в строй.
Вторая ошибка: вывод разбора звучит как «добавили в документацию» или «будем внимательнее». Это не действие. Действие меняет систему: проверка в сборке, алерт, лимит, значение по умолчанию, которое не даёт повторить ошибку.
Третья: причина названа фамилией коллеги. В разборе интересна цепочка, которая позволила ошибке дойти до прода, а не автор коммита, иначе следующий инцидент просто скроют.