Постройте дашборд сервиса
Вопрос
Интервьюер: «Расскажите, как вы бы построили дашборд для API-сервиса, чтобы дежурный ночью быстро понял, что происходит».
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Цель: ответить «плохо ли пользователям и где» за минуту
Сверху SLO и RED, ниже зависимости, насыщение и ресурсы
Переменные окружения и сервиса, `$__rate_interval`
Перцентили и heatmap вместо средних, пороги на графиках
Аннотации деплоев, ссылки на логи, трейсы и раннбук
Дашборд как код и проверка на реальном инциденте
Что могут спросить следом
- Как понять, что дашборд плохой?
- Сколько панелей допустимо?
Разбор
Образцовый ответ: «Строю его вокруг вопроса дежурного. Первая строка: доступность и задержка относительно SLO и остаток бюджета ошибок, крупные stat-панели с цветом. Вторая: RPS, доля 5xx и p50, p99 по времени, на графиках линии порогов и аннотации деплоев. Дальше исходящие вызовы к базе, кешу, внешним API, с той же схемой RED, затем пулы и очереди, в конце CPU, память и рестарты. Переменные $env и $service, окно $__rate_interval. С панелей ссылки в Explore на логи и трейсы с теми же фильтрами и ссылка на раннбук. Храню дашборд в git и генерирую из шаблона для всех сервисов. Проверяю просто: после инцидента спрашиваю дежурного, помог ли дашборд, и убираю панели, на которые никто не смотрел».
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.