Circle K сократила разбор инцидентов с 45–60 до менее чем 15 минут

После срабатывания алерта инженер обычно ещё не чинит систему. Сначала он открывает метрики, ищет нужные строки в логах, проверяет состояние контейнеров, читает документацию сервиса и смотрит последние изменения в коде. В Circle K такой разбор занимал 45–60 минут. Компания автоматизировала именно эту часть работы: агент собирает контекст из нескольких источников и отправляет дежурному в Slack вероятную причину сбоя, доказательства и следующие шаги.

По внутренним метрикам Circle K, среднее время первичного разбора сократилось до менее чем 15 минут — на 67–75%. Простые случаи обрабатываются за 5–8 минут. Это не независимый эксперимент, а опубликованный AWS разбор внедрения собственного сервиса, поэтому цифры стоит воспринимать как результат конкретной команды, а не обещание для любой инфраструктуры.

Как устроен разбор

Сигнал из Grafana через Amazon SNS и SQS попадает в Lambda. В первой версии два специализированных агента работали параллельно. Один проверял состояние задач ECS, балансировщиков, метрик и логов CloudWatch. Второй искал прикладные ошибки и трассировки в OpenSearch, а также доставал из базы знаний карточку сервиса с его зависимостями.

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

Представим всплеск ответов HTTP 5xx. Проверка инфраструктуры обнаруживает перезапуски контейнеров, логи показывают отказ соединения с PostgreSQL, а анализ репозитория — создание нового подключения на каждый запрос. Если незадолго до сбоя началась маркетинговая кампания, система связывает рост нагрузки с исчерпанием пула соединений. Дежурный получает не россыпь сообщений, а проверяемую гипотезу и варианты исправления: переиспользовать соединения, добавить RDS Proxy или скорректировать масштабирование.

Что изменилось при росте нагрузки

Когда объём логов и контекста вырос, отдельным узлам Bedrock Flows стало не хватать времени. Команда сначала усилила фильтрацию и сократила передаваемый контекст, а затем перенесла логику в Amazon Bedrock AgentCore Runtime. Три агента объединили в один процесс с сохраняемым состоянием, а доступ к OpenSearch, базе знаний и GitHub централизовали через AgentCore Gateway.

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

Что можно повторить без привязки к AWS

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

Circle K отдельно отмечает, что полезнее заранее отфильтровать логи и передать модели релевантные строки, чем заставлять её самостоятельно перебирать огромные массивы. Но такой фильтр может скрыть важный сигнал, а модель — убедительно связать несвязанные события. Поэтому результат агента должен оставаться гипотезой: с временными метками, источниками и возможностью быстро проверить каждый вывод. Лучший первый этап внедрения — теневой режим на истории инцидентов, измерение времени, точности причин и доли ложных рекомендаций, а уже затем подключение к рабочему каналу дежурных.