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

Las tres piezas de la operación autónoma — telemetría del trabajo del agente (no solo de su máquina), alarmas donde cada una exige acción humana, y el canal de aprobación donde esperar no cuesta y no responder tiene desenlace decidido — son doctrina de la serie. GCP las implementa con su stack de observabilidad (el heredero de Stackdriver) y una traducción limpia del patrón estrella.

Pieza	En AWS	En GCP
Métricas y alarmas	CloudWatch	Cloud Monitoring
Logs centralizados	CloudWatch Logs	Cloud Logging
Trazas distribuidas	X-Ray	Cloud Trace
Métrica desde logs	Metric filters	Log-based metrics
Orquestación con espera de veredicto	Step Functions (waitForTaskToken)	Workflows (callbacks)
Notificar al aprobador	SNS	Pub/Sub / canales de alerta

La tesis del módulo

El stack de GCP no cambia qué se mide — las capas del curso de AWS aplican fila por fila — pero regala un atajo operativo: las log-based metrics convierten cualquier línea de log en métrica alertable sin tocar código, lo que vuelve trivial instrumentar las métricas de trabajo del agente que en otras nubes exigían emisión custom. Y Workflows con callbacks es el waitForTaskToken de esta casa: token, espera dormida sin facturar, timeout con desenlace conservador. La autonomía sigue siendo supervisión convertida en arquitectura.

Qué medir: la tabla no cambia, el cómo se abarata

Las cinco capas del módulo de AWS (infraestructura → flujo → modelo → trabajo del agente → calidad) se trasladan directo: Cloud Monitoring trae gratis las tres primeras (Cloud Run, Pub/Sub — incluida la reina: la edad del mensaje más viejo por suscripción, nativa —, Vertex), y la cuarta sigue siendo tuya. El atajo local para hacerla barata:

• Log-based metrics: el agente ya loguea lo que hace (clasificado: facturación, escalado a humano, validación fallida) en Cloud Logging; una log-based metric convierte ese patrón en serie temporal — contador o distribución — alertable como cualquier métrica. La distribución de salidas del clasificador (el detector barato de deriva conductual) pasa de “instrumentación custom” a “una definición sobre logs que ya existen”. El logging estructurado (JSON con campos) es el requisito; si tus agentes ya loguean bien, las métricas de trabajo están a minutos.
• Cloud Trace encadena la petición a través de Run, Pub/Sub y Vertex — el X-Ray de la casa, con la misma misión: depurar sistemas de piezas desacopladas sin arqueología.

Las alarmas con regla binaria (exige acción humana o es dashboard) se copian línea a línea: DLQ con mensajes, edad de suscripción sobre umbral, tasa de escalada anómala, presupuesto (módulo 8), hallazgo de Command Center (módulo 10), aprobación esperando demasiado. Los canales de notificación de Monitoring (correo, chat, Pub/Sub, PagerDuty) cierran el circuito — y el dashboard único de cinco preguntas del curso de AWS se rearma idéntico con estas piezas.

La aprobación asíncrona: Workflows con callback

La traducción del patrón estrella. Workflows es la máquina de estados administrada de GCP — pasos declarativos, reintentos, y la pieza clave: callbacks — el workflow crea un endpoint de callback, notifica al aprobador y se detiene a esperar la respuesta sin facturar cómputo, hasta el timeout que definas:

   APROBACIÓN ASÍNCRONA EN GCP

  agente decide acción irreversible
        │
        ▼
  ┌────────────────────┐  notifica (Pub/Sub →
  │ Workflows crea     │  correo / chat)
  │ endpoint de        │ ──────────► aprobador
  │ callback y ESPERA  │                 │
  │ (sin facturar)     │ ◄───────────────┘
  └─────┬──────────┬───┘  responde al endpoint
        │          │
 aprueba▼          ▼ timeout sin respuesta
  ┌──────────┐  ┌────────────────────┐
  │ ejecutar │  │ abortar y escalar  │
  │ la acción│  │ (decidido ANTES;   │
  └──────────┘  │ el silencio jamás  │
                │ aprueba)           │
                └────────────────────┘

Las decisiones de arquitectura dentro del patrón son las mismas cuatro del curso de AWS y no se re-argumentan — qué exige aprobación se declara desde la política de gobernanza; el timeout tiene desenlace explícito y conservador; la espera es gratis por diseño (el workflow duerme, el agente efímero ya murió, la respuesta es un evento más); el veredicto queda escrito en Firestore y los audit logs. Hasta la métrica del aprobador-como-cuello-de-botella (tiempo hasta veredicto, % aprobado, recalibración trimestral de la política) se copia entera.

Ojo — Workflows también orquesta lo demás: igual que Step Functions, Workflows no es solo el patrón de aprobación — es la casa natural de los flujos multi-paso con esperas largas (el pipeline aprobar→ejecutar→verificar del módulo 3). Si un flujo del agente tiene pasos con horas o días entre medio, la pregunta “¿esto es un job o un workflow?” se responde por la espera: los jobs trabajan, los workflows coordinan y duermen. Un contenedor coordinando con sleep() es el anti-patrón de siempre con sintaxis nueva.

Errores comunes

• Instrumentar métricas de trabajo con código custom antes de mirar los logs. En GCP el orden es al revés: logging estructurado primero, log-based metrics encima. Buena parte de tu instrumentación ya está escrita en tus logs.
• Logs de texto libre. Sin estructura (JSON con campos), las log-based metrics no tienen de dónde agarrar y la joya local queda sin usar. El logging estructurado es la inversión de un día que habilita todo el módulo.
• Alarmas por CPU. El estribillo de la serie: si el auto-scaling la maneja, es dashboard. Las alarmas miden trabajo, colas, escaladas, gasto y hallazgos.
• Aprobación con contenedor esperando. Workflows con callback existe exactamente para esto: espera dormida, desacoplada, con timeout. Pagar cómputo por esperar un OK es el mismo error en cualquier nube.
• Timeout sin desenlace. “¿Y si nadie responde?” se decide en el diagrama, no en producción. Abortar y escalar; el silencio jamás aprueba — doctrina, no sugerencia.
• Workflows como martillo universal. Coordina y espera; no procesa. El trabajo pesado vive en jobs (módulo 3); el workflow los dirige. Confundirlos produce workflows kilométricos o jobs que duermen — ambos caros.

La frase para llevarse

“Mide lo mismo que en AWS pero empieza por los logs — en GCP, una línea bien estructurada ya es una métrica alertable — y traduce el patrón estrella sin miedo: Workflows crea el callback, duerme gratis, y el timeout conservador decide lo que el silencio nunca debe decidir.”

Qué viene

Módulo 12, el cierre del curso: la arquitectura de referencia en GCP. El diagrama completo del agente autónomo con las piezas de esta casa — Pub/Sub y Scheduler despertando Cloud Run, Vertex con Model Armor como punto único, las tres jaulas (service account mínima, egress corto, perímetro), Workflows esperando veredictos — más la tabla honesta de qué cambió de verdad respecto de AWS, y el puente final hacia Azure.

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
• Harness — Clase 3: gobernanza de agentes
• Deploy de Agentes — Módulo 13: observabilidad y seguridad
• Glosario de Arquitectura GCP para Agentes de IA