El equipo de investigación de DORA (DevOps Research and Assessment) ha tocado la columna vertebral de las métricas de operaciones. El "Tiempo de Recuperación" (MTTR), esa métrica que lleva persiguiéndonos en los dashboards desde hace una década, se acaba de bifurcar oficialmente en dos: Human-MTTR y Agent-MTTR.

El anuncio en el blog de DevOps de Google Cloud no me sorprende. Llevo meses viendo cómo los equipos de guardia dedican más tiempo a supervisar a las IAs que arreglan cosas que a arreglarlas ellos mismos. Medir ambas resoluciones bajo el mismo paraguas del MTTR estaba falseando los datos. Un agente repara un clúster caído en milisegundos. Un humano necesita tomar café, leer logs y entender el contexto. Mezclar esas medias aritméticas destruía cualquier análisis serio de rendimiento.

Si tu sistema levanta un ticket, un agente lo analiza, reinicia un pod en Kubernetes y cierra la incidencia en diez segundos, tu MTTR global cae en picado. Pareces un genio de la fiabilidad. Pero si un fallo grave requiere intervención manual y tardas cuatro horas, ese dato queda enmascarado por la velocidad de la máquina en fallos menores.

DORA nos obliga ahora a separar estas dos realidades. Las empresas tienen que reportar qué porcentaje de sus incidentes críticos son resueltos exclusivamente por IA frente a los humanos.

El impacto en la guardia y la ingeniería de datos

Esta separación cambia las reglas del juego para la gobernanza de la IA en producción. Ya no basta con decir que la plataforma es estable. Tienes que demostrar cuánta de esa estabilidad es autónoma y cuánta depende de quemar a tus ingenieros a las tres de la mañana.

En la práctica, esto requiere modificar nuestros pipelines de observabilidad. No puedes calcular el Agent-MTTR si tu sistema de ticketing (Jira, PagerDuty, Opsgenie, Service Now...) no diferencia entre una resolución humana y un cierre automatizado por un agente de IA. Ya exploramos cómo integrar agentes IA en la gestión de incidencias, pero ahora el rastreo de su actividad se vuelve obligatorio a nivel directivo.

Cómo implementar la separación en producción

Aterricemos esto. Si trabajas manejando datos de telemetría de sistemas, necesitas interceptar los webhooks de resolución de incidentes y añadir metadatos. Tienes que inyectar una capa de clasificación antes de que esos datos acaben en tu Data Warehouse para calcular el nuevo panel de DORA.

Aquí tienes un ejemplo de cómo puedes parsear un payload de PagerDuty usando Python en una función Lambda o Cloud Run para derivar el origen de la resolución. La idea es simple: si el usuario que resuelve el incidente es un bot o una cuenta de servicio designada como agente, etiquetamos la métrica en consecuencia antes de enviarla a Prometheus o Datadog.

import json
from datetime import datetime

# Lista de IDs de usuarios que son agentes de IA en nuestro sistema
AGENT_USER_IDS = ["USR-AI-01", "USR-AI-02", "AUTORESOLVER-BOT"]

def procesar_webhook_incidencia(event, context):
    payload = json.loads(event['body'])

    # Solo nos interesan las incidencias resueltas
    if payload.get('event') != 'incident.resolved':
        return {"statusCode": 200, "body": "Ignorado - No es resolución"}

    incident = payload['incident']
    resolved_by = incident['resolved_by']['id']

    # Extraer tiempos
    created_at = datetime.fromisoformat(incident['created_at'].replace('Z', '+00:00'))
    resolved_at = datetime.fromisoformat(incident['resolved_at'].replace('Z', '+00:00'))
    time_to_resolve_seconds = (resolved_at - created_at).total_seconds()

    # Clasificación DORA
    is_agent = resolved_by in AGENT_USER_IDS
    metric_name = "dora_agent_mttr" if is_agent else "dora_human_mttr"

    # Enviar métrica a nuestro backend de observabilidad (ej. Datadog)
    enviar_metrica_datadog(
        metric_name=metric_name,
        value=time_to_resolve_seconds,
        tags=[f"service:{incident['service']['name']}", f"severity:{incident['urgency']}"]
    )

    return {"statusCode": 200, "body": f"Registrado como {metric_name}"}

def enviar_metrica_datadog(metric_name, value, tags):
    # Simulación de envío a la API de Datadog
    print(f"[{metric_name}] Valor: {value}s | Tags: {tags}")

Con un script como este enganchado a tus flujos, empiezas a separar la métrica de inmediato. Tienes una serie temporal para el esfuerzo humano y otra para el rendimiento puro de la máquina.

Veremos pronto herramientas nativas adaptándose a esto, pero mientras tanto, nos toca ensuciarnos las manos en el nivel de datos. Si estás montando equipos de agentes para automatizar la infraestructura, separar el MTTR es el primer paso lógico para justificar la inversión sin manipular los números.