Ответ вслух Middle System design на фронте спрашивают часто обновлено

Мониторинг фронтенда

Вопрос

Спроектируй наблюдаемость фронтенда: понять, что у пользователей что-то сломалось.

Веди разговор вслух, как на секции. Начинать с решения - главная ошибка: первые полторы минуты только вопросы.

Попробуйте сами

Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.

Показать ответ и разбор

Коротко

Три слоя: ошибки, производительность у реальных пользователей, бизнес-воронка. Ошибки собираем глобальными ловушками плюс границами ошибок React.

Что должно прозвучать в ответе

  • уточнил, что считаем инцидентом и кто будет на это смотреть

  • ошибки: window.onerror, unhandledrejection, error boundary

  • source maps на сервере ошибок, иначе стек бесполезен

  • метрики пользователей: LCP, INP, CLS с реальных устройств, а не только Lighthouse

  • бизнес-события: дошёл ли пользователь до оплаты

  • версия сборки в каждом событии, чтобы связать всплеск с релизом

  • семплирование и лимиты, чтобы не залить сервер и не тормозить клиент

  • алерты на то, что требует действия, иначе их перестают читать

Что могут спросить следом

  • Как отличить всплеск ошибок от одного бота?
  • Почему Lighthouse показывает не то же, что реальные пользователи?
  • Что делать с ошибками из расширений браузера?

Разбор

Три слоя: ошибки, производительность у реальных пользователей, бизнес-воронка.

Ошибки собираем глобальными ловушками плюс границами ошибок React. Без source maps на сервере ошибок стек из минифицированного бандла бесполезен - это первая вещь, которую забывают.

Производительность меряем полевыми данными через PerformanceObserver: лабораторный Lighthouse на своём макбуке врёт. Он легко показывает две секунды там, где у пользователя на мобильном совсем другое.

Версия сборки в каждом событии - то, что превращает мониторинг из шума в инструмент: всплеск ошибок мгновенно связывается с релизом.

Семплирование обязательно: слать всё с миллиона сессий - залить и хранилище, и клиент.

И про алерты: ложные срабатывания убивают мониторинг быстрее его отсутствия. Например, цели, заданные захардкоженными именами контейнеров, начинают врать после переименования, поэтому лучше обнаружение сервисов. Алерт должен требовать действия, иначе его отключат.

Ответьте сами, а не прочитайте

В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.