Validación — Runbook de operación diaria
Uso interno. No exponer como material para stakeholders.
Estado
- Última actualización: 2026-08-02
- Owner: Desarrollo / documentación
Qué quedó confirmado
- La ventana operativa real es 05:00 a 08:30, derivada de los horarios del scheduler.
- Los logs de cada tarea están declarados en el código:
ecd-sync.log,cenace-process.logyservice-process.log, enstorage/logsde la instancia. - La revisión debe hacerse por instancia de participante; no hay vista agregada.
Preguntas abiertas
| # | Pregunta | Por qué importa |
|---|---|---|
| 1 | ¿Quién ejecuta la revisión diaria y a qué hora? | Hoy no hay responsable asignado. |
| 2 | ¿Dónde se registra el resultado? | Sin registro no hay forma de detectar problemas recurrentes. |
| 3 | ¿Qué se considera "normal" en volumen procesado por etapa? | Sin línea base, "procesó menos de lo esperado" no es verificable. |
| 4 | ¿Existe alguna alerta hoy, aunque sea informal? | Define si la detección es proactiva o reactiva. |
| 5 | ¿Cuál es la ruta de escalamiento y su tiempo de respuesta? | El runbook la asume pero no la define. |
Gaps abiertos
| Gap | Detalle | Quién lo cierra |
|---|---|---|
| Sin tablero | La revisión exige abrir varios logs en varias instancias. | Infraestructura |
| Sin alertamiento | Todo incidente empieza porque alguien notó algo. | Infraestructura |
| Sin línea base | No hay volúmenes esperados por etapa. | Operación |
| Sin bitácora | No queda registro de la revisión diaria. | Operación |
| Idempotencia | Sin ella, "reintentar" es siempre una decisión con riesgo. | Desarrollo |
Riesgos identificados
- El log vacío parece normal. Si el cron cae, no hay errores: no hay nada. Un revisor desprevenido puede interpretarlo como un día sin incidentes.
- Detección tardía. Los problemas de demanda y de ECD se manifiestan en el cierre mensual, semanas después de originarse.
- Ejecución manual dentro de la ventana automática. Riesgo de duplicar procesamiento si alguien interviene entre 05:00 y 08:30.