Главное о кейсе
PostgresPro — крупнейший в России поставщик программного обеспечения для управления базами данных PostgreSQL.
Продукт, над которым мы работали,— PostgresPro Enterprise Manager. Это панель управления и мониторинга кластеров баз данных.
В этом проекте нам удалось создать сложную многослойную архитектуру, которая открывает новые возможности для PostgresPro. Она позволит расширять функциональность Enterprise Manager сторонним разработчикам.
У нас получилось достигнуть гармоничного сочетания простоты графического интерфейса и гибкости командной строки.
____
PostgresPro is the largest provider of software for managing PostgreSQL databases in Russia.
The product we've been working on is PostgresPro Enterprise Manager. This is a dashboard for managing and monitoring database clusters.
We managed to create a complex multi-layered architecture that opens up new opportunities for PostgresPro. It will allow third-party developers to extend the functionality of Enterprise Manager.
We achieved a harmonious combination of the simplicity of the graphical interface and the flexibility of the command-line interface.
Как проект изменил жизнь пользователей
Проект совсем недавно вышел в продакшен, и мы ждём обратную связь от пользователей.
Мы ожидаем, что проект:
- Упростит процесс администрирования БД и будет экономить время дорогостоящим специалистам;
- Снизит порог входа в администрирование кластеров БД и упростит подготовку новых востребованных на рынке кадров;
- Потенциально ещё больше увеличит распространение экосистемы PostgresPro на рынке.
___
The project has recently been released, and we are waiting for feedback from users.
We expect that the project:
- Will simplify the process of database administration and will save time for expensive specialists;
- Will reduce the threshold for entry into the administration of DB clusters and simplify the training of new personnel in demand on the market;
- Potentially further increase the spread of the PostgresPro ecosystem on the market.
Бизнес-задача и ее решение
НАШИМИ ЗАДАЧАМИ БЫЛИ:
Создать интерфейс продукта;
Спроектировать архитектуру для интерфейса, которая позволит расширять функциональность дополнительными модулями-плагинами;
Обеспечить возможность отображения различного интерфейса для разных конфигураций продукта. Например, пользователь установил новый модуль, в интерфейсе появилась соответствующая функция.
Нам предстояло создать интерфейс для сложной системы. Этот интерфейс должен быть гибким: поддерживать расширение через плагины, которые разрабатывают сторонние специалисты. А сами плагины должны иметь возможность расширяться другими плагинами.
Аналогичных продуктов на рынке практически не представлено. Были похожие сервисы для других БД, но они не покрывали весь функционал, который нам нужно было реализовать. Поэтому этап аналитики был критично важен.
Чтобы разобраться в особенностях иерархии и взаимосвязей объектов мы построили множество mind-карт.
Кроме того, мы провели серию интервью с представителями целевой аудитории, чтобы понять привычные паттерны работы по администрированию БД.
Выяснили, что самая большая боль ЦА — постоянно отслеживать состояние всей инфраструктуры и мгновенно реагировать на инциденты.
Для того, чтобы узнать состояние системы, пользователи открывают программную строку и через неё выясняют статус сервера/инфраструктуры, получают ответ, запрашивают статус снова и т. д. Процесс долгий и неудобный.
Поэтому мы создали дашборд, на котором сразу можно понять состояние системы и ключевых ресурсов. Дашборд также отображал все критические состояния и отправлял уведомления пользователям без задержек по шаблону, который можно настроить в профиле.
Пользователи PostgresPro привыкли работать с командной строкой, поэтому нашей задачей стало создание интерфейса, который не вызывал дискомфорта при переходе на новый способ управления системой. Мы стремились минимизировать любые неудобства, сделав процесс более понятным и эффективным для будущих пользователей. Полученные инсайты упаковали в proof of concept — прототип в Figma.
____
KEY PROJECT TASKS:
Create a product interface;
Design an architecture for the interface that will allow clients to extend the functionality with additional plugins;
Provide the ability to display a different interface for various product configurations. For example, if a user installs a new module, the corresponding function will appear in the interface.
We had to create a UI for a complex system. This interface should be flexible: being able to support the extension through plugins developed by third-party specialists. And plugins should be able to be expanded by other plugins.
There is a lack of similar products on the market. There were look-alike services for other databases, but they did not cover all the functionality that we needed to implement. Therefore, the analytics stage was critically important.
To understand the features of the hierarchy and the relationships of objects, we have built a lot of mind maps.
In addition, we conducted a series of interviews with representatives of the target audience (TA) to understand the usual patterns of work on database administration.
We found out that the biggest pain of the TA is to constantly monitor the state of the entire infrastructure and instantly respond to incidents.
In order to find out the status of the system, users open the сommand-line and request the server / infrastructure status, receive a response, request the status again, etc. The process is long and inconvenient.
Therefore, we have created a dashboard where users can immediately understand the state of the system and key resources. The dashboard also displays all critical states and sends notifications to users without delay according to a template that can be configured in the profile.
PostgresPro users are used to working with the command-line interface, so our task was to create an interface that did not cause discomfort when switching to a new way of managing the system. We tried to minimize any inconvenience by making the process more understandable and efficient for future users. The received insights were packaged in proof of concept — a prototype in Figma.
Крафт (мастерство), реализация, технические детали
АРХИТЕКТУРА И РАЗРАБОТКА
Плагинная архитектура
Поскольку PostgreSQL имеет разные наборы расширений на разных серверах, то не существует универсального решения, которое подходило бы для всех сценариев использования.
Нам предстояло сделать так, чтобы расширения могли изменять интерфейс, добавлять новые страницы или изменять существующие, и у расширений могли быть свои дополнительные расширения.
При этом у нас не было готового набора этих расширений. Их список мог постоянно дополняться новыми функциями, которые пишут сторонние разработчики.
Для сборки и подключения мы использовали динамические узлы в Webpack Module Federation. Список расширений формировался динамически по запросу в API на перечень доступных установленных расширений.
Это добавило сложности от самого Webpack, который не поддерживает динамическое подключение из коробки. Нам пришлось разбираться самостоятельно, изучая примеры кода и документацию для другого стека (AngularJS).
Плагины внутри других плагинов
Ещё одной интересной задачей было сделать возможным расширение функциональности одних плагинов другими плагинами. Для этого мы добавили концепцию слотов. Так у нас появился специальный компонент, который описывал слот внутри плагина.
В описание плагина мы добавили поле виджетов, через которое можно было в слот другого плагина прокинуть нужный компонент. Фактически это позволяет делать расширения для расширений.
ДИЗАЙН И ПРОРАБОТКА UX
Наш дизайнер-проектировщик начала с более глубокого погружения в способы отображения инструментария БД, т. к. в системе множество разных метрик, надстроек и конфигураций.
Важно было проанализировать сервисы, которым пользуется ЦА. Для этого мы разбирались, как работают пользователи в консоли.
Комментарий дизайнера-проектировщика Марии:
Я много разбиралась в способах визуализации данных в таблицах. Смотрела, как это сделано в разных продуктах: Grafana, Datadog, Instana и т. д. и вообще в любых сервисах, где есть данные с таблицами. Кроме того подглядывала классные решения в других индустриях, например, в медицине. Это помогало найти подходящее решение для PostgresPro.
Основные референсы подготовил продакт на стороне клиента. Он же объяснял фичи, которые сделаны в этих приложениях и то, как именно они работают и как такие фичи должны работать в PostgresPro.
ФИНАЛЬНЫЙ ВИД СИСТЕМЫ
Стандартное взаимодействие пользователя с кластерами примерно такое: Администратор пишет запрос в командную строку, система отвечает о текущих проблемах, на это админ пишет другой запрос и так далее.
Мы решили сохранить привычный паттерн и внедрили концепцию многофункционального интерфейса с консолью и командной строкой.
___
ARCHITECTURE AND DEVELOPMENT
Plug-in architecture
Since PostgreSQL has different sets of extensions on different servers, there is no universal solution that would be suitable for all use cases.
We had to make it so that extensions could change the interface, add new pages or modify existing ones, and extensions could have their own additional extensions.
At the same time, we did not have a ready-made set of these extensions. Their list could be constantly updated with new features written by third-party developers.
We used dynamic nodes in the Webpack Module Federation to build and connect. The list of extensions was formed dynamically upon request in the API.
This added complexity from Webpack itself, since it does not support dynamic connections out of the box. We had to figure it out on our own, studying examples and documentation for another stack (AngularJS).
Plugins inside other plugins
Another interesting task was to extend the functionality of some plugins within other plugins. To do this, we have added the concept of slots. So we had a special component that described the slot inside the plugin.
In the description of the plugin, we added a widget field to throw the desired component into the slot of another plugin. In fact, it allows users to make extensions for extensions.
DESIGN
Our designer started with a deeper dive into the ways of displaying the database tools, because there are many different metrics, add-ons and configurations in the system.
It was important to analyze the services used by the TA. To do this, we figured out how users work in the console.
Maria explains: I had figured out a lot of ways to visualize data in tables. I looked up different products such as Grafana, Datadog, Instana, etc to see how this is done.
In addition, she peeked at interesting solutions in other industries, for example, in medicine. This helped to find a suitable solution for PostgresPro.
The main references were prepared by the client's product manager. He also explained all of the features in these applications and how exactly they work and how they should work in PostgresPro.
The standard user interaction with clusters is something like this: the administrator writes a request to the command line, the system gives a response on current problems, the admin writes another request, and so on.
We decided to keep the usual pattern and implemented the concept of a multifunctional interface with a console and a command line.
Инсайты, гипотезы, процесс создания и взаимодействия с заказчиком
Продакт-менеджер клиента выступал в роли заказчика, который чётко понимал, что он хочет получить в итоге, и помогал, объясняя, как должна работать система. Нашей задачей было спроектировать продукт наилучшим образом с точки зрения UX.
За последние годы мы наработали экспертизу в GUI для сложных доменных областей. Так что к проекту подключили дизайнера-проектировщика с опытом разработки системы для DevOps специалистов.
___
The client's product manager acted as a customer who clearly understood what he wanted to get in the end, and helped by explaining how the system should work. Our task was to design the product with the best UX.
Скриншоты