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

Цикл інцидентів, який забирає весь день інженера забезпечення надійності

Більша частина дня інженера забезпечення надійності сайту пройде у одному повторюваному циклі: спрацьовує попередження, хтось починає розбиратися, з’ясовується первинна причина, впроваджується виправлення та замовлення закривається. Кожен крок вимагає часу, а середній час усунення проблеми (MTTR) може становити від хвилин до годин. У міру зростання обчислювальних ресурсів у хмарі ця ручна процедура перетворюється на вузьке місце.

AgentSRE — це автономна платформа для управління інцидентами в AWS, створена саме для подолання цього вузького місця. Вона керує інцидентом від моменту виявлення до усунення за допомогою складових AI-агентів, кожен з яких спеціалізується на певному типі завдань з усунення проблем. Дизайн передбачає використання низки малих, взаємодіючих агентів замість одного монолітного скрипта автоматизації, причини цього наведені нижче.

Як виглядає типовий інцидент

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

Усі ці кроки є необхідними, проте більшість з них є механічними. Інженер не розв’язує нової задачі — він дотримується знайомої схеми діагностики та усунення проблем, і це має реальні наслідки. Зміна контексту, навігація по панелях керування та ручне виконання запитів збільшують час, необхідний для вирішення проблеми, коли інцидент триває довше, ніж слід.

Якщо діагностичний алгоритм зрозумілий, а спосіб виправлення чітко визначений, весь цикл можна автоматизувати, при цьому людина все одно схвалює зміни. AgentSRE охоплює весь життєвий цикл інциденту у п’яти етапах: виявлення, розслідування, прийняття рішення, виконання та закриття.

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

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

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

У діаграмі архітектури все починається зліва: сповіщення від CloudWatch надходить у потік, що працює за принципом подій. Теми SNS розсилають сповіщення, функція Lambda відкриває інцидент у ServiceNow, а агент AWS DevOps починає самостійне розслідування. Результати знаходяться у фронтенді на базі React, розділеному на розділи „Чат“, „Інциденти“ та „Звіти“. Унизу три варіанти відображення топології дозволяють операторам бачити візуальний вигляд кожного інциденту. Отже, одна діаграма охоплює весь процес від виявлення до візуалізації, і жоден етап не чекає на ручну передачу інформації.

Виявлення

Перший сигнал — це сповіщення CloudWatch про аномалію, наприклад високу затримку читання даних, вичерпані з’єднання чи постійно зростаючу чергу нерозібраних повідомлень. Воно публікує інформацію у тему SNS, що запускає функцію Lambda для надсилання сповіщень, яка одразу створює інцидент у ServiceNow та розпочинає розслідування за допомогою агента AWS DevOps Agent. На цьому етапі зовсім не потрібна участь людини.

Розслідування

Агент AWS DevOps Agent — це керована послуга, яка автономно проводить розслідування. Він аналізує показники CloudWatch, дані RDS Performance Insights та журнали повільних запитів, сам визначаючи, які дані є значущими у зв’язку зі сповіщенням. Асинхронна функція Lambda збирає отримані результати та записує їх у DynamoDB.

Amazon Bedrock, який запускає Claude, потім узагальнює результати дослідження у короткому описі первинної причини, оцінці впливу та рекомендаціях щодо пом’якшення наслідків. Цей огляд розташовується у верхній частині вікна перегляду розслідування, а повний аналіз — нижче.

На скріншоті показано вікно з результатами розслідування: спочатку огляд, а потім деталі.

Рішення та керування

Перед застосуванням будь-яких змін виконуються перевірки безпеки. Механізми контролю аналізують кожну SQL-запит та відхиляють такі, що можуть завдати шкоди, наприклад, створення запитів на видалення таблиць чи рядків без умови WHERE. Дія отримує рівень ризику та надсилається людині для затвердження. У діалоговому вікні підтвердження вказується точний запит, цільовий ресурс та спосіб скасування змін.

Етап участі людини є навмисним. Повна автономія — це потужно, але зміни в продакшні вимагають моменту людського оцінювання, особливо для операцій із високим ризиком.

Вищий діалог — це те, що бачить оператор, коли його просять підтвердити виправлення.

Надсилання виправлення до правильного агента

Як тільки виправлення схвалене, оркестратор класифікує категорію усунення проблеми та надсилає запит відповідному агенту. Саме тут проявляється користь від можливості композиції.

Діаграма детально ілюструє процес усунення проблем. Коли хтось схвалює виправлення, оркестратор бере на себе керування та виконує три завдання: він класифікує первинну причину проблеми, застосовує заходи безпеки SQL та передає запит відповідному фахівцю, водночас записуючи операцію в DynamoDB. Далі існують два шляхи подальших дій. З боку бази даних станова машина LangGraph у Amazon Bedrock AgentCore перевіряє SQL-запит за допомогою ШІ-аналітика, виконує його щодо бази даних через гейтвей Lambda у VPC та записує результат у Jira разом із записом аудиту. З боку черги процес відбувається аналогічно для завдань, таких як спорожнення черги непрочитаних повідомлень чи надсилання повідомлень назад туди, звідки вони надійшли.

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

Як працює класифікація

Інтелект, який забезпечує цю функціональність, знаходиться в оркестраторі. Коли агент AWS DevOps завершує роботу, він створює аналіз первинної причини проблеми мовою природи, а оркестратор читає його та призначає категорію усунення проблеми перед тим, як запустити будь-який агент.

Класифікація відбувається у два кроки. Спочатку структурований парсер шукає в аналізі заздалегідь визначений блок корекції, який вказує тип виправлення, цільовий ресурс та заплановану дію. Якщо такого блоку немає, оркестратор звертається до класифікатора на основі мовної моделі в 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, вже заповнений деталями сповіщення, пріоритетом та категорією; спочатку шукається вже існуючий відкритий інцидент, щоб уникнути дублікації. Таким чином, заява існує з самого початку, і нікому не потрібно її подавати.

У міру розвитку інциденту AgentSRE додає оновлення до заяви. Результати розслідування записуються як примітки до роботи, тож кожен, хто переглядає заяву, бачить повний аналіз причин у контексті. Коли виконується виправлення, результат — з описом вжитих дій, кінцевим ефектом та часовою міткою — стає ще однією приміткою до роботи. Після успішного вирішення проблеми платформа переміщує заяву у статус «вирішено» та додає примітки з описом рішення.

У результаті у 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. Шар знань може використовувати уроки з минулих інцидентів для покращення майбутніх рекомендацій. А оскільки паттерн агентів не прив’язаний до однієї хмари, цей підхід може бути застосований у багатохмарних середовищах.

Архітектурні висновки

Автономне управління інцидентами виявляється як практичним, так і доцільним, коли воно ґрунтується на правильних принципах: автономне розслідування, композитні агенти для усунення проблем, людське схвалення та детальні перегляди топології. Разом вони значно скорочують середній час усунення проблем, зберігаючи при цьому безпеку та повну відстежуваність.

Ключовий урок стосується архітектури. Розділення процедур виправлення на спеціалізовані, комбіновані агенти замість однієї автоматизації відповідає реальним практикам команд з обслуговування, дозволяє системі розширюватися та робить кожну дію видимою. У міру того, як хмарні середовища стають все складнішими, це є масштабованим шляхом до операцій, керованих ШІ.