AgentSRE: Agentes de IA componibles para la remediación autónoma de incidentes en AWS

El ciclo de incidentes que consume el día de un SRE

Gran parte del día de un ingeniero de fiabilidad del sitio se dedica a un ciclo repetitivo: se dispara una alerta, alguien investiga, se identifica la causa raíz, se aplica la solución y el ticket se cierra. Cada paso lleva tiempo, y el tiempo medio de resolución (MTTR) puede extenderse de minutos a horas. A medida que crecen las infraestructuras en la nube, esa rutina manual se convierte en un cuello de botella.

AgentSRE es una plataforma autónoma de gestión de incidentes en AWS diseñada para solucionar ese cuello de botella. Permite gestionar un incidente desde su detección hasta su resolución mediante agentes de IA componibles, cada uno especializado en un tipo diferente de tarea de reparación. El diseño trata la reparación como un conjunto de agentes pequeños que colaboran entre sí y no como un único script de automatización monolítico; las razones de esto se explican a continuación.

Así es un incidente típico

Imagínese una alarma de CloudWatch que indica una alta latencia en las lecturas de una base de datos. El ingeniero de turno recibe una notificación, abre un panel de control, verifica las métricas y examina los registros de consultas lentas, hasta que finalmente descubre que la falta de un índice está obligando a escanear toda la tabla. Luego escribe y ejecuta una instrucción CREATE INDEX, confirma que la solución funcionó y actualiza el ticket correspondiente.

Todos esos pasos son necesarios, pero la mayoría son mecánicos. El ingeniero no está resolviendo un nuevo problema; simplemente sigue un patrón de diagnóstico y reparación ya conocido, y eso tiene un costo real. Cambiar de contexto, navegar por los paneles de control y ejecutar consultas a mano generan tiempo adicional mientras el incidente permanece abierto más de lo necesario.

Si se comprende el patrón de diagnóstico y la solución está bien definida, todo el ciclo puede automatizarse con una persona que sigue aprobando los cambios. AgentSRE abarca todo el ciclo de vida de un incidente en cinco etapas: detección, investigación, toma de decisiones, ejecución y cierre.

La característica distintiva es la forma en que se organiza la ejecución. Un único script extenso que intenta todas las soluciones posibles es reemplazado por agentes especializados, uno por cada categoría: un agente de base de datos para la corrección de problemas en SQL y un agente de colas para los problemas relacionados con mensajería. Cada agente es su propia máquina de estados, por lo que puede desarrollarse, probarse y lanzarse por separado, y nuevos tipos de agentes pueden integrarse sin modificar los existentes. La composibilidad es el principio central del diseño. Refleja cómo un equipo de operaciones real distribuye los problemas entre especialistas y permite que la plataforma crezca a medida que surgen nuevos tipos de soluciones.

Arquitectura a primera vista

La plataforma funciona íntegramente con servicios gestionados por AWS, lo que mantiene los costos operativos bajos y permite una escalabilidad automática.

En el diagrama de arquitectura, todo comienza a la izquierda con una alarma de CloudWatch que alimenta un pipeline basado en eventos. Los temas de SNS distribuyen la notificación, un Lambda de alertas abre el incidente en ServiceNow y el agente AWS DevOps comienza a investigar por sí mismo. Lo que encuentra se muestra en una interfaz frontal de React dividida en secciones de Chat, Incidentes e Informes. En la parte inferior, tres vistas de topología muestran a los operadores cómo se ve visualmente cada incidente. De este modo, una sola figura abarca todo el proceso desde la detección hasta la visualización, y ninguna etapa espera una transferencia manual.

Detección

La primera señal es una alarma de CloudWatch por alguna anomalía, como una alta latencia en las lecturas, conexiones agotadas o una cola de cartas perdidas que sigue creciendo. Esta alarma se publica en un tema de SNS, lo cual activa el Lambda encargado de las alertas, el cual abre un incidente en ServiceNow y da inicio a la investigación del AWS DevOps Agent. Esta etapa no requiere intervención humana alguna.

Investigación

El AWS DevOps Agent es un servicio gestionado que lleva a cabo la investigación de forma autónoma. Analiza las métricas de CloudWatch, los informes de rendimiento de RDS y los registros de consultas lentas, y decide por sí mismo qué datos son relevantes teniendo en cuenta la alarma. Un Lambda asíncrono recopila los hallazgos y los escribe en DynamoDB.

Amazon Bedrock, al ejecutar Claude, condensa los hallazgos en una breve declaración de la causa raíz, una evaluación del impacto y medidas de mitigación recomendadas. Este resumen se muestra en la parte superior de la vista de investigación, mientras que el análisis completo está disponible debajo.

