1. Что было неудобно? И для чего это всё?

Изначально я занимался одним проектом со стороны тестирования в роли старшего тестировщика. У нас микросервисная архитектура — около 15 сервисов хранится в Git. Для тестирования на стенде нужно развернуть примерно 5–7 сервисов за один релиз. Всего стендов два, и после тестирования их же нужно деплоить в продакшн.

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

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

Поэтому мне приходилось делать так: заходить в каждый проект, открывать репозиторий сервиса, искать меню «Operate», затем «Environments» и там уже смотреть нужный стенд. И так — для каждого сервиса при деплое на тестовый стенд, при обновлении в продакшн или во время тестирования.

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

2. Как было по умолчанию?

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

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

3. Почему выбрал Superset?

Несмотря на это, периодически хотелось видеть нужный мне срез сервисов на стенде сразу, ане ходить каждый раз по списку в Git. Ранее что‑то подобное видел в разных системах мониторинга. Поинтересовался, что есть в наличии у разработки и девопсов. Из доступного и уже используемого ПО в компании был Superset (BI‑платформа с открытым исходным кодом, служащая для визуализации данных и аналитики бизнеса — из вики). Ранее не сталкивался, но альтернатив не было. Посмотрел, как можно в нём отображать информацию — строить красивые графики, таблички и т. д. Сформировал требования, отдал в команду BI.

4. Как создавал дашборд в Superset?

Процесс состоял из нескольких этапов:

1) Настроить интеграцию Supeset и БД Git

Сделал через запрос в техподдержку.

2) Написать запрос, который вытаскивает необходимые данные из БД

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

3) Вставить запрос в Superset и вывести его в дашборд

Здесь мне помог админ BI. Мы прошли несколько итераций, связанных с особенностями именно Superset и настройкой дашборда. Например, запрос к базе данных выполняется без ошибок, а на дашборде отображается неправильно или выглядит не так, как хотелось бы. В течение недели мы решили эти вопросы.

4) Настроить доступы для пользователей

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

5. Использование дашборда

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

Список могу фильтровать по любому значению любого столбца (настраивается в Superset).

В гите проставляю метки (topics) для фильтрации по проекту.

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

Сейчас им пользуются в обязательном порядке как тестировщики при деплое на стенды qa, так и релиз-менеджеры и разработчики при деплое на прод. Это происходит в реальном времени, статус меняется сразу, виден весь список сервисов с тегами, средой установки, датой установки, тем, кто задеплоил, и то чем пользуются наиболее часто. При желании можно посмотреть и другие параметры.

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

6. Что дальше?

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

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

Дашборд Superset для просмотра статуса деплоя сервисов Git