Circle K скоротила розбір інцидентів до 15 хвилин

Як влаштований розбір: від алерту до повідомлення в Slack

Моніторинг у Circle K веде Grafana. Коли спрацьовує алерт, сповіщення через черги AWS потрапляє до функції Lambda, яка запускає розслідування. У першій версії на Amazon Bedrock Flows його виконували три агенти в чіткому порядку:

• Паралельно працюють два агенти. Перший перевіряє контейнери ECS, балансувальники, метрики й логи CloudWatch у кількох акаунтах AWS. Другий читає логи й трасування в OpenSearch і має доступ до бази знань із «картками продуктів», тобто описами сервісів та їхніх залежностей.
• Після них агент GitHub шукає в коді, інфраструктурних файлах і свіжих комітах саме те, на що вказали перші два.
• Окремий виклик моделі без інструментів зводить усе в один формат: ймовірна причина / докази / сервіс і власник / кроки виправлення. Формат розрахований на те, щоб черговий переглянув його менш ніж за 2 хвилини.

Приклад із джерела: частка помилок HTTP 5xx понад 5% протягом трьох хвилин поспіль. Агенти знайшли вичерпаний пул з'єднань із базою PostgreSQL, у логах — помилки «connection refused», а в коді — що сервіс відкриває нове з'єднання на кожен запит. Фінальний аналіз зіставив час збою з маркетинговою кампанією, що стартувала за 10 хвилин до алерту, і запропонував виправлення в коді, а не тимчасову латку.

Де система вперлася в межі

Версія на Flows кілька місяців працювала добре: прості інциденти розбиралися менш ніж за 10 хвилин. Але обсяг даних для кожного розслідування зростав, і частина інцидентів потребувала довшого аналізу, ніж встигав один вузол Flow. Команда фільтрувала логи, скорочувала контекст, ділила сервіси на окремі Flows. Це допомогло, але логи й база знань продовжували рости.

У квітні 2026 року Circle K запустила версію на Amazon Bedrock AgentCore: три агенти об'єднали в одного, який працює в єдиній сесії й може зробити другий, точніший прохід по логах, не втрачаючи зібраного. Простий інцидент отримує зведення за 5–8 хвилин, складний багатосервісний — у межах 15.

Уроки, які переносяться на інші задачі

• Давати агенту сам текст, а не посилання на нього. Ранні версії передавали лише назви груп логів і проміжок часу; агент сам робив запити, що додавало затримку й часто повертало забагато даних. Краще спрацювало, коли Lambda заздалегідь вибирала релевантні рядки.
• Звужувати пошук знахідками попереднього кроку. Пошук у репозиторіях без зачіпки дає забагато результатів.
• Налаштовувати пошук і генерацію. Стабільні зведення дали продуманий системний промпт і підібрана температура.
• Тримати логіку аналізу окремо від оркестрації. Тому перехід на AgentCore обійшовся без переписування логіки.

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

Що перевірити, перш ніж покладатися на зведення

Система називає ймовірну причину й рекомендує виправлення, а виконує його інженер. Автоматичні дії — перезапуск, масштабування, відкат розгортання — команда лише планує через AWS DevOps Agent, і кожну дію має підтверджувати інженер у Slack.

• Чи підтверджують наведені уривки логів названу причину, а не лише збігаються з нею в часі.
• Чи є підстави вважати алерт хибним: за джерелом, на це вказують здорові сервіси й відсутність корельованих помилок.
• Які дані йдуть у модель. Для Circle K умовою було те, що Amazon Bedrock не передає дані клієнта постачальникам моделей і не використовує їх для навчання.

Скорочення на 67–75% пораховано за внутрішніми метриками команди; вартості рішення в матеріалі немає.