La captura de pantalla muestra la vista de hallazgos de la investigación, con el resumen primero y los detalles a continuación.

Toma de decisiones y gobernanza

Se realizan verificaciones de seguridad antes de aplicar cualquier cambio. Las medidas de control examinan cada instrucción SQL y rechazan aquellas destructivas, como eliminar una tabla o borrar filas sin una cláusula WHERE. La acción recibe un nivel de riesgo y es enviada a un humano para su aprobación. El diálogo de confirmación muestra el comando exacto, el recurso objetivo y cómo revertir los cambios.

El paso humano es intencional. La autonomía total es poderosa, pero los cambios en producción merecen un momento de juicio humano, especialmente para operaciones de mayor riesgo.

El diálogo anterior es lo que ve un operador cuando se le pide confirmar una solución.

Enrutamiento de la solución al agente adecuado

Una vez aprobada la solución, el orquestador clasifica la categoría de la corrección y envía la solicitud al agente correspondiente. Ahí es donde la composibilidad resulta útil.

El diagrama muestra en detalle el proceso de corrección. Cuando alguien aprueba una solución, el orquestador asume el control y realiza tres tareas: clasifica la causa raíz, aplica las medidas de seguridad SQL y envía la solicitud al especialista correspondiente, al tiempo que registra la operación en DynamoDB. A partir de ahí existen dos ramas. En el lado de la base de datos, una máquina de estado LangGraph en Amazon Bedrock AgentCore valida el SQL con un analista de IA, lo ejecuta contra la base de datos a través de una Lambda en la VPC y escribe el resultado en Jira junto con un registro de auditoría. El lado de la cola funciona de manera similar para tareas como vaciar una cola de cartas muertas o enviar mensajes de vuelta al lugar de donde provienen.

Ningún agente accede directamente a un recurso. Cada uno utiliza herramientas de pasarela: una función de pasarela que se conecta a RDS para el agente de base de datos, y otra que realiza operaciones en SQS para el agente de colas. Este diseño mantiene a los agentes pequeños y permite un acceso controlado y trazable a los recursos. Una vez que termina cualquiera de las ramas, un pipeline de resultados compartido almacena el resultado en DynamoDB, agrega una nota a ServiceNow, resuelve la incidencia y actualiza la topología, de modo que cada incidente finalice de manera consistente independientemente del agente que lo haya manejado.

Cómo funciona la clasificación

La inteligencia que hace posible esto se encuentra en el orquestador. Cuando el AWS DevOps Agent finaliza su tarea, genera un análisis de la causa raíz en lenguaje natural; el orquestador lo lee y asigna una categoría de solución antes de que se ejecute cualquier agente.

La clasificación se realiza en dos pasos. Un analizador estructurado busca primero en el análisis un bloque de corrección predefinido que indica el tipo de solución, el recurso objetivo y la acción planificada. Al no encontrar dicho bloque, el orquestador recurre a un clasificador de modelo de lenguaje en Amazon Bedrock, el cual lee la descripción libre de la causa junto con el contexto original de la alarma y determina la categoría. El contexto de la alarma ayuda a relacionar el síntoma con la solución. Una alta latencia de lectura indica la necesidad de agregar un índice en la base de datos, las conexiones agotadas sugieren finalizar una consulta que bloquea el sistema, y un aumento en la cola de mensajes no entregados apunta a realizar una limpieza o volver a procesarlos.

La enrutación es determinista una vez que se establece la categoría: los datos de la base de datos van al agente de base de datos, y las colas van al agente de colas. Mantener la clasificación separada de la ejecución facilita las adiciones posteriores, ya que una nueva categoría simplemente se asocia a un nuevo agente sin que cambie la lógica de enrutamiento.

Los dos agentes de producción

AgentSRE incluye dos agentes de producción, cada uno diseñado para una categoría específica de correcciones. Ambos funcionan como entornos ejecutables en contenedores en Amazon Bedrock AgentCore y comparten un diseño interno similar: una máquina de estados LangGraph con unos pocos nodos bien definidos, cada uno equipado para registrar su tiempo de ejecución y resultado.

El agente de base de datos

Este agente se encarga de todas las correcciones basadas en SQL. Su diseño sigue un flujo de trabajo real de operaciones en bases de datos, organizado como una máquina de estados con una capa de enrutamiento que selecciona el siguiente paso a partir del estado actual.

