22. Documentación de operación: monitoreo, respaldos, alertas y tareas frecuentes
22.1 Introducción
Cuando un sistema está en funcionamiento, necesita operación continua: monitoreo, revisión de alertas, respaldos, tareas periódicas, mantenimiento de configuración, análisis de errores y respuesta ante incidentes. La documentación de operación permite realizar estas actividades de forma ordenada y repetible.
Este tipo de documentación suele consultarse en momentos críticos. Si un servicio falla, si una alerta se dispara o si se necesita restaurar datos, el equipo no debería depender de memoria individual. Necesita instrucciones claras, actualizadas y verificables.
En este tema veremos cómo documentar monitoreo, alertas, respaldos, restauración, tareas frecuentes, runbooks, escalamiento y revisión operativa.
22.2 Qué es documentación de operación
La documentación de operación describe cómo mantener un sistema funcionando correctamente después del despliegue. Incluye procedimientos, verificaciones, tareas rutinarias, respuesta ante fallas y criterios de escalamiento.
Su audiencia principal suele ser operación, infraestructura, soporte técnico, administradores y equipos de desarrollo que participan en mantenimiento. El foco está en la disponibilidad, estabilidad, recuperación y observabilidad del sistema.
22.3 Elementos de la operación documentada
La imagen muestra los elementos principales de la documentación de operación: monitoreo, métricas, registros, alertas, respaldos, restauración, tareas frecuentes, runbooks, escalamiento e incidentes.
22.4 Monitoreo
El monitoreo permite observar el estado del sistema. Puede incluir disponibilidad, tiempos de respuesta, uso de CPU, memoria, espacio en disco, errores, tráfico, colas, base de datos, servicios externos y procesos programados.
La documentación debe indicar qué se monitorea, dónde consultar la información, qué valores son normales y qué valores indican riesgo. Sin esta referencia, una métrica puede ser visible pero difícil de interpretar.
22.5 Métricas importantes
No todas las métricas tienen la misma importancia. Conviene documentar las que ayudan a detectar problemas reales: disponibilidad del servicio, latencia, tasa de errores, saturación de recursos, tiempos de consultas, tamaño de colas y fallas de integraciones.
Para cada métrica importante puede indicarse descripción, fuente, frecuencia de actualización, umbrales esperados y acción recomendada cuando supera un límite.
22.6 Registros o logs
Los registros permiten investigar comportamientos, errores e incidentes. La documentación debe indicar dónde se consultan, qué formato tienen, qué niveles existen, cómo buscar por identificador y qué datos no deben registrarse por seguridad.
También conviene documentar correlación entre servicios. Si una operación atraviesa varios componentes, un identificador de trazabilidad permite seguir el recorrido completo.
22.7 Alertas
Las alertas notifican condiciones que requieren atención. Deben documentarse con claridad: qué las dispara, qué significa, qué impacto puede tener, qué revisar y cuándo escalar.
Una alerta mal documentada genera incertidumbre. Una persona puede recibirla y no saber si debe actuar de inmediato, esperar, reiniciar un servicio o contactar a otro equipo.
22.8 Respaldos
Los respaldos protegen información ante fallas, errores humanos, corrupción de datos o incidentes. La documentación debe indicar qué se respalda, con qué frecuencia, dónde se almacena, cuánto tiempo se conserva y quién es responsable.
También debe indicar cómo se verifica que los respaldos son válidos. Un respaldo que nunca se prueba puede fallar cuando se necesita restaurar.
22.9 Restauración
La restauración describe cómo recuperar datos o servicios a partir de respaldos. Debe documentarse paso a paso, incluyendo condiciones previas, riesgos, permisos, tiempo estimado, validación posterior y comunicación necesaria.
Restaurar datos puede tener efectos importantes. Por eso, la guía debe indicar si la restauración afecta información reciente, si requiere detener servicios o si debe realizarse en un ambiente temporal antes de producción.
22.10 Tareas frecuentes
Las tareas frecuentes son actividades operativas que se repiten: revisar procesos programados, rotar registros, renovar certificados, limpiar archivos temporales, validar respaldos, actualizar configuraciones o reiniciar servicios controladamente.
Documentarlas evita que dependan de una sola persona. Para cada tarea conviene indicar frecuencia, responsable, pasos, verificación y riesgos.
22.11 Runbooks
Un runbook es una guía operativa para responder a una situación específica. Puede describir qué hacer si una API no responde, si una cola crece demasiado, si una base de datos se queda sin espacio o si falla una integración externa.
Un buen runbook incluye síntomas, impacto, pasos de diagnóstico, acciones posibles, criterios de escalamiento y verificación de recuperación. Debe estar escrito para usarse bajo presión, por lo que debe ser directo y claro.
22.12 Escalamiento
No todos los problemas pueden resolverse en el primer nivel de operación o soporte. La documentación debe indicar cuándo escalar, a quién, con qué información y por qué canal.
También conviene indicar severidades. Un error menor en una pantalla interna no requiere la misma respuesta que una caída total del sistema o pérdida de datos.
22.13 Tabla de alerta documentada
| Alerta | Significado | Acción inicial | Escalar si |
|---|---|---|---|
| API sin respuesta | El servicio principal no responde al endpoint de salud. | Revisar estado del servicio y registros recientes. | No se recupera en cinco minutos. |
| Errores 5xx elevados | Aumentó la tasa de errores internos. | Consultar registros y cambios recientes. | Afecta operaciones críticas. |
| Cola acumulada | Los mensajes no se procesan al ritmo esperado. | Verificar consumidores y conexión con servicios externos. | La cola sigue creciendo. |
22.14 Documentación de incidentes
Después de un incidente, conviene registrar qué ocurrió, impacto, causa, línea de tiempo, acciones tomadas, recuperación y medidas preventivas. Esta información ayuda a aprender y mejorar la operación.
La documentación de incidentes no debe enfocarse en culpas personales. Debe ayudar a comprender el sistema y mejorar procesos, alertas, pruebas, despliegues o documentación.
22.15 Revisión operativa
La documentación de operación debe revisarse periódicamente. Los sistemas cambian, las métricas evolucionan, aparecen nuevas alertas y algunos procedimientos dejan de ser válidos.
Una revisión puede comprobar que los enlaces funcionan, los responsables siguen vigentes, los pasos son correctos, las alertas tienen acción asociada y los respaldos fueron probados.
22.16 Errores frecuentes
Al documentar operación suelen aparecer estos errores:
- Listar métricas sin explicar cómo interpretarlas.
- Crear alertas sin acciones recomendadas.
- No documentar restauración, solo respaldos.
- Depender de conocimiento informal para tareas frecuentes.
- No indicar responsables ni canales de escalamiento.
- No probar procedimientos operativos antes de necesitarlos.
- No actualizar runbooks después de incidentes reales.
22.17 Qué debes recordar de este tema
- La documentación de operación permite mantener el sistema funcionando y responder ante fallas.
- Debe incluir monitoreo, métricas, registros, alertas, respaldos y restauración.
- Las alertas necesitan significado, acción inicial y criterios de escalamiento.
- Los runbooks ayudan a actuar bajo presión.
- Los respaldos deben probarse mediante restauraciones controladas.
- Los incidentes deben documentarse para mejorar el sistema y los procedimientos.
- La documentación operativa debe revisarse periódicamente.
22.18 Conclusión
La documentación de operación transforma conocimiento operativo en procedimientos claros y repetibles. Permite monitorear, responder, recuperar y mejorar el sistema con menor dependencia de memoria individual.
En el próximo tema estudiaremos guías de solución de problemas e incidentes comunes.