intro

Всем привет. У меня очередное весеннее обострение, поэтому я решил сделать что-то полезное и рассказать о такой полумагической штуке, как дашборды. Сначала я написал одну статью, в которой просто рассказывал как и что я делаю на примере мониторинга графит кластера, но в итоге мне показалось уместным сначала дать теоретическую часть, а потом дополнить её практической (которая, может быть, уже будет и не нужна). Итак, простая теоретическая часть :)

Теория

Самый важный шаг в построении дашборда — определение того, какую проблему он должен решить, и сможет ли он решить эту проблему. Этот шаг должен быть чётко сформулирован и записан:

я должен видеть, есть ли у пользователей проблема с моим сервисом

или

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

или

я должен понять, проблема в сервисе или в конкретном инстансе

или

связана ли проблема с новым релизом, с возросшей нагрузкой или с другими сервисами

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

Попробуйте представить, что вы говорите на незнакомом языке (например, немецком, французском или китайском) и придумайте пару предложений внутри головы. Кажется просто? А теперь произнесите это вслух. Вышла каша и непохоже на почти настоящую речь, которая звучала внутри головы? Тоже самое бывает, когда мелодия крутится внутри головы, а напеть её не получается. Это значит, что вы не запомнили мелодию, а не то, что физически не можете её напеть.

Избавиться от такого когнитивного искажения важно не только в рамках задачи построения дашборда, это вообще важная часть любого действия — полностью понимать, что вы делаете и зачем. Поэтому, чтобы построить хороший дашборд, надо писать хорошие метрики, по которым можно построить хороший дашборд. А хорошие метрики надо писать на этапе написания кода и думать о них на этапе построения архитектуры приложения. Что-то похожее на TDD, когда сначала думаешь, что ты хочешь увидеть, и как ты это можешь увидеть, а потом строишь вокруг этого код. Мой любимый и очень сильно упрощённый пример включает в себя приложение и базу данных:

Если ваше приложение работает с базой данных, то, скорее всего, вы захотите знать, когда база данных начнёт тормозить, и за ней начнёт тормозить ваше приложение. Соответственно, стоит писать сколько времени потратило ваше приложения на запись в БД. Но тут, опять же, стоит сразу разделить разные запросы по типам, так как в одном случае это может быть чтение пользователя из таблицы, в другом — обновления какого-то поля, в третьем — запись большого количества текста, или обновление сразу нескольких полей. И если вы будете писать все эти данные в одну и ту же метрику, то это мало что покажет. Поэтому стоит сразу разделять эти запросы таким образом, чтобы запрос каждого типа предположительно выполнялся за предсказуемое и более-менее одинаковое время.

Если вы пишите время загрузки вашего сайта, то стоит разбить его по страницам, так как разные страницы могут грузиться разное время (и, наверное, лучше никогда не смотреть на среднее время, а смотреть на какой-то 95-й перцентиль)

В итоге мы можем иметь такую схему:

Canvas 2

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

Исходя из опыта, добавлю — пусть дашборды дублируют данные, но каждый дашборд должен отвечать только на один-два вопроса, которые тесно связаны между собой (чтобы не дублировать всё подряд). Много графиков замыливают глаз, и, в итоге, вы можете либо вообще не смотреть ни на что, либо не видеть проблему. Лучше два необходимых графика, чем 20 необязательных в рамках решения конкретной задачи. Мы же все люди, мы не можем держать в голове горы информации, поэтому в наше время чаще всего надо знать, что вы хотите знать и видеть.

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

P.S. большое спасибо Александру Иванову (@alxschwarz) за правки.