Дашборд

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

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

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

На картинке слева как раз такой дашборд. Это панель с различными приборами, которые показывают скорость, топливо, температуру охлаждающей жидкости. В современном автомобиле есть индикаторы, которые показывают, все ли хорошо с машиной, или же там загорается лампочка 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 8125echo "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 раз один поставил, то и я тоже, а осознанные.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Привет, меня зовут Владимир Шилов, я руководитель направления в департаменте анализа данных Ростелекома. В мае 2019 года я пришёл в команду Business Intelligence (BI) и одной из первых задач была реализация отчётности по анализу посещаемости отчетов во всех BI-инструментах, установленных в компании.

Решение этой задачи позволило собрать любопытную статистику и сделать выводы о востребованности BI-инструментов в Ростелекоме. В этой статье я хочу поделиться следующими результатами нашего анализа:

Какие BI системы наиболее востребованы в реалиях крупной компании;
Какие критерии влияют на внутреннюю популярность решения;
Какие современные тенденции пользовательского поведения можно наблюдать внутри компании и какие вопросы будут стоять перед ИТ-подразделениями в ближайшее время.

С чего всё началось: реализация решения по анализу используемости BI систем

Начну с общего описания ситуации и подходов к сбору информации. У нас в компании целевыми BI-системами являются:

1. Oracle BI
2. Microsoft analysis services
3. Microsoft Power BI
4. Qlik Sense
5. Форсайт

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

Для сбора информации об использовании инструментов было разработано специализированное решение, подход к реализации которого можно представить в виде последовательности шагов:

1. Провести анализ логов BI-систем по запуску отчётов;
2. Спроектировать модель витрины данных;
3. Разработать ETL;
4. Реализовать отчет в Power BI;

Решение получилось примерно следующим:

Очевидно, что любая разработка в крупной компании с некоторой бюрократией превращается в нечто большее, чем просто Возьми и сделай! Ты же мужик! и выполнение простого алгоритма из четырёх шагов. Я довольно сильно погряз в разработку архитектурного решения и согласования его с архитекторами, а также предоставления доступов к логам и ETL. В этой статье описывать свои трудности я детально не буду и сконцентрируюсь на конечном результате.

Для начала предлагаю рассмотреть каждый BI-инструмент в отдельности.

Oracle BI

На Oracle BI реализовано подавляющее большинство отчётности в виду того, что Oracle BI является самым старым инструментом и у него почти не было альтернативы очень долгое время. Ниже представлены графики динамик по следующим показателям:
Количество используемых уникальных отчётов за период;
Количество уникальных пользователей.

На основе второго графика динамики уникальных пользователей можно сделать вывод, что аудитория BI-системы стабилизировалась и сильного роста в 2020 году не наблюдается. Этому есть ряд причин:
Доступ к отчётности требует согласования, а прозрачность процесса предоставления доступа очень низкая;
Новые предметные области появляются очень редко;
Нет возможности создавать дашборды с аналитикой.

Analysis services

Microsoft Analysis services в компании это тоже достаточно распространённый инструмент, что во многом обусловлено удобной для пользователей работой в Excel. Именно этот инструмент получил наибольшее распространение в компании: он даже более популярен в МРФ (макрорегиональных филиалах), чем в корпоративном центре. Это можно увидеть на следующей диаграмме по уникальным пользователям в разрезе территорий за последние 12 месяцев:

Ниже представлены графики динамик по следующим показателям:
Количество используемых уникальных OLAP-кубов за период;
Количество уникальных пользователей.

Рост количества используемых OLAP-кубов за последний год не наблюдается, а рост аудитории в BI-системе нестабильный со значительными всплесками. У такой статистики несколько причин:
OLAP-кубы в основном дорабатываются, а новые кубы появляются очень редко;
BI-система больше предназначена для аналитиков, умеющих работать с данными, и она сложно продается широкой аудитории;
Доступ к отчётности требует согласования с владельцем OLAP-куба.

Power BI

