Agentes en operaciones en la nube, empezando por el final aburrido

Las operaciones en la nube parecen hechas para la automatización: gran volumen de eventos, investigaciones repetitivas, experiencia concentrada en pocas personas y una acumulación de mejoras a las que nadie llega.

El instinto es señalar a un agente hacia el flujo de alerta y dejar que decida. Esa es la aplicación con más probabilidades de fallar, por una razón que vale la pena mencionar antes que nada.

Por qué las decisiones automatizadas fallan aquí primero

Una alerta significa cosas diferentes dependiendo de lo que sucedió en sentido ascendente, qué se está implementando, qué mantenimiento está programado y si este patrón se parecía a algo que resultó ser nada el último trimestre.

La mayor parte de ese contexto no está en la alerta. Está en otros sistemas y en las cabezas de los ingenieros. Un agente que decida sin él se equivocará con confianza, y dos errores de confianza son suficientes para acabar con la confianza que hizo posible el proyecto.

Tampoco existe un paso de revisión natural. Cuando se puede revisar una decisión, ya ha tenido consecuencias.

donde funciona

Asamblea de contexto antes de que un humano decida. Cambios recientes en la ruta afectada, incidentes pasados ​​relacionados, el estado de implementación actual, la sección del runbook relevante. Esto elimina para siempre los diez minutos de búsqueda que preceden a cada diagnóstico real, a cada incidente.

Cronogramas posteriores al incidente, que existen en varios sistemas y se escriben tarde y mal.

Revisión de costes y capacidades, que es mecánica, continua y permanentemente despriorizada.

Validación de cambios frente a políticas e incidentes pasados, marcando en lugar de bloqueando.

El límite de acceso

Un agente que puede leer el estado de la infraestructura y no puede cambiarlo es un riesgo fundamentalmente diferente de uno que puede hacer ambas cosas. Ese límite pertenece al punto donde ocurre la acción, no al mensaje.

Las credenciales se resuelven en tiempo de ejecución desde la bóveda de la organización, por lo que ninguna credencial de infraestructura reside en la configuración de un agente y la revocación es una sola acción.

Instrumente al agente como instrumenta todo lo demás.

Los equipos de la nube suelen ser buenos en esto y se olvidan de aplicarlo al propio agente. Costo atribuido por agente. Percentiles de latencia en lugar de medias, porque las ejecuciones de agentes están muy sesgadas. Los reintentos se cuentan por separado de los éxitos, ya que son el mismo trabajo facturado dos veces.

Evaluaciones en cada ejecución en lugar de una auditoría periódica, porque la falla que le importa es la que aparece gradualmente.

Forma inicial

Montaje de contexto sobre una clase de incidente. Propietario designado en el lado de operaciones. Criterios de evaluación construidos a partir de incidencias reales del último trimestre. Para empezar, solo lectura y un presupuesto que bloquea.

Amplíe cuando las partituras sean aburridas, no cuando la demostración sea impresionante.

Siguiente

Las páginas de Observabilidad de IA y Monitoreo de tokens cubren la instrumentación. Las páginas del Sistema de orquestación de agentes cubren políticas, credenciales y evaluación.