Continuidad para agentes: primero el modo degradado y la frescura de cola
Por Equipo Quantum Developers
Resumir:
Tesis operativa
Restaurar servidores no restaura necesariamente una operación. Durante una falla, pueden acumularse facturas, embarques o casos; algunos ya tuvieron una acción externa y otros no. Un backup no decide cuáles pueden esperar, cuáles pasan a personas ni cómo reconciliar estados inciertos. La tesis es concreta: continuidad para agentes exige definir admisión, función mínima, frescura de cola y reconciliación.
La guía de planificación de contingencia NIST SP 800-34 Rev. 1 organiza el trabajo alrededor de análisis de impacto, estrategias de recuperación, planes, pruebas y mantenimiento. Para un agente, el análisis debe bajar al objeto de negocio. “Servicio disponible” no responde si la factura aún es válida o si el embarque ya perdió su ventana.
Cuatro relojes distintos
La continuidad debe distinguir:
- tiempo hasta detectar: cuánto permanece invisible una degradación;
- tiempo hasta contener: cuánto tarda el equipo en impedir nuevas acciones riesgosas;
- edad del caso: cuánto lleva esperando el objeto más antiguo que todavía exige atención;
- tiempo hasta reconciliar: cuánto tarda en confirmarse qué ocurrió durante la falla.
RTO y RPO siguen siendo útiles, pero no sustituyen esos relojes. Un sistema puede recuperar rápido con una cola que ya incumplió compromisos. También puede conservar todos los mensajes y, aun así, duplicar una acción si no sabe si el primer intento llegó al ERP.
AWS documenta métricas de SQS como mensajes visibles y edad aproximada del mensaje más antiguo en su lista de CloudWatch metrics para colas. Esas métricas son específicas de un servicio, pero ilustran el principio: longitud y antigüedad cuentan historias diferentes. La continuidad de negocio necesita ambas y debe segmentarlas por prioridad.
Artefacto: matriz de degradación
| Falla | Función que se conserva | Trabajo que se detiene | Ruta alternativa | Señal de recuperación |
|---|---|---|---|---|
| modelo o regla | captura y cola | nuevas decisiones automáticas | regla previa o revisión humana | prueba de casos representativos |
| herramienta externa | clasificación y evidencia | acción remota | cola idempotente o proceso manual | confirmación y reconciliación |
| fuente de datos | casos con datos vigentes | población afectada | fuente autorizada secundaria | frescura y consistencia restauradas |
| aprobador | propuesta de bajo riesgo | acciones que exigen aprobación | cola priorizada | capacidad humana confirmada |
| plataforma de control | política cacheada de bajo riesgo | cambios y acciones sensibles | buffer de eventos | sincronización de estado |
| sistema de registro | recepción y validación local | escritura final | diario de intención | lectura posterior y conciliación |
Cada celda debe indicar dueño, permiso, comando de activación y prueba. “Proceso manual” no es una ruta si nadie ha ensayado su capacidad ni sabe cómo devolver los resultados al flujo.
Admisión antes de recuperación
Cuando la capacidad baja, aceptar todo empeora el incidente. Google SRE describe en Handling Overload cómo rechazar temprano y priorizar trabajo puede evitar desperdicio y fallas en cascada. Un agente necesita una política de admisión por consecuencia:
- preservar casos con ventana irreversible o impacto humano;
- aceptar casos cuya evidencia seguirá vigente al procesarse;
- diferir trabajo que puede regenerarse sin pérdida;
- rechazar de forma explícita cuando guardar solo crea una cola tóxica.
La clasificación ocurre antes del incidente. Si depende del mismo modelo que falló, no es una salvaguarda. Use campos deterministas: tipo, fecha límite, importe o severidad definidos por el dominio.
Un ledger de frescura
Cada tipo de objeto recibe:
- tiempo máximo de espera antes de revisión;
- fuente y marca de tiempo que determinan vigencia;
- evento que invalida el caso;
- prioridad de recuperación;
- destino cuando expira;
- evidencia necesaria para re-procesar.
Los límites son internos, no benchmarks. Una empresa puede definir que una cotización caduca con la lista de precios, mientras una alerta logística pierde valor después de la ventana de intervención. El tablero debe mostrar percentiles o bandas de edad, no solo promedio; pocos casos antiguos pueden quedar ocultos detrás de muchos nuevos.
Acciones inciertas y reconciliación
La categoría más peligrosa no es fallido: es “resultado desconocido”. El agente envió una orden, perdió conexión y no sabe si el sistema externo la aceptó. Reintentar sin clave idempotente puede duplicar. Marcar como error puede ocultar una acción real.
El runbook crea un conjunto de reconciliación con identificador, intención, último estado conocido, sistema destino y método de consulta. Primero se pregunta al sistema de registro; después se decide completar, compensar o escalar. Ningún caso incierto vuelve automáticamente a la cola general.
Activación y salida del modo degradado
La activación puede ser automática para detener una acción, pero ampliar capacidades debe requerir evidencia. Use estados explícitos: normal, restringido, solo recomendación, solo captura y detenido. Cada cambio guarda actor y motivo.
La salida requiere más que un indicador verde:
- dependencia accesible y consistente;
- prueba sintética exitosa;
- muestra de casos reales sin acción material;
- cola priorizada y capacidad suficiente;
- reconciliación de estados inciertos en curso;
- dueño que autoriza el aumento.
En Quantum Automation Center, estados de ejecución, cronologías, artefactos, logs, permisos y aprobaciones pueden mostrar el modo vigente y ligar cada caso con su recuperación. El sistema de registro sigue siendo la autoridad sobre la acción final.
Ejercicio de mesa y prueba real
Un ejercicio plantea una caída concreta: fuente disponible pero atrasada, herramienta que responde con timeout o aprobador sin capacidad. El equipo recorre matriz, permisos y comunicaciones. Después realiza una prueba controlada: detener admisión, activar modo, procesar una muestra, restaurar y reconciliar.
Mida decisiones, no solo tiempo: ¿se protegió la población correcta?, ¿se preservó evidencia?, ¿hubo casos huérfanos?, ¿el backlog envejeció dentro del límite? Actualice el plan con hallazgos, como recomienda el ciclo de mantenimiento de contingencia de NIST.
El mejor contraargumento
Varios modos degradados aumentan complejidad. Una ruta poco usada puede fallar justo durante el incidente, y mantener lógica duplicada consume presupuesto. Para algunos equipos, detener de forma limpia es más fiable que operar parcialmente.
La crítica es válida. No construya un modo por cada dependencia. Empiece con dos: seguro en pausa y una función mínima que proteja el objeto. Añada otros solo cuando el análisis de impacto muestre que detener causa más daño y exista capacidad de probarlos regularmente.
Cuándo no usar este enfoque
No diseñe una arquitectura compleja de degradación para trabajo no crítico que puede detenerse con seguridad y reanudarse desde una fuente íntegra. Tampoco acumule una cola si los objetos caducan antes de que la capacidad vuelva.
Use la matriz cuando una interrupción crea obligaciones, ventanas o acciones inciertas. La continuidad real no es mantener al agente “arriba”; es preservar decisiones seguras mientras el contexto está abajo y demostrar después qué ocurrió con cada objeto.
Sources
Temas del artículo