Cuando llega una solicitud, el agente primero selecciona la base de datos objetivo y la consulta SQL sugerida del incidente. A continuación se realiza una validación, en la cual un analista de IA que opera en Bedrock examina la consulta para confirmar que está bien formada y es segura. Esa verificación semántica se suma a las protecciones deterministas que ya aplicó el orquestador, de modo que una consulta defectuosa o peligrosa se enfrenta a una segunda barrera.

Una vez superada la validación, el agente ejecuta la consulta, aunque no directamente. Llama a una función Lambda de gateway dentro de la VPC que se conecta a la instancia RDS objetivo mediante autenticación IAM. Por lo tanto, las credenciales de la base de datos y el acceso a la red permanecen confinados en un único componente controlado, mientras que el agente sigue siendo ligero al no tener una conexión directa a la base de datos.

Un mismo pipeline sirve para una variedad de soluciones. El agente puede crear un índice faltante para corregir la latencia de lectura, finalizar una consulta que bloquea recursos y agota conexiones, o ejecutar otras instrucciones correctivas según sea necesario. Posteriormente registra el resultado, incluyendo las filas afectadas y el tiempo de ejecución, y crea una entrada correspondiente en Jira además de un registro de auditoría completo. Dado que el mismo pipeline de validación, ejecución y auditoría se utiliza para cada operación SQL, implementar un nuevo tipo de corrección en la base de datos no requiere modificar la estructura del agente.

El agente de cola

El agente de cola se encarga de los problemas relacionados con los mensajes, la mayoría de las veces una cola de cartas perdidas donde se han acumulado mensajes fallidos. Sigue el mismo proceso en tres etapas de validación, ejecución y auditoría, pero con una lógica específica para colas.

La validación muestra por qué la seguridad es lo más importante para un agente de cola autónomo. Antes de realizar cualquier acción destructiva, se asegura de que la cola objetivo sea realmente una cola de cartas muertas, primero verificando el formato del ARN y luego consultando a su herramienta de gateway sobre los atributos de la cola. Una cola que no sea una cola de cartas muertas hace que el agente se detenga de inmediato, informando un fallo de seguridad, en lugar de arriesgarse con una cola de producción activa. Borrar la cola incorrecta destruiría los mensajes en tránsito, y ese riesgo justifica una verificación dedicada.

Una vez que la validación tiene éxito, se lleva a cabo una de dos acciones. La eliminación borra todos los mensajes acumulados de la cola de cartas no deseadas, que contiene mensajes considerados irrecuperables. La reenvío los envía de vuelta a la cola de origen para intentar procesarlos nuevamente, con un límite de velocidad configurable para evitar saturar a los consumidores posteriores. También existe una verificación de estado para monitorear el proceso de reenvío en curso.

Al igual que el agente de la base de datos, el agente de la cola envía cada operación a través de su propia función de pasarela, la cual realiza las llamadas a boto3 SQS y registra todas las acciones para fines de auditoría. Acepta tanto solicitudes estructuradas como texto en lenguaje natural, y extrae la acción y el ARN de la cola de cualquiera de ellos.

Independencia por diseño

Ningún agente tiene conocimiento del otro. Cada uno lleva consigo su propia máquina de estados, herramienta de pasarela y mecanismo de validación adaptados a su área específica. Solo el orquestador puede ver ambos, y no hace nada más que clasificarlos y enrutarlos.

Esta independencia es lo que significa en la práctica la composibilidad. Un tercer agente encargado de reiniciar un contenedor, rotar credenciales o cambiar una política de escalado seguiría el mismo procedimiento: utilizaría una máquina de estados LangGraph que se encargaría de validar, ejecutar y auditar las acciones, además de contar con su propia herramienta de pasarela. Se registraría bajo una nueva categoría ante el orquestador, mientras que los agentes anteriores seguirían funcionando sin afectación. El crecimiento se logra añadiendo componentes, nunca editándolos.

Informes y cierre

Una vez completada la tarea, el agente informa si tuvo éxito, cuántas filas se modificaron y cuánto tiempo llevó. El resultado se guarda en DynamoDB y se agrega al incidente de ServiceNow como nota de trabajo; una ejecución exitosa resuelve el ticket sin necesidad de más intervenciones. Se registra cada paso, lo que genera un registro de auditoría completo desde la primera alarma hasta su resolución.

La interfaz de operaciones

