Наблюдаемость фронтенда: как мы строим RUM, метрики и алерты, которые помогают делу

RUM мониторинг фронтенда (Real User Monitoring) — это не «поставить пиксель». Это инженерная система, которая собирает метрики восприятия (Web Vitals), связывает их с релизами, трассирует пользовательские сценарии, аномалии и ошибки, и умеет поднимать правильные алерты в нужный момент. Наблюдаемость нужна не только разработчикам: продукту — чтобы видеть, где теряются пользователи, поддержке — чтобы закрывать кейсы быстрее, бизнесу — чтобы понимать, как «едут» деньги. Ниже — наш стандарт наблюдаемости клиентских приложений.

1) RUM vs синтетика: обе нужны, но для разного

Синтетические проверки (Lighthouse/ретранслированные сценарии) дают стабильную «лабораторную» картину и ранние сигналы регрессий. RUM показывает, как страница ведет себя у реальных пользователей: разные устройства, сети, кэши, регионы, расширения. Мы комбинируем: синтетика как «дымовой тест» на каждый релиз, RUM — как основа дашборда здоровья продукта и SLO.

2) Web Vitals: что и как измеряем

Мы собираем LCP (крупнейший элемент), INP (реактивность взаимодействий),CLS (стабильность макета), а также TTFB, FCP, показатели рендеринга и навигации. Важно мерить P75 по сессиям и сегментам (страна, тип сети, тип устройства), иначе среднее «съедает» боль «длинного хвоста». Метрики связываем с версиями/релизами, страницами и ключевыми сценариями (checkout, поиск, дашборды).

• P75 по каждой ключевой странице; минимальный объём выборки для значимых выводов.
• Сегментация: «холодный»/«тёплый» кэши, SSR/CSR, авторизованные/гости.
• Экспорт в time-series хранилище; алерты по динамике, а не фикс-порогам.

3) Distributed Tracing: от клика до базы

Без распределенной трассировки сложно объяснить, почему «медленно». Мы прокидываем traceparentиз браузера в BFF/бэкенды и дальше в базу/очереди. Так на одном графе виден весь путь запроса. Для SPA — помечаем навигации, важные интеракции и «кадры» рендеринга; для SSR — время на сервере, сеть и гидратацию. Это позволяет понять, где «горит» время и кто «виноват» — фронт, сеть или соседний сервис.

Практики трассировки

• Сэмплирование по умолчанию + «взвинченный» семпл на ошибках и медленных спэнах.
• Имена спэнов — по домену («search.query», «checkout.capture»), не «fetch #123».
• Линки на релизы/коммиты; корелляция с RUM-метриками и ошибками.

4) Ошибки, sourcemaps, релизы

Ошибка без источника — бесполезна. Мы загружаем sourcemaps в хранилище ошибок, помечаем события версией релиза и окружением, скрываем PII. Группируем по «причинам», а не по тексту, прикладываем контекст: браузер, фичефлаги, роут, последние действия. Ретрай-сигналы — отдельно от «фатальных» багов.

5) Алерты, SLO и ошибочный бюджет

«Кричащие» алерты убивают команду. Мы используем SLO по P75 Web Vitals и ошибкам на 1k сессий. Алерты — по «скорости сгорания» бюджета (burn rate): если за час сгорело 5% месячного бюджета — сигнал высокого приоритета. Так уведомления соответствуют реальному риску для пользователей и бизнеса.

6) Метрики фич и бизнес-события

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

7) Session Replay и приватность

Запись сессий полезна для сложных багов, но опасна для приватности и перфоманса. Мы включаем её точечно (по флагам и алертам), замазываем чувствительные поля, ограничиваем FPS/события и TTL хранения. Для банков/ медицины чаще достаточно событийной аналитики и трассировки без видео.

8) Панели, рутины и эксплуатация

Дашборд здоровья продукта — в одном месте: виталс, ошибки, алерты, карта релизов. Еженедельные «санитарные часы»: гасим дубликаты, закрываем «старые» группы ошибок, переносим улучшения в бэклог. Любая «красная» метрика должна иметь в бэклоге «зелёную» гипотезу и ответственного.

9) Анти-паттерны

• Средние вместо P75 — ложное чувство «всё хорошо».
• Алерты по абсолютным порогам — шум на медленных сетях/устройствах.
• Отсутствие связывания с релизами — невозможно понять, «кто сломал».
• Сквозная трассировка без приватности — риск утечки PII.

Итог: наблюдаемость — это метрики Web Vitals, трассировка, ошибки/релизы и внятные алерты, которые ведут к действию. Мы строим стек так, чтобы команда видела проблему раньше пользователей и могла объяснить её причину. Сроки/стоимость внедрения обсудим по контактам на сайте.