AgentSRE: Композитные ИИ-агенты для автономного устранения инцидентов на AWS

Цикл инцидентов, отнимающий весь день SRE

Большая часть времени инженера по надежности сайтов проходит в одном повторяющемся цикле: срабатывает оповещение, кто-то начинает расследование, выявляется корневая причина, вносится исправление и заявка закрывается. Каждый шаг требует времени, и среднее время устранения проблемы (MTTR) может варьироваться от нескольких минут до часов. По мере роста облачных инфраструктур такая ручная процедура превращается в узкое место.

AgentSRE — это автономная платформа управления инцидентами в AWS, созданная для преодоления этого узкого места. Она обрабатывает инцидент от момента обнаружения до устранения с помощью составных ИИ-агентов, каждый из которых специализируется на определенном типе задач по устранению проблем. Дизайн предполагает использование набора мелких взаимодействующих агентов, а не одного монолитного скрипта автоматизации; причины этого описаны ниже.

Как выглядит типичный инцидент

Представьте себе сигнал тревоги CloudWatch, указывающий на высокую задержку чтения в базе данных. Инженер, находящийся в режиме дежурства, получает уведомление, открывает панель управления, проверяет метрики и анализирует журналы медленных запросов, в итоге обнаруживая, что отсутствие индекса приводит к полному сканированию таблицы. Затем он пишет и выполняет команду CREATE INDEX, подтверждает, что проблема решена, и обновляет заявку.

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

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

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

Архитектура в одном взгляде

Платформа полностью работает на управляемых сервисах AWS, что позволяет снизить операционные затраты и обеспечивает автоматическое масштабирование.

На диаграмме архитектуры всё начинается слева: сигнал тревоги от CloudWatch поступает в поток обработки событий. Темы SNS распространяют уведомления, функция Lambda для оповещений открывает инцидент в ServiceNow, а агент AWS DevOps Agent начинает самостоятельное расследование. Результаты исследования отображаются в интерфейсе на базе React, разделенном на разделы Чат, Инциденты и Отчеты. Внизу три вида топологических представлений показывают операторам визуальный обзор каждого инцидента. Таким образом, одна диаграмма охватывает весь процесс от обнаружения до визуализации, и ни один этап не требует ручной передачи задачи.

Обнаружение

Первым сигналом является оповещение CloudWatch об аномалии, например высокой задержке чтения, исчерпании соединений или постоянно растущей очереди нераспространенных сообщений. Оно публикует данные в тему SNS, что запускает функцию Lambda для отправки уведомлений; эта функция одновременно создает инцидент в ServiceNow и начинает расследование с помощью агента AWS DevOps Agent. На этом этапе вовсе не требуется участие человека.

Расследование

Агент AWS DevOps Agent — это управляемый сервис, который автономно проводит расследование. Он анализирует метрики CloudWatch, данные RDS Performance Insights и журналы медленных запросов, самостоятельно определяя, какие данные имеют значение в связи с возникшей аномалией. Асинхронная функция Lambda собирает полученные результаты и сохраняет их в DynamoDB.

Amazon Bedrock, запускающий Claude, затем сводит результаты анализа в краткое описание корневой причины, оценку воздействия и рекомендации по устранению проблемы. Этот краткий обзор отображается в верхней части интерфейса расследования, а полный анализ — ниже.

На скриншоте показан интерфейс отображения результатов расследования: сначала обзор, а ниже детали.

Принятие решений и управление

Перед применением любых изменений выполняются проверки безопасности. Система Guardrails анализирует каждую SQL-запрос и отклоняет те, которые могут нанести ущерб, например, удаление таблицы или строк без использования условия WHERE. Каждой операции присваивается уровень риска, после чего она передаётся человеку для утверждения. В диалоговом окне подтверждения указываются точный команд, целевой ресурс и способ отката.

Участие человека является намеренным шагом. Полная автономия — мощный инструмент, но изменения в производственной среде требуют оценки со стороны человека, особенно при выполнении операций с высоким уровнем риска.

Вышеупомянутое окно диалога — это то, что видит оператор, когда от него просят подтвердить устранение проблемы.

Перенаправление задачи к соответствующему агенту

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

