Алерт в 3 ночи: задержки без релизов
Вопрос
Интервьюер: «3 ночи, burn-rate алерт по задержке: p99 API вырос с 300 мс до 4 секунд, ошибок почти нет, релизов и изменений не было. Как будете искать?»
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Оценить масштаб: все эндпоинты или часть, все поды или некоторые, все зоны
Пройти по зависимостям: база, кеш, очереди, внешние API, их RED и насыщение
Трейсы медленных запросов: где тратится время
Проверить ресурсы и насыщение: пулы соединений, CPU-троттлинг, GC, диски, сеть
Ночные задачи: бэкапы, cron, батчи, VACUUM, совпадения по времени
Смягчить: убрать тяжёлую задачу, вывести плохой узел, добавить мощности
Что могут спросить следом
- Что если тормозит только один под из двадцати?
- Как быть, если причина во внешнем API?
Разбор
Образцовый ответ: «Если релизов не было, ищу, что ещё изменилось: нагрузка, данные, расписание. Сначала масштаб: на дашборде вижу, что медленные все эндпоинты, работающие с базой, на всех подах. Значит, смотрю базу: время запросов выросло, пул соединений приложения насыщен, ожидание соединения 3 секунды. Трейсы медленных запросов подтверждают: время уходит на ожидание соединения и на один тяжёлый запрос. В pg_stat_activity вижу долгий запрос аналитической выгрузки, которая по cron стартовала в 02:50 и читает мастер. Смягчаю: останавливаю выгрузку, задержки возвращаются. Сообщаю в канал. В постмортем: переводить выгрузки на реплику, лимит времени запросов для аналитической роли, алерт на насыщение пула. Если бы тормозил один под, вывел бы его из балансировки и разбирался отдельно».
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.