Aunque la automatización realiza el trabajo, los operadores aún necesitan un lugar desde donde supervisarla, dirigirla y comprenderla. AgentSRE cuenta con una interfaz web personalizada, desarrollada con React y alojada en AWS Amplify, que funciona como una única ventana de control para todo el ciclo de vida del incidente. El acceso se realiza a través del inicio de sesión único de Microsoft Entra ID, por lo que el proveedor de identidades de la organización determina quién puede utilizar los controles operativos. La interfaz tiene tres áreas, cada una destinada a satisfacer una necesidad distinta.

Chat

Chat es una interfaz de conversación para el AWS DevOps Agent. Los operadores hacen preguntas en lenguaje sencillo sobre el estado de una base de datos en particular, si hay alarmas activas o cómo avanza una investigación. Al escribir un número de incidente, se inicia una investigación completa directamente desde el chat. La interfaz mantiene el contexto de la conversación a lo largo de los mensajes y maneja las respuestas lentas al intentarlo nuevamente en segundo plano, de modo que los operadores reciben una respuesta y no un error.

La captura de pantalla muestra la vista del chat.

Incidentes

Incidentes es el panel de control para las operaciones diarias. Cada incidente se muestra con su estado, indicando si alguien lo ha investigado y si se ha aplicado una solución. Un operador puede iniciar una investigación desde allí, leer la causa raíz, examinar la topología y comenzar con las medidas correctivas. Corregir el problema solo requiere un clic, seguido de un cuadro de diálogo de confirmación que muestra el cambio exacto antes de ejecutarlo.

Este es el panel de control de incidentes.

Informes

Los informes ofrecen análisis de todos los incidentes: cantidad de investigaciones, tasas de resolución, MTTR y desgloses por prioridad y recurso. Convierten los datos de un único incidente en información operativa a lo largo del tiempo.

La vista de informes aparece arriba. Dentro de la vista de investigación, la interfaz también ofrece una visualización de topología, que se describe a continuación; esta transforma los análisis detallados en gráficos interactivos que permiten comprender la situación de inmediato.

Integración con ServiceNow

Una plataforma autónoma que ignore la gestión existente de servicios de TI generaría más problemas de los que resolvería. Por eso, AgentSRE se integra directamente con ServiceNow, lo que significa que cada incidente que maneja se refleja en el sistema de registro del cual ya dependen los equipos operativos.

La información fluye en ambas direcciones a lo largo de todo el ciclo de vida. Cuando se dispara una alarma de CloudWatch, la función Lambda encargada de las alertas crea automáticamente un incidente en ServiceNow, prellenado con los detalles de la alarma, su prioridad y categoría, después de buscar primero un incidente abierto para evitar duplicados. De este modo, el ticket ya está presente desde el principio sin que nadie tenga que crearlo.

A medida que el incidente avanza, AgentSRE publica actualizaciones en el ticket. Los hallazgos de la investigación se registran como notas de trabajo, de modo que cualquier persona que consulte el ticket pueda ver el análisis completo de la causa raíz en su contexto. Cuando se aplica una solución, el resultado, que incluye las acciones realizadas, el outcome y una marca de tiempo, se registra como otra nota de trabajo. Tras una solución exitosa, la plataforma pasa el ticket a la categoría “resuelto” y adjunta notas de resolución.

El resultado es un registro completo y auditable dentro de ServiceNow que refleja todo el flujo de trabajo automatizado. Los equipos siguen trabajando en la herramienta que conocen mientras la automatización se encarga de las tareas más complejas, y respetar el proceso existente hace que la plataforma sea adoptable en una empresa y no un sistema paralelo del cual las personas deben aprender por separado.

Este es un ticket de ServiceNow después de que la plataforma lo haya actualizado.

Viendo qué sucedió: vistas de topología

Saber qué ocurrió durante un incidente es casi tan importante como solucionarlo, y una imagen comunica más que texto denso. AgentSRE ofrece tres vistas de topología, cada una representada como un gráfico interactivo.

Topología de investigación

Esta vista muestra el radio de impacto: qué recursos se ven afectados y cómo están conectados. El recurso causante principal se resalta de manera distinta, y los bordes animados trazan la ruta del fallo a medida que este se propaga. El gráfico se genera dinámicamente a partir de los hallazgos de la investigación, por lo que diferentes incidentes producen topologías distintas, ya que cada gráfico refleja lo que el agente encontró realmente.

La vista anterior muestra una topología de investigación.

Topología de infraestructura

Este mapa muestra toda la arquitectura: cada gateway API, función Lambda, agente, base de datos, cola y componente de monitoreo, además de los enlaces entre ellos. Ofrece a los operadores una visión completa del sistema desplegado y la ruta que siguen las solicitudes.