В диаграмме подробно показан процесс устранения проблемы. Когда кто-то одобряет исправление, оркестратор берёт управление на себя и выполняет три задачи: он классифицирует корневую причину, вводит меры безопасности для SQL-запросов и передаёт запрос соответствующему специалисту, одновременно записывая информацию об операции в DynamoDB. Далее существуют два пути дальнейших действий. С точки зрения базы данных, штатная машина LangGraph в Amazon Bedrock AgentCore с помощью ИИ-аналитика проверяет SQL-запрос, выполняет его в базе данных через гейтвей Lambda в VPC и записывает результат в Jira вместе с записью аудита. С точки зрения очередей действия происходят аналогичным образом для таких задач, как очистка очереди непрочитанных сообщений или возврат сообщений туда, откуда они пришли.

Ни один агент не обращается к ресурсу напрямую. Каждый из них использует инструменты шлюза: функцию шлюза для подключения к RDS для агента базы данных и инструмент для выполнения операций с SQS для агента очереди. Такая архитектура позволяет сохранять агенты небольшими по размеру и обеспечивает контролируемый и отслеживаемый доступ к ресурсам. После завершения работы любого из агентов общий канал результатов сохраняет их результаты в DynamoDB, добавляет примечание в ServiceNow, закрывает заявку и обновляет топологию, так что каждый инцидент заканчивается одинаково, независимо от того, какой агент им занимался.

Как работает классификация

Механизм, обеспечивающий это, находится в оркестраторе. После завершения работы агента AWS DevOps Agent он генерирует анализ корневой причины на естественном языке, оркестратор читает его и присваивает категорию устранения проблемы перед запуском любого агента.

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

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

Два агента для производственной среды

AgentSRE поставляется с двумя агентами для производственной среды, каждый из которых предназначен для одной категории действий по устранению проблем. Оба работают в виде контейнеризованных сред выполнения на Amazon Bedrock AgentCore и имеют одинаковую внутреннюю структуру: это машина состояний LangGraph с несколькими четко определенными узлами, каждый из которых оснащен механизмом для записи времени выполнения и результата.

Агент базы данных

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

Когда поступает запрос, агент сначала выбирает целевую базу данных и предложенный SQL-запрос из описания инцидента. Затем происходит проверка: аналитик на основе ИИ, работающий в Bedrock, изучает запрос, чтобы убедиться в его правильной структуре и безопасности. Эта семантическая проверка дополняет уже применённые оркестратором механизмы защиты, так что некорректный или опасный запрос сталкивается с дополнительным барьером.

После успешной проверки агент выполняет запрос, но не напрямую. Он вызывает лямбду-шлюз внутри VPC, который через механизм IAM-аутентификации подключается к целевой инстанции RDS. Таким образом, учетные данные базы данных и права на доступ к сети остаются в пределах одного контролируемого компонента, в то время как агент остаётся легковесным и не имеет прямого подключения к базе данных.

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

Агент очереди

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

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

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

Как и агент базы данных, агент очередей отправляет каждую операцию через собственную функцию-шлюз, которая выполняет вызовы boto3 SQS и ведет журнал всех действий для аудита. Он принимает либо структурированный запрос, либо текст обычным языком, и извлекает информацию о действии и ARN очереди из любого из них.

Независимость по замыслу

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

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

Отчетность и завершение

После завершения работы агент сообщает, была ли она успешной, сколько строк изменилось и сколько времени это заняло. Результат сохраняется в DynamoDB и добавляется в инцидент ServiceNow в качестве примечания о выполненных действиях; успешное завершение операции решает проблему без дальнейших действий. Все шаги фиксируются, что обеспечивает полную аудиторскую трассу от первого сигнала тревоги до её устранения.

Интерфейс операций

Автоматизация выполняет работу, но операторам всё равно нужно место для наблюдения, управления и понимания процесса. AgentSRE имеет собственный веб-интерфейс, созданный с использованием React и размещённый на AWS Amplify; он служит единым окном для всего жизненного цикла инцидента. Доступ осуществляется через систему одноразового входа Microsoft Entra ID, поэтому поставщик идентификации организации контролирует, кто может использовать инструменты оперативного управления. Интерфейс состоит из трёх зон, каждая из которых отвечает за разные задачи.

Чат

Чат представляет собой интерфейс для общения с агентом AWS DevOps Agent. Операторы могут задавать вопросы простым языком о состоянии конкретной базы данных, наличии активных сигналов тревоги или ходе расследования. Введение номера инцидента запускает полное расследование прямо из чата. Интерфейс сохраняет контекст разговора между сообщениями и справляется со медленными ответами путем повторных попыток в фоновом режиме, так что операторы получают ответ, а не ошибку.

