Мониторинг оформления заказа: синтетический покупатель вместо одного ping

Главная страница отвечает за 120 миллисекунд, статус 200, график зелёный. А покупатель нажимает «Оформить заказ» и видит бесконечный индикатор загрузки. Ping честно проверил то, что умеет: сервер жив, веб-сервер принимает соединения, шаблон главной отрисовывается. Продажа же устроена иначе. Это цепочка из десятка действий, и обрывается она чаще всего не на входе, а на третьем-пятом шаге: на расчёте доставки, на запросе к платёжному модулю, на записи заказа.

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

Путь покупателя глазами робота

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

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

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

Что доказывает, что заказ действительно принят

HTTP-статус 200 доказывает лишь то, что сервер ответил страницей. Страница с текстом «Спасибо за заказ» доказывает чуть больше, но фронтенд иногда показывает её оптимистично, не дожидаясь подтверждения от бэкенда. Настоящее доказательство лежит в данных системы. Есть несколько уровней, от слабого к сильному:

• Видимый результат. На странице появился номер заказа в ожидаемом формате. Уже лучше, чем текст благодарности, потому что номер выдаёт бэкенд.
• Письмо или уведомление. Тестовый ящик получил письмо с этим номером. Это проверяет ещё и очередь отправки.
• Запись в системе. По номеру заказ находится в админке или через служебный запрос, статус корректный, сумма совпадает с ожидаемой.

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

Столь же важна проверка суммы. Если тестовый товар стоит 10 условных рублей, а в корзине оказалось 0 или 1000, это поломка расчёта цены, которую не заметит ни ping, ни кликер без сверки.

Оплата: где проходит граница, за которую робот не заходит

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

Есть три разных варианта, и выбирать между ними нужно сознательно.

На практике удобно разделить задачу на две проверки с разной частотой. Первая, частая: путь до заказа с безденежным способом оплаты, раз в несколько минут. Вторая, более редкая: путь с оплатой в sandbox провайдера, например раз в полчаса или час. Так вы быстро замечаете обрыв самой воронки и отдельно следите за платёжным звеном, не нагружая тестовый контур провайдера без нужды.

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

• в окружении робота лежит только тестовый ключ, боевого там нет физически;
• сценарий в начале проверяет, что страница оплаты работает в тестовом режиме (по признаку, который даёт провайдер или ваш модуль), и если признака нет, останавливается до ввода платёжных данных.

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

Свой товар, свой покупатель, своя уборка

Робот не должен покупать то, что продаётся людям. Заведите для него отдельные сущности:

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

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

Есть три рабочие стратегии, их можно сочетать:

1. Пометка и исключение. Каждый заказ робота несёт признак теста. Отчёты, выгрузки и аналитика его игнорируют. Это минимум.
2. Автоматическая отмена. Сразу после проверки робот переводит заказ в статус «отменён» штатным способом, причём это же проверяет, что отмена работает. Следите, чтобы отмена не запускала возврат реальных денег и не слала письма живым людям.
3. Периодическое удаление. Отдельное задание раз в сутки удаляет или архивирует заказы с признаком теста старше нескольких дней. Несколько дней нужны, чтобы при расследовании инцидента было что посмотреть.

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

Уведомление, которое называет шаг

Теперь вернёмся к началу. Допустим, робот упал. Что получит дежурный? Сообщение «проверка не пройдена» бесполезно: придётся самому открывать сценарий и гадать. Хорошее уведомление отвечает на три вопроса: где остановились, что ожидали, что увидели.

Сравните два сообщения:

Проверка «оформление заказа» не пройдена.

Остановка на шаге 5 из 6, «подтверждение заказа». Ожидался номер заказа на странице, за 15 секунд он не появился. Последний ответ сервера: 502. Предыдущие шаги заняли 4,1 секунды. Запуск из точки проверки на отдельном сервере.

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

Ещё два приёма заметно улучшают сигнал:

