Проектирование 2 из 3 - дэш здоровья метрик

В прошлом посте серии я разобрал первый кейс - дэш миграции хранилища - и рассказал про «Проектирование взаимодействия». Главный тезис там был: один дэш ≠ две аудитории, разделять контуры менеджмента и кураторов доменов.

Сегодня - второй кейс. Здесь та же логика, но контур уже не «менеджмент vs кураторы», а две роли поглубже внутри одной технической семьи. И там разница между ними ещё тоньше, поэтому шаблон работает как фильтр.

Контекст. В большом продукте есть пара тысяч продуктовых метрик. Например 10 000+. У каждой метрики - оунер (аналитик, который её ведёт) и куратор - лид кластера, отвечающий за весь домен метрик. У каждой метрики есть «здоровье» - 5 факторов, которые показывают, можно ей доверять или пора чинить.

Дэш здоровья метрик строится один. А аудитории у него две. И на первый взгляд они хотят почти одного и того же - «сделать метрики здоровее». Но это иллюзия.

Куратор домена - Lead кластера, BI ★★★★★, sql-high. Заходит регулярно, в проверяющем режиме. Цель - удерживать долю зелёных метрик в своём домене. Решение, которое принимает - какую задачу заводить на оунеров, кому что приоритизировать. Выходит со списком задач в трекер и коммуникацией с оунерами «нездоровых» метрик.

Оунер метрики - Аналитик, BI ★★★★★, sql-medium+. Заходит реактивно - когда пришёл алёрт по его метрике или когда куратор дал задачу. Цель - понять, насколько одна конкретная метрика плоха и что именно фиксить в первую очередь. Решение - сколько времени займёт починка и что делать руками. Выходит с конкретным action item на свою метрику.

Один и тот же набор из 5 факторов здоровья читается по-разному:

▫️ Куратор видит распределение - сколько процентов метрик в красной зоне, как это выглядит в разрезе вертикали и кластера, сравнение с компанией в среднем
▫️ Оунер видит карточку - его метрика, её 5 факторов, конкретный action «допиши описание», «почини зависимость»

Дэш по-прежнему один. Но в нём два сценария использования - агрегатный для куратора и карточный для оунера. Это сильно отличается от «один экран с фильтрами для всех» - тут даже наборы плиток на странице разные, потому что разный объект внимания.

Шаблон 5+2 в применении

Куратор домена - заходит ежемесячно/еженедельно, кросс-фильтрует по вертикали и кластеру, видит распределение метрик по зонам и сравнение с компанией, выходит со списком задач для оунеров; отдельные карточки метрик не нужны - это уровень оунера. Доверяет цифрам, потому что бейдж сертификации, документированная логика 5 факторов и автоматизированные рассылки совпадают с тем, что он видит на экране.

Оунер метрики - заходит реактивно на алёрт, открывает карточку своей метрики, видит 5 факторов и конкретные action items, выходит с минимальным списком «что починить»; общая статистика по домену ему не нужна, она его только запутает. Доверяет, потому что 5 факторов - те же, что в трекере задач, и «почему красная» совпадает с тем, что говорит куратор.

Защита от ошибок здесь - отдельная тема. Две главные ловушки: судить о здоровье домена по одному агрегату (одна красная метрика ≠ красный домен) и формулировать action item на уровне домена, а не конкретной метрики. Шаблон ловит обе через раздел «Каких сценариев быть не должно» - когда вы явно прописываете, чего экран НЕ показывает, эти ловушки уходят.

🚀 В третьем посте серии - дэш core-слоя данных, где контуров уже не два, а три, и шаблон становится не роскошью, а условием выживания.