Настройка Synthetic Monitoring: выявление скрытых проблем сайта

Synthetic Monitoring: сбои, которые видны только клиентам

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

Деградация без ошибок в логах — самый дорогой класс отказов. Платёжный шлюз отвечает, но через сорок секунд вместо двух; сторонний скрипт аналитики блокирует отрисовку кнопки «Оплатить»; кэш отдаёт устаревший файл корзины после релиза. Каждый случай формально успешен и не создаёт ни одной строки в журнале, а страдает только конверсия — её падение замечают уже по выручке.

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

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

Что даёт имитация действий пользователя по расписанию

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

Именно поэтому время обнаружения сбоя измеряется минутами, а не часами до первого письма в поддержку. Раннее оповещение приходит в дежурный канал с привязкой к конкретному шагу сценария — видно, что сломалось: вход, оплата, выдача каталога. Доля отказов, найденных до обращения клиента, становится управляемой величиной, и её видно на графике по неделям.

Отдельный слой — контроль внешних интеграций. Проверка на границе с чужой системой показывает, деградация у нас или у поставщика, и снимает переписку «у нас всё работает». Пороги настраиваем с запасом: например, сценарий считается упавшим после двух подряд неудачных попыток из разных регионов, чтобы одиночный сетевой всплеск не поднимал дежурного.

Мы собираем такие сценарии на Grafana и связываем с панелями доступности, чтобы цифры на графике и в оповещении совпадали. Нагрузка на поддержку падает за счёт того, что часть отказов закрывается до появления тикетов, а остальные приходят с готовым контекстом. Обсудите задачу — вернёмся с планом сценариев и их расписания.

Режимы Synthetic Monitoring: доступность, точка входа, браузер

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

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

Частота запусков и география проверок

Интервал задают по цене простоя: доступность проверяют раз в минуту, сценарий в браузере — раз в 5–15 минут, иначе нагрузка на прод растёт без пользы. Запуски раскидываем по 3–5 регионам присутствия пользователей: так сбой локального маршрута не маскируется под общую аварию, а расхождение результатов между площадками сразу указывает на сеть, а не на приложение.

Сводные графики и историю отказов держим в Grafana — по ним видно, деградация это или разовый таймаут. Тревогу поднимаем только по повторяющимся отказам с двух площадок: дежурный не просыпается из-за одиночного всплеска.

Как мы строим проверки: от инвентаризации до передачи

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

1. Аудит критичных сценариев. Собираем пользовательские пути: вход, поиск, оформление заказа, оплата, личный кабинет. Отдельно помечаем те, что завязаны на внешние сервисы и на фоновые задания — именно они чаще всего отваливаются незаметно.

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

3. Настройка проверок. Расписание, география запусков, авторизация, тестовые учётные записи и данные. Сценарии выполняются в изолированном контуре, не пишут в боевые таблицы и не мешают реальному трафику.

4. Калибровка порогов срабатывания. Снимаем базовую линию по каждому сценарию за период, затем задаём порог по времени отклика и по числу последовательных ошибок. Так ночные всплески нагрузки не поднимают дежурного, а устойчивая деградация — поднимает.

5. Тест на реальном сбое. Останавливаем сервис, блокируем внешний вызов, разрываем соединение — и смотрим, что оповещение ушло, за какое время и хватает ли в нём данных для диагностики. Пороги после этого правим.

6. Передача в эксплуатацию. Отдаём правила, инструкцию для дежурного, схему эскалации и список ответственных. Прогоняем по каждому оповещению вопрос «что делать» — если ответа нет, проверка недоработана.

После передачи покрытие живёт: раз в квартал пересматриваем сценарии под новые разделы и интеграции, чтобы мониторинг не расходился с продуктом.

Что остаётся в проекте после настройки проверок

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

• Карта покрытия проверками — какие пользовательские сценарии и внешние точки входа закрыты, где проходит граница контроля и что осознанно оставлено вне проверок.
• Параметры проверок — состав шагов, периодичность запуска, набор точек запуска, пороги по времени ответа и допустимые коды ответа.
• Правила оповещений — что будит дежурного, что уходит в очередь на утро, кому адресован канал и как гасится лавина сообщений при массовом сбое.
• Регламент реакции — сроки взятия инцидента, точки эскалации, зона ответственности нашей команды и контакт на стороне заказчика.
• Инструкция для дежурного — что проверить в первые минуты, как отличить отказ приложения от сбоя внешнего поставщика, где смотреть историю запусков.
• Документация по мониторингу — описание сценариев, владельцы, порядок добавления новых проверок и вывода устаревших из эксплуатации.
• Журнал изменений проверок — когда и по какой причине менялся сценарий, чтобы рост числа проверок не превратился в неуправляемый набор.

Всё это лежит рядом с кодом в репозитории и проходит такую же проверку при изменениях, как само приложение — проверки живут вместе с продуктом, а не отдельно от него.

Кейс: скрытые отказы оплаты на сайте-каталоге

Отказ, которого не было в серверных метриках

Каталог на несколько тысяч позиций, оплата — через внешний платёжный шлюз. Серверные метрики выглядели ровно: время ответа приложения в норме, доля пятисотых не растёт, очереди пусты. При этом поддержка еженедельно получала обращения «оплата прошла, заказа нет», и каждое всплывало через 4–11 часов после начала сбоя — когда пострадали уже десятки покупателей.

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

Что настроили и что изменилось

Собрали полный сценарий покупки: поиск товара, корзина, оформление, выбор доставки, переход на платёжную страницу, ожидание подтверждения в тестовом контуре и проверка, что в личном кабинете появился заказ с верным статусом. Прогон — раз в 5 минут из четырёх регионов через Checkly, с проверкой не только кода ответа, но и содержимого страницы: так ловится случай, когда сервер отдаёт «успех» с пустой корзиной.

Метрики до и после: время до обнаружения отказов — с 4–11 часов до 2 минут, доля потерянных оплат в часы пик — с 3–5% до 0,2%, доля сценариев, доходящих до конца, — 99,8%. Дежурный получает оповещение с номером упавшего шага, снимком экрана и трассировкой запросов, поэтому восстановление сценария занимает один разбор, а не поиск причины вслепую. Тот же сценарий запускается после каждого релиза — регрессия на шаге оплаты видна до того, как о ней напишут покупатели.

Чем синтетические проверки отличаются от данных реальных посетителей?

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

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

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

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

Технические сомнения перед запуском проверок

Проверки идут с внешних узлов и ведут себя как редкий аккуратный посетитель: единицы запросов в минуту на сценарий, а планировщик разносит обходы, чтобы они не совпадали с пиками трафика. Закрытые разделы проверяем отдельной технической учётной записью с минимальными правами — реальных данных это не касается.

Ложные срабатывания гасим подтверждением с двух независимых узлов и порогом в два провала подряд: в дежурный канал попадает подтверждённый инцидент, а не единичный сетевой сбой. Разграничение ответственности фиксируем заранее — отказ инфраструктуры уходит эксплуатации, сбой бизнес-сценария владельцу продукта.

Как проверять закрытые разделы, где нужна авторизация?

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

Куда приходят оповещения и кто их разбирает?

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

Обсудим задачу и вернёмся с планом проверок

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

В ответ присылаем план, по которому дальше идём:

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

Опишите задачу — вернёмся с оценкой и планом проверок.