Создание автономного Copilot SRE для AWS с использованием MCP, Bedrock Nova и подтверждения от человека.

Примерно год индустрия сосредоточена на ChatOps: использовании больших языков моделей в Slack или Telegram в качестве умных оболочек для пайплайнов CI/CD. Однако чат-боты — это лишь видимая часть проблемы. Настоящая ценность для предприятий заключается в переходе от реактивных чат-ботов к автономным агентам. Автономный помощник по инженерии надежности сайта (SRE), созданный на базе Amazon Bedrock (Nova), протокола Model Context Protocol (MCP) и сервисов AWS, демонстрирует, как это может выглядеть. Он делает гораздо больше, чем просто запускает пайплайны: самостоятельно анализирует происходящие в продакшене инциденты, собирает метрики и логи, выявляет корни проблем и применяет исправления, при этом всё происходит внутри защищенной среды с участием человека.

Управляемый вариант: AWS DevOps Agent

Прежде чем создавать что-либо собственное, архитектор должен узнать, не предлагает ли AWS уже такое решение. Оно действительно существует, хотя и в определенной форме. AWS представила DevOps Agent на конференции re:Invent 2025; превью версия стала доступна в декабре 2025 года, а полная версия — в марте 2026 года. Это серьезная многоагентная система, предназначенная для автономного реагирования на инциденты в AWS.

Она значительно превосходит более старые инструменты вроде DevOps Guru:

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

Проверки готовности к выпуску. Они позволяют оценить изменения в коде и процессы развертывания перед тем, как они попадут в производственную среду.

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

Широкая интеграция. Datadog, Dynatrace, New Relic, Splunk, PagerDuty, GitHub, GitLab, ServiceNow и Slack подключаются без дополнительных настроек.

На бумаге это покрывает все, что может понадобиться команде SRE.

Зачем создавать собственную систему

Проблема заключается в доступе. DevOps Agent поставляется в составе пакетов поддержки AWS уровней Business+ и Enterprise и не доступен широкой публике по запросу. Организации, использующие поддержку уровня Developer Support, стартапы, независимые команды или консультанты, работающие в аккаунтах клиентов без Enterprise Support, просто не могут им воспользоваться.

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

Основная проблема: инструменты в масштабе

Такие модели, как Amazon Nova, понимают распределенные системы, архитектуру AWS и сложную отладку. Однако по умолчанию они остаются своего рода «мозгами в банке» — они не могут отображать показатели CloudWatch или взаимодействовать с таблицами DynamoDB.

Использование внешних инструментов для LLM традиционно подразумевало создание хрупкого пользовательского кода:

1. Определить схему JSON для инструмента.
2. Написать функцию на Python для ее запуска.
3. Заложить учетные данные AWS непосредственно в код агента.

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

Появление MCP

Протокол Model Context Protocol, представленный компанией Anthropic и быстро ставший отраслевым стандартом, эффективно решает эту проблему. Это стандартизированный протокол, своего рода USB-C для ИИ, который соединяет модели с внешними источниками данных и инструментами. Вместо встроения инструментов AWS непосредственно в агента создаётся отдельный сервер MCP. Он находится внутри среды AWS с необходимыми ролями IAM и предоставляет строго типизированные, семантически корректные инструменты через стандартный протокол. Агент, работающий где угодно, подключается в качестве клиента MCP. Ему не нужны учётные данные AWS, поскольку он просто запрашивает у сервера выполнение необходимых инструментов.

Свобода выбора модели

Поскольку MCP не зависит от того, какая модель находится по другую сторону, оркестратор агентов SRE может использовать любую подходящую модель:

Amazon Nova  ─┐
Claude 3.5   ─┼──→  SRE Agent Orchestrator  ──→  MCP Server  ──→  AWS Cloud
OpenAI GPT-4o─┘          (agent.py)                (server.py)

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

Архитектура помощника SRE

1. Целевая инфраструктура

Чтобы у агента было что исправлять, с помощью Terraform развертывается стандартный серверless-микросервис: API Gateway перед функцией Lambda, которая записывает данные в таблицу DynamoDB. Умышленным недостатком является ограниченная таблица, настроенная с всего лишь 1 единицей пропускной способности для чтения и 1 единицей для записи. При любой реальной нагрузке эта API выдает ошибки ProvisionedThroughputExceededException.

2. Сервер MCP

