Operations

El modelo operacional del día a día: quién corre qué, cuándo y cómo. La cadencia, las responsabilidades y el path de escalado.

Propósito

Esta página documenta el modelo operacional del lab. Es la compañera del Runbook (que es la referencia paso a paso) y de los Health Checks (que es la referencia de verificación).

Cadencia

La cadencia operacional del lab es:

Cadencia	Actividad
Continua	Heartbeat checks (gates, agentes, misiones en curso).
Per-request	Session state, memory updates, audit log.
Diaria	Token pool review, mission state cleanup, log rotation.
Semanal	Audit review, health check report, retention policy review.
Mensual	Auditoría comprehensiva, security review, documentation review.
Ad-hoc	Post-incident review, configuration change, agent update.

La cadencia la aplica el scheduler del framework y la disciplina del usuario.

Roles

Las operaciones del lab involucran un único rol: el operator. El operator es el usuario.

Las responsabilidades del operator:

Monitorizar los health checks.
Revisar el audit log.
Aplicar la retention policy.
Actualizar la configuración.
Reiniciar los agentes cuando sea necesario.
Escalar issues a los maintainers del framework (el usuario, en el caso del lab).

El operator es el único rol. El lab no tiene múltiples usuarios u operators.

Daily checks

Los daily checks son:

Token pool review. Leer el fichero de estado del token pool. Identificar tokens exhausted o con error. Añadir tokens si es necesario.
Mission state cleanup. Identificar misiones que llevan en estado no-terminal más allá del timeout. Reanudarlas o cancelarlas.
Log rotation. Comprobar el tamaño del request journal. Rotar si es necesario.
Espacio en disco. Verificar que el output directory y la raíz de research tienen suficiente espacio libre.

Los daily checks toman 5-10 minutos. La salida de los daily checks es una nota corta en el daily log.

Weekly checks

Los weekly checks añaden:

Audit review. Leer los audit reports más recientes. Identificar nuevos hallazgos.
Health check report. Leer los resultados de los health checks. Identificar servicios degradados.
Retention policy review. Comprobar los contadores de retención. Ajustar si es necesario.
Documentation review. Comprobar que la documentación refleja el estado actual del sistema.

Los weekly checks toman 30-60 minutos. La salida es un weekly audit report.

Monthly checks

Los monthly checks añaden:

Auditoría comprehensiva. Revisar todos los componentes, el security boundary y el threat model.
Security review. Revisar los security principles y el audit model. Actualizar si es necesario.
Documentation review. Actualizar la documentación para reflejar el estado actual del sistema. Identificar gaps.
Roadmap review. Actualizar el roadmap con los hallazgos de la auditoría.

Los monthly checks toman 2-3 horas. La salida es un monthly audit report y un roadmap actualizado.

Incident response

El incident response del lab es:

Detect. El heartbeat, los health checks o el usuario detectan el incidente.
Triage. Identificar el componente afectado y la severidad.
Contain. Detener el componente afectado si es necesario. Prevenir que el incidente se propague.
Mitigate. Aplicar el procedimiento de runbook relevante.
Recover. Verificar que el sistema vuelve a un estado saludable.
Post-mortem. Escribir un documento de post-mortem. Añadir los hallazgos al audit log.

El documento de post-mortem se almacena bajo {workspace-root}/security/incidents/YYYY-MM-DD-{name}.md. El formato es:

# Incident — {name}
 
## Date
{YYYY-MM-DD HH:MM UTC}
 
## Summary
{Un párrafo.}
 
## Detection
{Cómo se detectó el incidente.}
 
## Impact
{Qué se vio afectado.}
 
## Root cause
{Qué causó el incidente.}
 
## Resolution
{Cómo se resolvió el incidente.}
 
## Follow-up actions
{Qué hay que cambiar para prevenir la recurrencia.}

Configuration management

La configuración del lab se gestiona a través de:

Ficheros. Ficheros de configuración en las ubicaciones documentadas en System Architecture → Configuration files.
Herramientas. La gestión de sesión del Coordinator y la validación de config del framework.
Revisiones. Los cambios de configuración los revisa el operator antes de aplicarlos.

El operator es el único que puede cambiar la configuración. El Coordinator surface el change request y el operator lo aprueba.

Backup

El backup del lab es:

Qué se respalda. MEMORY.md, logs diarios, artefactos de skills, notas de proyecto, artefactos de research, audit reports.
Qué NO se respalda. Outputs generados (Media Lab outputs, media descargado), runtime state (session state, cachés in-memory).
Dónde. Disco externo o cloud (elección del usuario).
Cuándo. Diario a medianoche (configurable por el usuario).
Cómo. El script backup.sh en {workspace-root}/ops/cheatsheets/.

La retención del backup es 30 días (configurable por el usuario). Los backups antiguos se borran.

Disaster recovery

El disaster recovery del lab es:

Detect. El usuario detecta el desastre (p. ej., el host se wipea).
Restore. Restaurar del backup más reciente.
Reconfigure. Reinstalar las herramientas, los frameworks, los ficheros de configuración.
Verify. Correr los health checks. Verificar que el sistema vuelve a un estado saludable.
Document. Documentar el desastre y la recuperación en el audit log.

El recovery time objective (RTO) es 4 horas. El recovery point objective (RPO) es 24 horas (el backup diario).

Change management

El change management del lab es:

Plan. El usuario decide hacer un cambio.
Test. El cambio se testea en aislamiento.
Apply. Se aplica el cambio.
Verify. Los health checks pasan.
Document. El cambio se documenta en el daily log.

El cambio se registra en el audit log si afecta al security boundary o al comportamiento de producción.