Arquitectura Azure — Módulo 11: operación autónoma

La doctrina de la operación autónoma llega a su tercera implementación con las tres piezas de siempre — medir el trabajo del agente y no solo su máquina, alarmas que exigen acción o no existen, y el canal de aprobación donde esperar es gratis y el silencio jamás aprueba. Azure la sirve con el stack de APM más maduro de la serie y dos formas de implementar el patrón estrella.

Pieza	En AWS	En GCP	En Azure
Métricas y alarmas	CloudWatch	Cloud Monitoring	Azure Monitor
Logs + consultas	CloudWatch Logs	Cloud Logging (+ log metrics)	Log Analytics + KQL
Trazas / APM	X-Ray	Cloud Trace	Application Insights
Despachar la respuesta	SNS + acciones	Canales + Pub/Sub	Action groups
Espera de veredicto	Step Functions (token)	Workflows (callback)	Durable Functions / Logic Apps

La tesis del módulo

Dos rasgos hacen la versión Azure: Application Insights trae el APM completo (trazas distribuidas, mapa de dependencias, métricas de aplicación) con instrumentación casi gratis sobre el cómputo del módulo 3, y KQL — el lenguaje de consultas de Log Analytics — es el instrumento único que interroga logs, trazas y métricas centralizados: la log-based metric de GCP y el dashboard de la serie son aquí consultas guardadas. Y la aprobación asíncrona tiene dos finales válidos: código (Durable) o conector (Logic Apps) — la elección es de equipo, no de doctrina.

Medir: App Insights + KQL

Las cinco capas de la serie (infraestructura → flujo → modelo → trabajo del agente → calidad) se cubren así: Azure Monitor trae las métricas de plataforma (Container Apps, Service Bus — incluida la reina: mensajes activos y edad en cola —, los despliegues de Foundry con sus tokens y throttling); Application Insights, enchufado al cómputo, agrega la vista de aplicación — cada petición trazada a través de colas, herramientas y modelo, el mapa de dependencias que muestra dónde se atora el flujo, y las custom metrics/events donde el agente emite su trabajo (clasificaciones, escaladas, validaciones fallidas).

Y todo desemboca en Log Analytics, donde KQL (Kusto Query Language) es el idioma común: la distribución de salidas del clasificador (el detector de deriva conductual), la tasa de escalada semanal, el cruce “errores de herramienta por versión del agente” — consultas de cinco líneas sobre los mismos datos que el módulo 10 centralizó como evidencia. La inversión que lo habilita es la de GCP: logging estructurado — el agente que loguea JSON con campos le entrega a KQL todo lo que las métricas custom no alcanzaron a emitir.

Las alarmas con regla binaria cierran igual que siempre — DLQ con mensajes, edad de cola, escalada anómala, throttling del despliegue (el TPM del módulo 7 avisando que quedó chico), budget (módulo 8), hallazgo de Defender (módulo 10), aprobación esperando — cada una despachada por su action group con acción humana definida. El dashboard de cinco preguntas se arma en workbooks sobre las mismas consultas KQL.

La aprobación asíncrona: dos finales

El patrón estrella — el agente pide permiso para lo irreversible, la espera no factura, el timeout decide conservador — tiene en Azure las dos implementaciones que el módulo 3 dejó presentadas:

• Durable Functions (el final en código): la orquestación espera el evento externo (“aprobación-cotización-123”) con un timer durable de timeout corriendo en paralelo — gana el que llegue primero, y la rama del timeout aborta y escala. Es el patrón de interacción humana canónico del framework, legible como un if y testeable como código. Para el equipo que vive en código, la implementación más clara de la serie.
• Logic Apps (el final con conector): el flujo usa el conector de aprobaciones — manda el correo (o tarjeta de Teams) con botones Aprobar/Rechazar, espera la respuesta con timeout configurado, y sigue por la rama que corresponda. La notificación, la UI del veredicto y la espera vienen resueltas por el conector — para aprobadores que viven en Outlook/Teams (es decir: el mundo corporativo Microsoft del módulo 1), la fricción más baja posible: el jefe aprueba desde el teléfono sin saber qué es un endpoint.

   APROBACIÓN ASÍNCRONA EN AZURE — DOS FINALES

  agente decide acción irreversible
        │
        ▼
  ┌─────────────────────────────────────┐
  │ Durable Function      Logic App     │
  │ espera evento    o    conector de   │
  │ externo + timer       aprobación    │
  │ (código)              (correo con   │
  │                       botones)      │
  └─────┬───────────────────────┬───────┘
        │ veredicto llega       │ timeout
        ▼                       ▼
  ┌──────────────┐   ┌────────────────────┐
  │ ejecutar (y  │   │ abortar y escalar  │
  │ registrar    │   │ (decidido ANTES;   │
  │ quién/cuándo)│   │ el silencio jamás  │
  └──────────────┘   │ aprueba)           │
                     └────────────────────┘