На скриншоте показан вид чата.

Инциденты

Раздел «Инциденты» является панелью управления для повседневных операций. Каждый инцидент отображается с указанием его статуса, информацией о том, проводилось ли расследование и было ли применено решение. Оператор может начать расследование оттуда, прочитать информацию о корневой причине, посмотреть топологию и начать устранение проблемы. Для применения решения достаточно одного клика, после чего появляется диалоговое окно с подтверждением, показывающее точные изменения перед их выполнением.

Это панель управления инцидентами.

Отчеты

В разделе «Отчеты» представлен анализ всех инцидентов: количество расследований, показатели урегулирования, время среднего восстановления и разбивка по приоритетам и ресурсам. Здесь данные о отдельных инцидентах преобразуются в оперативные выводы за определенный период времени.

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

Интеграция с ServiceNow

Автономная платформа, игнорирующая существующие системы управления ИТ-услугами, приведет к большему количеству проблем, чем решит. Поэтому AgentSRE интегрируется непосредственно с ServiceNow, что означает, что каждый обработанный им инцидент отражается в системе записей, от которой уже зависят команды операционного управления.

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

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

В результате в ServiceNow формируется полная, подлежащая аудиту запись, отражающая весь автоматизированный рабочий процесс. Команды продолжают работать в знакомом им инструменте, в то время как автоматизация берет на себя тяжелую работу, а соблюдение существующих процедур позволяет использовать платформу в рамках корпоративной структуры, а не как отдельную систему, которую приходится изучать отдельно.

Это тикет в ServiceNow после его обновления платформой.

Просмотр того, что произошло: визуализации топологии

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

Топология расследования

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

Приведённый выше вид показывает топологию расследования.

Топология инфраструктуры

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

Карта инфраструктуры отображает ту же самую систему.

Топология составных агентов

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

Топология агента показывает одну попытку устранения проблемы.

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

Почему композитность приносит пользу

Создание инструментов устранения проблем в виде составных агентов, а не монолита, приносит ряд практических преимуществ.

• Расширяемость. Для добавления новой категории устранения проблем, такой как перезапуск контейнера, настройка политики масштабирования или замена учетных данных, достаточно создать один агент и зарегистрировать его в оркестраторе, при этом существующие агенты остаются нетронутыми.
• Возможность тестирования. Одну машину состояний с определенными входными и выходными данными можно тестировать изолированно, поэтому изменения в одном агенте вряд ли повлияют на другие.
• Возможность наблюдения. Каждый агент следует определенной машине состояний, поэтому его работу можно отслеживать и визуализировать, причем представление топологии составных агентов напрямую вытекает из этой конструкции.
• Многократное использование. Один агент может обрабатывать множество инцидентов. Например, агент для работы с базами данных без изменений обрабатывает создание индексов, завершение запросов и другие исправления в SQL-запросах.

Технологическая стек

Платформа объединяет эти сервисы AWS и фреймворки с открытым исходным кодом, разделенные по функциям:

• Мониторинг и сигнализация осуществляются с помощью Amazon CloudWatch, а оркестрация на основе событий — с использованием Amazon SNS в сочетании с AWS Lambda.
• Расследование проводится с помощью AWS DevOps Agent, в то время как Amazon Bedrock с Claude отвечает за логические рассуждения, составление краткого изложения и извлечение топологии.
• Amazon Bedrock AgentCore хранит агентов, а LangGraph обеспечивает их машины состояний.
• Amazon DynamoDB хранит данные о состоянии и аудит, а ServiceNow управляет жизненным циклом заявок.
• Фронтенд реализован с использованием React и React Flow для интерфейса и графиков топологии; он размещен на AWS Amplify.

Измеряемый эффект

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

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

Как это может развиваться дальше

Композитная основа открывает несколько направлений для развития. Более многочисленные агенты могут заниматься устранением проблем на уровне инфраструктуры с помощью Systems Manager или Terraform. Процессы утверждения могут проходить через инструменты совместной работы, такие как Microsoft Teams. Слой знаний может использовать уроки, извлеченные из прошлых инцидентов, для усиления будущих рекомендаций. Кроме того, поскольку паттерн агентов не связан с одной облачной платформой, тот же подход можно применять в мультиоблачных средах.

Архитектурные выводы

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

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