Esta publicación fue escrita en colaboración con Marek Klatowicz, ingeniero de DevOps en la nube de Circle K.
Muchos equipos de DevOps conocen el patrón de evaluación de incidentes: se dispara una alerta y, antes de que alguien pueda corregir el problema, un ingeniero pasa 45–60 minutos averiguando qué ocurrió. Consultan los registros, verifican el estado de los servicios y correlacionan los síntomas a través de varias herramientas. Todo esto sucede antes de que pueda comenzar la remediación.
En Circle K, este desafío creció con el negocio. La empresa opera más de 17,200 tiendas de conveniencia y estaciones de combustible en 27 países. Detrás de los establecimientos, una infraestructura nativa de la nube soporta sistemas de punto de venta, aplicaciones de fidelización y aplicaciones de carga de vehículos eléctricos (EV) que funcionan en AWS. A medida que la empresa ampliaba sus operaciones digitales, la carga de evaluación crecía con ellas. Más servicios significaban más alertas, y cada una requería la misma investigación manual antes de que pudiera comenzar la remediación.
Para abordarlo, Circle K construyó un sistema de evaluación automatizado usando Amazon Bedrock, un servicio totalmente administrado que pone los modelos fundacionales (FM) a disposición a través de una única API. Para conocer la disponibilidad de modelos por región de AWS, consulte Modelos compatibles por región de AWS en Amazon Bedrock. El sistema utiliza una arquitectura de IA agéntica para investigar cada incidente de manera autónoma y entregar un resumen estructurado en Slack dentro de los minutos siguientes al disparo de una alerta. En lugar de alertas sin procesar, los ingenieros de guardia ahora reciben contexto accionable, por lo que pueden actuar de inmediato en lugar de pasar una hora averiguando qué ocurrió.
Desde la implementación de este sistema, Circle K ha reducido el tiempo medio de evaluación a menos de 15 minutos, una reducción del 67–75 por ciento según las métricas internas de respuesta a incidentes del equipo.
En esta publicación, describimos la arquitectura tanto de la implementación inicial con Amazon Bedrock Flows como de la migración a Amazon Bedrock AgentCore, y compartimos las lecciones aprendidas al escalar el sistema.
El desafío de la carga de evaluación
El equipo de DevOps de Circle K monitorea la infraestructura en múltiples cuentas de AWS mediante Grafana. Un día típico trae alertas por reinicios de contenedores, tasas de error elevadas, picos de latencia e implementaciones fallidas. Cada alerta es una señal útil, pero a medida que el sistema se expandía, el equipo quería ayudar a los ingenieros de guardia a ver rápidamente qué señales requerían atención, con el contexto adecuado.
Cuando llegaba una alerta, la evaluación involucraba una secuencia familiar de pasos manuales: revisar los registros recientes en Amazon CloudWatch, examinar los trazas a nivel de aplicación en Amazon OpenSearch Service, verificar el estado de las tareas de Amazon Elastic Container Service (Amazon ECS) y cruzar los síntomas con los runbooks internos en GitHub. Esto les daba a los ingenieros la información que necesitaban, pero también mostraba cuánta recopilación de contexto repetitiva se requeriría a medida que se incorporaran más servicios.
El equipo identificó dos áreas donde una inversión proactiva podría ayudar. Primero, las mismas consultas de registros, verificaciones de estado y búsquedas en runbooks se repetirían para cada incidente. Segundo, la profundidad y la velocidad de la evaluación podían variar según la familiaridad del ingeniero de guardia con el servicio afectado. A medida que crecía el volumen de alertas y la propiedad de los servicios, cambiar entre múltiples herramientas para cada investigación podía ralentizar la respuesta y dificultar la aplicación consistente de las mejores prácticas del equipo.
Por lo tanto, el equipo de DevOps de Circle K inició una iniciativa de investigación y desarrollo (R&D) para explorar cómo la IA podría apoyar el monitoreo y la evaluación de incidentes. El objetivo era automatizar la recopilación de contexto repetitiva y proporcionar hallazgos estructurados y accionables, al tiempo que se respaldaba el criterio operativo de los ingenieros durante una investigación.
Por qué Circle K eligió Amazon Bedrock
El equipo evaluó varios enfoques antes de construir, incluidos frameworks de agentes de código abierto sobre infraestructura autogestionada. Ese enfoque habría significado asumir el alojamiento de modelos, el versionado de prompts, la orquestación de herramientas y los controles de seguridad.
Con Amazon Bedrock, el equipo evitó esa sobrecarga. Podían acceder a los modelos fundacionales a través de una única API e intercambiar modelos fundacionales sin reescribir el código. Como Circle K ya operaba en AWS, Amazon Bedrock se integró en las políticas existentes de AWS Identity and Access Management (IAM), las configuraciones de Amazon Virtual Private Cloud (Amazon VPC) y los pipelines de registro.
Dos capacidades administradas cubrieron la orquestación y la recuperación. Amazon Bedrock ayudó con la orquestación de agentes, brindando a los agentes el uso nativo de herramientas para llamar a las API de AWS, consultar bases de datos y recuperar documentos sin código de orquestación personalizado. Amazon Bedrock Knowledge Bases, la capacidad totalmente administrada de Generación Aumentada por Recuperación (RAG), se encargó de la ingesta y recuperación de las fichas de producto internas, por lo que el equipo no necesitó ejecutar una base de datos vectorial separada. Esto permitió que el equipo de DevOps se concentrara en el diseño de prompts y las definiciones de herramientas.
La privacidad de los datos completó el panorama. Los datos de incidentes de Circle K incluyen métricas operativas, detalles de infraestructura y registros que pueden contener información sensible. Amazon Bedrock no comparte los datos de los clientes con los proveedores de modelos ni los usa para entrenar modelos fundamentales. Para un equipo que introduce registros de producción y detalles de servicios internos en el sistema, este enfoque de manejo de datos cumplía con los requisitos de seguridad de Circle K.
Descripción general de la solución
Esta sección describe la arquitectura inicial, que el equipo construyó sobre Amazon Bedrock Flows. Una sección posterior cubre la migración a AgentCore.
La solución utiliza Amazon Bedrock Flows como capa de orquestación, coordinando un conjunto de agentes especializados que cada uno maneja una parte diferente del análisis. El pipeline comienza cuando una alerta de Grafana publica una notificación en Amazon Simple Notification Service (Amazon SNS), que la reenvía a una cola de Amazon Simple Queue Service (Amazon SQS) . Una función de AWS Lambda sondea la cola, extrae el payload de la alerta e invoca el Flow.
Dentro del Flow, se invocan dos agentes en paralelo. El AWSResourceExplorerAgent consulta la infraestructura en múltiples cuentas de workload administradas con AWS Organizations. Comprueba el estado de las tareas de Amazon ECS, la salud de los targets del Application Load Balancer, y las métricas y registros de CloudWatch. Al mismo tiempo, el OpenSearchExplorerAgent consulta Amazon OpenSearch Service en busca de registros a nivel de aplicación y trazas distribuidas. Este agente se ejecuta por separado porque OpenSearch devuelve grandes volúmenes de datos de registros. Aislarlo mantiene la ventana de contexto de cada agente manejable. También tiene acceso exclusivo a la base de conocimiento, que contiene fichas de producto que describen cada servicio y sus dependencias.
Después de que ambos agentes devuelven sus hallazgos, se ejecuta el GitHubExplorerAgent . Recibe la salida de los dos agentes anteriores y encuentra los repositorios de GitHub del servicio afectado. Luego busca en su código de aplicación, definiciones de infraestructura y commits recientes para localizar la fuente del problema y proponer una corrección concreta. Ejecutarlo después de los agentes paralelos significa que sabe exactamente qué buscar en lugar de realizar una consulta amplia.
Las tres salidas se introducen en un nodo AnalysisPrompt , que es una única llamada al modelo sin herramientas adjuntas. Recibe los datos de recursos de AWS, los registros de OpenSearch y el contexto de GitHub, y luego produce un resumen estructurado: causa raíz probable, evidencia de apoyo, servicio afectado y propietario, y pasos de remediación recomendados. La salida del prompt utiliza un formato consistente que el equipo de guardia puede revisar en menos de 2 minutos.
El Flow devuelve este resumen a la función Lambda que lo invocó, la cual lo publica en un canal de Slack. Todo el proceso, desde la alerta hasta el mensaje de Slack, toma entre 5 y 15 minutos dependiendo de la complejidad del incidente.
El siguiente diagrama muestra esta arquitectura de extremo a extremo, desde la alerta inicial de Grafana hasta el resumen final en Slack.
Figura 1: Arquitectura de triaje automatizado de incidentes de Circle K utilizando Amazon Bedrock Flows
Ejemplo de triaje
Una alerta de Grafana: la tasa de errores HTTP 5xx de un servicio supera el 5% durante 3 minutos consecutivos.
El AWSResourceExplorerAgent comprueba la salud de las tareas de ECS en la cuenta objetivo y encuentra que el pool de conexiones a la base de datos está agotado, con el servicio de ECS intentando reinicios. El OpenSearchExplorerAgent devuelve registros de aplicación que muestran errores de «connection refused» desde el servicio hacia su base de datos PostgreSQL subyacente. También recupera la ficha de producto del servicio afectado desde la base de conocimiento, que documenta su dependencia de esa base de datos. El GitHubExplorerAgent busca en el repositorio del servicio y en los archivos de infraestructura y encuentra la definición de Amazon Relational Database Service (Amazon RDS). Ve que el servicio abre una nueva conexión a la base de datos por cada solicitud en lugar de reutilizar las existentes.
El AnalysisPrompt recibe los tres resultados. Correlaciona el momento con una campaña de marketing programada que comenzó 10 minutos antes de la alerta. Lo combina con el hallazgo del GitHubExplorerAgent para recomendar una corrección concreta a nivel de código en lugar de un parche temporal.
El mensaje final de Slack dice:
Summary: XYZ Service 5xx errors caused by connection pool exhaustion
Root cause: Scheduled marketing campaign drove traffic spike; connection pool max (50) insufficient for load
Evidence: OpenSearch logs show "connection refused" at 14:32 UTC; ECS shows 3 task restarts since 14:30
Owner: XYZ team (backend)
Next steps: Add Amazon RDS Proxy to pool connections, or update the service to reuse existing connections instead of opening a new one per request; consider an Auto Scaling rule for future campaignsEscalado a Amazon Bedrock AgentCore
La arquitectura de Amazon Bedrock Flows funcionó bien durante meses, y los incidentes simples se triaban en menos de 10 minutos. Con el tiempo, el volumen de datos y el contexto detrás de cada investigación crecieron, aunque el conjunto de servicios se mantuvo igual. Algunos incidentes requerían análisis de mayor duración de lo que un solo nodo de Flow podía completar.
El equipo primero optimizó dentro del diseño existente filtrando los registros de forma más agresiva, acortando las ventanas de contexto y dividiendo ciertos servicios en Flows separados. Estos pasos ayudaron, pero los volúmenes de registros y la base de conocimiento seguían creciendo.
Amazon Bedrock AgentCore cubrió esta necesidad. AgentCore es una plataforma para construir, conectar y optimizar agentes de IA a escala con cualquier framework o modelo. Para esta carga de trabajo, la capacidad clave fue AgentCore Runtime: la investigación completa se ejecuta en una sola sesión, por lo que cada paso puede tomar el tiempo que sus datos requieran. AgentCore Runtime admite sesiones de hasta 8 horas, muy por encima de lo que las investigaciones actuales necesitan. El equipo containerizó su lógica de agente y la desplegó en AgentCore Runtime.
El siguiente diagrama muestra la arquitectura de producción tras la migración a Amazon Bedrock AgentCore.
Figura 2: Arquitectura de producción usando Amazon Bedrock AgentCore Runtime y AgentCore Gateway
La lógica de análisis sigue siendo la misma, pero la forma en que se ejecuta ha cambiado. Los tres agentes especializados de la versión de Flows ahora se consolidan en un único agente que se ejecuta en una sesión de AgentCore Runtime. La función Lambda inicia la sesión, y el agente realiza los mismos pasos que antes. Consulta recursos de AWS en varias cuentas, extrae registros de Amazon OpenSearch Service, busca en GitHub y recupera fichas de producto de la base de conocimiento. El agente devuelve sus hallazgos a la función Lambda dentro de 15 minutos, lo cual está dentro del tiempo máximo de espera de Lambda. Luego, la función Lambda publica el resumen estructurado en Slack.
Amazon Bedrock AgentCore Gateway, una capacidad de Amazon Bedrock AgentCore, actúa como intermediario del acceso del agente a sus fuentes de datos, incluidas Amazon OpenSearch Service, Amazon Bedrock Knowledge Bases y GitHub. El Gateway expone cada fuente como una herramienta que el agente invoca, lo que centraliza el control de acceso y facilita al equipo agregar o cambiar fuentes de datos.
Cómo AgentCore Runtime apoyó la escala creciente del equipo
Más allá de sesiones de mayor duración, Amazon Bedrock AgentCore Runtime agregó tres capacidades que apoyaron la escala creciente del equipo: persistencia de sesión, observabilidad basada en OpenTelemetry y flexibilidad de frameworks.
Persistencia de sesión: El agente mantiene un estado intermedio a lo largo de una investigación. Si una primera pasada sobre los registros revela algo, el agente puede ejecutar una segunda pasada, más específica, sin perder el contexto que ya ha construido. Esto encaja con la forma iterativa en que se investigan los incidentes complejos de múltiples servicios.
Observabilidad: AgentCore captura trazas de cada sesión usando los estándares de OpenTelemetry y las expone a través de CloudWatch. El equipo puede ver cuánto tarda cada paso, qué consultas a la base de conocimiento hace el agente y dónde se producen los cuellos de botella. Estos conocimientos alimentan directamente el ajuste de los prompts.
Flexibilidad de frameworks: Con AgentCore Runtime, el equipo puede implementar agentes en contenedores construidos con una amplia gama de frameworks. Pueden iterar la lógica del agente, agregar pasos de triaje o reestructurar el razonamiento del agente a medida que cambian sus requisitos, todo en el mismo Runtime.
La arquitectura de AgentCore ahora se ejecuta en producción y maneja toda la gama de incidentes, desde alertas simples de un solo servicio hasta investigaciones grandes de múltiples servicios.
Resultados
Circle K implementó la versión AgentCore del sistema de triaje en abril de 2026. Según las métricas internas de respuesta a incidentes del equipo, el tiempo medio de triaje se redujo de 45–60 minutos a menos de 15 minutos, una reducción del 67–75 por ciento. Los incidentes sencillos reciben un resumen en 5–8 minutos. Los incidentes complejos de múltiples servicios, que antes tomaban más de una hora en triarse manualmente, ahora se completan en 15 minutos.
Los ingenieros ahora parten de un resumen en lugar de recopilar el contexto por sí mismos. El equipo observa tres cambios en la forma en que se manejan los incidentes:
Triaje consistente. Cada ingeniero de guardia recibe el mismo resumen estructurado, con los mismos extractos de registros, referencias de la base de conocimiento y pasos siguientes recomendados, independientemente de cuánto conozca el servicio afectado.
Escalamiento más rápido. Cuando un problema requiere apoyo de otro equipo, el resumen le da al ingeniero de guardia el contexto relevante para un escalamiento oportuno e informado.
Manejo más rápido de falsas alarmas. Cuando el análisis encuentra servicios saludables y sin errores correlacionados, el ingeniero puede reconocer la alerta y continuar.
Lecciones aprendidas
Construir este sistema tomó varias iteraciones. Cuatro lecciones destacaron que aplican a los equipos que construyen una solución similar con Amazon Bedrock.
Incluya el contenido de los registros directamente en el prompt. Las primeras versiones pasaban solo nombres de grupos de registros y rangos de tiempo, y luego el agente intentaba consultar CloudWatch a través de grupos de acciones. Esto agregaba latencia y a menudo devolvía demasiados datos para procesar. Circle K obtuvo mejores resultados haciendo que funciones Lambda preconsultaran los registros y pasaran las líneas relevantes directamente al agente. El agente razona más rápido cuando puede leer los mensajes de error reales.
Ajuste la recuperación y la generación para los casos de uso. La configuración de recuperación afectó significativamente la calidad de los resultados de la base de conocimiento. Después de probar las opciones disponibles, el equipo de Circle K encontró que una base de conocimiento de Amazon Bedrock con su configuración predeterminada funcionaba mejor para sus datos. Amazon Bedrock maneja embeddings, indexación y almacenamiento vectorial de extremo a extremo, por lo que el equipo tiene menos componentes que mantener. En el lado de la generación, un system prompt bien diseñado y una configuración de temperatura ajustada produjeron resúmenes consistentes en Slack.
Enfoque la búsqueda de código con los hallazgos de los registros. Buscar en los repositorios del servicio sin una pista devuelve demasiados resultados para ser útil. El equipo ejecuta la búsqueda en GitHub después del análisis de recursos de AWS y de los registros, de modo que el agente ya sabe qué error, componente o cambio reciente buscar. En el ejemplo de triaje, así fue como el agente descubrió que el servicio abría una nueva conexión de base de datos para cada solicitud.
Mantenga la lógica de análisis independiente de la capa de orquestación. El tiempo de análisis crece con el volumen de datos, así que planifique que las investigaciones tomen más tiempo con el tiempo. El equipo mantuvo sus prompts, definiciones de herramientas y pasos de análisis separados de la estructura de flujo. Esto hizo posible consolidarlos en un único agente en AgentCore Runtime sin reescribir la lógica de triaje.
Pasos siguientes
Hoy, el sistema de triaje encuentra la causa raíz probable y recomienda una corrección, y un ingeniero lleva a cabo la corrección. A continuación, el equipo planea integrarse con AWS DevOps Agent, de modo que el sistema también pueda manejar remediaciones simples. Los ejemplos incluyen reiniciar una tarea, escalar un servicio o revertir un despliegue. Un ingeniero aprobará cada acción en Slack antes de que se ejecute.
El equipo también planea darle al agente más contexto con el que trabajar:
- Jira, para vincular cada incidente con tickets relacionados y dar seguimiento al trabajo pendiente.
- Confluence, para añadir documentación interna al código y los registros que el agente ya lee.
- Runbooks en la base de conocimientos, para que el agente pueda relacionar síntomas con modos de fallo conocidos y correcciones que funcionaron antes, en lugar de depender solo de las fichas de producto.
Conclusión
El equipo de Circle K pasó de 45–60 minutos de triaje manual de incidentes a menos de 15 minutos al automatizar la recopilación de contexto que los ingenieros hacían a mano. El sistema recopila datos de registros, recursos de AWS y código, permite que un agente razone sobre ellos y entrega un resumen estructurado a Slack.
El equipo creó la primera versión con Amazon Bedrock Flows y Amazon Bedrock Knowledge Bases. A medida que las investigaciones crecieron, el equipo migró a un único agente en Amazon Bedrock AgentCore Runtime, con AgentCore Gateway proporcionando acceso a sus fuentes de datos.
Si su equipo dedica la mayor parte del tiempo de respuesta a incidentes a recopilar contexto en lugar de resolver problemas, este patrón se aplica directamente. Para comenzar, explore Amazon Bedrock AgentCore y Amazon Bedrock Knowledge Bases. Para obtener orientación práctica o comentar su caso de uso con un especialista de AWS, visite la página de introducción a Amazon Bedrock o contacte con AWS.
Queremos saber cómo abordan el triaje de incidentes. Comparta su experiencia en los comentarios.