Что делать при срочном запросе к базе данных без связи с командой?

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

Здесь проверяют не SQL, а здравый смысл: не наделаете ли вы бед в продакшене из желания помочь. Следом почти всегда спрашивают: «а если просят не выгрузить данные, а исправить их прямо сейчас?»

Как отвечать

Покажите порядок действий, в котором риск снижается на каждом шаге:

• уточнить запрос: кто просит, какие данные, к какому сроку и что случится, если подождать час. Многие «срочные» запросы после двух вопросов перестают быть срочными;
• разделить чтение и запись: выгрузку можно сделать самому, если доступ выдан по регламенту. Изменение данных без подтверждения ответственного не делается;
• читать безопасно: реплика или read-only пользователь, LIMIT, фильтр по индексированным полям, statement_timeout. Тяжёлый запрос без WHERE к большой таблице способен положить прод не хуже бага;
• писать с подстраховкой: если правка согласована, сначала SELECT с тем же условием и сверка числа строк, затем UPDATE в транзакции и COMMIT, только когда затронуто ровно ожидаемое количество;
• искать эскалацию: дежурный, on-call, руководитель, runbook. «Нет связи с командой» редко значит, что ответственных нет вообще;
• оставить след: какой запрос, во сколько и зачем, в тикете или общем чате.

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

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

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

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

Забывают про персональные данные. Выгрузка с телефонами клиентов, отправленная в личный мессенджер, грозит нарушением 152-ФЗ, даже если отчёт был действительно срочным.