15 марта 2021 г.

Евгений Рюмин

После того, как я посмотрел сериал «Кремниевая долина», меня осенило: понял, насколько замечательны дашборды и им подобные средства визуализации данных! Конечно, я использовал дашборды и раньше, но только после просмотра сериала осознал, до какой степени это универсальный и полезный инструмент для ИТ-команд!

Вот лишь один из эпизодов сериала «Кремниевая долина»: в четвертом сезоне команда Ричарда Хендрикса, адаптировав алгоритм сжатия для видеочата, обнаружила взрывной рост популярности их приложения. С помощью дашборда (в России эти средства визуализации еще называют информационными панелями) специалисты в реальном времени увидели, как не по дням, а по часам увеличивается их пользовательская база. Участники команды смотрели на различные метрики, и это вселяло в них позитив и уверенность. Специалисты Хендрикса убедились в том, что их проект нужен людям. С одной стороны, это их очень вдохновило, но с другой — вызвало стресс, так как рост был взрывным и для его поддержки требовалось много ресурсов. Таким образом, благодаря дашборду команда уже на ранней стадии поняла всю серьезность происходящего.

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

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

Кто и что может отслеживать?

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

Среди активных пользователей дашбордов в нашей компании StormWall — технический директор, сетевые инженеры и другие коллеги. Мы контролируем нагрузку на различные ресурсы и системы, анализируем текущую динамику DDoS-атак.

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

В проектах разработки с помощью дашбордов полезно выявлять и отслеживать различные аномалии. Распространенным сценарием является «отлов» утечек памяти — ошибок кодирования, из-за которых программные модули не освобождают ставшие ненужными блоки оперативной памяти. В контейнерных средах такие ситуации обычно заканчиваются тем, что оркестратор перезагружает контейнеры, в которых уже не осталось свободной памяти. Выявить эти ошибки, анализируя логи (системные журналы), скорее всего, не получится, но зато вы всё поймете, взглянув на дашборд: если изучить графики запуска контейнеров, например за неделю, то окажется, что эти графики имеют пилообразный вид — верный признак того, что контейнеры регулярно перезапускались. Одна из наиболее вероятных причин «пилы» — утечки памяти в ПО, работающем на этих контейнерах.

С помощью дашборда можно легко сравнивать различные периоды жизни проекта разработки. Например, в процессах CI/CD при каждом очередном развертывании вы можете записывать в базу данных его дату и список внесенных в очередной релиз изменений, а на дашборде — визуализировать эту информацию в виде линий показателей каждого вашего релиза. И если вы увидите, что среднее время ответа сервера увеличилось, то сможете детализировать данные и понять, после какого релиза произошли негативные изменения.

Чтобы добиться высокой производительности создаваемых приложений, обычно используют запись событий в логах и их анализ. Кстати, визуализировать и анализировать логи удобно, например, используя стек инструментов ELK (ElasticSearch, LogStash, Kibana и др.).

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

Приведу пример из собственной практики. Однажды нам с коллегами пришлось разбираться с новой системой, которая перенаправляла часть запросов пользователей на уровне back-end в унаследованную с «древних» времен программу. Традиционно уделяя пристальное внимание отладке, мы сделали так, что все значимые события записывались в лог. И вот, проигрывая некоторые сценарии, мы обратили внимание на странную аномалию: происходила существенная задержка небольшой части запросов, в то время как остальные обрабатывались быстро. Мы стали разбираться в деталях: построили с помощью ELK дашборд с визуализацией времени отклика и обнаружили, что среднее время было в норме (не больше 3-4 секунд), но максимальное время отклика по непонятным пока причинам составляло около 30 секунд. Что еще удивительнее, максимальное время отклика наблюдалось каждые полчаса. Детализировав логи, мы выяснили, что запросы, порождающие 30-секундные задержки, шли в унаследованную систему. Связавшись с ее разработчиком, мы узнали, что каждые полчаса система производит выгрузку данных и пока она идет, все запросы к системе ожидают в очереди ее окончания. В свою очередь, в нашей системе таймер ожидания ответа был установлен на 30 секунд: если за это время запрос не обслуживался, то фиксировалась ошибка. Таким образом, нам удалось выявить причину аномалий, которую едва ли удалось бы обнаружить без создания дашборда.

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

Дашборды «для своих»: на чем их делать?

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

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

Оптимальным инструментарием для создания дашборда, предназначенного для ИТ-команд, в большинстве случаев будет Grafana — платформа компании Grafana Labs с открытым исходным кодом для визуализации, мониторинга и анализа данных. С ее помощью можно быстро, легко и с небольшими затратами создать вполне функциональный дашборд с современным дизайном, кастомизировать его и интегрировать со всеми необходимыми источниками данных.

В Grafana имеются возможности добавления различных графиков, плагинов и адаптеров к источникам данных. Эта система позволяет быстро добавлять или удалять графики, использовать другие способы визуализации, подключаться к различным источникам данных. Около 10 адаптеров к данным идут в дистрибутиве, множество других можно найти в маркетплейсе Grafana.

Для мониторинга и визуализации происходящего в проектах разработки целесообразно применять GitLab — веб-инструмент с открытым исходным кодом, созданный специально для сопровождения жизненного цикла DevOps.

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

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

Требования к дашбордам

Первое и самое главное требование к дашбордам для ИТ-команды (не для ее клиентов) — дешевизна разработки и поддержки.

Кроме того, дашборд должен быть адаптивным и обладать как минимум базовыми функциями: указание диапазона значений показателей (например, временного периода) и автоматическое обновление значений с определенной периодичностью и/или при наступлении каких-то событий. Если говорить о периодичности, то приемлемое время обновления составляет 5 секунд. Если же оно больше, то об отображении информации для ИТ-команды в реальном времени, скорее всего, придется забыть.

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

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

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

Дашбордируйте это!

Источник: Евгений Рюмин, руководитель отдела разработки компании StormWall