• Повтор перед тревогой. Одиночный сбой может быть случайностью: сеть моргнула, провайдер на секунду не ответил. Тревога после двух-трёх подряд неудачных запусков экономит нервы. Но не растягивайте очередь повторов настолько, чтобы реальная поломка длилась полчаса до первого сообщения.
• Тайминги как ранний признак. Если шаг оформления обычно занимает две секунды, а сегодня восемь, заказ пока проходит, но система уже страдает. Мягкое предупреждение о замедлении часто приходит раньше обрыва.

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

Когда ломается не магазин, а сам робот

Самая коварная ситуация наступает после очередного обновления витрины. Дизайнер переименовал кнопку, поменял разметку формы, добавил баннер с согласием на cookie, который перекрыл кнопку «Оформить». Магазин работает прекрасно, но робот не находит нужный элемент и поднимает тревогу. Через неделю таких ложных сигналов команда начинает их игнорировать, и мониторинг фактически умирает, а это хуже его отсутствия.

Чтобы отличать сломанный магазин от сломанного робота, помогают такие меры:

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

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

Где живёт робот и сколько ему нужно

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

Браузер — самая прожорливая часть. Ориентируйтесь на собственные замеры: запустите сценарий вручную, посмотрите потребление памяти и процессора в момент пика и добавьте запас. Ресурсы тарифа не равны обещанию ёмкости, поэтому не берите цифры из каталога за готовый ответ. У MAATRIX в публичном предложении перечислены тарифы от Ba (1 vCPU, 2 ГБ RAM, 40 ГБ NVMe) до Djed (16 vCPU, 32 ГБ, 320 ГБ), NVMe-диски и процессоры AMD EPYC, root-доступ, а также локации UK, US, RU и FR. Для одного сценария в браузере логично начать с младших тарифов и сверить результат с замером, а вот для нескольких параллельных сценариев потребуется больше памяти.

Локация тоже часть проверки. Если покупатели в России, имеет смысл запускать робота из локации, близкой к ним, а второй экземпляр — из другой, чтобы различать «магазин недоступен всем» и «недоступен из одного региона». Подробности наличия и параметров конкретной конфигурации уточняйте в форме заказа на странице аренды VPS MAATRIX: там же указаны способы оплаты картой РФ и СБП и автоматическое создание сервера после оплаты.

Про параллельность: в документации Playwright для CI рекомендуется начинать с одного worker ради воспроизводимости, а более мощная машина может выполнять тесты параллельно. Для синтетического мониторинга это почти прямое руководство к действию: запускайте сценарии последовательно, пока не появится причина иначе. Параллельные заказы с одним тестовым аккаунтом могут мешать друг другу, например делить одну корзину. Если сценариев станет много, можно распределить их между задачами; sharding в документации описан именно как распределение набора тестов между CI jobs, но для мониторинга это уместно лишь когда каждому сценарию выделены свои тестовые данные.

Подробнее о построении самого сценария проверки магазина на сервере, от карточки до тестового заказа, читайте в материале про проверку интернет-магазина через Playwright. Здесь мы обсуждали не технику написания тестов, а то, что должно стоять вокруг них, чтобы сигнал был правдивым.

Расписание и цена каждого прогона

Частота запусков — компромисс между скоростью обнаружения и нагрузкой. Условный пример: сценарий идёт 20 секунд и запускается каждые 5 минут. Это 288 заказов в сутки и немногим более полутора часа браузерной работы в месяц на каждые 100 запусков. Если выручка магазина за час исчисляется ощутимыми суммами, пятиминутная задержка обнаружения оправдана, а если заказов десяток в день, достаточно реже, иначе робот создаст больше заказов, чем настоящие покупатели.

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

Передача владельцу

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

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

Последний пункт спасает от привычки «заглушим на время» с забыванием включить. Лучше, чтобы пауза имела срок и сама истекала.

Что теперь означает зелёный цвет

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