Синтетический мониторинг: когда отказ видно только клиенту
Сервис отвечает на проверку живости, графики ровные — а доля оформленных заказов проседает. Отказ виден только клиенту: маршрут до одного из узлов уходит в чёрную дыру, на периферийном балансировщике истёк сертификат, провайдер отдельного региона режет трафик до платёжной интеграции. Внутренний мониторинг смотрит на процессы и ресурсы изнутри контура — такой сбой для него не существует.
Синтетический мониторинг закрывает именно этот класс отказов. Сценарии на Playwright прогоняются по расписанию с внешних точек в разных регионах и сетях: открыть каталог, добавить товар в корзину, довести заказ до подтверждения, проверить ответ платёжной интеграции. Путь тот же, что у живого покупателя, — снаружи контура, через публичный вход и сеть доставки контента.
Каждая проверка доступности сервиса фиксирует не только факт ответа, но и время по шагам, коды, переходы и наличие ключевого блока на странице. Расхождение между точками сразу локализует проблему до региона, оператора или конкретного узла — дежурному не приходится выяснять, «у всех ли лежит». Оповещение срабатывает на порог времени шага, а не только на полную недоступность.
Практический эффект — меняется порядок событий: о недоступности из отдельного региона узнаём мы, а не покупатель, который уже ушёл. Потеря заказов из-за недоступности перестаёт быть невидимой строкой в отчёте: у сбоя есть время начала, затронутые точки и подтверждение восстановления. Разбираем, как это закрывается.
Что даёт регулярная проверка доступности сервисов
Регулярная проверка — это не пинг порта, а воспроизведение пользовательского пути из внешних сетей: проба раз в минуту с нескольких независимых точек открывает страницу, авторизуется, добавляет товар и доходит до подтверждения заказа. Сценарии описываются кодом и версионируются рядом с конфигурацией инфраструктуры — через Checkly, поэтому проверка проходит то же ревью, что и остальные изменения.
Успешный код ответа ещё не значит, что сервис работает: форма может молча терять заявки, внешний платёжный сервис — отвечать отказом, сертификат — истечь ночью. Такие отказы проба находит раньше первой жалобы: сигнал уходит дежурному через одну-три минуты, тогда как клиент пишет в поддержку спустя десятки минут. Порог ставим на серию неудачных попыток, чтобы одиночное сетевое моргание не поднимало дежурного.
Локализация причины отказа — вторая половина эффекта. Проба показывает, на каком шаге рвётся: разрешение имени, проверка сертификата, ответ балансировщика или содержимое страницы. Разрез по точкам отделяет полный отказ от недоступности из одного региона — инженер начинает не с вопроса «что упало», а с конкретного участка цепочки.
Отсюда и время восстановления сервиса: на разбор уходят минуты вместо часа поиска. Часть классов отказов уходит совсем — истёкшие сертификаты, отвалившиеся внешние интеграции, сценарии, которые не проходят на отдельных устройствах.
Снижение числа жалоб клиентов — следствие: поддержка перестаёт быть каналом мониторинга, а доля отказов, о которых мы узнаём от пользователей, падает с большинства до единиц.
Режимы синтетического мониторинга: сравнение подходов
Режим проверки выбирают по тому, что именно нужно доказать. Одношаговая проверка страницы — одно обращение к адресу с контролем кода ответа и времени отклика: этого достаточно для точек входа и статических разделов, чтобы подтвердить, что сервис отвечает.
Многошаговый сценарий заказа повторяет путь покупателя — подбор, корзина, оформление, подтверждение — и сверяет ответы на каждом шаге. Он ловит разрыв интеграций, который одиночный запрос пропускает: страница открывается, а заказ не проходит.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Одношаговая проверка страницы | точки входа, статические разделы, быстрый контроль доступности | не видит отказов после первой страницы: «страница отдалась» ещё не значит «заказ оформляется» |
| Проверка из нескольких регионов | когда качество зависит от маршрута трафика и географии клиентов | растёт шум: локальные сети дают ложные срабатывания, нужна синхронизация расписания и порогов |
| Многошаговый сценарий заказа | критичные бизнес-пути: корзина, оплата, подтверждение | дороже в поддержке — тестовые данные и учётные записи, зависимость от внешних сервисов, шаги правят при каждом изменении интерфейса |
| Сценарий с входом в личный кабинет | закрытые разделы, где отказ виден только авторизованному клиенту | нужны служебные учётные записи и ротация доступов, проверка чувствительна к политикам безопасности |
Общее ограничение синтетических проверок — они подтверждают, что путь проходим, но не показывают, как по нему идёт живой клиент. Поэтому сценарии дополняют замерами от реальных сессий, а пороги по времени отклика задают с запасом, чтобы уведомление приходило на сбой, а не на всплеск трафика.
Этапы внедрения: от разбора точек входа до передачи поддержке
Синтетический мониторинг начинается не с панелей и графиков, а с инвентаризации того, что вообще должно быть доступно снаружи. Пока нет списка критичных точек входа и их владельцев, проверки превращаются в набор случайных запросов, которые ловят не то, что болит. Порядок работ ниже — это последовательность, в которой каждый следующий шаг опирается на результат предыдущего.
- Аудит точек входа. Собираем внешние адреса, API, формы авторизации, партнёрские и платёжные ручки, отдельно отмечаем те, чей сбой не виден внутреннему мониторингу. Для каждой точки фиксируем владельца и ожидаемое поведение.
- Приоритизация. Делим список на критичные и второстепенные сценарии: интенсивность проверок и громкость оповещений должны соответствовать реальному влиянию на операции и клиентов.
- Схема проверок. Для каждой точки описываем сценарий: код ответа, цепочку редиректов, наличие ключевого фрагмента в теле ответа, время отклика, срок действия сертификата. Проверяем из нескольких регионов, чтобы отличать сбой сервиса от сетевой аварии на маршруте.
- Пороги чувствительности. Настраиваем не «одна ошибка — тревога», а серию неудачных попыток или долю сбоев за окно; отдельные пороги для недоступности и для деградации по времени отклика.
- Каналы оповещений. Маршрутизация по критичности: дежурный инженер, чат команды, задача в системе учёта. Обязательны объединение повторов и подавление дублей, иначе одна авария порождает десятки сообщений и внимание к ним падает.
- Проверка на ложные срабатывания. Запускаем проверки в режиме наблюдения, сверяем с реальными инцидентами за прошлый период, смотрим шум в нерабочие часы и на плановых работах. Таймауты, окна и тексты сообщений правим здесь, а не после первой ночной тревоги.
- Передача поддержке. Отдаём инструкцию дежурного: что означает срабатывание, какие шаги диагностики, кого подключать. Отдельно фиксируем регламент ревизии сценариев при релизах и изменении точек входа.
Что передаём вместе с настроенными проверками
Проверки бесполезны, если после сдачи никто не понимает, что именно они контролируют и что делать при срабатывании. Поэтому вместе с синтетическим мониторингом мы передаём всё, что нужно дежурной смене для самостоятельной работы: не только набор сценариев, но и логику их изменений, маршруты уведомлений и порядок действий при инциденте. Документация описывает проверки на том уровне детализации, чтобы ваша команда правила их своими руками, без обращения к нам.
- Схема покрытия сервисов — какие точки входа, ключевые пользовательские сценарии и внешние зависимости проверяются, какие участки осознанно оставлены без проверок и почему.
- Конфигурации проверок — шаги сценария, периодичность запуска, точки запуска из разных сетей, ожидаемые коды ответов и пороги, после которых проверка считается упавшей.
- Настройки оповещений — маршруты уведомлений по дежурным, правила группировки связанных срабатываний, подавление на время плановых работ, повторная отправка, если сигнал никто не подтвердил.
- Регламент реагирования — что считается инцидентом, кто подтверждает сигнал и в какой срок, в каких случаях проверку временно отключают как ложную и кто принимает это решение.
- Инструкция для дежурного — пошаговый разбор типового срабатывания: от открытия отчёта проверки до уведомления ответственных, эскалации и записи в журнал.
- Документация по проверкам — описание каждого сценария, его владелец, привязка к сервису, порядок правки порогов и добавления новых проверок.
- Передача знаний команде — разбор на живых срабатываниях, ответы на вопросы по спорным порогам, выдача доступов и распределение ролей.
После передачи мы обычно остаёмся на коротком сопровождении, чтобы команда прошла несколько реальных инцидентов рядом с нами. Дальше проверки живут своей жизнью: новые сценарии добавляются по мере роста сервисов, устаревшие снимаются, а схема покрытия остаётся актуальной.
Кейс: как мы убрали ложные срабатывания и ускорили реакцию
Когда инфраструктура заказчика разрослась до нескольких десятков сервисов, синтетические проверки запускались из одной точки и срабатывали по жёсткому порогу времени отклика. Любой сетевой всплеск или плановое обслуживание базы поднимало волну оповещений: за неделю дежурный получал больше сотни сигналов, из которых реальными были два-три. Настоящая авария тонула в этом потоке — её замечали в среднем через полчаса, потому что на очередное срабатывание уже никто не смотрел как на сигнал.
Что перестроили
Проверки развели по уровням. Внешние сценарии — вход, авторизация, ключевой пользовательский путь — вынесли на несколько независимых точек присутствия, чтобы отличать падение сервиса от проблем на канале конкретного оператора. Порог заменили на подтверждение: оповещение уходило только после нескольких подряд неудачных попыток, а короткие отклонения по времени отклика перевели в наблюдение без пробуждения дежурного. Сценарии описали как код и собирали в Grafana, где сигнал сразу виден рядом с метриками сервиса.
Что стало
Доля ложных срабатываний упала с 86% до 7%, и шум в оповещениях перестал быть фоном. Среднее время реакции на реальный сбой сократилось с получаса до двух-трёх минут: теперь приходит один сигнал, привязанный к конкретному пользовательскому сценарию, с готовым порядком действий для дежурного. Разбор инцидента занимает минуты вместо часов — по истории проверок сразу видно, что именно ломалось и на каком шаге.
Что делать, если проверки уже настроены, но сигналы бесполезны?
Чаще всего дело не в инструменте, а в том, что проверки живут с первого запуска: опрашивают один адрес, ничего не знают о части сервисов и срабатывают позже, чем сбой замечает клиент. Сигнал приходит, когда проблема уже разошлась по пользователям, и дежурный привыкает его игнорировать — доверие к оповещениям ломается именно здесь.
Сигналы запаздывают по двум причинам: период проверки больше допустимого времени недоступности, а на подтверждение отказа уходит несколько циклов. Отсчёт ведём от целевого времени обнаружения — сколько сервис может не отвечать, прежде чем это увидит клиент, и уже под него подбираем частоту и число подтверждений. Заодно разделяем внешние и внутренние проверки: из закрытого контура не видно отказов маршрутизации и сертификатов.
Реальный отказ отделяется от шума переходом от проверок «процесс отвечает» к сценариям сквозного пути: вход, ключевая операция, выдача результата. Ложные срабатывания уходят, когда сценарий не завязан на один внешний сервис, имеет запас по времени ожидания и запускается с нескольких точек. Оставшийся шум разбираем адресно — правим порог или убираем проверку, а не глушим канал.
Дежурство и эскалация настраиваются по сервисам: оповещение попадает к тем, кто может починить, с окнами тишины на плановые работы и правилом «не подтвердил — ушло выше по цепочке». Тогда ночной сигнал становится поводом действовать, а не фоном.
Перестройка идёт итеративно: инвентаризация того, что проверяется сейчас, затем сценарные проверки критичных путей, потом чистка по итогам каждого срабатывания. Метрика доверия здесь — доля оповещений, по которым действительно что-то сделали.
Сомнения и ограничения: что важно учесть заранее
Синтетическая проверка видит ровно тот путь, который в неё заложили. Если сценарий входит под сервисной учётной записью и обращается к одному адресу, падение на шаге оплаты или выгрузки он не заметит, а зелёный статус создаст ложную уверенность. Проверка из внешней сети не покажет деградацию между сервисами внутри контура, и наоборот: запущенная внутри, она не увидит проблем у провайдера и в DNS.
Отдельная статья — нагрузка. Частые проверки с полным обходом сценария на каждой площадке складываются в поток запросов, заметный на слабом стенде и на внешних сервисах с лимитами. Поэтому частоту и глубину сценария считают заранее, а тяжёлые проверки уводят на отдельный контур.
Проверка зелёная, а клиенты жалуются. Почему?
Сценарий идёт по одному фиксированному маршруту, а живой трафик — через другие шаги, кэш, регион и версию клиента. Синтетика надёжно ловит полный отказ, но не видит частичную деградацию: медленный ответ, ошибки на части запросов, проблемы у отдельных групп пользователей. Рядом нужно наблюдение за реальным трафиком и журналы.
Стоит ли проверять сценарии с авторизацией?
Да: вход, продление сессии и выход ломаются чаще всего, а без них проверка не дойдёт до личного кабинета. Учётные данные хранят в секретах, а не в тексте сценария, под отдельной ролью с правом только на чтение и ограничением по адресам, откуда разрешён вход.
Внутренние и внешние проверки — что выбрать?
Оба слоя закрывают разное. Внешние показывают то, что видит клиент: доступность домена, срок действия сертификата, ответ на ключевых страницах. Внутренние — состояние сервисов за балансировщиком. С одним слоем картина будет односторонней.
Обсудим задачу и вернёмся с оценкой и планом
Чтобы вернуться с оценкой и планом работ, а не с уточняющими вопросами, нам достаточно нескольких вводных по инфраструктуре и ожиданиям. Собираем их на первом разговоре — он задаёт порядок старта и границы проверок.
- список сервисов и точек входа, доступность которых важна, с пометкой критичности: что может лежать час, а что не должен падать вовсе;
- пользовательские сценарии, которые нужно проверять целиком — вход, поиск, оформление заказа, оплата, ответ внешнего интерфейса;
- как о сбое узнаёте сейчас — жалобы, дежурный, отдельная система — и сколько времени проходит до сигнала;
- где размещены сервисы и из каких сетей должны идти проверки, чтобы видеть картину снаружи, а не только изнутри;
- требования к доступам, режим согласований и окна регламентных работ, чтобы проверки не будили дежурного на плановом обслуживании;
- ожидаемый порядок старта: пилот на одном критичном контуре или сразу весь список сервисов.
Из этих данных собираем состав работ по проверкам: какие сценарии автоматизируем, с какой частотой и из каких точек запускаем, как настроим уведомления и отсечём ложные срабатывания. Дальше возвращаемся с оценкой сроков внедрения, этапами, ответственными и критериями приёмки. Опишите задачу в удобном виде — обсудим её и вернёмся с планом.
