Сила дашбордов

Всем привет! Меня зовут Егор Иванов, и я специалист по автоматизации тестирования. Довольно долгое время до этого я проработал в различных компаниях из сферы BI. Я обожаю визуализацию данных и считаю, что без нее невозможно строить рабочие процессы и уж тем более процессы в тестировании. Поэтому хочу, чтобы ее использовали как можно больше людей, так как визуализация данных очень важна, а в виде дашбордов она еще и прекрасна.

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

Многие из нас видят дашборд каждый день. Он пришел к нам из транспорта — это приборная панель автомобиля.

Слева - дашборд автомобиля, справа - информационный дашборд в IT
Слева - дашборд автомобиля, справа - информационный дашборд в IT

На картинке слева  — как раз такой дашборд. Это панель с различными приборами, которые показывают скорость, топливо, температуру охлаждающей жидкости. В современном автомобиле есть индикаторы, которые показывают, все ли хорошо с машиной, или же там загорается  лампочка «Check engine», и вам надо что-то проверить.

Другой пример (картинка справа) — это информационный дашборд в IT, который показывает, как ведут себя пользователи того или иного продукта. Он тоже представляет собой панель с различными индикаторами. Схожесть между двумя дашбордами не только в том, что это сущности с индикаторами, но и в том, что обе сущности очень важны. Вряд ли вы сядете за руль автомобиля без всех этих индикаторов, собранных на одной панели. А если сядете, то наверняка  случайно нарушите скоростной режим и не заметите, когда закончится бензин.

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

Определение дашборда

Дашборд — это визуальное представление важной информации. Данные в нем сгруппированы и расположены таким образом, чтобы их изменения можно было легко и быстро отслеживать. Обратите внимание, что здесь заключается главное требование к дашборду — информацию должно быть легко отслеживать. Когда вы будете создавать дашборд, учитывайте это и делайте так, чтобы дашборд был понятен, а не чтобы это была просто панель со вставленными визуализаторами.

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

  • Операционный дашборд предназначен для быстрого предоставления пользователям критически важной информации. Помогает пользователям быть быстрыми, активными и эффективными.

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

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

Наш первый дашборд

Чтобы познакомить вас с одним из наших первых дашбордов, расскажу про процессы, информацию по которым он отображает.

Это процессы, в которых участвует моя команда — группа интеграционного тестирования. Чем мы занимаемся? «ЮMoney» имеют микросервисную инфраструктуру, и когда у нас с каждой фичи срезается релиз, на ней проводятся регрессионные тесты, а потом он попадает к нам, чтобы мы проверили, насколько реально этот релиз может попасть на продакшен.

Мы имеем в своем арсенале набор тестовых схем, которые копируют прод. На этих схемах — всегда свежие сервисы. И мы накатываем этот сервис на наши схемы, прогоняем на нем тесты. Если всё ОК, этот релиз идет дальше.

Как всё это выглядит с нашей стороны? В Jira прилетает тикет на проведение интеграционных тестов. Чтобы посмотреть тикет, есть канбан-панель, и флоу подразумевает четыре статуса: «открытый», «в работе», «в ожидании», «закрытый». «В работе» — это когда гоняются тесты. «В ожидании» — это если что-то пошло не так и требуется ручное вмешательство.

Еще у нас есть такой инструмент, как Autorun, который и проводит весь процессинг тикета. Подробнее про это можно прочитать в другой нашей статье тут.

После того, как Autorun берет в работу тикет в Jira, ему нужно выделить отдельный стенд для запуска. Это позволит не прогонять на одном стенде одновременно несколько тестов и заблокировать другой стенд, на котором уже проводятся работы. Для этого у нас есть инструмент под названием Locker.

Autorun обращается к этому инструменту, чтобы получить схему. У Locker тоже есть UI. То есть стенд может быть заблокирован или доступен, и с каким-то комментарием. Если есть комментарий, стенд блокируется.

