AI incident triage + runbook executor

El agente reduce el tiempo desde el disparo de la alerta hasta la primera acción significativa — el propio MTTM (Mean Time To Mitigate), que determina cuánto sufren realmente los clientes a causa de un incidente. Funciona como una combinación de monitoreo, orquestación de runbooks y comunicaciones con los responsables de guardia, convirtiendo señales dispersas en un único proceso gestionado.

Qué hace el agente paso a paso

1. Recibe señales brutas de los sistemas de observability — métricas, logs, trazas, health-checks, alertmanager — y agrupa los duplicados en un único incidente mediante claves de correlación.
2. Clasifica el incidente por severity (SEV1-SEV4) y dominio (BD, API, red, deploy, proveedor externo) en función de patrones históricos y reglas predefinidas.
3. Recopila el contexto: últimos deploys, cambios de feature flags, incidentes similares del pasado, lista de responsables del componente, SLO/SLA del servicio.
4. Enruta la alerta al canal de comunicación correcto — uno, y no cinco. El responsable de guardia recibe un briefing compacto en Slack o PagerDuty en lugar de una decena de alertas idénticas.
5. Selecciona el runbook adecuado de la biblioteca y propone su ejecución con una evaluación de los riesgos de cada paso.
6. A petición del responsable de guardia, ejecuta los pasos del runbook con confirmaciones receipt intermedias — antes de cada acción mutadora muestra exactamente qué se realizará y qué consecuencias se esperan.
7. Documenta la línea de tiempo del incidente: quién hizo qué, cuándo y con qué efecto. Prepara un borrador de postmortem con hechos, no suposiciones.

Qué no hace el agente

1. No toma decisiones de rollback, failover o drain sin la confirmación explícita del ingeniero de guardia — cada acción irreversible requiere receipt, por lo que en el piloto se registraron cero rollbacks erróneos.
2. No reemplaza la rotación on-call ni elimina la responsabilidad del equipo — acelera al ingeniero, no lo sustituye.
3. No adivina las causas de incidentes para los que no hay datos en la biblioteca de runbooks o en los registros históricos. Las nuevas categorías de fallos se escalan a personas, y las lagunas en los runbooks se destacan en el informe posterior al incidente.

Bajo el capó — un agente orquestador sobre un framework de agentes (LLM como capa de reasoning), conectado al stack de observability, al sistema de comunicaciones y a la biblioteca de runbook. El principio clave — todas las acciones con efectos secundarios pasan por el mecanismo de receipt: el agente formula la intención, se la muestra a la persona y espera confirmación.

Flujo de procesamiento del incidente

La alerta llega a la cola del agente mediante webhook desde alertmanager, PagerDuty o DataDog. El agente normaliza el formato, verifica los incidentes abiertos (si hay duplicado) y enriquece el contexto con la API de monitoreo y el CMDB. A continuación, la capa LLM clasifica el incidente y selecciona el runbook — esto es una llamada de structured output independiente con validación por esquema JSON. El orquestador ejecuta el runbook como un grafo de pasos: cada paso es read-only (consulta de métricas, búsqueda de logs) o mutating (restart de pod, flip de feature-flag, rollback de deploy). Los pasos mutating requieren receipt del operador de guardia.

Pasos de implementación

1. Inventario — recopilar la lista de runbooks (aunque estén en Confluence, en la cabeza del senior o en gists), catalogarlos por componentes y severity.
2. Normalización de runbooks — convertir al formato legible por máquina: YAML, Markdown con frontmatter o DSL. Cada paso se etiqueta como read-only o mutating, con una acción de rollback explícita.
3. Conexión de observability — configurar los webhooks de salida desde alertmanager/PagerDuty/DataDog al agente, mapear los labels de las alertas con la clasificación de dominio.
4. Integración de communications — bot de Slack para briefings y diálogos de receipt, threading por incident ID, enrutamiento de canal por equipo responsable.
5. Configuración del pipeline LLM — clasificador, selector de runbook, generador de briefing. Cada llamada — structured output con esquema JSON estricto.
6. Pilot en 1-2 servicios — primero en modo shadow (el agente propone pero no actúa), luego con manual approval en todo, después con auto-approve en los pasos read-only.
7. Expand al resto de equipos — a medida que se estabilizan las métricas de MTTM y crece la confianza de los operadores de guardia.

Componentes del sistema

Runbook store — elemento crítico: si no hay runbooks o están desactualizados, el agente trabaja en vacío. Las primeras semanas de implementación se dedican precisamente a la disciplina del equipo en su redacción. Audit log — segundo elemento crítico: sin él, la mecánica de receipt pierde sentido, porque no es posible reconstruir quién confirmó qué.

El agente opera en el ciclo reasoning → action → receipt → observation hasta alcanzar un estado resuelto (las métricas vuelven a la normalidad) o un escalation (la persona toma el control, el agente pasa al rol de asistente y documenta las acciones del operador de guardia).

Para la implementación se necesita una madurez básica de los procesos — sin ella, el agente no tiene en qué apoyarse.

Datos y accesos

• Stack de observability con webhook de alertas (Prometheus + alertmanager, DataDog, New Relic, Grafana, PagerDuty — cualquier moderno).
• Al menos 5-10 runbooks escritos para las clases de incidentes más frecuentes. Pueden estar en Confluence, Notion o git — lo importante es que existan.
• Acceso a la API de los sistemas de infraestructura para acciones mutating (kubectl, Terraform Cloud, plataforma de feature-flag, CI/CD).
• Canal de comunicaciones para incidentes (Slack o Teams) con permisos de bot para escritura, lectura de threads, creación de canales.
• Historial de incidentes pasados de 3-6 meses para calibrar el clasificador.

Preparación del equipo

• Un owner designado por parte de SRE/DevOps, responsable de la biblioteca de runbooks y su vigencia.
• Cultura de postmortems sin blame — de lo contrario, el agente que lo documenta todo generará resistencia.
• Los ingenieros de guardia están preparados para el nuevo workflow con confirmaciones de receipt en lugar de acciones directas en la consola.
• Comprensión de que las primeras 2-4 semanas el agente trabajará en modo shadow sin acciones reales — esto no es un fracaso, sino la calibración del clasificador y del selector de runbooks.

Cronograma

Un proyecto promedio — 6-10 semanas desde el kick-off hasta el uso productivo en varios servicios. Las primeras dos semanas — inventario y normalización de runbooks, la tercera a la quinta — integraciones con observability y communications, piloto en modo shadow. De la sexta a la décima — ampliación del scope y configuración de auto-approve para los pasos seguros de read-only.