Створення автономного 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, стартапи, незалежні команди чи консультанти, які працюють у клієнтських проектах без підтримки рівня Enterprise, просто не можуть ним скористатися.

Ця керована послуга підходить для команд, які вже користуються послугою Enterprise Support та працюють за стандартними патернами AWS, адже AWS вже виконала більшу частину роботи, а інтеграції є широкими. Однак для архітектора ШІ цікавішим є питання про те, чи достатньо добре розуміється цей патерн, щоб можна було створити його самостійно та розширити там, де закінчується керований продукт. Саме це демонструє цей проект.

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

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

Використання ШІ поза традиційними інструментами зазвичай означало створення крихкого спеціального коду:

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 розгортається стандартний безсерверний мікросервіс: API Gateway перед функцією Lambda, яка записує дані у таблицю DynamoDB. Навмисно створена проблема полягає у таблиці з обмеженою продуктивністю — лише 1 одиницею пропускної здатності для читання та 1 одиницею для запису. Під будь-яким реальним навантаженням цей API викидає помилки ProvisionedThroughputExceededException.

2. Сервер MCP

Сервер Python FastMCP виконує функцію посередника, надаючи доступ до чотирьох можливостей 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 та продовжує роботу, поки не знайде рішення та не активує інструмент для усунення проблеми.

Цикл у дії

Коли агенту показують обмежений за пропускною здатністю таблицю DynamoDB та просять з’ясувати, чому демонстраційний 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 підтримує сервери MCP з відкритим кодом.