После того, как Autorun сходит к Locker, он обращается к еще одному инструменту — Pinger, чтобы понять, насколько схема живая. С точки зрения UI-интерфейса, Pinger — это тоже мини-дашборд, на котором представлены все наши сервисы и их статусы: зеленые, если всё в порядке, или красные, если что-то не так. Autorun через API запрашивает у сервиса информацию. Если стенд не в порядке, он сообщает нам об этом и не запускает на нем тесты.

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

Но иногда что-то может пойти не так. Для таких случаев у нас есть дежурный — кто-то один из нашей команды. Он должен разобраться, что именно не так. Раньше для этого ему приходилось идти по всем трем UI, а в случае с Locker и Pinger — еще и по пяти тестовым стендам, чтобы посмотреть, все ли хорошо на всех них. Это занимало время, а хотелось понимать причину сразу же.

Что мы для этого сделали? Конечно же, построили дашборд. Первым дашбордом была обычная HTML-страничка, которая скриптом ходила в API инструментов, запрашивала у них самую важную информацию и отображала ее.

Что представляла из себя самая важная информация? Из Jira мы брали только количество задач в каждом из статусов, из Pinger — только красные компоненты, из Locker — статусы схем и пояснение причины лока. То есть фактически мы ничего нового не изобрели, просто сделали общий UI и назвали его «дашборд дежурного», а пользу он принес большую. Скорость понимания того, что происходит, увеличилась в разы. Мы вывели этот дашборд на телевизор в кабинете, и теперь на вопрос, что сейчас происходит, может ответить даже человек, который случайно зашел в кабинет. И для этого ему не надо проводить никаких манипуляций с остальными инструментами.

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

Он значит, что со всеми стендами все отлично, новых задач нет — и можно идти на обед☺

Все бы это хорошо, но на каждый случай  дашборд не напишешь. Нужен был инструмент для масштабирования и отображения различных данных. И мы решили использовать то, что у нас уже было, — Grafana.

Многие с этим инструментом знакомы, зачастую он используется для отображения состояния продукта — его нагрузки либо состояния стендов. А мы хотели визуализировать всю информацию, которая нам поступает.

На самом деле, для построения дашбордов есть множество решений, но некоторые из них входят в целые BI-платформы наподобие ClickView, а некоторые облачные решения, например Google Data Studio, нам не подходят. А Grafana у нас уже была и использовалась в команде мониторинга.

На всякий случай повторю, что такое Grafana.

Это инструмент для построения дашбордов на основе различных источников — от PostgreSQL до Google Sheets. В нашем случае источником был Graphite. Чем он нам был удобен? У нас не было готового хранилища знаний, где лежали бы все нужные данные. Мы сами пушим данные. Соответственно, Graphite — удобное хранилище для таких временных метрик.

Как происходит отсылка этих метрик? В формате StatsD мы отправляем их в Telegraf. Формат такой: название метрики, ее тип и значение. Telegraf за 30 секунд агрегирует метрики в зависимости от типа, который мы передали, и потом отсылает их в хранилище Graphite.

На самом деле, мы даже не особо переживаем и отправляем метрики по UDP, потому что на каждом нашем хосте есть инстанс Telegraf и до него 100% дойдет. Плюс у нас не настолько критичные технические метрики, которые мы отображаем в дашбордах, чтобы переживать, если они не дойдут.

Метрики StatsD бывают четырех типов, которые покрывают полную потребность:

  • g (Gauge) — в течение 30 секунд Telegraf отправляет только значение последней метрики, которую получил;

  • с (Count) — все полученные за интервал данные будут сложены, то есть Telegraf суммирует все, что к нему пришло;

  •  s (Set) — отправляет уникальные значения, пришедшие за это время;

  • ms (Timer) — отправляет множество разных метрик по таймеру (среднее время выполнения, count, max, min и т.д.).

Сами метрики отсылаются так же просто. Если у вас Java, Java StatsD Client — в нем создаем сам клиент и через него отправляем метрики. Всё. Отправку из Java мы используем как раз в наших инструментах, содержащих данные, которые надо отослать. То есть Autorun может отправить данные о количестве пришедших задач. Состояние схем может отправлять Pinger.