BI-система Power BI от Microsoft появилась самой последней в стеке инструментов компании, но именно к этой системе сейчас приковано самое большое внимание со стороны бизнеса по следующим причинам:
Базовый набор визуализаций имеет хороший дизайн;
Лицензирование осуществляется по ядрам на сервере, отсутствует лицензирование по пользователям;
Скорость разработки отчётов довольно высокая, но стоит отметить, что на полный цикл разработки это не сильно влияет.

Ниже представлены динамики показателей аудитории и количество отчётов, которые она использует:

Стоит отметить, что при относительно низком росте количества используемой отчётности аудитория продолжает расти. Это связанно в большей степени с тем, что доступ к отчётам предоставляется без выделения лицензий на каждого пользователя и изначально нет никаких ограничений по доступу, то есть оформлять заявку не нужно. Уже сейчас наблюдается тенденция перевода отчетов с Qlik sense на Power BI именно потому, что новые пользователи подключаются бесплатно.

Qlik sense

Qlik sense была первой корпоративной BI-системой с возможностью реализации полноценных дашбордов. Именно с Qlik sense связан переход от предоставления табличных данных к графическим визуализациям в компании.
Ниже представлены графики динамик по следующим показателям:
Количество используемых уникальных отчётов за период;
Количество уникальных пользователей.

Казалось бы, перед нами современный BI-инструмент с высоким спросом, в котором можно создавать красивые решения, но сильного роста отчётности по сравнению с Oracle BI и Analysis services мы не наблюдаем. Тут есть несколько причин, влияющие на аудиторию и количество новых отчётов:
Лицензия на одного пользователя стоит существенных денег, и поэтому бизнес отказывается заказывать отчетность в Qlik sense;
Длительный период реализации отчётов от подготовки данных до реализации не позволяет быстро перенести все бизнес-процессы на новый инструмент.

Теперь поговорим про инструменты Self-service.

Self-service инструменты

Qlik sense self-service

В ноябре 2019 для бизнеса мы развернули self-service и предложили бизнесу реализовывать свои отчеты на своих источниках самостоятельно. С точки зрения лицензирования было одно изменение разработчики лицензируются отдельно. С лицензиями пользователей изменений не было по причине того, что сервера были объединены в один кластер и лицензии, соответственно, тоже.
Графики динамик количества запускаемых отчётов и уникальных пользователей в недельной динамике представлены ниже:

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

Power BI self-service

Вот мы и дошли к самому интересному. Power BI self-service появился примерно в то же самое время, что и Qlik Sense self-service, но у данных систем есть одно существенное отличие в лицензировании. Для подключения команды разработчиков от бизнеса в Power BI self-service надо разово заплатить за лицензию на 2 ядра, что примерно равняется 35 лицензиям пользователей в Qlik sense, но лимита на пользователей в Power BI нет.

То есть бизнес-подразделение разово платит за одну лицензию и получает существенные возможности по реализации отчётности для большой аудитории. Разумеется это позитивно повляло на показатели используемости данной системы, стоит отметить, что цена вхождения BI-разработчика в разработку базовых отчетов очень низкая.
Ниже представлены динамики показателей аудитории и количество отчётов, которые она использует:

Ещё более наглядно всё выглядит если показать все рассматриваемые системы вместе:

Какие критерии влияют на развитие отчетности?

В части развития отчетности в BI-системах стоит выделить следующие особенности, которые описаны в таблице:

Исходя из результатов нашего анализа именно критерии, описанные в таблице, оказали самое большое влияние как на скорость создания новой отчетности, так и на востребованность отчетности пользователями компании. А ключевым фактором успеха Power BI self-service стала политика лицензирования и его условная бесплатность для разработчиков на стороне бизнеса.

Заключение

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

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

Несмотря на то, что у ИТ сейчас нет однозначных ответов на эти вопросы, очевидно, что бизнес уже сделал свой выбор в пользу Self-service инструментов, и на эти вопросы нам придется отвечать. Будем рады присоединиться к обсуждению в комментариях. О том, какие решения мы нашли для self-service контура Ростелекома мы расскажем вам в наших будущих статьях.

