Antes de empezar
- Una lista de las aplicaciones, programadores y servicios externos en uso.
- Acceso al estado de los trabajos de la aplicación y a logs debidamente anonimizados.
- Un entorno de prueba separado y un destino aprobado para las notificaciones de prueba.
2. Asigna a cada tarea una breve tarjeta operativa.
Use una fila por cada trabajo distinto. Añada la zona horaria, la identidad de ejecución, la duración normal una vez medida, el último resultado útil y el responsable en caso de fallo. No incluya contraseñas, tokens ni cuerpos completos de notificaciones privadas en la ficha.
| Tarea hipotética | Desencadenante | Resultado útil | En caso de fallo |
|---|---|---|---|
| Resumen semanal de la wiki | Programación semanal acordada | Un resumen para los destinatarios previstos | El editor comprueba la lista de destinatarios y la vía de entrega |
| Limpieza de archivos | Programación de mantenimiento de la aplicación | Trabajo temporal elegible eliminado | El mantenedor comprueba los errores de las tareas y el crecimiento del disco |
| Recordatorio del calendario | Recordatorio configurado del evento | Recordatorio esperado para un evento de prueba | El propietario verifica la configuración del evento y el remitente |
| Copia de seguridad independiente | Programación de copia de seguridad acordada | Nuevo punto de recuperación con un resultado registrado | El propietario de la copia de seguridad investiga antes de asumir la cobertura |
Las programaciones anteriores son ejemplos para decidir, no valores predeterminados para copiar en una aplicación. Registre cómo se comporta el trabajo omitido tras un tiempo de inactividad: se omite, se pone al día o se encola para más tarde.
3. Rastrea una notificación más allá de «enviar».
Escriba la ruta desde el evento de la aplicación hasta la cola o el proceso de envío, y luego hasta el servicio de correo y el destinatario previsto. Registre quién controla la cuenta de envío, dónde obtienen las credenciales los mantenedores autorizados y qué límites o informes de fallos proporciona ese servicio. Una selección de recursos de VPS no proporciona por sí sola una configuración de correo saliente funcional.
La documentación de Nextcloud describe explícitamente la conexión a un servidor de correo funcional en lugar de contener un servidor de correo completo propio. Su función de correo de prueba ayuda a verificar una ruta de envío configurada. Configuración de correo electrónico de Nextcloud 33.
BookStack también utiliza el correo electrónico para los flujos de gestión de cuentas y ofrece webhooks salientes para integraciones basadas en eventos. Añada ambos al mapa de dependencias cuando estén habilitados; un remitente roto puede afectar a la recuperación, así como a la comodidad. Correo electrónico y webhooks de BookStack.
4. Decide qué significa la repetición.
Para cada tarea, haga dos preguntas: ¿puede comenzar otra ejecución antes de que finalice esta, y qué sucede si se reintenta después de haber realizado parte de su trabajo? Una actualización del índice de archivos y un mensaje enviado a todos los miembros tienen consecuencias diferentes. Registre la concurrencia y el comportamiento de reintento de la aplicación en lugar de asumir que todas las tareas pueden ejecutarse dos veces de forma segura.
En el resumen semanal hipotético, el propietario mantiene un registro del período de notificación previsto y comprueba si ese período ya produjo un envío completado antes de reintentarlo manualmente. Esa es una comprobación operativa, no una afirmación de que la aplicación elegida implemente la supresión de duplicados. Si no ofrece controles adecuados, elija un procedimiento de recuperación manual más seguro antes de confiar en la tarea.
5. Contén los efectos secundarios durante una restauración.
Una base de datos restaurada puede contener trabajo pendiente o un estado de eventos más antiguo. Antes de iniciar una copia de prueba, impida que contacte con destinatarios reales o sistemas externos. Aísle el entorno de prueba, desactive sus programadores y trabajadores según corresponda, y dirija la salida de prueba explícitamente permitida a un destino controlado. No asuma que un nombre de host diferente cambia los destinatarios almacenados ni las URL de webhook.
Para el ejemplo del taller, la copia de prueba debería permitir a un mantenedor verificar una página y un archivo adjunto sin reenviar el resumen de la semana pasada. Registre qué trabajos permanecen detenidos, cómo inspeccionará el trabajo pendiente y quién puede autorizar una ejecución de prueba limitada. Antes de un cambio real, defina qué instancia posee el trabajo programado para que las copias antigua y nueva no lo realicen ambas.
6. Verifica un resultado pequeño y observable.
Use un evento de prueba inofensivo con una etiqueta reconocible y un único destinatario de prueba aprobado. Registre la hora del disparador, el inicio de la tarea, el resultado de finalización y la recepción real cuando corresponda. Compruebe el contenido y los enlaces, así como la llegada. Una acción correcta de la aplicación no demuestra que todos los destinatarios previstos recibieran un mensaje.
Si no llega nada, inspeccione en orden el disparador, el programador, el error de la tarea y la ruta del remitente. Si llegan duplicados, detenga los reintentos manuales repetidos e identifique qué instancia o trabajo produjo cada intento. Si el trabajo se retrasa, compare la antigüedad de la cola o de las tareas pendientes con el tiempo de ejecución y el uso de recursos. Conserve evidencia concisa sin copiar tokens, cuerpos de mensajes privados ni direcciones innecesarias en notas generales.
7. Asigna la siguiente comprobación.
Elija un intervalo de revisión adecuado a la consecuencia del fallo. Un remitente de recuperación de cuenta fallido requiere una respuesta diferente a la de un resumen semanal tardío. Defina quién comprueba el último resultado correcto cuando falta una alerta, y asegúrese de que el propio canal de alertas no sea la única forma de descubrir un remitente averiado.
Mantenga las tarjetas de tareas con su inventario de servicios. Añádalas a la simulacro de restauración y los rutina de mantenimiento. Esta guía describe una forma de organizar y probar el software que elija; no proporciona un programador gestionado, una garantía de entrega de mensajes ni un resultado de prueba ejecutado.
Documentación detrás de esta nota
Usa la documentación de la versión que realmente ejecutas. Estos ejemplos son material de planificación, no un registro de una prueba en un VPS Hoszen.