AWS научила мониторинг проверять не серверы, а смысл дашбордов

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

Пять стадий вместо одного «умного» промпта

Цикл начинается с реестра разделов в Amazon Redshift и расписаний EventBridge. Для визуального контроля Lambda запускает headless browser и открывает раздел так, как его открыл бы пользователь. Снимок проходит через Amazon Rekognition: распознанные тексты маскируются, а числа заменяются синтетическими значениями до сохранения в S3. Так модель получает структуру экрана, но хранилище не накапливает исходные чувствительные показатели.

На стадии анализа Claude через Amazon Bedrock ищет пустые плитки, сообщения об ошибках и пропавшие визуализации. Контекст нужен для самой сложной развилки: пустой график может быть поломкой, а может быть корректным результатом выбранного фильтра. Выход модели ограничен структурированным вердиктом и confidence score; неоднозначные случаи направляются человеку, а не превращаются в автоматический алерт. Затем владельцу раздела приходит Slack-уведомление со скриншотом, оценкой уверенности и ссылкой на расследование.

LLM читает, код считает

Вторая ветка проверяет одинаковые показатели на разных панелях. Названия, единицы и расположение метрики могут отличаться, поэтому модель находит нужный элемент и извлекает значение. Но нормализацию единиц, округление, допустимые отклонения и окончательное matched/mismatched выполняет обычный код. AWS пришла к этому после схемы с двумя LLM, включая модель-судью и calculator tools: ошибки возникали не столько в сложении, сколько в непоследовательных правилах сравнения.

Разделение обязанностей здесь важнее выбора конкретной модели. Семантическая часть отвечает на вопрос «это та же самая метрика?», а детерминированная — «совпадают ли два числа по заранее заданным правилам?». После замены модельного сравнения программным обновления моделей улучшили recall извлечения с 0,88 до 0,95, не меняя сам критерий вердикта.

Что показала эксплуатация

За 30 дней система провела 153 000 проверок и обнаружила 802 контентных сбоя — 0,52% от общего числа. Менее одного процента найденных случаев имели соответствующее пользовательское обращение. Среднее время обнаружения сократилось с периода до 72 часов до менее часа: визуальная проверка запускается ежечасно. Отдельный числовой механизм более шести месяцев работает недельными циклами и сравнивает по 50–70 точек за цикл.

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

Практический вывод

Главный урок — не пытаться заменить одним LLM все уровни контроля. Endpoint monitoring, проверки данных и визуальная валидация отвечают на разные вопросы и должны дополнять друг друга. Для алертов особенно опасны ложные срабатывания: владельцы быстро перестают доверять системе, которая не отличает корректный ноль от поломки. Поэтому AWS сознательно предпочла объяснимость и human review скорости любой ценой.

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

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