Что происходит после выхода фронтенда в продакшн? Мониторинг, который действительно работает

Вы только что выкатили новую версию фронтенда. Сборка прошла, деплой завершён, CDN раздаёт свежий бандл. Но через пять минут пользователь из Юго-Восточной Азии сообщает, что кнопка оформления заказа не реагирует на клик. Логи сервера чисты, API отвечает нормально. Проблема невидима с вашей стороны.

Такова реальность мониторинга фронтенда. В отличие от бэкенда, где можно проверить статус процесса, загрузку CPU или логи запросов, ваш фронтенд работает на устройствах, которые вы не контролируете. Разные браузеры, операционные системы, условия сети и даже блокировщики рекламы могут заставить ваш код вести себя по-разному для каждого пользователя. Если вы мониторите только серверы, вы летите вслепую.

Почему мониторинга сервера недостаточно для фронтенда

Когда ваш бэкенд падает, вы видите это сразу. Процесс останавливается, порт закрывается, или частота ошибок в логах резко растёт. Вы получаете оповещение, разбираетесь, чините.

Сбои фронтенда выглядят иначе. Ваш JavaScript может выбросить исключение только на Safari 15 на старом iPhone с медленным соединением. API-вызовы могут выполняться успешно, но логика рендеринга молча ломается, потому что не загрузился сторонний скрипт. Пользователь видит пустую страницу или зависший спиннер, но ваш сервер понятия не имеет, что что-то пошло не так.

Этот разрыв означает, что вам нужна другая стратегия мониторинга для фронтенда. Вам нужно видеть, что ваши пользователи на самом деле испытывают в своих браузерах, а не только то, что сообщает ваша инфраструктура.

Частота ошибок в браузере: первый сигнал

Самый важный показатель, который нужно отслеживать после релиза фронтенда — это частота ошибок JavaScript в браузере. Это не ошибки API и не исключения на стороне сервера. Это ошибки, которые происходят внутри вашего кода, выполняющегося на устройстве пользователя.

Распространённые примеры:

  • Функция, использующая API браузера, недоступное в старых версиях
  • Библиотека, которая не загрузилась из-за обрыва сети у пользователя
  • Ошибка нулевой ссылки, потому что ответ API не содержал ожидаемого поля
  • Синтаксическая ошибка, внесённая в процессе сборки и проявляющаяся только в определённых конфигурациях минификации

Чтобы перехватывать их, вам нужен инструмент Real User Monitoring (RUM), который собирает исключения, стектрейсы и контекст браузера от реальных пользователей. Такие инструменты, как Sentry, Datadog RUM или New Relic Browser, работают, добавляя на вашу страницу небольшой скрипт, который перехватывает необработанные ошибки и отправляет их в центральный коллектор.

Вот минимальный пример того, как можно настроить глобальный обработчик ошибок и зафиксировать производительность загрузки страницы в вашем приложении:

// Глобальный обработчик необработанных исключений
window.onerror = function (message, source, lineno, colno, error) {
  const errorData = {
    message: message,
    source: source,
    line: lineno,
    column: colno,
    stack: error ? error.stack : null,
    url: window.location.href,
    userAgent: navigator.userAgent
  };
  // Отправляем данные об ошибке в ваш мониторинговый эндпоинт
  fetch('/api/log-error', {
    method: 'POST',
    body: JSON.stringify(errorData),
    headers: { 'Content-Type': 'application/json' }
  });
};

// Захват производительности загрузки страницы
window.addEventListener('load', function () {
  const perfData = window.performance.timing;
  const pageLoadTime = perfData.loadEventEnd - perfData.navigationStart;
  console.log('Время загрузки страницы (мс):', pageLoadTime);
  // Отправляем в сервис мониторинга
  fetch('/api/log-performance', {
    method: 'POST',
    body: JSON.stringify({ loadTime: pageLoadTime, url: window.location.href }),
    headers: { 'Content-Type': 'application/json' }
  });
});

Ключевой момент — настроить оповещения на основе изменения частоты ошибок. Если после релиза частота ошибок подскакивает с 0,1% до 2%, что-то не так. Вам не нужно ждать жалоб пользователей. Данные скажут вам об этом до того, как жалобы начнут накапливаться.

Время загрузки страницы: что пользователи на самом деле чувствуют

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

