Observation: la calidad en producción

Qué es

Observation es el último stage del Late-Game, la fase en la que QA trabaja junto a DevOps y SRE. Viene después de Regression: el release ya salió y ahora importa lo que pasa con usuarios reales. Agrupa los steps 11 a 15 del IQL. El step 10 (mantenimiento continuo y regresión) pertenece al stage Regression, que sí tiene skill.

Su función en el método es cerrar el ciclo. Lo que se aprende en producción vuelve al análisis del siguiente Shift-Left, y vuelve por un mecanismo con nombre: el error budget y la escape rate. Si ningún número regresa al step 1, el último step es un final y no un retorno.

El contrato agéntico

Como todo stage, Observation declara qué hace el agente y qué firma la persona. Esta fila está en la tabla de contratos de stage-gates.md:

La rutina agéntica

Hay stages que no caben en una sesión: nadie se sienta a mirar producción todo el día. Para eso el IQL define la rutina agéntica, una corrida que arranca sola (por horario o por un disparo) y cuyo producto es evidencia con un destinatario. Tiene cuatro partes:

1. Disparador

   Qué la despierta: un horario, un push, un umbral cruzado. Tiene que ser explícito y único. Sin disparador con nombre, es un script que alguien corre a mano.

2. Permisos acotados

   Qué puede leer y qué puede escribir, y nada más. No hereda la confianza general del agente.

3. Evidencia

   Qué deja al terminar, salga bien o mal: el comando, la salida, el artefacto. Sin evidencia reproducible no hay conclusión, aunque nadie la mire.

4. Reporte

   A quién le habla y por qué canal. Una rutina que no le reporta a una persona es una alarma apagada.

Los cinco steps

El sitio oficial los marca como "panorama": se enseñan como mapa de la industria y hoja de ruta, no como práctica que se opera contra un entorno productivo real. Cada uno exige algo del entorno antes de tener sentido. El número de adopción sugerido indica en qué orden conviene incorporarlos.

Step 11: Canary release monitoring

La feature nueva sale primero para un porcentaje chico de usuarios. Se comparan las métricas de esa cohorte con las del resto y, con esos datos, se decide si se amplía el rollout o se hace rollback. El aporte de QA es definir qué señales miran la cohorte (errores, latencia, conversión del flujo nuevo) y con qué umbral se corta.

Requiere despliegue progresivo (canary o feature flags) con métricas por cohorte. Adopción sugerida: nº 4.

Step 12: A/B testing

Dos versiones de una funcionalidad conviven y se mide cuál funciona mejor con usuarios reales. El experimento necesita una hipótesis clara y una métrica de éxito definida antes de empezar, y el resultado se analiza con criterio estadístico, no a ojo.

Requiere feature flags y analítica de producto. Adopción sugerida: nº 5.

Step 13: Real User Monitoring (RUM)

Se instrumenta la aplicación para capturar el rendimiento que viven los usuarios reales: Core Web Vitals, errores del lado del cliente, diferencias por dispositivo o región. Las alertas avisan cuando algo se degrada. Es la fuente de buena parte del MTTD.

Requiere error tracking y RUM en producción. Adopción sugerida: nº 2.

Step 14: Chaos engineering

Se introducen fallas controladas (un servicio caído, latencia agregada, una dependencia que no responde) para comprobar que el sistema se recupera como se espera. Cada experimento parte de una hipótesis de resiliencia y empieza por servicios no críticos. Lo que falla se documenta como debilidad de arquitectura.

Requiere arquitectura distribuida, SLOs definidos y un equipo SRE. Adopción sugerida: nº 6, la última.

Step 15: Feedback loop

Se juntan el feedback de soporte, las reseñas y las métricas de producción, y se convierten en trabajo: ACs actualizados, ítems nuevos en el backlog, riesgos que el siguiente Shift-Left tiene que mirar. Es el step que convierte el ciclo en bucle.

Requiere al menos una fuente de producción (RUM o alertas) y un ritual que devuelva lo aprendido al step 1. Adopción sugerida: nº 3.

SLO y error budget

SLO (Service Level Objective)

El objetivo de servicio que el equipo se compromete a cumplir, por ejemplo "99.9% de las requests responden sin error en el mes". Lo define la persona, no el agente, y se elige según la criticidad del producto: un banco y una app interna de RRHH no necesitan el mismo.

Error budget

Lo que el SLO deja de margen. Con un SLO de 99.9%, el presupuesto es el 0.1% restante. Mientras quede presupuesto, el equipo puede seguir liberando; cuando se consume, la política de error budget dice qué pasa (por ejemplo, frenar releases hasta estabilizar). Esa política también la firma una persona.

Escape rate

Bugs encontrados en producción sobre el total de bugs del período. Mide lo que el método promete: que el defecto se encuentre antes de llegar al usuario.

Juntos, error budget y escape rate son el mecanismo de retorno: le dicen al siguiente ciclo dónde tiene que invertir análisis.

Métricas

Las fases anteriores se evalúan por lo que producen: un plan, un caso, un PR. Esta se evalúa por lo que pasa en producción cuando nadie está mirando. Los valores de la tabla son benchmarks de referencia del sitio oficial, no objetivos universales: cada producto declara los suyos según criticidad, baseline, arquitectura y negocio.

El IQL suma métricas que miden al propio método:

Hasta dónde llegar

Esta fase no se adopta entera. Cada nivel de madurez pide algo del entorno, y Observation es el último:

Herramientas

El IQL define qué observar; la herramienta la pone el entorno. Casi todo en esta fase lo trae el cliente, y se trabaja con lo que ya tiene:

Qué puedes hacer con este repo

No hay skill de Observation, pero sí hay piezas del ciclo que ya conectan con producción:

• Regression cubre el step 10: /regression-testing corre la suite, clasifica fallas y emite GO / CAUTION / NO-GO. Es el prerrequisito de todo lo demás.
• Reportar lo que aparece en producción. Según .agents/skills/agentic-qa-core/references/defect-management-doctrine.md, un problema en una feature que ya está viva por encima de Staging es un Bug, y se registra con la misma doctrina que cualquier otro defecto: severidad, components y el Epic QA Defect Management.
• Cerrar el bucle a mano. Lo que aprendas de producción entra como ítem de backlog y lo toma el siguiente /shift-left-testing, que es donde el método espera que vuelva.

Lo que falta es la rutina que vigile las señales por su cuenta. Hasta que exista, esa vigilancia es trabajo humano con las herramientas del equipo.

El transporte para una rutina así ya está en el repo: el modo AUTOMATION de /orca-orchestration corre un prompt versionado con un disparador tipo cron, sin una persona del otro lado. Cumple las cuatro partes de arriba a su manera: despacha workers y no produce nada por sí mismo, no publica ni aprueba, lo ambiguo lo reporta en vez de adivinarlo y su reporte siempre dice cuánto costó la corrida en tokens. Sus recetas, como el triage nocturno de una corrida de regresión, están en .agents/skills/orca-orchestration/references/automations.md. Ninguna vigila producción: la rutina de Observation es la que sigue sin escribirse, y sería una receta más sobre ese mismo transporte.