Circle K reduce el análisis de incidentes de 45–60 minutos a menos de 15

Cuando salta una alerta, el ingeniero normalmente aún no está arreglando el sistema. Primero abre las métricas, busca las líneas relevantes en los logs, comprueba el estado de los contenedores, lee la documentación del servicio y revisa los últimos cambios en el código. En Circle K este análisis llevaba entre 45 y 60 minutos. La empresa automatizó precisamente esa parte del trabajo: un agente recopila contexto de varias fuentes y envía al ingeniero de guardia, por Slack, la causa probable del fallo, las evidencias y los siguientes pasos.

Según las métricas internas de Circle K, el tiempo medio del análisis inicial se redujo a menos de 15 minutos, un 67–75 % menos. Los casos sencillos se resuelven en 5–8 minutos. No es un experimento independiente, sino un análisis publicado por AWS sobre la implantación de su propio servicio, por lo que las cifras deben tomarse como el resultado de un equipo concreto, no como una promesa válida para cualquier infraestructura.

Cómo funciona el análisis

Una señal de Grafana llega a Lambda a través de Amazon SNS y SQS. En la primera versión, dos agentes especializados trabajaban en paralelo. Uno comprobaba el estado de las tareas de ECS, los balanceadores, las métricas y los logs de CloudWatch. El otro buscaba errores de aplicación y trazas en OpenSearch, y además extraía de la base de conocimiento la ficha del servicio con sus dependencias.

Después, un tercer agente consultaba GitHub: localizaba el repositorio del servicio afectado y estudiaba el código, los archivos de infraestructura y los últimos commits. Una llamada final al modelo combinaba los resultados en un informe breve: causa probable, hechos que la respaldan, responsable del servicio y acciones recomendadas.

Imaginemos un pico de respuestas HTTP 5xx. La revisión de infraestructura detecta reinicios de contenedores, los logs muestran un rechazo de conexión a PostgreSQL y el análisis del repositorio revela que se crea una conexión nueva en cada solicitud. Si poco antes del fallo comenzó una campaña de marketing, el sistema relaciona el aumento de carga con el agotamiento del pool de conexiones. El ingeniero de guardia no recibe una lluvia de mensajes, sino una hipótesis verificable y opciones de corrección: reutilizar conexiones, añadir RDS Proxy o ajustar el escalado.

Qué cambió al crecer la carga

Cuando aumentó el volumen de logs y de contexto, a los nodos individuales de Bedrock Flows empezó a faltarles tiempo. El equipo primero reforzó el filtrado y redujo el contexto transmitido, y después trasladó la lógica a Amazon Bedrock AgentCore Runtime. Los tres agentes se unificaron en un solo proceso con estado persistente, y el acceso a OpenSearch, la base de conocimiento y GitHub se centralizó mediante AgentCore Gateway.

En la práctica importan tres decisiones. Primero, el agente puede precisar sus consultas durante la investigación sin perder el contexto ya encontrado. Segundo, las trazas de OpenTelemetry muestran la duración de los pasos y los cuellos de botella. Tercero, las herramientas obtienen un acceso limitado y gestionado de forma centralizada a los datos.

Qué se puede replicar sin depender de AWS

La idea principal no está en la elección del modelo ni en la autonomía total. Conviene empezar por automatizar la recopilación repetible de hechos, dejando la decisión y la corrección en manos del ingeniero. Divida las fuentes en infraestructura, logs de aplicación, documentación y código; otorgue a cada herramienta los permisos mínimos; exija que el informe final cite datos observables.

Circle K señala por separado que es más útil filtrar los logs de antemano y pasar al modelo las líneas relevantes que obligarlo a recorrer por sí solo enormes volúmenes. Pero ese filtro puede ocultar una señal importante, y el modelo puede vincular de forma convincente eventos no relacionados. Por eso el resultado del agente debe seguir siendo una hipótesis: con marcas de tiempo, fuentes y la posibilidad de verificar rápidamente cada conclusión. La mejor primera etapa de implantación es un modo sombra sobre el historial de incidentes, midiendo el tiempo, la precisión de las causas y la proporción de recomendaciones erróneas, y solo después conectarlo al canal real de guardia.