import com.timgroup.statsd.StatsDClient;
import com.timgroup.statsd.NonBlockingStatsDClient;
public class Foo {
private static final StatsDClient statsd = 
        new NonBlockingStatsDClient("my.prefix", "statsd-host", 8125);
    public static final void main(String[] args) {
    statsd.incrementCounter("bar");
    statsd.recordGaugeValue("baz", 100);
    statsd.recordExecutionTime("bag", 25);
    }
    }

https://github.com/tim-group/java-statsd-client

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

echo "my.prefix.bar:1|c" | nc -w 0 -u statsd-host 8125
echo "my.prefix.baz:25|g" | nc -w 0 -u statsd-host 8125

После отправки всех метрик построить дашборд просто. Мы добавляем новую панель в Grafana, выбираем подходящий визуализатор и создаем запрос, по которому хотим отобразить данные. Потом немного работаем с панелькой — выставляем правильные значения по осям, красиво рисуем, включаем/выключаем легенду и так далее. Повторяем это действие нужное количество раз и получаем дашборд. Дальше — о том, какие дашборды мы получаем.

Дашборд — визуализатор метрик

Самым первым у нас был дашборд по метрикам нашей команды. Так как основной процесс у нас  — это интеграционное тестирование, мы взяли метрики, относящиеся к этому процессу:

  • количество релизов;

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

  • поломанные релизы, в которых была найдена ошибка;

  • пропущенные релизы, для которых была проверена только корректность развертывания сборки в тестовой среде (тестов нет).

Мы решили посмотреть, что будет, если построить такой дашборд и смотреть на него каждый день. Какие плюсы мы от этого получили?

Самое интересное — мы поняли, что у нас неправильно считаются метрики. Все они высчитывались по формулам и отправлялись руководству раз в спринт. При ежедневном просмотре мы заметили, что где-то стало выскакивать больше 100%, а где-то поняли: «Ага, были релизы без тестов, а у нас из-за этого почему-то процент просел, хотя этого не должно было произойти». Выяснилось, что у нас ошибка в формулах, и это удалось заметить благодаря тому, что мы просто стали смотреть за данными.

Как само собой разумеющееся — увеличилась скорость реакции на ухудшение. Когда вы видите каждый день эти данные и понимаете, что сегодня что-то идет хуже, чем вчера, а если это еще в течение недели продолжается, — конечно же, вы быстрее реагируете на это.

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

Дашборд — мотиватор

Помимо того, что все стали видеть проблемы, — все захотели, чтобы в их дежурство было 100% AutoPass. В наше дежурство было много релизов, и мы их хорошо выдержали. Так появилась мотивация устанавливать рекорды.

Мы проверили, насколько дашборд может быть реальным инструментом для мотивации. И нашли проблему, где нам не хватает мотивации — в проведении code review. Самописный бот назначает ревьюеров, коллег из моей команды, и мы проводим ревью тестов и наших инструментов для автоматизации. При этом ревьюер не один, иногда даже не два, а одного «approve» обычно достаточно. То есть если один человек поставил «approve», значит, все хорошо. Тут может получиться так, что кто-то вообще никогда не ревьюит и надеется, что это сделают другие. Чтобы это понять, мы построили дашборд и посмотрели, что изменилось.

Дашборд по активностям на ревью
Дашборд по активностям на ревью

Новый дашборд показывал активности ревьюеров: comments, approve, needs work. Такая визуализация меня сильно замотивировала. Я — «желтенький». По рисунку видно, что я более-менее часто ставлю approve, но, например, комментирую не так много. После этого я  старался ревьюить активнее.

Если раньше у нас б в pull request чаще всего стоял один «approve», то сейчас более чем в 90% случаях он стоит как минимум от двух человек. И это не случайные  «approve» — «раз один поставил, то и я тоже», — а осознанные.

Дашборд для анализа