Статья подготовлена командой управления данными Ростелекома

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

Застройщики сталкиваются стакими проблемами:

• разрозненные данные вотчётности;

• беспорядок вCRMи, как следствие, потеря лидов;

• при масштабировании бизнеса иотдельных проектов теряется контроль над тактическими задачами;

• человеческий фактор впроцессе обработки информации приводит кпотере данных;

• нет единой системы бизнес-аналитики.

Застройщикам важно видеть, что происходит накаждом уровне воронки продаж, как работает каждый офис икаждый менеджер.

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

При размещении рекламы всоциальных сетях инарекламных площадках важно отслеживать еёэффективность, чтобы оптимизировать рекламный бюджет.

Мыразработали динамический отчёт застройщика вPower BI.

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

Сводный отчёт

Сводный отчёт по всем объектам дашборд для топ-менеджеров. Он показывает ситуацию по продажам в целом.

Сверху набор карточек с ключевыми показателя за выбранный отчётный период:

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

Диаграмма воронки продаж позволяет оценить качество привлекаемых лидов:

Диаграмма снакоплением показывает объёмы продаж идостигнутый результат:

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

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

Внизу представлена таблица сдетальной информацией поколичеству заключённых ирасторгнутых договоров иброней, что позволяет видеть динамику пообоим показателям (подписание/расторжение), своевременно принимать меры вслучае необходимости, строить прогнозы попереводу договоров встатус Подписано.

Отчёт потелефонным звонкам

Дашборд предназначен для руководителя колл-центра.

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

Диаграмма позвонкам показывает общую картину работы колл-центра иинтенсивность звонков заотчётный период:

Отдельно представлена информация понепринятым ипотерянным (когда менеджер неперезвонил клиенту) звонкам.

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

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

График подлительности звонков позволяет проанализировать работу менеджеров:

• насколько оперативно отвечают;

• как долго разговаривают склиентом;

• почему пропускают входящие звонки.

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

Digital

Дашборд предназначен для менеджеров порекламе.

Надашборде представлена динамика стандартных метрик интернет-рекламы заотчётный период. Панель фильтров позволяет более детально проанализировать каждый канал.

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

Сделки

Дашборд для отдела продаж ибухгалтерии.

Панель карточек вверху показывает сводную информацию позаключенным сделкам:

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

Диаграмма потипам оплат позволяет выявить предпочтения клиентов иоценить объёмы длинных денег (рассрочка/ипотека):

Внизу таблица сдетальной информацией попроданным объектам:

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

Как дашборд помогает застройщику

Отчёт застройщика вPower BIпредоставляет существенные преимущества для анализа продаж:

1. Информация изразных источников собрана водном отчёте.

2. Гибкая система фильтров позволяет индивидуально выбирать отчётный период, детализировать информацию понеобходимым параметрам.

3. Засчёт ежедневного обновления данных вотчёте можно получать актуальную информацию.

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

5. Вместо громоздких таблиц наглядные диаграммы играфики. Они позволяют проще воспринимать иинтерпретировать информацию.

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

   ---

Поверь своим глазам и тому что видишь на Дашборде

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

Каждый менеджер или Product Owner досконально знает свою область и любые отклонения могут вызвать вопросы. Поэтому к достоверности дашбордов и метрик предъявляются повышенные требования. А мы в команде Аналитики стремимся идентифицировать и исправить проблемы раньше, чем они попадут в отчетность.

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

Уверенность в актуальности витрин данных

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

• К 10 утра каждого дня у нас рассчитаны витрины за полные прошлые сутки

• Чтение из источников идет в ногу со временем и отставание не превышает 8 часов

• Все источники продолжают слать лог изменений в DWH

Выходит, задача QA формулируется следующим образом:

• Покажи мне все витрины данных, в которых время актуальности отстает от ожидаемого

Реализация для Хранилища:

• В конфигурационном файле .yml добавим параметр freshness:

