ИИ разбирает сбои, инженеры принимают решения: опыт Rescale

Что объявлено: агент внутри действующего процесса

AWS рассказала, как Rescale создала агента с помощью Strands SDK и методологии AI-Driven Development Lifecycle, или AI-DLC. За пятидневный практикум команда прошла путь от определения задачи до тестового окружения. Выход в производственную эксплуатацию занял недели.

Агент запускается как шаг существующего процесса Argo Workflows в Amazon EKS. Поводом служат ошибки ночного набора сквозных тестов Playwright. Такое размещение позволило использовать уже работающую инфраструктуру, не добавляя отдельную среду исполнения.

Для классификации используется Claude Opus 4.8 через Amazon Bedrock. Агент различает инфраструктурные проблемы, ошибки кода, нестабильные тесты и проблемы окружения. Затем он обращается к историческим случаям и получает журналы через Model Context Protocol.

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

Бизнес-сценарий: сократить путь от сигнала до решения

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

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

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

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

Как организовали разработку: сначала границы, затем код

В AI-DLC искусственный интеллект составляет планы, предлагает архитектуру и пишет код, а люди утверждают решения. Вместо последовательных передач между участниками используются совместные рабочие сессии. В Rescale инженеры вместе отвечали на уточняющие вопросы и согласовывали планы до продолжения работы.

Задачу разделили на базу исторических сбоев, основного агента, интеграцию с Argo и средства оценки. Границы первого этапа определяли люди. Автоматическое создание запросов на изменение кода отложили, не превращая первоначальный проект в систему самостоятельного исправления.

Архитектуру также корректировали после человеческой проверки. Размещение перенесли с Amazon Bedrock AgentCore в существующий кластер Amazon EKS, а источником журналов вместо стороннего сервиса стал Amazon CloudWatch. Решения фиксировали в общих документах, сохраняя контекст для дальнейшей реализации.

Ограничения и контроль: совпадение не равно безошибочности

По сообщению компании, совпадение классификации агента с человеческим разбором выросло с 44% при первоначальном внедрении до 68%. Улучшение связано с доработкой эталонного набора примеров и запросов к модели. Этот показатель нельзя представлять как доказательство полной надёжности системы.

Снижение времени блокировки развёртывания на 20% относится к описанному процессу Rescale. Оно не означает такого же сокращения всей длительности разработки, расходов или количества ошибок. Источник не даёт оснований переносить этот результат на любую организацию.

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

Практический чек-лист: что определить перед пилотом

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

Главный переносимый принцип этого кейса — не выбор конкретной модели, а разделение ответственности. ИИ получает узкую задачу и проверяемый контекст; команда сохраняет архитектурные решения, оценку результата и разрешение на изменения. Именно такую схему редакция предлагает рассматривать отправной точкой пилота.

Сцена по теме: Работа инженерной команды →