Еще дашборд можно использовать  для анализа. Мы тестировщики и любим анализировать именно тесты.

Лично я больше всего люблю анализировать время выполнения тестов. Иногда кажется: «Ага, у нас тесты что-то очень долго выполняются…» Но как понять на самом деле, долго они выполняются или нет, если ты не знаешь, как они выполнялись вчера, позавчера или в течение года и как это соотносится с количеством тестов? На этот вопрос также сложно ответить без визуализации.

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

Анализ времени выполнения тестов
Анализ времени выполнения тестов

Выполнение наших тестов, которые включают в себя компиляцию и само исполнение тестов, в целом не менялось. По индикатору мы не вышли за целевое время. При этом даже тесты по фронтенду, наоборот, стали быстрее. Но время компиляции увеличилось. И получилось, что тесты могли бы проводиться гораздо быстрее — достаточно только вернуть ту компиляцию, которая была еще пару месяцев назад. Этот дашборд был создан недавно именно для того, чтобы ответить на вопрос: все ли у нас хорошо со временем прогона тестов?

В целом, когда хотим что-то улучшить, мы строим дашборд, наблюдаем за тем, как идут дела. Либо, если у нас уже есть про это метрики, то как дела идут сейчас и как шли раньше — нам уже понятно. Потом вносим изменения, ставим метку о том, что мы сделали, и дальше смотрим, не потеряем ли мы новые улучшения.

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

Дашборд для экономии времени

Например, у нас есть такая активность — разбор того, насколько хорошо у нас прогнались утренние тесты на подготовку данных. Есть такой механизм — мы заранее подготавливаем тяжелые тестовые данные. То есть пользователи с выпущенными карточками. Это занимает время, и в тест это загружать тяжеловато. Поэтому пул таких пользователей мы готовим утром. Данные готовятся на наших пяти схемах (тестовых стендах, которые участвуют в приемках). Плюс это не один и не два тестовых запуска. И утром по результатам всех этих прогонов прилетает целая куча писем: «На такой-то схеме прошло так-то», «На такой-то схеме прошло так-то». Точнее, раньше прилетали все эти письма — и было тяжеловато.

Как эту проблему решить? Можно сгруппировать все в один пайплайн, сделать так, чтобы все было в одном письме и, возможно, в нем же были какие-то решения. Но зачем придумывать тяжелое решение, если можно все сделать через дашборд? Мы сделали такое отображение по результатам тестов — и этот дашборд приходит одним письмом. Открыв его, сразу можно увидеть, что все хорошо.

Либо увидеть, что все плохо, сильно расстроиться и идти разбираться, почему так случилось.

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

Небольшое резюме

При внедрении дашборда мы получаем: 

  • инструмент для объективной оценки происходящего,

  • экономию времени при анализе,

  • дополнительную мотивацию,

  • новую информацию, которая раньше была незаметна,

  • множество данных для анализа в будущем.

И еще один плюс. По понятным причинам мы все работаем из дома, и всем хотелось понять, пошло у нас что-то хуже или нет. Для этого мы просто посмотрели на все наши дашборды и убедились, что ничего особо не изменилось. И раз так, то мы так же прекрасно можем работать в дистанционном режиме.

В заключение добавлю прекрасную цитату Джона Тьюки, американского математика, статистика, одного из основателей визуализации данных и статистического анализа:

«Изображение приобретает особую значимость, если оно позволяет углядеть в нем то, что мы не предполагали увидеть».

ЮMoney (Яндекс.Деньги)
Всё о разработке сервисов онлайн-платежей

Comments 3

    0
    Спасибо за статью, мотивирует на новые возможности мониторинга :)
    Заинтересовал «Дашборд — мотиватор».
    Каким образом данные из github (или любой другой хостинг) попадают в графану?
      0
      Наш бот, назначающий ревьюверов на pull request, слушает вебхуки от битбакета. Информация о действиях ревьювера получаем из хуков и отправляем в графану.
      0
      Спасибо!

      Only users with full accounts can post comments. Log in, please.