El diagnóstico de un agente de SRE es un punto de partida, no un hallazgo: AWS y Microsoft

«Sugerido no es lo mismo que confirmado.» Es el pie de una captura de pantalla en una publicación de ingeniería de Microsoft, bajo el diagnóstico de un incidente de producción hecho por un agente de IA, y puede ser la frase más útil que se ha escrito sobre agentes de operaciones este año.

En la publicación, del 14 de octubre, un ingeniero de Microsoft recorre un incidente en una demo de Contoso modelada sobre uno real: el health check del gateway pasó mientras los pedidos y los pagos fallaban. Azure SRE Agent recogió el incidente y reportó una base de datos PostgreSQL detenida. El ingeniero pasó el resto de la investigación comprobando esa afirmación. Los logs respaldaban un problema de conectividad; no probaban que la base de datos estuviera detenida, y la propia comprobación del registro de actividad del agente no había encontrado ningún evento de parada. El incidente real de producción detrás de la demo, señala, fue agotamiento de recursos.

Un día después, AWS anunció algo con la misma forma desde la dirección opuesta.

Dos lanzamientos, un traspaso

AWS. El AWS Resilience Hub de nueva generación ahora se conecta con AWS DevOps Agent. Cuando un equipo ejecuta una prueba de resiliencia, el agente la observa y devuelve un análisis estructurado de síntomas, causa raíz e impacto, junto con acciones de recuperación observadas, como un cambio de Región. A partir de un hallazgo de evaluación de modos de fallo, un ingeniero puede iniciar una tarea del agente con el contexto del hallazgo ya cargado, investigar y construir un plan de mitigación. La integración se ofrece en una larga lista de Regiones, que incluye Europa (Irlanda, Londres, Fráncfort, París, Estocolmo) y Sudamérica (São Paulo), pero no la Región de Europa (España) ni ninguna otra de Latinoamérica. Los equipos en España, bajo el RGPD, o en México, Colombia o Chile con sus propios requisitos de residencia de datos deben comprobar en qué Región se ejecutan las pruebas de resiliencia y las investigaciones del agente antes de confiar en ellas. El anuncio describe investigar y planificar; no dice que el agente aplique los cambios por sí mismo.

Microsoft. El nuevo canvas de Azure SRE Agent pone la investigación del agente junto a una conversación de GitHub Copilot, en la aplicación de Copilot y en sesiones de Copilot CLI compatibles con canvas. El ingeniero aporta lo que al agente de SRE le falta: el código, las fuentes de datos privadas y el conocimiento de la aplicación. Las conexiones privadas siguen siendo privadas para Copilot; conectar una investigación no le da al agente de SRE los permisos de datos del ingeniero, y la evidencia vuelve al agente solo cuando el ingeniero la previsualiza y la aprueba. Las consultas se muestran completas y se aprueban antes de ejecutarse. Conceder capacidad, el posible arreglo, es una acción aparte con su propia aprobación.

Por qué el traspaso es el diseño

Ambos lanzamientos aceptan que un agente de operaciones ve solo una parte del cuadro. El agente de AWS ve una prueba estructurada que se le pidió observar. El agente de Azure ve la telemetría a la que está conectado, no el clúster de Kusto al que solo llega el desarrollador. Ninguno debería tener la última palabra, y ambos productos están construidos para que una persona lleve el análisis más lejos con su propio acceso.

Eso tiene dos consecuencias que vale la pena adoptar, sea cual sea la plataforma que use:

• La salida del agente debería separar las afirmaciones de las observaciones. El primer prompt del ingeniero de Microsoft le pide a Copilot que «separe el diagnóstico reportado de la evidencia observada» y enumere «qué sigue necesitando verificación independiente». Ese debería ser el formato por defecto de todo resumen de incidente que escriba un agente, no un prompt que un experto tenga que recordar.
• Los permisos se quedan con las personas. El acceso del desarrollador no se le presta al agente. Los hallazgos del agente se le llevan al desarrollador. Así la identidad del agente se mantiene estrecha, algo que importa cuando su investigación lee contenido de logs que no es de confianza. Es el patrón que vimos en Cornerstone, donde los agentes de bases de datos diagnostican y luego preguntan.

Donde las pruebas de resiliencia cambian las reglas

La integración de AWS añade algo que las herramientas de incidentes suelen no tener: una causa conocida. En una prueba de resiliencia, el equipo inyectó el fallo. Eso convierte las ejecuciones de prueba en el mejor conjunto de evaluación posible para un agente de operaciones. Si el análisis de causa raíz que hace el agente de un fallo inyectado es erróneo, también lo será en un incidente real, y se enteró un martes por la tarde en lugar de a las 3 de la mañana.

Un programa práctico para los equipos que adopten cualquiera de las dos herramientas:

1. Puntuar al agente con fallos inyectados antes de confiar en él para los reales: ¿nombró la causa que usted inyectó?
2. Exigir enlaces a la evidencia para cada afirmación del resumen de un agente, la consulta y el resultado, como Block mantiene la evidencia en bruto detrás de cada investigación.
3. Mantener la mitigación como un cambio aparte y aprobado, como hacen ambos proveedores, incluso cuando el agente la haya redactado.
4. Devolver al agente los hallazgos confirmados. Microsoft señala que lo que aprende el ingeniero vuelve a la memoria del agente; revise lo que entra, porque una lección equivocada guardada ahí se repite.

Los agentes de operaciones están mejorando en la primera hora de un incidente. El trabajo del ingeniero se está moviendo de encontrar la evidencia a juzgarla, y las herramientas por fin se están construyendo para ese trabajo.