«Скриншоты вместо селекторов»: AWS собрала синтетический мониторинг на Nova Act и AgentCore

Зачем нужен синтетический мониторинг и почему ломаются старые скрипты

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

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

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

Как устроен агентный подход

Amazon Nova Act применяет мультимодальную большую языковую модель, которая обрабатывает скриншоты интерфейса, а не селекторы DOM, за счёт чего заметно устойчивее к изменениям внешнего вида. В ранних внедрениях у корпоративных заказчиков Amazon Nova Act демонстрировал точность выше 90 % на браузерных сценариях. AWS, впрочем, оговаривается: командам стоит проверять решение на своих сайтах и закладывать логику повторных попыток там, где адаптация не сработала. Разница в коде наглядна — вместо трёх строк с классами, идентификаторами и XPath и требования к десяти с лишним строкам явных селекторов на один сценарий появляются три вызова вида «нажать кнопку оформления заказа».

Решение собирается из нескольких сервисов, каждый из которых отвечает за своё. Nova Act описывает и исполняет сценарии работы с интерфейсом через действия на естественном языке, заменяя скрипты на селекторах зрительным и языковым рассуждением. Amazon Bedrock AgentCore Runtime даёт бессерверное исполнение с изоляцией сессий и стабильными адресами вызова, а браузерный инструмент AgentCore Browser — защищённое изолированное окружение удалённого браузера на каждый тестовый прогон, избавляя от необходимости содержать собственные браузерные фермы. Планирование и оповещения берут на себя Amazon EventBridge Scheduler и Amazon SNS.

Поток выглядит так: планировщик запускает проверку по расписанию — от каждых пяти минут до раза в час, в зависимости от критичности сценария. Каждый запуск вызывает InvokeAgentRuntime напрямую, через возможность универсальной цели в планировщике EventBridge. Агент работает внутри AgentCore Runtime и через Nova Act ведёт интерфейс действиями на естественном языке в сессии AgentCore Browser. Если сценарий падает на любом шаге, агент публикует уведомление в SNS, и оно сразу уходит на подписанные точки — почту, интеграции с чатами, инструменты реагирования на инциденты.

Браузерный инструмент AgentCore сам по себе предоставляет защищённое изолированное окружение для взаимодействия агентов с веб-приложениями и работает в контейнеризованной среде, отделяя веб-активность от вашей системы. Среди его возможностей — изоляция сессий, наблюдаемость через просмотр в реальном времени, журналирование в CloudTrail и запись сессий. Сессии запускаются изолированно и с настраиваемыми таймаутами: по умолчанию 15 минут, максимум 8 часов. Для упрощения работы с браузером можно использовать библиотеки Strands, Nova Act или Playwright.

Что проверяет агент и как не утонуть в ложных срабатываниях

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

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

Отдельный компромисс — повторные попытки. Пример агента выполняет каждый шаг с одной попытки, что минимизирует стоимость браузерной сессии. Поскольку адаптация на естественном языке срабатывает примерно в 90 % случаев, единственная попытка иногда даёт ложную тревогу, когда Nova Act не нашёл реально существующий элемент. Командам, которым нужен более низкий уровень ложных срабатываний, предлагают добавить повтор шага перед объявлением отказа — ценой более длинных сессий. Типичный сценарий из шести шагов занимает от двух до четырёх минут в зависимости от скорости загрузки страниц.

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

Развёртывание: CLI, CDK и цена каждых пяти минут

Для внедрения нужен аккаунт AWS с доступом к Amazon Nova Act, AgentCore Runtime и браузерному инструменту, Amazon ECR, IAM, EventBridge Scheduler и SNS, а также Python 3.11 или новее, Docker и настроенный AWS CLI версии 2. Для продакшен-пути дополнительно требуются Node.js 18 или новее и AWS Cloud Development Kit; отдельно приложен и самостоятельный скрипт развёртывания.

Перед вызовом агента по расписанию его разворачивают в AgentCore Runtime через Nova Act CLI: команды act workflow упаковывают код агента, отправляют образ контейнера в Amazon ECR и создают среду исполнения. После развёртывания адрес эндпоинта остаётся неизменным, а обновления создают новые версии среды, не требуя правок цели в планировщике. Скрипт deploy.py оборачивает эти команды проверками предварительных условий, создаёт тему SNS и настраивает расписание, так что развёртывание выполняется одной командой. Для повторяемого продакшен-развёртывания в примере есть стек CDK с расписанием на правах наименьшей достаточности, темой SNS и очередью SQS для недоставленных вызовов, плюс два аварийных сигнала CloudWatch — на глубину этой очереди и на пропущенные запуски.

Стоимость складывается из пяти составляющих: вызовы AgentCore Runtime, браузерные сессии, вывод модели Nova Act, вызовы планировщика EventBridge и уведомления SNS. Основные драйверы расходов — длительность браузерной сессии и обращения к выводу Nova Act на каждом шаге сценария. В примере для сценария из шести шагов, запускаемого каждые пять минут, приводится оценка примерно в 8 640 вызовов в месяц и около 207 360 обращений к действиям и утверждениям — по 24 на сценарий. Вызовы планировщика EventBridge при таком объёме оцениваются примерно в 0,009 доллара, а уведомления SNS — как пренебрежимо малые.

Изоляция, доступы и регионы

AgentCore Runtime изолирует каждое исполнение по строгой модели «одна сессия — одна микро-виртуальная машина» на базе Firecracker. По умолчанию сессия завершается с полной очисткой памяти, поэтому cookies, кеш браузера и LocalStorage не сохраняются между прогонами, что защищает от ложных срабатываний из-за утечки состояния между тестами. Для синтетических мониторов рекомендуют именно эфемерные сессии, хотя AgentCore предлагает и постоянные профили браузера через API SaveBrowserSessionProfile — они предназначены для других задач.

По умолчанию браузерный инструмент использует публичный сетевой режим — это подходит для проверки клиентских сайтов, — но для внутренних приложений AgentCore поддерживает конфигурацию с Amazon VPC, ограничивающую доступ конкретными доменами. Доступы выдаются по принципу наименьшей достаточности через IAM: роли определяют, к каким ресурсам может обращаться агент, включая права на публикацию в SNS и вызов браузерного инструмента. Если сценарии требуют аутентификации, учётные данные следует хранить в AWS Secrets Manager — так они остаются зашифрованными, а доступ аудируется через AWS CloudTrail.

Компании с пользователями по всему миру могут развернуть мониторинг в нескольких регионах AWS, чтобы проверять опыт из разных географических точек и находить региональные проблемы. Развёртывание при этом описывают инфраструктурой как кодом, чтобы раскатка по поддерживаемым регионам была воспроизводимой. Полная рабочая реализация выложена в репозитории github.com/aws-samples/sample-nova-act-synthetic-monitoring. Материал подготовили Саратх Кришнан, старший специализированный архитектор решений по генеративному ИИ и машинному обучению, Мэттью Джорат, менеджер по работе с клиентами в сегменте розницы и потребительских товаров, и Карен Хаттселл, специалист по ИИ и машинному обучению.