Сервер FastMCP на Python выполняет роль интерфейса, предоставляя четыре возможности SRE:

• describe_architecture находит все ресурсы AWS (ARN) с тегом приложения.

query_cloudwatch_metrics загружает данные временных рядов, такие как ThrottledRequests.

query_cloudwatch_logs выполняет запросы CloudWatch Logs Insights для поиска трейсов выполнения.

remediate_dynamodb_capacity — это мутирующий инструмент, который увеличивает объем хранилища таблицы.

Границей доверия является момент, когда в процесс вмешивается человек. Инструменты с режимом только чтения полностью автономны, поэтому модель может использовать их сколько угодно для анализа. Однако инструмент для устранения проблем требует обязательного участия человека: перед вызовом API AWS он останавливается и запрашивает у оператора в терминале разрешение с пометкой [y/N], показывая при этом обоснование действий модели. Наличие проверочных точек для аудита каждого действия, изменяющего состояние системы, сформированных в соответствии с собственными правилами организации, — это то, чего не предоставляют DevOps Guru и Amazon Q.

3. Автономный агент

Этот агент — небольшой Python-скрипт, который взаимодействует с API Amazon Bedrock Converse через библиотеку boto3; для работы выбрана семейство моделей Amazon Nova благодаря их функциональным возможностям и низкой стоимости. Он выполняет автономный цикл while:

1. Он получает запрос вроде «Пользователи сообщают, что API Payment тайм-аутит. Исправьте это».
2. Он запрашивает у сервера MCP, какие инструменты доступны.
3. Он преобразует схемы инструментов MCP непосредственно в формат Bedrock Converse.
4. Он начинает анализ: находит ресурсы API Payment, проверяет их показатели, затем читает логи.
5. Он вызывает инструменты через MCP, передаёт результаты обратно в Bedrock и продолжает работу до тех пор, пока не найдёт решение и не активирует инструмент для устранения проблемы.

Как работает цикл

Получив задание выяснить причину того, почему демо-API возвращает ответы 429 и 500, агент выполняет следующие действия:

1. Он вызывает функцию describe_architecture, чтобы найти ARN таблиц Lambda и DynamoDB.
2. Затем он вызывает функцию query_cloudwatch_metrics для этих таблиц, анализирует показатель ProvisionedThroughputExceededRequests и обнаруживает резкий скачок.
3. Чтобы убедиться, он вызывает функцию query_cloudwatch_logs для функции Lambda, парсит JSON-логи и подтверждает наличие исключения ProvisionedThroughputExceededException.
4. В итоге он делает вывод о недостаточности мощностей и вызывает функцию remediate_dynamodb_capacity, запрашивая 50 RCU и 50 WCU.

Здесь сервер MCP перехватывает этот запрос и запрашивает у человека подтверждение:

=======================================================
⚠️ URGENT: AGENT REQUESTING PERMISSION TO MODIFY INFRASTRUCTURE
=======================================================
Action: Scale DynamoDB Table 'sre-copilot-payments-dev'
New Capacity: Read=50, Write=50
Agent's Reason: The table is experiencing severe throttling (ProvisionedThroughputExceededException). Scaling up to mitigate the incident.
=======================================================
Approve this change? [y/N]: y

Тот же агент также работает в качестве приложения-чата Streamlit, отображая предложенное решение и шаг утверждения. После того как человек дает согласие, мощность обновляется, и инцидент решается.

Преимущества такой архитектуры

Разделение «мозга» (Amazon Nova через Bedrock) от «рук» (API AWS) с использованием MCP обеспечивает гибкость, которой не могут дать инструменты управления AWS:

• Переносимость LLM. Замена Nova на Claude или GPT-4o требует лишь одной изменения конфигурации.
• Безопасность. Чистые учетные данные никогда не попадают в среду выполнения LLM.
• Безопасность использования. Действия проходят через настраиваемый шаг утверждения человеком.
• Расширяемость. Добавление нового инструмента — будь то PagerDuty, запрос к API Datadog или проверка тикета в ServiceNow — осуществляется с помощью одной функции @mcp.tool().

Автономность. Агент свободно исследует телеметрию с правами только на чтение, что позволяет ему выявлять необычные проблемы, которые могут ускользнуть от инструментов по поиску шаблонов, таких как DevOps Guru.

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

Для справки: спецификация MCP опубликована на modelcontextprotocol.io, а AWS Labs поддерживает open-source серверы MCP в качестве примера.