El criterio de elección es el del módulo 3 elevado: código vs. conector es una decisión de equipo y mantenimiento — Durable para lógica de aprobación con reglas (montos, cadenas, delegaciones programáticas), Logic Apps para el flujo estándar donde el valor está en la fricción cero del aprobador. Ambos cumplen la doctrina completa: espera sin facturar, timeout explícito conservador, veredicto registrado (Cosmos + los logs del módulo 10). Y la ventaja transversal de Azure asoma de nuevo: el aprobador es una identidad del mismo directorio — grupos de Entra definiendo quién puede aprobar qué, sin tabla artesanal de aprobadores.

Ojo — el conector no exime de la política: la comodidad del correo con botones invita a repartir aprobaciones como confeti, y una plataforma donde todo pide permiso por Teams es la fatiga de alertas con corbata. La política de gobernanza — qué exige aprobación, por qué atributos de riesgo — se declara igual que en las tres nubes, y las métricas del patrón (pendientes, tiempo a veredicto, % aprobado) alimentan la recalibración trimestral. La herramienta cómoda hace más necesaria la política, no menos.

Errores comunes

• Instrumentar a mano lo que App Insights regala. El auto-instrumentado cubre trazas y dependencias; tu trabajo son los eventos de negocio del agente. Empezar por SDKs artesanales de tracing es resolver lo resuelto.
• Logs de texto libre, tercera edición. KQL es tan bueno como la estructura de lo que consulta. JSON con campos o el módulo se queda en la mitad.
• Alarmas por CPU, edición de despedida. Si el auto-scaling la maneja, es dashboard. Trabajo, colas, throttling, gasto, hallazgos — y cada alarma con su acción.
• Elegir Durable vs. Logic Apps por bando religioso. Reglas programáticas → código; flujo estándar con aprobadores de Outlook → conector. Es mantenibilidad, no pureza.
• Aprobar por silencio porque el correo “se habrá perdido”. El timeout del conector y el timer de Durable existen para lo mismo: abortar y escalar. La doctrina no se ablanda porque la UI sea amable.
• Repartir aprobaciones sin política. El conector cómodo + cero criterio = fatiga de aprobación y sellos automáticos. Los atributos de riesgo deciden qué pide permiso; el trimestre recalibra.

La frase para llevarse

“App Insights te da el mapa, KQL te da las preguntas, los action groups despachan — y la aprobación tiene dos finales dignos: el evento esperado en código o el correo con botones. En ambos, la espera no factura, el veredicto queda escrito, y el silencio — por tercera nube consecutiva — jamás aprueba.”

Qué viene

Módulo 12, el cierre del curso y de la serie: la arquitectura de referencia en Azure — el diagrama completo con las piezas de esta casa — más lo que ningún módulo anterior podía dar: la tabla tri-cloud final, las cinco diferencias que valieron cada curso, y la pregunta del arquitecto completo: ¿cuál nube para qué — y qué es lo que ya no depende de ninguna?

Material relacionado

• Módulo 10: seguridad de la plataforma
• Módulo 12: la arquitectura de referencia
• Curso de AWS — Módulo 11: operación autónoma
• Curso de GCP — Módulo 11: operación autónoma
• Harness — Clase 3: gobernanza de agentes
• Glosario de Arquitectura Azure para Agentes de IA