freshness:   warn_after: {count: 4, period: hour}   error_after: {count: 8, period: hour} loaded_at_field: "__etl_loaded_at"

• Для каждого теста будет выполнен простой шаблонизированный SQL-запрос:

select max({{ loaded_at_field }}) as max_loaded_at, {{ current_timestamp() }} as snapshotted_atfrom {{ source }}where {{ filter }}

• Собранные метрики можно визуализировать в сводный отчет:

Мониторинг метрик расчета Витрин Данных

Неминуемо при проектировании сложных витрин, кубов, будут возникать проблемные места:

• Баги и просчеты в формулах расчета метрик

• Неожиданные данные (edge cases), которые могут нарушать заложенную логику

• Бутылочное горлышко (bottleneck) в операциях расчетов

Они могут привести к серьезным последствиям:

• Ошибки: Таймаут, Out of Memory, Disk Full

• Замедление всего пайплайна загрузок и расчетов и нарушение SLA

Для контроля можно собирать следующие метрики:

• Время, затраченное на формирование витрины + его динамика (скачки времени расчета)

• Потребление ресурсов CPU

• Потребление ресурсов диска и сети - IO, network

Лидеры этого рейтинга становятся первыми кандидатами на оптимизацию и рефакторинг.

Задача формулируется следующим образом:

• Покажи мне те витрины, формирование которых требует излишне много ресурсов

Реализация для Хранилища:

• Снять метрики расчетов витрин

• Отрисовать дашборд

• Настроить алерты

+pre-hook: "{{ logging.log_model_start_event() }}"+post-hook: "{{ logging.log_model_end_event() }}"

Валидация схемы данных в основе тестирования

Современные Хранилища предполагают структуру, строгую типизацию, поколоночное хранение и компрессию данных. Структура данных суть схема - набор атрибутов, их типов, ограничений, например, PRIMARY KEY, FOREIGN KEY, NOT NULL, UNIQUE.

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

Какие базовые ожидания можем иметь относительно данных:

• Есть ли в данных пропуски (NULL) там, где их быть не должно?

• Какова атомарность моих данных (UNIQUE ID строки)?

• Как таблицы соотносятся между собой (PRIMARY - FOREIGN KEYS)?

• Есть ли записи, выходящие из списка допустимых значений(ACCEPTED VALUES)?

Задача QA формулируется следующим образом:

• Покажи мне те витрины и источники, данные в которых нарушают наши ожидания

Реализация для Хранилища:

• В конфигурационном файле .yml добавим параметр tests:

- name: dim_cars     description: Wheely partners cars.     columns:         - name: car_id           tests:               - not_null               - unique         - name: status           tests:               - not_null               - accepted_values:                   values: ['deleted', 'unknown', 'active', 'end_of_life', 'pending', 'rejected'                           , 'blocked', 'expired_docs', 'partner_blocked', 'new_partner']   

• Для каждого теста будет выполнен простой шаблонизированный SQL-запрос

-- NOT NULL testselect count(*) as validation_errorsfrom "wheely"."dbt_test"."dim_cars"where car_id is null -- UNIQUE testselect count(*) as validation_errorsfrom (   select       car_id   from "wheely"."dbt_test"."dim_cars"   where car_id is not null   group by car_id   having count(*) > 1) validation_errors -- ACCEPTED VALUES testwith all_values as (   select distinct       status as value_field   from "wheely"."dbt_test"."dim_cars"),validation_errors as (   select       value_field   from all_values   where value_field not in (       'deleted','unknown','active','end_of_life','pending','rejected','blocked','expired_docs','partner_blocked','new_partner'   ))select count(*) as validation_errorsfrom validation_errors

Бизнес-логика тоже подлежит проверке

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

Несколько простых примеров:

• Сумма заказа не может быть отрицательной

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

• Пользовательская сессия заканчивается только одним заказом, либо прерывается

• Комиссия не превышает заданного %

Резкие скачки сумм (и вверх и вниз), неправдоподобные графики и значения метрик чаще всего становятся объектом пристального внимания на дашбордах и в отчетах.