Время загрузки страницы зависит от нескольких факторов:

  • Размер ваших JavaScript-бандлов
  • Количество сетевых запросов, которые делает страница
  • Скорость и задержка сети пользователя
  • Вычислительная мощность устройства
  • То, как ваш код обрабатывает рендеринг и интерактивность

Инструменты RUM могут показать распределение времени загрузки по всей вашей пользовательской базе. Вы можете увидеть, что пользователи в одном регионе испытывают задержку в 3 секунды, а в другом — ждут 8 секунд. Или что мобильные пользователи в сетях 3G имеют совершенно другой опыт, чем пользователи десктопов на оптоволокне.

После релиза сравните распределение времени загрузки до и после. Если медианное время загрузки увеличилось на 500 миллисекунд, это регрессия. Даже если функция работает корректно, пользовательский опыт ухудшился.

Взаимодействие с пользователем: сработала ли кнопка на самом деле?

Частота ошибок и время загрузки говорят о техническом здоровье, но не говорят, могут ли пользователи выполнять свои задачи. Страница может загрузиться без ошибок, но при этом иметь сломанную отправку формы или неработающую строку поиска.

Здесь на помощь приходит синтетический мониторинг. Вы пишете автоматизированные скрипты, которые симулируют путь пользователя через ваше приложение. Скрипт нажимает кнопки, заполняет формы, переходит между страницами и проверяет, что каждый шаг завершается успешно.

Например, синтетический тест для интернет-магазина может:

  1. Загрузить главную страницу
  2. Выполнить поиск товара
  3. Добавить товар в корзину
  4. Перейти к оформлению заказа
  5. Заполнить данные доставки
  6. Отправить заказ
  7. Проверить, что появилась страница подтверждения заказа

Запускайте эти тесты после каждого деплоя. Если тест падает на этапе оформления заказа, вы знаете, что в этом потоке что-то сломалось. Вы можете разобраться до того, как реальные пользователи столкнутся с проблемой.

Синтетический мониторинг не заменяет RUM. Он даёт контролируемые, повторяемые проверки, но не охватывает всё разнообразие реальных пользовательских сред. Используйте оба подхода вместе.

Интеграция мониторинга в ваш пайплайн

Мониторинг не должен быть отдельной активностью после деплоя. Он должен быть частью самого пайплайна развёртывания.

Вот практическая последовательность:

  1. Разверните новую версию фронтенда в продакшн
  2. Дождитесь распространения по CDN (обычно несколько минут)
  3. Запустите набор синтетических тестов против живых продакшн-URL
  4. Подождите пять-десять минут, чтобы накопились данные RUM от реальных пользователей
  5. Проверьте частоту ошибок и метрики времени загрузки на соответствие вашим порогам
  6. Если какая-либо метрика превышает порог, инициируйте автоматический откат или уведомите дежурную команду

Это не означает, что ваш пайплайн ждёт часами данных RUM. Первоначальная проверка — это быстрый санитарный тест. Если частота ошибок резко возрастает в первые несколько минут, вы ловите это немедленно. Если метрики выглядят нормально, деплой считается здоровым, и вы можете продолжать пассивный мониторинг.

Практический чек-лист для мониторинга релизов фронтенда

  • Установите инструмент RUM, который перехватывает ошибки JavaScript, время загрузки и контекст браузера
  • Настройте оповещения об изменении частоты ошибок после каждого деплоя
  • Создайте синтетические тесты для критических пользовательских сценариев
  • Запускайте синтетические тесты автоматически после каждого деплоя
  • Определите приемлемые пороги для частоты ошибок и времени загрузки
  • Настройте автоматический откат или уведомление при превышении порогов
  • Регулярно просматривайте данные мониторинга, чтобы замечать тренды, а не только инциденты

Резюме

Ваш фронтенд работает на устройствах, которые вам не принадлежат, в средах, которые вы не контролируете. Логи сервера не расскажут вам, когда кнопка перестала работать или когда страница загружается слишком медленно. Real User Monitoring и синтетическое тестирование дают вам видимость, необходимую для выявления проблем до того, как о них сообщат пользователи. Встройте эти проверки в свой пайплайн деплоя, и вы будете знать в течение нескольких минут, действительно ли релиз работает, а не только то, что он развернулся успешно.