О проекте
В рамках Huemen Design я проектировал внутреннюю платформу мониторинга коммуникационной инфраструктуры для Polycom — Polycom Aqua. Системой пользовались SRE и инженеры инфраструктуры для диагностики видеоконференц-сервисов в реальном времени.
Главная задача интерфейса: за секунды понять — регион работает штатно или движется к отказу. В большинстве инструментов мониторинга важные сигналы разбросаны по разным экранам, и инженеру приходится вручную сопоставлять загрузку, потерю пакетов и сбои сессий. Это замедляет расследование инцидентов и заставляет пропускать ранние признаки деградации.
Вопросы, на которые отвечает интерфейс
- Регион здоров или деградирует?
- Какая метрика подняла тревогу?
- Какова наиболее вероятная причина?
- Какие узлы затронуты?
- Откуда начинать расследование?
Пользователи
Основные пользователи — SRE и инженеры инфраструктуры, поддерживающие медиа-системы реального времени. Их работа критична по времени и завязана на сигналы. Во время инцидента им нужно оценить состояние региона, увидеть ранние признаки деградации и решить, откуда начинать расследование.
- Следить за загрузкой системы
- Находить риски перегрузки
- Диагностировать причины отказов
- Определять затронутые узлы
- Расследовать активные инциденты
Моя работа
- UX/UI веб-платформы для десктопа и мобильного
- Глубинные интервью с SRE и инженерами инфраструктуры
- Совместное с инженерами определение ключевого набора метрик и их пороговых значений
- Проектирование дашбордов с расстановкой приоритетов сигналов
- Визуализация сигналов трёх типов: загрузки, качества и отказов
- Оптимизация пользовательских потоков для ускорения работы с инцидентами
Интерфейс
Ключевые метрики
Логика отбора: показывать не максимум метрик, а минимальный набор индикаторов, вскрывающих ранние признаки деградации. Сигналы делятся на три категории.
- Загрузка — система приближается к лимитам
- Качество — производительность медиа
- Отказы — причины и масштаб деградации
- Загрузка пула (Pool Utilization) — процент ёмкости пула, занятой активными сессиями. Главный ранний сигнал перегрузки. Пороги: 70% штатно, 85% риск, 95% исчерпание.
- Запас ёмкости (Headroom) — сколько трафика система ещё выдержит до отказа. Дополняет загрузку: важен операционный буфер, не только текущее состояние.
- Сбои установления сессии (Failed Setups) — процент звонков, упавших на старте. Прямо отражает влияние на пользователя — в отличие от чисто инфраструктурных метрик.
- Потеря пакетов (Packet Loss, p95) — процент медиа-пакетов, не дошедших до получателя. p95 показывает худший случай для пользователей. Сигнал качества медиа.
- RTT и Jitter — задержка и стабильность сети. Помогают отделить проблемы загрузки от проблем сети.
- Топ причин отказов (Top Failure Reasons) — агрегация наиболее частых ошибок за окно времени, без копания в логах. Пример: 503 MCU Busy.
- Затронутые узлы (Affected Nodes) — узлы с наибольшей загрузкой или наименьшим запасом. Видно, проблема локализована или охватила весь регион.
Результаты
- Сократил время от обнаружения проблемы до решения инженера — за счёт просмотра приоритизированных сигналов на одном экране
- Стандартизировал ключевой набор сигналов для всей инженерной команды
- Высокая оценка от инженерных команд после релиза
- Подход к расстановке приоритетов сигналов перенесён в последующие платформы
Контекст
- Интерфейсы для SRE и инженеров инфраструктуры — специфический профессиональный контекст с устоявшимися моделями работы
- Большой объём технических данных: метрики соединений, сетевая топология, статусы устройств
- Стрессовый контекст — инженеры реагируют на инциденты в реальном времени
- Единственный UX/UI на проекте — от пользовательских интервью до готового дизайна