El mapa de infraestructura muestra el mismo sistema.

Topología de agentes componibles

Esta vista sigue el camino de remediación paso a paso: el desencadenante por parte del usuario, la clasificación por parte del orquestador, la invocación del agente, la llamada a la herramienta de gateway, el cambio en los recursos y el resultado final publicado en ServiceNow. Cada nodo representa un componente real que se invoca durante la corrección, de modo que la arquitectura componible deja de ser una idea abstracta y se convierte en algo que los operadores pueden ver y verificar.

La topología del agente muestra una ejecución de remediación.

La topología se extrae mediante un método híbrido. Un extractor basado en reglas construye el grafo de inmediato y de forma gratuita cuando el incidente coincide con un patrón conocido. Para casos desconocidos, el sistema pide a Bedrock Claude que extraiga la topología del texto de investigación. Los casos comunes se resuelven rápidamente, y los inusuales también reciben atención.

Por qué la componibilidad rinde frutos

Desarrollar las soluciones de corrección como agentes componibles y no como un monolito conlleva varios beneficios prácticos.

• Extensibilidad. Una nueva categoría de corrección, como reiniciar un contenedor, ajustar una política de escalado o rotar credenciales, implica crear un único agente y registrarlo en el orquestador, sin afectar a los agentes existentes.
• Practicabilidad de pruebas. Una sola máquina de estados con entradas y salidas definidas puede probarse de forma aislada, por lo que un cambio en un agente tiene menos probabilidades de dañar a otro.
• Observabilidad. Cada agente sigue una máquina de estados definida, lo que permite rastrear y visualizar su ejecución; además, la vista de topología de los agentes componibles surge directamente de este diseño.
• Reutilización. Un único agente puede manejar numerosos incidentes. Por ejemplo, el agente de base de datos se encarga de la creación de índices, la finalización de consultas y otras correcciones SQL sin modificaciones.

Stack tecnológica

La plataforma combina estos servicios de AWS y frameworks de código abierto, agrupados por función:

• El monitoreo y las alarmas provienen de Amazon CloudWatch, mientras que la orquestación basada en eventos se realiza con Amazon SNS junto a AWS Lambda.
• La investigación la lleva a cabo el AWS DevOps Agent, mientras que Amazon Bedrock con Claude se encarga del razonamiento, los resúmenes y la extracción de topologías.
• Amazon Bedrock AgentCore alberga a los agentes, y LangGraph proporciona sus máquinas de estado.
• Amazon DynamoDB guarda los datos de estado y de auditoría, y ServiceNow gestiona el ciclo de vida de los tickets.
• La interfaz frontal utiliza React con React Flow para la interfaz y los gráficos de topología, alojados en AWS Amplify.

Efecto medido

La automatización del ciclo genera beneficios medibles. A mano, la investigación y la corrección pueden tardar entre una y cuatro horas, pero AgentSRE logra pasar de la alarma a la resolución en menos de diez minutos. La investigación suele durar de tres a cinco minutos, y una corrección aprobada se ejecuta en menos de treinta segundos.

Tanto la consistencia como la velocidad mejoran. Todos los incidentes reciben la misma investigación cuidadosa, verificaciones de seguridad y registro de auditoría, por lo que el equipo de turno no determina la calidad de la respuesta.

Hacia dónde puede evolucionar

La base componible abre varias posibilidades. Más agentes podrían encargarse de las correcciones a nivel de infraestructura mediante Systems Manager o Terraform. Los flujos de aprobación podrían gestionarse a través de herramientas de colaboración como Microsoft Teams. Una capa de conocimiento podría aprovechar las lecciones extraídas de incidentes anteriores para mejorar las recomendaciones futuras. Y dado que el patrón de agentes no está vinculado a una sola nube, el mismo enfoque podría aplicarse a entornos multi-nube.

La conclusión arquitectónica

El manejo autónomo de incidentes resulta ser práctico y viable cuando se basa en los principios adecuados: investigación autónoma, agentes de remediación componibles, aprobación humana y vistas detalladas de la topología. Juntos, reducen significativamente el tiempo promedio de resolución manteniendo la seguridad y una trazabilidad completa.

La lección clave se refiere a la arquitectura. Dividir las tareas de corrección en agentes especializados y componibles, en lugar de utilizar una sola solución de automatización, se ajusta a la forma en que realmente trabajan los equipos operativos, mantiene el sistema abierto para futuras extensiones y hace que cada acción sea visible. A medida que los entornos en la nube se vuelven más complejos, esta es una vía escalable hacia operaciones impulsadas por IA.