Задача
Главный экран отражал структуру системы, но не отвечал на вопрос, с которым в неё заходят: что происходит и всё ли хорошо.
Что получилось
Экран даёт оценку состояния дата-центра и показывает активные проблемы. Действие начинается здесь же, без перехода в разделы.
Обзор решения
тот же экран в тёмной теме
Главный экран
12 → 1
Вместо каталога из 12 разделов — один экран с оценкой состояния.
Конфликт IP-адреса
3 клика
Разрешение прямо из алерта на главной, без перехода в разделы.
Основа требований
2 интервью
DevOps-инженер и системный администратор. Решение построено на их барьерах.
Важно. Цифры описывают спроектированное решение, а не измеренный эффект. Продукт не выходил в прод — проверить можно интервью и макеты.
Как я к этому шёл
01
Два интервью: DevOps-инженер и системный администратор. Разбор четырёх аналогов: NetBox, Device42, Nautobot, Proxmox.
02
JTBD по четырём ситуациям и требования к продукту. Каждый сценарий разложен на шаги и барьеры.
03
Дашборд состояния и два флоу: конфликт IP и смена статуса устройства. Собрано на токенах Gravity UI и связано в кликабельный прототип.
Интервью
Среди знакомых нашёл двух человек, чья работа — ровно то, про что тестовое. Каждому задал пять вопросов: где ищут информацию об инфраструктуре, что мешает и что хотели бы видеть первым делом.
| 1 | Когда тебе нужно понять, что вообще есть в инфраструктуре — серверы, IP, зависимости, — где смотришь? Есть какой-то единый источник правды или собираешь по кускам отовсюду? |
|---|---|
| 2 | Бывало, что что-то упало и ты не мог быстро понять, кто последним менял конфигурацию этого узла? |
| 3 | Если удавалось отследить, кто это сделал, — сколько действий тебе требуется для этого? |
| 4 | Если бы был инструмент, где можно быстро найти любой объект инфраструктуры и увидеть его состояние, — что для тебя было бы важно видеть первым делом? |
| 5 | Что конкретно в твоей работе вызывает больше всего неудобств и почему? |
| Поле | DevOps-инженер26 лет | Системный администратор20 лет |
|---|---|---|
| Инструменты | Docker, Kubernetes, Helm, Terraform, Ansible, GitlabCI | Kubernetes, Proxmox, Terraform, Ansible |
| Цитата | «Первым делом хочу видеть айпишник, метрики, логи и алерты» | «Состояние кластера и его ресурсы — наболевшее. Дашборд в графане какой-нибудь» |
| Что неудобно | Чтобы отследить причину инцидента, нужно пройти через несколько инструментов: версия, сборка, коммит, автор. | Единого инструмента для понимания состояния инфраструктуры нет — приходится смотреть в Proxmox, Terraform, Ansible, в зависимости от того, как развёрнута среда. |
| Боли | Единого источника правды нет — информация об инфраструктуре размазана по разным системам. | Ручные изменения на сервере не отслеживаются: если кто-то «залез руками и поменял», узнать, кто это сделал, можно только через bash history. |
| Инсайт | Пользователь знает, что ему нужно при инциденте, но интерфейс не даёт это быстро. Приоритет информации чёткий: IP → метрики → логи → алерты. | Состояние кластера и ресурсов хотят видеть первым делом. Сейчас это закрывают внешними инструментами вроде Grafana — значит, в самом продукте этого не хватает. |
Ограничение выборки
Два респондента — этого мало для статистики.
Но оба независимо назвали одно и то же: единого места, где видно состояние инфраструктуры, нет. Данные собирают руками из разных систем. На этом совпадении построено решение.
Конкурентный анализ
Разобрал четыре системы по одним критериям: что показывает вход, как устроен поиск, есть ли история изменений и алерты.
| Критерий | NetBox | Device42 | Nautobot | Proxmox |
|---|---|---|---|---|
| Главный экран | Каталог плиток: Devices, IP Addresses, Racks, VLANs. Счётчики есть, но без контекста — ни состояния системы, ни алертов. | Дашборд из виджетов, состав выбирает сам пользователь. Есть Insights+ с аналитикой. Но это сводка, а не ориентация на действие. | Дашборд с активностью, статусами джобов и системными метриками. Ближе к рабочему инструменту, чем каталог, но фокус на автоматизации. | Реальное время: CPU, память, статус нод и VM. Лог задач всегда внизу экрана. Самый близкий к мониторингу состояния. |
| Поиск | Индексация в реальном времени, точное и частичное совпадение, сохраняемые фильтры. После 3.4 деградировал — пользователи ушли в таблицы с фильтрами. | Глобальный поиск с автодополнением на главной, фильтры и операторы на страницах списков. Истории и команд нет. | Глобальный поиск через Cmd+K, с синтаксисом фильтрации по типу объекта. Истории нет. | Базовый, по имени объекта в шапке: VM, контейнеры, ноды. Поиска по IP нет — это активный запрос пользователей. |
| Audit Log | Все изменения логируются в ObjectChange, к каждому можно добавить комментарий. На главном экране недоступен. | Централизованный лог: объект, что изменилось, источник, автор, время. На карточке объекта — своя история изменений. | Полноценный: глобальный через меню и вкладка Changelog на каждом объекте. На главном экране отсутствует. | Task history показывает операции, но кто менял конфигурацию — не отслеживается. Собирать приходится из системных логов. |
| Alerts | Уведомления об изменениях объектов через подписки и event rules. IP-конфликт и загрузку стоек не выявляет. | Счётчики уведомлений на дашборде, правила по OS, subnet и discovery, интеграция с PagerDuty. Но это алерты об изменениях данных, не мониторинг состояния. | Нативных нет. События уходят через webhooks в Slack и PagerDuty. Мониторинг состояния — только внешними плагинами вроде Prometheus. | Системные события через email или Gotify. Панели алертов в интерфейсе нет. Состояние VM и нод — внешними инструментами. |
| Вывод | Документирование, а не мониторинг. Проблемы состояния не выявляет сам — о них узнаёшь постфактум. | Документирование с сильной аналитикой. Но фокус на данных: статистику видно, что с ней делать — нет. | Автоматизация сети, а не оперативное управление. Инструмент для опытных инженеров, но как точка входа для диагностики не подходит. | Единственный с дашбордом реального времени — ближайший референс. Но слабый поиск и отсутствие audit log не дают ему быть единым рабочим инструментом. |
Что из этого следует
Ни один из четырёх не отвечает на вопрос «всё ли в порядке» на входе.
Документирование решено у всех. Мониторинг состояния — только у Proxmox, и тот без поиска и истории изменений. Свободная ниша — не хранение данных, а оценка состояния и переход к действию с главного экрана.
Проблемы
Из двух разговоров сложились четыре повторяющихся барьера. На них и построен экран.
01
Как устроена система, разбираться не нужно. Важно понять, что происходит в инфраструктуре прямо сейчас.
02
Человек точно знает нужный объект. Но добирается до него через навигацию и несколько разделов подряд.
03
Единого контекста нет: информация размазана по инструментам. Сбор занимает время, которого при инциденте нет.
04
Действия повторяются, но система не помогает вернуться к прерванному. Каждый раз ищешь заново.
JTBD
Четыре ситуации из интервью. Для каждой — требование к продукту и решение, которое его закрывает.
При инциденте
JTBD
Когда что-то упало, хочу быстро увидеть всю информацию об объекте, чтобы найти причину, а не тратить время на её поиск.
Требование
Диагностика инцидента не должна начинаться с похода в другой раздел.
Решение
Единый контекст объекта + Audit Log + метрики
При входе в систему
JTBD
Когда я захожу в систему, хочу сразу понять состояние инфраструктуры, чтобы определить, требует ли что-то моего внимания.
Требование
Оценка состояния не должна требовать перехода в другие разделы.
Решение
Дашборд состояния + алерты + ресурсы
Когда нужно найти объект
JTBD
Когда мне нужен конкретный объект, хочу найти его напрямую, чтобы не тратить время на навигацию по разделам.
Требование
Поиск не должен зависеть от точного названия — только от любого известного параметра.
Решение
Глобальный поиск по IP, имени, VLAN и тегу
При возвращении к работе
JTBD
Когда я возвращаюсь к работе, хочу быстро открыть последние объекты, чтобы продолжить без повторного поиска.
Требование
Возврат к прерванной работе не должен требовать повторного поиска.
Решение
Continue working + частые операции в один клик
Решение
Экран открывался каталогом разделов — оценки состояния на входе не было.
скриншот «до» не подложен
Каждая аннотация — барьер из интервью и то, как он закрыт.
Что это даёт
Оценка состояния, активные проблемы и переход к действию — на одном экране. Конфликт IP разрешается в три клика прямо из алерта.
Это свойства макета — их видно по прототипу. Ускоряют ли они реакцию на инцидент, покажут только тесты на инженерах. Продукт не выходил в прод, замеров нет.
Один адрес назначен двум устройствам, оба работают нестабильно. От алерта до закрытия три клика — плюс предупреждение, если выбрать рискованный адрес.
Устройство выключили в обход системы, причина неизвестна. Система просит объяснение при возврате в онлайн — или честно помечает, что его нет.
Итог
Что получилось
Видно на макетах
Это покажут только тесты
Рефлексия
Спасибо, что дочитали