Задача QA формулируется следующим образом:

• Покажи мне те витрины данных, в которых нарушены бизнес-правила.

Реализация для Хранилища:

• В терминах SQL выразить ту ситуацию, которая описывает нарушение правил

• Сформировать тест на базе SQL-запроса

• Тест считается пройденным (PASSED) если запрос возвращает 0 записей, и проваленным (FAILED) если записей >= 1

Continuous Integration на страже мастер-ветки DWH

Хорошо, идём дальше. Над DWH мы работаем совместно всей командой. Это подразумевает скоординированность и согласованность действий. Однако нередки случаи ошибок, просчеты, невнимательности на этапе разработки, которые приводят к ошибкам в PROD-окружении после PR Merge:

• Доработка в одной части может послужить причиной ошибки в другой части

• DEV-окружение инженера может отличаться от PROD-окружения

• Запуск неоптимального кода на всех данных может привести к ошибке (например, Out of Memory)

Решение давно придумано - это использование практик тестирования в рамках Continuous Integration (CI). И его можно и нужно применять к данным!

Задача формулируется следующим образом:

• Минимизировать вероятность появления ошибок в master-ветке и PROD-окружении DWH после релизов.

Реализация для Хранилища:

• Подготовить окружение для CI (например, актуальная копия PROD-окружения, содержащая только 7 последних дней)

• Выполнить полный пересчет всех витрин и метрик без ошибок прежде чем дать возможность влить feature-ветку в master

Кросс-сверка состояния DWH и Источников

От Хранилища Данных мы ожидаем отображение актуального состояния (а также всей истории) источников данных:

• Наличие в DWH всех записей, которые присутствуют в источнике

• Точное соответствие значений атрибутов (статус, временные метки, метрики) один-к-одному

Мы хотели бы застраховаться от ситуаций, когда часть данных просто не попадает в Хранилище в силу технических причин, а также от потери изменений состояния записей (например, финализация статуса заказа или корректировка его стоимости).

Задача формулируется следующим образом:

• Убедиться в том, что Хранилище находится в консистентном (согласованном) с источниками состоянии.

Эта задача имеет одну из самых сложных реализаций и может стать темой отдельной статьи, судите сами:

• Определить набор атрибутов, подлежащих верификации: идентификаторы, внешние ключи, измерения (страна, город, статус), метрики (стоимость, продолжительность, комиссия).

• Выгрузить все строки из источника, актуальные на текущий момент

• Загрузить строки в DWH и подготовить логику сверок

• Настроить визуализацию и уведомления

Визуальное представление с возможностью drill-down до уровня атомарных записей:

Собирая всё в единый пазл

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

• Регулярный мониторинг, сбор и анализ метрик

• Continuous Integration and Testing

• Настройка уведомлений и алертов для команды

• Проактивная работа над устранением инцидентов и причин ошибок

• Управление ожиданиями пользователей в случае возникновения проблем (У нас всё под контролем)

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

Обширный набор тем, связанных с обработкой, хранением, тестированием данных изучается в рамках курса Data Engineer в OTUS, запуск которого состоится уже совсем скоро.

Как преподаватель курса я приглашаю вас 4 ноября в 20:00 на День Открытых Дверей курса Data Engineer. Приходите на вебинары в OTUS знакомиться со мной и другими экспертами, будем ждать.

Что почитать еще

Напоследок я оставлю вам несколько ссылок на смежную тематику для дальнейшего изучения:

1. Data Build Tool или что общего между Хранилищем Данных и Смузи - обзор DBT на русском языке

2. The farm-to-table testing framework - комплексный подход к тестированию качества данных

3. Tests - Related reference docs - раздел документации DBT, посвященный тестированию

4. How to get started with data testing - тред на dbt discourse с обсуждением по теме

5. Data testing: why you need it - взгляд на преимущества тестирования данных

6. Manual Work is a Bug - несколько слов о принципах автоматизации и DRY